Immer mehr Nutzer greifen auf das Internet zu und benutzen somit massenweise Anwendungen und Protokolle zur Kommunikation zwischen dem Web-Browser und dem Web-Server. Im Zuge der Internetentwicklung ist das Leistungsspektrum von HTTP inzwischen an ein Limit geraten und bildet gerade für die Interprozess-Kommunikation von Anwendungen untereinander allein über das Internet keine ausreichende technische Basis mehr. Durch die begrenzte Anzahl an Ports für die Kommunikation der RPC’s, der verteilten Objektstrukturen und der immer stärker zunehmende Einsatz von Firewalls zum Schutz der eigenen Infrastruktur kommen riesige Probleme auf die Entwickler zu. SOAP (Simple Object Access Protocoll) bietet mit einem inzwischen nicht mehr ganz neuen Kommunikationsprotokoll jedoch eine professionelle Lösung.
SOAP stellt in erster Linie ein spezialisiertes Protokoll für den Datenaustausch von Anwendungen untereinander dar. Die Protokollstruktur basiert auf der Auszeichnungssprache XML (eXtended Markup Language) und ermöglicht somit ein wesentlich flexibleres Nachrichtenhandling als es mit HTTP und den RPC’s als eigenständige Lösungen möglich wäre. Erst die richtige Kombination aus diesen Protokollen ermöglicht eine hocheffiziente und problemlose Kommunikation im Internet in Bezug auf die heute notwendigen technischen Anforderungen. Das Nachrichtenprotokoll SOAP besteht dabei aus drei wesentlichen Säulen, die dieses Messaging erst sinnvoll agieren lassen.
Die Bestandteile von SOAP
Hier steht nun der Begriff »Envelope«, der den Inhalt und die Anwendung einer SOAP-Nachricht übergreifend beschreibt. Auf der anderen Seite verwendet man eine Gruppe an Auszeichnungsregeln, um die verschiedenen Datentypen und Instanzen in einer Nachricht entsprechend zu „verpacken“ und anwenden zu können. Die dritte Form behandelt die Möglichkeiten, RPC’s in eine SOAP-Message einzubetten, um damit die Anfragen und entsprechende Ergebnismeldungen verarbeiten zu können. SOAP kann hier mit einer großen Anzahl an vorhandenen Protokollen umgehen und somit mit diesen kombiniert werden.
Alle Datentypen, die in SOAP verwendet werden können, lehnen sich in erster Linie an die XML-Spezifikation an. Man unterscheidet hier zwischen einfachen und zusammengesetzten Datentypen. Einfache Datentypen wären beispielsweise Integer, Gleitkomma oder Zeichenketten. Als zusammengesetzte Datentypen finden wir hier unter anderem Strukturen und Records oder auch Arrays. Die genauen Deklarationen aller möglichen Datentypen wie einfache Typen, Strings, Aufzählungsobjekte und Arrays finden Sie hierbei in der Spezifikation XML Schemas Teil 2 vom W3C-Konsortium https://www.w3.org/TR/xmlschema-2/ .
Die SOAP-Message im Detail
Im folgenden Quelltextfragment möchten wir Ihnen den grundsätzlichen Aufbau einer SOAP-Message darstellen. Im Quelltext wird eine Anfrage »GetLastTradePrice« an einen entsprechenden Server gesendet, um den aktuellen Handelspreis für ein Produkt zu erfahren. Die Anfrage verwendet dabei einen String, ein Ticker-Symbol und erhält als Antwort einen Float-Wert mit dem eingetragenen Handelspreis zurück. Neben dem „normalen“ HTTP-Header stellt die XML-Notation im HTTP-Body die eigentliche SOAP-Nachricht im Envelope-Element als abgeschlossenen Anfrageblock dar.
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>Als erstes Element dieser XML-Nachricht finden wir die Angabe zu der SOAP-Envelope. Darauf folgt die Angabe des Namespace zu der Envelope, die quasi eine Versionsangabe darstellt. Allerdings wird hier nicht mit Versionsnummern gehandelt, es genügt die Vergabe der Namespace-URI zur Qualifizierung. Die folgende Angabe verweist in gleicher Weise auf die Auszeichnungsregeln, nach der die folgende Botschaft codiert wird. Auch hier wird der Namespace in Form einer URI angegeben und genügt somit der Anforderung.
Daran folgt nun der eigentliche Body-Botschaftsblock, in dem wir die Codierung unserer Preisanfrage finden können. Das Body-Element kapselt nun die eigentliche Nachricht in Form von RPC-Aufrufen oder Fehlerreporten. In unserem Beispiel versenden wir eine RPC an den Server, der uns den gewünschten Handelspreis eintragen und zurücksenden soll. Die abschließenden Tag’s formen den XML-Block folgerichtig zu einer konsistenten und gültigen Einheit.
Eine mögliche Antwort auf unsere Anfrage könnte vom Server wie folgt gestaltet werden und auf dem Client entsprechend angezeigt werden. Wir verweisen auf die einzelnen Elemente der Anfrage, um die Ergebnisse besser deuten zu können.
HTTP/1.1 200 OK
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>Wie an diesem kleinen Beispiel bereits gut zu erkennen ist, verwenden wir also SOAP-Messages, verpackt in einer XML-Hülle (die hier als SOAP-Envelope bezeichnet wird), um diese letztendlich über HTTP versenden zu können. Zu beachten ist an dieser Stelle nur die Angabe des korrekten Medientyps im HTTP-Header. Dieser sollte bei der Integration von SOAP-Messages generell den Wert » text/xml « darstellen.
SOAP-Messages und Firewalls
Die Anwendung von verteilten Objektprotokollen hat sich im Intranet als besonders effektiv dargestellt und wird daher auch entsprechend häufig eingesetzt. Die Übertragung dieser Objektprotokolle auf das freie Internet stellt dagegen eine gewisse Problematik dar. Ein Server, der einmal an das Internet angebunden ist, kann prinzipiell von jedem beliebigen Client aus aktiviert und geöffnet werden. Aus genau diesem Grund werden bei vielen Firmen und Organisationen hocheffektive Firewalls zwischen dem Intranet und der Verbindung zum Internet geschalten, um mögliche Sicherheitsrisiken zu eliminieren. Doch genau diese Firewalls erzeugen unter Verwendung der Interprozess-Kommunikation zwischen Anwendungen im und aus dem Internet massive Probleme.
Unter Verwendung eines TCP/IP-Protokolls verwendet jedes eingesetzte Übertragungsprotokoll eine bestimmte Portnummer für den Zugriff auf die Informationen. HTTP benutzt hier z.B. die Standard-Portnummer 80, FTP hingegen verlangt die Portzuweisung 21. Die Firewalls ermöglichen nun die Abweisung einer Anfrage an einen bestimmten Port unter vordefinierten Voraussetzungen. Der Knackpunkt ist nun das Verhalten von verteilten Objektprotokollen. Diese benutzen in der Regel keine festen Portzuweisungen und können für eine Übertragung einer Anfrage sogar mehrere Ports virtuell belegen, um die gestellten Aufgaben zu lösen. In genau diesem Verhalten scheitert das Objektmodell an dem Einsatz einer Firewall.
Ein primäres Ziel bei der Implementierung von SOAP-Messages war die problemlose Integration in bestehende Strukturen wie HTTP-Protokolle, Proxies, Firewalls und alle weiteren relevanten Aspekte. Dabei kann SOAP das SSL-Protokoll (Secure Socks Layer) als Sicherheitsstruktur, HTTP als Transportprotokoll und SOAP-Envelopes als Botschaftsmedium kombiniert einsetzen. Das Ganze wird dann „einfach“ nur mit einem normalen HTTP-Header ausgezeichnet und versendet. Trifft solch ein Nachrichtenpaket auf eine Firewall, so wird der normalerweise freigegebene Port 80 (für HTTP-Anfragen) genutzt und passiert somit ohne weitere Probleme die Firewall. Zudem beherrscht SOAP auch das Signieren und Verschlüsseln von Elementen, dass wir in einem separaten Artikel SOAP - Signieren und Verschlüsseln detailliert beschreiben.
Fazit
Manchmal sind benötigte Lösungen im Rahmen der Internet-Kommunikation relativ einfach und mit bestehenden Implementierungen wie XML und SOAP zu lösen. Die sinnvolle Kombination aus bereits bestehenden Strukturen und neuen Botschaftsprotokollen, unter Anwendung der XML-Auszeichnungssprache, verdeutlicht das Potential des technologisch möglichen Fortschrittes. Einmal mehr zeigt die flexible SOAP-Implementierung https://www.w3.org/TR/soap12-part1/ , wie effektiv das bereits sehr lange etablierte XML anzuwenden ist. Die bisherige Entwicklung von aus XML abgeleiteten Auszeichnungssprachen ist schon mehr als erstaunlich.
So gibt es beispielsweise auch eine sehr interessante Weiterentwicklung von SOAP um einen Mechanismus, Binärdaten als Anhänge zu SOAP-Nachrichten zu versenden. Eine andere Entwicklung ist DIME (Direct-Internet-Message-Encapsulation), die stark an das bekannte MIME angelehnt ist und spezielle Vorteile für SOAP-Attachments bietet. Auch die RPC’s (Remote-Procedure-Calls) haben einen sehr hohen Stellenwert in SOAP und werden standardmäßig im SOAP-Body modelliert. Neben dem zeitlich moderneren REST hat SOAP nicht nur eine absolute Daseinsberechtigung, es ist in bestimmten Anwendungsfällen sogar REST vorzuziehen.