Web-Service-APIs Contest – Teil 2 Entstehung, Aufbau und Funktionsweise von SOAP

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.

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:

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.

Web-Service-API Contest – Teil 1

Web-Dienste und Service-orientierte Architektur

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.

Wofür wird SOAP eingesetzt?

SOAP wird in der Praxis meist dann verwendet, wenn ein direkter Zugang „fremder“ Systeme zu einer Informationsquelle nicht gewünscht oder möglich erscheint, etwa weil es zwischen der Architektur von Quell- und Zielanwendung große Kompatibilitätsbarrieren gibt. Aber auch Sicherheitsaspekte sind ursächlich für den Einsatz von SOAP.

Soll z. B. eine komplexe Multi-Tier-Web-Anwendung nur einen partiellen Zugriff auf eine Datenbank-Tabelle erhalten, so muss dank SOAP nicht dem kompletten Anwenderprogramm ein direkter Zugang auf die Tabelle oder gar die ganze Datenbank gestattet werden. SOAP erlaubt es, die Anzahl der ausführbaren Methoden zu definieren bzw. zu reglementieren. Damit zielt der Einsatz von SOAP – ebenso wie der von REST – auf die sogenannte „lose Kopplung“ von Systemen.

Vor und Nachteile von SOAP

SOAP ist zwar sehr komplex, allerdings verwenden Entwickler in der Regel nur jene Teile/Aspekte, die sie zur Lösung einer bestimmten Aufgabe benötigen. Zur Implementation eines öffentlichen Web-Dienstes, der frei für jedermann verfügbar ist, muss man sich beispielsweise nicht mit WS-Security auseinandersetzen.

Auf der anderen Seite kann der XML-Code zur Formulierung von Anfragen und das Erhalten von Antworten in SOAP extrem komplex werden. Je nach verwendeter Programmiersprache müssen solche Anfragen manuell erstellt werden. Das ist wiederum nicht unproblematisch, weil SOAP nicht sonderlich fehlertolerant ist.

Für ausgewählte Sprachen stellt SOAP allerdings Verknüpfungen (z. B. zu WDSL) bereit, was wiederum den Aufwand zum Erstellen einer Anfrage und Analysieren der Antwort reduziert. Bei .NET-Sprachen beispielsweise kommt man mit XML quasi nicht in Berührung.

Einen großen Anteil an dieser „Magie“ hat die Web Services Description Language (WSDL). Hierbei handelt es sich um eine plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Netzwerkdienste (Webservices) zum Austausch von Nachrichten auf XML-Basis.

Auch die Meta-Sprache WSDL ist ein Industriestandard des W3C. Eine WDSL-Datei beschreibt in SOAP die Schnittstellen von Web-Services, also wie der Dienst funktioniert und wie Nachrichtenstrom-Formate sowie Funktionsaufrufe definiert sind.

Web-Service-APIs Contest – Teil 3

Konzept, Aufbau und Funktionsweise von REST

Eine solche WDSL-Datei lässt sich z. B. automatisch aus Java-Source-Dateien erzeugen. Erstellt man also in der eigenen IDE einen Verweis auf die WDSL-Datei, kann die IDE den Prozess der Generierung des XMLs quasi vollständig automatisieren. Faktisch hängt also der Schwierigkeitsgrad bei der Verwendung von SOAP in hohem Maße von der verwendeten Sprache ab.

Im Prinzip ist die Handhabung von SOAP ohne WDSL gar nicht praktikabel. So hat Microsoft beispielsweise erst im Oktober 2016 eine Möglichkeit für Azure-Kunden geschaffen, dass diese über das Azure-API-Management eine Art Proxy für ihre SOAP-APIs erstellen können, ähnlich wie das bereits für REST-APIs möglich war.

Das funktioniert allerdings nicht ohne WDSL-File, weil das Erstellen von SOAP-Services „from scratch“ im Vergleich zu REST viel zu komplex ist. Matt Farmer hat dazu ein sehenswertes Video im MSDN-Blog von Microsoft veröffentlicht.

Bereits erwähnt wurde die Flexibilität von SOAP bei der Auswahl des Transport-Protokolls. Zwar kommt HTTP/S am häufigsten zum Einsatz, es gibt aber in der Tat auch Spezifikationen für die Verwendung von SMTP oder FTP. Python- und PHP-Entwickler machen durchaus auch Gebrauch davon.

Fehlerbehandlung

Ferner gehört die integrierte Fehlerbehandlung sicher zu den Vorzügen von SOAP. Gibt es beispielsweise ein Problem mit eine Anfrage, finden sich in der Antwort brauchbare Fehlerinformationen, die zur Behebung des Problems verwendet werden können.

Angesichts der Tatsache, dass man ja nicht der Eigentümer, bzw. Ersteller des angefragten Web-Services ist, ist dies eine äußerst wichtige Hilfestellung. Die Fehlerberichterstattung liefert sogar standardisierte Codes, so dass es möglich ist, einige Fehlerbehandlungsaufgaben im eigenen Code zu automatisieren.

Die SOAP-Kommunikation

SOAP ermöglicht den Aufbau „schwach“ gekoppelter Systeme. Diesen Vorteil in der Flexibilität erkauft man sich allerdings mit Nachteilen beim Übertragungsvolumen und im Rechenaufwand, weil das XML-Dokument zunächst beim Sender aufgebaut und danach validiert werden muss.

Ein weiteres Manko ist, dass die zu übertragende Datei im Verlauf der Konstruktion des XML-Dokuments mit einer ganzen Reihe von Metadaten angereichert wird. So führt das einfache Versenden einer True/False-Information in einem schwach gekoppelten System zu einem extrem hohen Datenvolumen, wozu bei einem stark gekoppelten oder monolithischen System ein Bit ausreichen würde.

Das andere Extrem: der flexible Aufbau des Dokuments erlaubt es, auch sehr komplexe Transaktionen in einer einzigen Anfrage zu formulieren, wozu bei stark gekoppelten Systemen meist mehrere Anfragen gestellt werden müssen. Somit verbessert sich bei komplexen Transaktionen das Verhältnis von Nutzdaten zu Metadaten erheblich, während der Kommunikationsaufwand für den Aufbau einer Verbindung gleich bleibt.

Übrigens unterscheidet SOAP zwischen endgültigem Empfänger und Zwischenstationen. So lassen sich Nachrichten über verschiedene „Hops“ versenden, sogar wenn dabei verschiedene Transportprotokolle zum Einsatz kommen; im Gegensatz zur Middleware benötigt der Absender dabei keinerlei Information zu den Zwischenstationen.

Neben dem erwähnte Message-Style (oder Document-Style) unterstützt SOAP auch einen an RPC angelehnten Communication-Style. Ein Codebeispiel für einen Document-Style-SOAP-Body könnte etwa so ausehen:

Web-Service-APIs Contest – Teil 4

Anwendungsbeispiele mit REST

(ID:44607740)