Möchte man in Netzwerken wie dem Internet miteinander kommunizieren, kann das nur nach festgelegten Regeln funktionieren. Damit die verschiedenen Computer und andere netzwerkfähige Geräte nicht im Chaos versinken, halten diese sich an ein Netzwerkprotokoll. SOAP ist – neben REST – eines der wichtigsten Protokolle im Internet.
Was ist SOAP?
Die Kommunikation im Internet basiert prinzipiell auf Protokollen wie HTTP, HTTPS, FTP oder – auf anderer Ebene – TCP. SOAP ist aber für Webservices wichtig. Hierbei handelt es sich um eine Schnittstelle, über die ein Gerät den Dienst eines Servers in Anspruch nehmen kann. Suchmaschinen, Onlineshopping und viele andere Dienste im Internet laufen über solche Webservices. SOAP ist eines der Protokolle, die das ermöglichen.
Fakt
Ursprünglich hat man den Namen SOAP als Akronym für „Simple Object Access Protocol“ verwendet. Da diese Bezeichnung aber nicht wirklich zu dem Protokoll passt (es ist weder einfach noch greift es nur auf Objekte zu), verwendet man SOAP inzwischen als Namen für sich.
SOAP ist bereits seit den 1990ern im Einsatz, um die Kommunikation zwischen einem Client – zum Beispiel dem Internetbrowser – und Diensten eines Servers zu ermöglichen. Damit das funktionieren kann, muss der Client Anfragen an das API stellen. Wie diese Anfragen auszusehen haben, wird durch das Framework von SOAP geregelt. Innerhalb dieses Regelwerks können allerdings – und das ist ein großer Vorteil von SOAP – applikationsspezifische Daten untergebracht werden. Webservices können so unterschiedliche Anwendungen bereitstellen. Damit diese nicht alle die gleiche Syntax haben müssen, um als Webservice verwendet werden zu können, legt SOAP nur die grundlegenden Regeln fest.
Hinweis
Der Software-Entwickler Dave Winer kreierte SOAP in Zusammenarbeit mit einem Microsoft-Team, um ein funktionstüchtiges Protokoll für das Internet zu schaffen. Dabei wurde großer Wert darauf gelegt, dass SOAP mit W3C-Standards kompatibel ist. Dadurch wurde SOAP selbst zu einer W3C-Empfehlung.
SOAP-Webservices – die Einsatzgebiete des Protokolls
SOAP spielt dann eine Rolle, wenn ein System in einer geordneten und eingeschränkten Art auf ein anderes System zugreifen soll. Statt dem anfragenden Client also kompletten Zugang auf den Server zu geben, kann der Zugriff mit einem Protokoll wie SOAP auf die notwendigen Funktionen beschränkt werden. SOAP bietet mit seiner Architektur zusätzlich den Vorteil, dass sehr unterschiedliche Systeme miteinander kooperieren können: Das Protokoll stellt einen Rahmen zu Verfügung, in den sich die spezifische Applikation eingliedern kann.
Die unterschiedlichsten Webservices basieren auf SOAP. Beispielsweise arbeiten Amazon und eBay (teilweise) mit dem Netzwerkprotokoll.
Der SOAP-Aufbau: Funktionsweise des Protokolls
SOAP basiert auf dem XML-Information-Set. Dieses – ebenfalls eine W3C-Empfehlung – ist eine Sammlung von Informationseinheiten, die für ein wohlgeformtes (also einem empfohlenen Aufbau entsprechendes) XML-Dokument notwendig sind. SOAP greift diese in seiner Nachrichtenstruktur auf und entspricht demnach prinzipiell einem XML-Dokument.
In den meisten Fällen wird SOAP zudem in HTTP eingegliedert. Der Transport funktioniert also über das bekannte Protokoll und wird in dessen Struktur eingebunden. Praktisch sieht eine HTTP-Nachricht mit einer SOAP-Request so aus:
POST /example HTTP/1.1Host: example.orgContent-Type: text/xml; charset=utf-8…<!--?xml version="1.0"?--><soap-env:envelope </soap-env:envelope<>xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">... <soap-env:header></soap-env:header> ... <soap-env:body></soap-env:body> ...In diesem Beispiel beginnt die Anfrage also mit einem HTTP-Header. Dann folgt der sogenannte SOAP-Envelope. Wie ein Briefumschlag umhüllt dieser den eigentlichen Inhalt der Nachricht. Grundlegende Elemente von SOAP sind dann Header und Body.
- Header: Der Kopf der SOAP-Anfrage enthält Metadaten, etwa zur verwendeten Verschlüsselung. Die Verwendung ist optional.
- Body: Im Körper der Nachricht sind die eigentlichen Daten enthalten.
Die im Body genutzten Begrifflichkeiten haben schließlich nichts mit SOAP selbst zu tun, sondern sind vollkommen applikationsabhängig.
Das Protokoll kommt oftmals noch in Kombination mit der Web Services Description Language (WSDL) vor. Dabei handelt es sich um eine Beschreibungssprache speziell für Webservices, die wiederum plattformunabhängig ist. Ein Client kann mithilfe der Sprache erkennen, welche Dienste ein Webservice anbietet. Aus der WSDL-Datei ermittelt der Client, welche Möglichkeiten er für einen SOAP-Request hat. WSDL und SOAP gemeinsam ermöglichen es also, dass zwei unterschiedliche Systeme ohne vorherige Anpassungen miteinander kommunizieren können.
SOAP vs. REST
SOAP und REST (letzteres ist eigentlich eine Architektur und kein Protokoll) werden beide für Webservices verwendet, gehen die Aufgabe aber unterschiedlich an. Während SOAP etwas älter ist, hat REST (bzw. RESTful Webservices) enorm aufgeholt und stellt derzeit ca. 70Prozent der Webservices im Internet zur Verfügung.
Beide haben allerdings unterschiedliche Vorteile: REST gilt beispielsweise als relativ einfach, arbeitet nicht nur mit XML, ist schneller und im Vergleich zu SOAP ein Leichtgewicht. Die Freiheit, die REST in Bezug auf XML hat (man greift hier häufig zu JSON), genießt SOAP bei der Auswahl des Protokolls. Zwar dürfte HTTP die häufigste Wahl sein, aber theoretisch funktioniert SOAP auch in Kombination mit FTP, SMTP oder anderen Protokollen.
SOAP hat zudem einen großen Vorteil in Bezug auf die Sicherheit: In dem Netzwerkprotokoll ist WS-Security (Spezifikationen zu Sicherheitsaspekten bezüglich Webservices) fest verankert. Auch der Umgang mit Fehlern ist in SOAP besser geregelt, denn hier ist eine Funktion zur Anfragewiederholung direkt eingebaut.
Fazit
Sowohl SOAP als auch REST haben Vor- und Nachteile – man kann nicht sagen, dass die eine Lösung generell besser als die andere ist. Zwecks Einfachheit greifen die meisten Entwickler allerdings zu REST. Letztlich hängt die Wahl aber davon ab, welche Programmiersprache man verwendet und in welchem Kontext man das Protokoll nutzen möchte.
