SOAP w 21 wieku

0

Nienawidze tego.

2

Nie, ale znam system który w 2016 przepisywano do SOAP. Było to w złym, polskim korpo

0

Pisałem ok 2017-2018 i była to próba ustalenia wspólnego mianownika "normalnych" języków z Delphi. Chodziło to logicznie OK, a dżentelmeni nie patrzą na stoper ;)
Po próbach nastąpiła implementacja w Apache Thrift.

4

Tak na poważnie jest masę systemów które tego używają. I jak np masz wielkiego ERP który pracuje na SOAP i potrzebujesz do tego coś dorobić, to nie będziesz tego robił w JsonRPC tylko dlatego ze tak ci wygodniej. Ja wiem, że większość młodych programistów uważa ze systemy starsze niż 10 lat należy zoarać bo są stare. Ale te nowe nie są lepsze i dlatego te stare cały czas działają. Znam kilka firm ze Skandynawii i Beneluksu, które cały czas tego używają i rozwijają systemy na rtym oparte.

0

Integrujemy się z ERP który używa tylko SOAPa wiec nie ma wyjścia

5

@Julian_: już widzę jak matka korporacja wydaje miliony na licencję na jakiś zewnętrzny system, a programiści mówią nie będziemy robili integracji z tym i ch***, bo trzeba do tego uderzać po SOAPie i nie robicie :D

To tak nie działa

1

BTW jakie są główne argumenty przeciw SOAP?

  1. Wydajność?
  2. Brak elastyczności?
    ... pewnie o wielu nie wiem.
4

Nie mam nic do SOAPa, nawet jak ktoś by robił serwis SOAP w tym roku Może bym się zdziwił, ale bardzo mnie to nie boli.
Dramatem są natomiast javowe popularne klienty SOAP oparte o JAXB, niedawno pisałem jakie tam sa fajne kwiatki.
może są jakieś sensowne alternatywy dla JAXB (nie wiem !!!...). Jak juz mam tego SOAPa to zwwykle w dojrzałym projekcie i nie dorzucam tam raczej kolejnyh technologii (płaczę, ale nie dorzucam).
Dramatem jest (w sumie użyteczny) tool SoapUI, w którym 20% czasu poświęca się na wcelowanie myszką w jednopixlową ramkę do skalowania okienka.

4
AnyKtokolwiek napisał(a):

BTW jakie są główne argumenty przeciw SOAP?

  1. Wydajność?
  2. Brak elastyczności?
    ... pewnie o wielu nie wiem.

Dodałbym:

  • Spory koszt wejścia w technologię (to "S" wcale nie jest Simple :-) )
  • Mnogość i złożoność specyfikacji WS-*
6

Czasy nie są dobre dla zwolenników Jsona.

Praktycznie w każdej firmie obecnie jest zasada:

soap.png

2
yarel napisał(a):
AnyKtokolwiek napisał(a):

BTW jakie są główne argumenty przeciw SOAP?

  1. Wydajność?
  2. Brak elastyczności?
    ... pewnie o wielu nie wiem.

Dodałbym:

  • Spory koszt wejścia w technologię (to "S" wcale nie jest Simple :-) )
  • Mnogość i złożoność specyfikacji WS-*

A propos 21 wieku, wygenerowałem swojego WSDL razem z serwisem przez atrybuty C#, skonsumowałem go klikając, jak blondynka. Jedyna chwila myślenia, to znaleźć w deko wielkim kodzie punkt wejścia. Absolutna kompatybilność NAWET w Delphi (zarówno w starym 8bitowym, jak i w nowszym unikodowym, a to jest wielki ból tego środowiska).
Jednak 21 wieczne biblioteki/narzędzia do stabilnego, uznanego standardu to nie jest samo zuo. Tagi XML-owe o tyle widziałem, w oknie konsoli, jak się przewalały. Nie było ich więcej niż dobry stacktrace Springa.
Wiem, że mój przykład nie dla każdej sytuacji jest adekwatny.

0

Żebym ja w pracy posmakował kiedykolwiek REST'a. Podejście u nas jest takie, że SOAP jest bezpieczny i stabilny, a REST nie. Ba! Dostaliśmy nawet generyczne wsdle, które przyjmują any, a w Javce sobie zunmarshalluj XML'a do odpowiedniej klasy. Oczywiście wszelakie .xsd lecimy z palca. Czy to jest szybsze rozwiązanie i łatwiej się w to wdrożyć gdy dokumentacja zmienia się co krok? Nie sądzę.

0

Dramatem są natomiast javowe popularne klienty SOAP oparte o JAXB, niedawno pisałem jakie tam sa fajne kwiatki.

No to prawda :(
Getter zwracający nową (mutowalną) liste to jakaś tragedia okrutna

6

Mnie trochę śmieszy takie wyśmiewanie "starej" technologii, kiedy cały czas powstaja jej nowsze klony :D Bo niby SOAP zły, ale jednocześnie mamy takie cuda jak json-schema czy GraphQL które garściami czerpią z SOAPa właśnie i jednocześnie ludzie się tym podniecają bo takie fajne, ma typesystem i w ogóle.

Ja osobiście uważam ze z SOAPem jest tylko taki problem, że jest dość toporny i czasem trudny w użyciu. Zresztą podobnie jak jego binarne poprzedniki w stylu CORBA. Sama idea typowanych remote calli nie jest wcale zła, wręcz przeciwnie.

0

Ale to Wy jakoś ręcznie te SOAPy piszecie? Wygenerować się nie da?

2

Tak piszę projekt w tym goooownie bo to jedyny interfejs jakim możemy gadać z systemem, z którym współpracujemy a żeby nie było, to po ich stronie wcale nie jest jakaś stara wersja tylko rozwiązanie z zeszłego roku. No cóż mamy wciąż na świecie dinozaury i tyle ...
Ale też nie jestem jakimś strasznym wrogiem tej technologii bo @Shalom ma dużo racji. Jednak przy tym co robimy aż prosi się o Resty z JSON`em.

2

Minusem SOAPa nie jest tyle sam SOAP, co fakt że dokumentacja do jego zawartości często nie istnieje lub jest szczątkowa. REST nie jest idealny, ale dobrze zaimplementowany pozwala człowiekowi się domyśleć co i jak (np. /articles robi za GET i POST, a nie cuda na kiju + masz HATEOAS). W pracy mamy i zabawę z XMLem i JSONem (ja tego RESTem nie nazwę, bo kłamać nie będę) i formaty formatami, ale zawsze kluczem jest dokumentacja i kontakt z człowiekiem po drugiej stronie endpointu. Jak jedno i drugie leży i kwiczy to nic nie pomoże ;)

11

@Pipes: weź nie żartuj :D W SOAPie przynajmniej jest WSDL i wiadomo jakie rzeczy możesz zawołać, z jakimi parametrami i czego się spodziewać. W REST jak nie masz Swaggera albo dokumentacji albo libki z klientem to jajo możesz znieść a nie się domyśleć co i jak. Jak ci nie powiem jakie parametry taki REST endpoint przyjmuje to możesz sobie z kuli wróżyć najwyżej ;) Tak samo jak nie masz listy endpointów.

1

@Shalom: Sęk w tym, że z tymi endpointami, którymi się muszę łączyć, 90% stron WSDL nie działa, same endpointy zaś śmigają bez zarzutu. Potem soapCall jakiś następuje, o którym nie mam pojęcia. W przypadku RESTa testowanie samemu tego czegoś (choćby i brute forcem) jest dużo łatwiejsze. Przynajmniej w branży, w której siedzę, dostrzegam prawidłowość, że przy RESTowych (lub RESTopodobnych) endpointach dokumentacja jest dużo lepsza (i nie zwraca "ERR_EMPTY_RESPONSE") :) Wybacz, że mój pogląd jest tak subiektywny ;)

0

Niechęć do SOAP IMHO wynika z tego że jest to nudne, smutne rozwiązanie korporacyjne które ładnie wygląda na diagramach u analityków. działa i nie ma przy pracy z nim fajerwerków. SOAP nie wpisuje się w modę na elastyczne, zwinne, rozproszone, nowoczesne technologie.

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