Web-Service-APIs Contest – Teil 2 Entstehung, Aufbau und Funktionsweise von SOAP
Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten
REST und SOAP sind die beiden aktuell wichtigsten Web-Service-APIs. Ob man das fast 20 Jahre alte SOAP oder den Newcomer REST nutzen sollte, hängt von verschiedenen Faktoren ab. Wir starten eine systematische Bestandsaufnahme mit SOAP.
Anbieter zum Thema
Die Anhänger von REST und SOAP liefern sich zum Teil bizarre Glaubenskriege. Dabei haben wie so oft im Leben beide Systeme ihre Vor- und Nachteile. Für welches man sich letztendlich entscheidet, hängt von der verwendeten Programmiersprache, den Eigenschaften des Services an sich und weiteren Rahmenbedingungen ab.
Zunächst die nüchterne Erklärung: Die Abkürzung SOAP stand ursprünglich für „Simple Object Access Protocol“. Allerdings wird sie seit der Version 1.2 aus zweierlei Gründen nicht mehr als offizielles Akronym verwendet: zum einem ist der Gebrauch durchaus nicht „simpel“ und zum anderen dient SOAP eben nicht nur dem Zugriff auf Objekte.
Rein formal handelt es sich bei SOAP um ein Netzwerkprotokoll, mit dem sich einerseits Daten zwischen Systemen im Web austauschen, andererseits aber auch Remote Procedure Calls abwickeln lassen. Konkret dient SOAP dem Austausch von Nachrichten, die auf so genannten XML-Information-Sets (Infoset) basieren, über ein Netzwerk.
Beim Information Set handelt es sich um einen Standard des World Wide Web Consortiums (W3C) vom Status „Recommendation“. Solche Infoset-Spezifikationen werden z. B. als Basis anderer Spezifikationen verwendet, die Aussagen zum formellen Informationsgehalt von XML-Dokumenten machen.
Damit unterstützt SOAP – und das war das primäre Ziel der Entwicklung – auch alle möglichen anderen W3C-Standards wie WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Koordination, WS-AtomicTransaction oder WS-RemotePortlets. Auch SOAP selbst ist heute ein Industriestandard des W3C.
Konkret definiert SOAP die Regeln für das Nachrichtendesign. Solche Policies steuern, wie genau die Daten „in“ der Nachricht abgebildet sind und interpretiert werden müssen. Allerdings gibt SOAP keine Konvention für das Durchführen von Remote Procedure Calls (RPCs) mithilfe von SOAP-Nachrichten vor.
Ebenso macht SOAP keine semantischen Vorschriften für die zu versendenden, applikationsspezifischen Daten. SOAP stellt vielmehr nur das Framework bereit, das es erlaubt, „beliebige“ applikationsspezifische Informationen zu übertragen oder RPC-Aufrufe abzusetzen.
Die Struktur einer SOAP-Message sieht üblicherweise etwa so aus:
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-env" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><SOAP-ENV:Header>
...
...
</SOAP-ENV:Header><SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
...
</SOAP-ENV:Body></SOAP_ENV:Envelope>
Wie ist SOAP entstanden?
Ursprünglich entwickelt wurde SOAP von Dave Wine von UserLand Software (dem Erfinder von RSS 2.0) gemeinsam mit Microsoft – Stand 1998 zunächst in Form einer Spezifikation für XML-RPC. Die Intention von Microsoft zur Entwicklung von SOAP lag ursprünglich darin, eine Ersatz für ältere Technologien zu finden, die im Internet nicht gut funktionieren.
Hier sind beispielsweise das verteilte Komponentenobjektmodell (DCOM) oder die Common Object Request Broker Architecture (CORBA) zu nennen. Beide Technologien sind für Web-basierte Software-Architekturen nicht geeignet, weil sie sich auf binäres Messaging verlassen.
Die Weiterentwicklung der Spezifikation wurde im Jahre 1999 unter der Bezeichnung SOAP in der Version 0.9 veröffentlicht, gefolgt von Version 1.0 am Ende selben Jahren. Erst als sich IBM im Jahr 2000 der Entwicklung anschloss, wurde die Spezifikation SOAP 1.1 von Microsoft, IBM, Microsoft, UserLand Software (Dave Winer) und DevelopMento dem World Wide Web Consortium (W3C) vorgelegt.
Als Etappenziel erreichte man die Gründung einer Arbeitsgruppe, deren Weiterentwicklung von SOAP schließlich in der Version 1.2 im Sommer 2003 vom W3C als Empfehlung anerkannt wurde. Da SOAP seit dieser Version nicht mehr als Akronym für Simple Object Access Protocol steht, konnte SOAP auch in den USA als Markenname eingetragen werden.
Wie arbeitet SOAP?
SOAP verwendet für die Repräsentation der Daten primär XML und setzt auf verschiedene Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der zugrunde liegenden Nachrichten. Dabei sind verschiedene „Kombinationen“ denkbar. Am gängigsten in der Praxis sind allein aufgrund der Kompatibilität SOAP over HTTP oder SOAP over TCP. SOAP lässt sich aber bei Bedarf aber auch über FTP, SMTP oder JMS benutzen.
Eine weitere Besonderheit von SOAP besteht darin, dass die mit der Nachricht übermittelten Nutzdaten nicht zwingend in XML gesendet werden müssen, da SOAP hierzu auch andere Formate wie CSV oder Base64 unterstützt. Selbstverständlich sind auch verschlüsselte Übertragungen von SOAP-Nachrichten möglich.
Eine echte Ende-zu-Ende-Verschlüsselung wird allerdings erst durch Verwendung des oben erwähnten WS-Security-Standards ermöglicht, der nicht auf Nachrichten-Ebene, sondern auf der Ebene des unterliegenden Transportprotokolls aufsetzt. Konkret schickt SOAP dabei das XML Information Set der SOAP-Anfrage bei Verwendung „on HTTP(S)“ im Body eines HTTP-POST-Requests als XML an eine passende URL.
(ID:44607740)
