SOAP w 21 wieku

1

SOAP – wsparcie dla WS-Security, SSL

REST – wsparcie dla SSL, utrudnione wprowadzenie mechanizmów WS-Security.

szczególnie ważne dla instytucji finansowych takich jak banki, jak wszystko w IT to zależy do czego...

2

Zaufalem Wam a wzamian oszukaliscie mnie i zdradziliscie.
Jak pytalem o servlety, jsp czy soapy to smialiscie sie mnie, ze jestem archeologiem, krzyczeliscie ze mamy 21 wiek. A teraz sami wychwalacie te rzeczy.

3

Chciałbym zobaczyć komentarz chwalący JSP...

3

@Julian_: kto tu oszukuje i zdradza i wychwala SOAPy?

Chyba nikt (no dobra, mogłem zapomnieć lub przegapić) tutaj nie próbuje

  • zachwalać SOAP jako super wygodną, topową technologię
  • twierdzić że SOAP jest super programmer-friendly
  • zaprzeczać toporności SOAPa

Chyba za bardzo emocjonalnie podchodzisz do tego tematu. Hurr durr SOAP zły bo brzydki, nudny, rozwlekły, to, tamto.... No tak, prawda. Namachasz się łopatą, narzucasz się przy tym XMLami w prawo i lewo. Jakbyś zamiast SOAPa miał użyć czegoś innego, tobyś się użerał z tym innym czymś, wkurzały by Cię inne wady i na co innego byś narzekał że jest gówniane.

Z CORBA byś się użerał, z jakimś RPC byś się użerał, z inszym RMI też byś się użerał. Ba, z super-modern REST API i coś tam jeszcze też byś się użerał, i to, że to coś nie jedzie po SOAP niczego nie zmienia.

Już Ci to mówiłem, zachciało się być programistą, w dodatku Javy, to teraz masz co chciałeś :]

1
systemy napisał(a):

SOAP – wsparcie dla WS-Security, SSL

REST – wsparcie dla SSL, utrudnione wprowadzenie mechanizmów WS-Security.

szczególnie ważne dla instytucji finansowych takich jak banki, jak wszystko w IT to zależy do czego...

Będę wdzięczny, za wyprowadzenie z ewentualnego błędu, ale czy przypadkiem odpowiednikiem dla REST-a WS-Security nie jest JWT?

0
BartoSAS napisał(a):

Będę wdzięczny, za wyprowadzenie z ewentualnego błędu, ale czy przypadkiem odpowiednikiem dla REST-a WS-Security nie jest JWT?

Raczej nie. JWT owszem może posiadać sygnaturę lub być szyfrowany, ale zarówno podpis jak i szyfrowanie dotyczy samej zawartości JWT, a nie danych z żądania. Z drugiej strony nie jestem pewien jak działa WS-Security :]

2
Julian_ napisał(a):

Zaufalem Wam a wzamian oszukaliscie mnie i zdradziliscie.
Jak pytalem o servlety, jsp czy soapy to smialiscie sie mnie, ze jestem archeologiem, krzyczeliscie ze mamy 21 wiek. A teraz sami wychwalacie te rzeczy.

Czuję się jednym z tych "zdrajców", moja wypowiedź zmieniła kierunek, w jakim wątek się przejawia.

Nie czuję się "ewangelizatorem SOAP", ale rzeczywiście czuję się emocjonalnie związany z ideą RPC (wolę type-safe niż inne). Uważam, że zawładniecie umysłami mas pod względem REST (i wyparcie się RPC) można ocenić jako krok wstecz pod pewnymi względami.

urobiłem sobie słowo "nowoczesne RPC", które w mojej definicji musi zawierać koncepcję "co zrobić, aby po obu stronach rury mogły istnieć różne wersje protokołu" *).
Na mojej krótkiej liście jest Google Protobuf (sam w sobie to sophisticated serializer, plus nadbudowa GRPC) i Apache Thrift (od początku projekt RPC).
GRPC testowałem, Thrifta regularnie uprawiam co jakiś czas, gdy jest potrzeba. Umiem wymienić nazwy pokrewnych rozwiązań, wiem, że są takie, o których nawet nie słyszałem.

*) i inne cechy, od wydajności przez środku do debugowania.. Np Thrift może w jednej "rurze" udostępnić więcej niż jeden serwis, ma wymienne "transporty" od preferowanego binarnego po tekstowe

1
Julian_ napisał(a):

Zaufalem Wam a wzamian oszukaliscie mnie i zdradziliscie.
Jak pytalem o servlety, jsp czy soapy to smialiscie sie mnie, ze jestem archeologiem, krzyczeliscie ze mamy 21 wiek. A teraz sami wychwalacie te rzeczy.

Jeden rabin powie tak, a inny powie nie
Najpierw wypowiedzieli się przeciwnicy, a teraz zwolennicy. Ja jednak dołączę do tych pierwszych.

Oprócz oczywistej zalety SOAP że włączasz i działa, oraz tego że czasem trzeba użyć, bo jak trzeba się zintegrować po SOAP to trzeba, to widzę pare mniejszych lub większych wad:

  • XML - Rozwlekły XML nie był zaprojektowany do przesyłania "programistycznych" struktur danych jak tablice (listy), tablice asocjacyjne (mapy, słowniki), zbiory (tablice asocjacyjne z samymi kluczami bez wartości), konstrukcje jeden-z-wielu (w Haskellu nazywa się to koprodukcją, w Ruscie - enumem). Mimo to jest do tego używany i przez to powstały tony dokumentacji jak powinno to być robione. W zasadzie jedyną, trochę lepszą alternatywą jest JSON, ale on też rozwiązuje tylko część problemów. Chociaż IHMO XML jest najmniejszym problemem bo i tak jest generowany i zwykle nie trzeba go pisać. Zostaje tylko mały psikus, nie da się rozróżnić nulla od pustej listy
  • JAXB - była tu już o tym. JAXB pochodzi z czasów gdy w Javie nie doceniano niemutowalności więc JAXB generuje mutowalne DTO. Można przemapowywać na niemutowalne klasy, można próbować zastąpić jacksonem. Tylko treści na ten temat mało bo zwolennicy niemutowalnych danych poszli robić co innego.
  • RPC - Największa zaleta SOAP jest też jego największą wadą i największym kłamstwem. Nie można tak po prostu wywoływać zdalnej metody jakby była lokalna i udawać że wszystko jest w porządku. Sieć istnieje i powoduje opóźnienia, albo i nie istnieje i powoduje timeouty. Ogólnie wszystkie RPC kłamią, że to będzie proste a potem jest zdziwienie architektów i managerów że to nie działa. Że trzeba jednak zrobić asynchroniczny zapis oparty na poleceniach bo obliczenia trwają za długo. Albo trzeba zrobić streamowany odczyt bo brakuje RAMu żeby przerobić to w pamięci. REST w takiej sytuacji kłamie mniej i nie udaje że pod spodem nie ma http ze swoimi wszystkimi problemami

BTW Dalej uważam że Servlety i zwłaszcza JSP to archeologia, ale robiłem to dla pieniędzy

1
Kamil Żabiński napisał(a):

Podpisuje się pod tym wyżej.

Zostaje tylko mały psikus, nie da się rozróżnić nulla od pustej listy

Tego nie rozumiem.
1) najczęściej nie potrzeba tego rozróżnienia - pusta lista by wystarczyła mi (a w prawie wszystkich frameworkach do SOAP nie da się tego łatwo wymusić)
2) XML to raczej nie jest tu problem - można by przecież w XML zrobić

<OBJECT>
  <ELEMENTS/> <!-- lista pusta>
</OBJECT>
<OBJECT>

</OBJECT>

null

Podobnie jak w json. Z punktu widzenia XML to jest rozróżnialne i nawet w DTD/ Schema da sie opisać.
Mogę się mylić - i czegoś nie pamiętać. Nieczęsto robie takie rzeczy ręcznie.

2
Kamil Żabiński napisał(a):
  • XML - Rozwlekły XML nie był zaprojektowany do przesyłania "programistycznych" struktur danych jak tablice (listy), tablice asocjacyjne (mapy, słowniki), zbiory (tablice asocjacyjne z samymi kluczami bez wartości), konstrukcje jeden-z-wielu (w Haskellu nazywa się to koprodukcją, w Ruscie - enumem). Mimo to jest do tego używany i przez to powstały tony dokumentacji jak powinno to być robione. W zasadzie jedyną, trochę lepszą alternatywą jest JSON, ale on też rozwiązuje tylko część problemów. Chociaż IHMO XML jest najmniejszym problemem bo i tak jest generowany i zwykle nie trzeba go pisać. Zostaje tylko mały psikus, nie da się rozróżnić nulla od pustej listy

No wiadomo.

XML był zaprojektowany do tego samego co Markdown, czyli markupowania tekstu (i tam obrazków i tabel). To że ktoś wpadł na pomysł że "jakoś" da się w tym trzymać/przesyłać niektóre struktury danych, i to że zostało to użyte gdzie się da to smutna niezgodność intencji :/

Wystarczy sobie rozwinąć skróty, żeby wiedzieć /(do czego|czym) miały/ być:

  • XML - Extensible Markup Language - ni mniej, ni więcej
  • JSON - JavaScript object notation - j.w.

Dygresja, w REST nie ma nigdzie mowy o tym że wymienia się dane w JSON'ie. Jedyne zalecenie było takie żeby traktować dane jak zasób (czyli jak plik), a to znaczy że można wymieniać dane w dowolnym formacie, jeśli tylko dało się go zserializować do pliku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0