About SOAP
by Volker Weber
SOAP. Simple Object Access Protocol. Except it's not Simple, it's Complicated. And it's not about Objects, it's about RPC. So, really: CRAP
— Joe Walnes (@joewalnes) March 3, 2014Comments
Welcome to the club. Though a nice refactoring of the acronym... ;-)
SOAP ist eine gute Idee, das an der Nähe zu Java EE leidet. Dort löst man Probleme, indem auf selbige solange Annotationen und XML kippt, bis keiner mehr das Problem sieht. :-)
Der Konsument von Webdiensten hat es heute gern leichtgewichtig und agil, das ist SOAP eher nicht. Dort ist alles formalisiert und bis in die abenteuerlichste Unwägbarkeit.
Übrigens: Wer mal in die Bredouille kommt, im REST- und JSON-lastigen iOS-Umfeld SOAP konsumieren zu müssen, findet unter http://sudzc.com/ einen erstklassigen Code-Generator, der das ganze "Enterprise-Gehampel" konsumierbar macht.
2007 war SOAP das Beste seit Erfindung der nahtlosen Klappstulle - yeah, lose gekoppelte Webservices...
SOAP ist von Anfang 2000 und erbt viele Konzepte von CORBA, welches aus 1991 stammt, also fast 25 Jahre alte Technik.
Weder SOAP und erst recht nicht CORBA sind für schnelle Ad-Hoc Lösungen geeignet, sondern können nur in den grössten Applikationen ihre wenigen Vorteile ausspielen.
Ich würde mich freuen wenn Softwareentwickler sich informieren und das passende Werkzeug für den anstehenden Job wählen, anstatt mit Scheuklappen von einem Trend zum nächsten zu Hopsen.
Richtig - wer alt genug ist, das er die Anfänge von SOAP mitbekommen hat und welche Probleme damit gelöst werden sollten, wird nicht umhin kommen auch heute noch eine Daseinsberechtigung für SOAP zu sehen.
"Simple" bezog sich eben auf CORBA und ähnliches, REST/JSON kamen wesentlich später... (und lieferten wiederum Antworten auf ganz andere Fragen)
Ein API für Web-Services das allen Seiten ermöglicht sich gegenseitig versichern zu können das sie wissen wovon sie reden wird nur begrenzt "performanter" wenn man mehr Hardware darauf schmeißt.
Aber es ist sehr nützlich in einer Umgebung, die sich aus (vielen) verschiedenen "Services" zusammen setzt, insbesondere wenn diese Dienste anbieten die jeder für sich gar nicht so "schmalspurig" und "leichtgewichtig" sind wie man meinen möchte. Und jeder für sich auch noch unterschiedlich schnell weiter entwickelt wird.
Dann sollte allerdings das jeweilige SOAP-basierte API auch mit Sorgfalt und Weitblick entwickelt werden.
In der Praxis passiert das aber oft genug nicht (Lackmus-Test: Versionierung?) oder es wird benutzt "weil es da ist" um damit die sprichwörtlichen Spatzen zu treffen.
Dann passt "CRAP". Für das Ergebnis, nicht für die zugrunde liegende Technik.
Were you at our architecture meeting last week?
If not - that's spooky.
