SOAP-RP: zustandsloses Routingprotokoll für SOAP-Messages

Fährtenleser

Volkmar Großwendt

SOAP (Simple Object Access Protocol) bietet mit einem neuen Kommunikationsprotokoll eine Lösung für eine vereinfachte Kommunikation im Web. Das Protokoll wird als zusätzliche Schicht auf einem Transportlayer wie z.B. TCP, UDP oder HTTP aufgesetzt und bietet dadurch alle Möglichkeiten der systemübergreifenden Kommunikation durch Botschaften. Bislang One-Way-Connection, versucht SOAP-RP diese Begrenzung aufzuheben und bietet nun auch so genannte Reverse-Channels zur Rückmeldung von Ereignissen und Antworten aller Art an den Sender der Botschaft.

In diesem Artikel möchte ich Ihnen nun die Erweiterung RP (Routing-Protokoll) zu SOAP präsentieren. Bei dieser Gelegenheit werden wir auch eine weitere neue Technik mit der Bezeichnung DIME (Direct Internet Message Encapsulation) vorstellen, die als Ergänzung zu SOAP-RP angewendet werden kann. DIME an sich ist ein eigenständiges Verfahren, um zusätzliche Anwendungsdaten über SOAP transportieren zu können. SOAP-RP ist damit nicht auf die Verwendung von DIME angewiesen, weshalb ich DIME in einem separaten Artikel ausführlich behandeln werde.

Das SOAP-Routing-Protokoll

Der Austausch von Botschaften zwischen zwei Systemen benötigt immer eine feste Route, die diese Botschaft gehen sollte. An einem Beispiel demonstriert, sollte eine Botschaft von einem Sender (System A) zu dem eigentlichen Empfänger (System X) auf direktem Weg geleitet werden. Im Zeitalter des ständig wachsenden Internets und damit auch des verstärkten Einsatzes von Web-Anwendungen wird dieses Routing allerdings immer aufwändiger. Aufwendiger aus einem bestimmten Grund, da die Botschaft im Internet wohl niemals den direkten Weg vom Sender zum Empfänger gehen kann. Durch die technischen Gegebenheiten der Web-Infrastruktur muss eine Botschaft über verschiedene Systeme laufen und unter Umständen auch über verschiedene Transportprotokolle abgewickelt werden.
Durch diese Tatsache haben wir es möglicherweise mit einer Vielzahl von Transportprotokollen zu tun, bis unsere Botschaft das eigentliche Zielsystem erreicht hat. SOAP-RP ist aber ohne weiteres in der Lage, während des Routings mit verschiedenen Protokollen und Transportlayern umgehen zu können (Abb. 1). Als Ausgangssystem für eine SOAP-Botschaft wird ein Sender A vorausgesetzt, das Zielsystem beschreiben wir mit Empfänger X. Alle dazwischenliegenden Systeme reichen die Botschaft dann auch nur weiter, da innerhalb der Botschaft bzw. deren Protokoll-Header der Empfänger ja genauestens deklariert ist. Die zwischen dem Sender und dem Empfänger liegenden Systeme nennen wir IS (Intermediary Systems), die sowohl als SOAP-Sender wie auch als SOAP-Empfänger agieren können. Verwechseln Sie hier aber nicht z.B. den http-Header des Transportprotokolls mit dem Botschaftsheader einer SOAP-Message. Den Unterschied werde ich Ihnen nach der Abpictureung 1 auch gleich näher vorstellen.

Abb. 1: Eine SOAP-Botschaft läuft über mehrere Systeme zum Empfänger

SOAP-RP definiert für seine Botschaften zum einen den forward-message-path und auch möglicherweise die Anzahl an Intermediaries, über die diese Botschaft zum ultimativen Empfänger laufen darf. Weiterhin kann eine SOAP-Botschaft an ein bestimmtes Transportprotokoll gebunden sein oder aber unabhängig davon auf verschiedenen Layern laufen. Trifft nun unsere Botschaft auf das Intermediary-System B, so wird es umgehend an den nächsten Empfänger weitergeleitet. Ist an dieser Stelle schon eine Umsetzung von http auf z.B. UDP nötig und die SOAP-Botschaft wurde als unabhängig vom Transportlayer definiert, so nimmt das System B die Umsetzung auf UDP vor.
Wird unsere Botschaft nun vom nächsten System C, das wiederum als Intermediary definiert ist, empfangen, ist eine erneute Weiterleitung nötig, da dieses System noch nicht der eigentliche Botschaftsempfänger ist. Auch an dieser Stelle darf erneut eine Umsetzung auf z.B. TCP/IP erfolgen, falls der Empfänger in einem Intranet vom System C liegt. Der letzte Schritt in unserem Botschaftsmodell liegt nun in der Zustellung der Botschaft an das System X.
Aus technischer Sicht kann man, wie bereits erwähnt, die Anzahl der Zwischenstationen bereits in der Botschaft definieren. Diese Möglichkeit könnte aber sehr schnell zur Einbahnstraße werden, wenn das Zielsystem in einem dynamischen Intranet liegt. Es ist durchaus denkbar, dass sich die Zieladresse durch eine Zwischenschaltung von weiteren Domains oder zusätzlichen Servern in einem Intranet verschiebt. Aus diesem Grund darf jedes Intermediary-System die Botschaft bzw. die Zieladresse in Eigenregie anpassen, damit der ultimative Botschaftsempfänger sicher erreicht werden kann. Aus diesem Grund muss die eigentliche Zieladresse nicht unbedingt beim Senden der Botschaft fest codiert werden, es genügt an dieser Stelle z.B. der Name bzw. die GUID des Zielobjektes. Das Routing kann dann von den Intermediaries übernommen werden.

One-Way oder bidirektional

Bei einer SOAP-RP-Botschaft spielt es generell keine Rolle, ob das genutzte Transportprotokoll eine Einweg- oder bidirektionale Verbindung unterstützt. Bei einer Einwegverbindung (z.B. UDP) wird in der SOAP-Botschaft bereits ein so genannter Reverse-Path definiert, der dann eine Rückmeldung z.B. über ein beim Empfänger aufgetretenes Ereignis zurückliefert. Somit sind sehr einfach Botschaftsmodelle wie Request/Response oder gar Peer-To-Peer-Verbindungen möglich. Dabei kann der Reverse-Path dynamisch von jedem beteiligten System erzeugt und eingebunden werden, das eine entsprechende Rückmeldung absetzen muss (z.B. aufgrund einer Fehlermeldung während des Transports).
Muss nun eine entsprechende Botschaft zum initialen Botschaftssender zurückgesendet werden, so wird der Pfadgenerator von SOAP-RP einfach die Sender/Empfänger-Definitionen umtauschen. Aus dem finalen Empfänger der Botschaft wird nun der neue Sender, aus dem ehemaligen initialen Sender wird nun der finale Empfänger. Auf diese Weise können Botschaften in beiden Richtungen ausgetauscht werden, ohne dass spezielle Techniken wie Channels oder virtuelle Verbindungen erzeugt und angewendet werden müssen. Zudem kann der Pfadgenerator selbst ein geeignetes Transportprotokoll zum Zielsystem auswählen und der Botschaft hinzufügen.

Zugriff auf Zusatzdienste, die der Botschaftssender angefordert hat. Dies können z.B. automatische Benachrichtigungen sein, Collaboration-Services mit anderen Systemen, Privacy-Services für die Botschaftskette oder auch Caching-Services für die Botschaften bzw. speziellen Inhalte.
Bildung von Firewalls auf Anwendungsebene, die als Filterobjekte dienen und nur deklarierte und markierte Botschaften in ein Intranet weiterleiten bzw. über weitere Intermediaries fortführen.
Umsetzung von Transportprotokollen zur Optimierung des Botschaftsweges. Ein Intermediary-System kann die Botschaftskette dynamisch über mehrere Transportprotokolle bedienen.
Dynamisches Routing von Botschaften, da jedes Intermediary-System den Empfänger neu berechnen und erreichen kann.

Beachten Sie in diesem Zusammenhang aber auch, dass SOAP-RP keinerlei Sicherheitsaspekte definiert. Hierzu sollten spezielle SOAP-Protokolle eingesetzt werden, um Anforderungen wie Sicherheitsrichtlinien und Sperrmechanismen implementieren zu können. Dies kann zum einen bereits auf der Ebene der Transportprotokolle basieren, andererseits aber auch von SOAP selbst definiert werden. Sehen Sie zu diesem Thema bitte in die Spezifikationen zu SOAP, die Sie am Ende des Artikels im Linkfenster finden können.
Ein Empfänger einer SOAP-Botschaft kann auch als ein SOAP-Gateway agieren. Weder der Sender noch der ultimative Empfänger werden bemerken, dass die Botschaft von einem solchen Gateway, in der Regel also ein Intermediary-System, verarbeitet bzw. weitergeleitet wurde. Gerade für die Umsetzung des verwendeten Transportprotokolls werden SOAP-Gateways gerne eingesetzt. Die bei einem Intermediary-System eintreffende Botschaft wird von diesem in der Eigenschaft als Gateway z.B. von TCP auf UDP umgesetzt, damit der Botschaftsweg entsprechend optimiert wird. Wie bereits erwähnt, spielt es dabei keine Rolle, ob die Botschaft einen Reverse-Path definiert hat. Der eigentliche Empfänger wird, unabhängig vom verwendeten Protokoll, dann eben einen geeigneten Reverse-Path unter Beachtung eines ebenso geeigneten Transportprotokolls erzeugen. Sehen Sie hierzu die Abpictureung 2, die eine Anwendung eines Gateways zeigt.

Abb. 2: Ein Intermediary-System als SOAP-Gateway

Sie können in dieser Botschaft nun an verschiedenen Elementen erkennen, wie der Botschaftslink funktionieren sollte. Das Element definiert den ultimativen Empfänger der Botschaft. Als Botschaftskette werden über das Element die verschiedenen Intermediary-Systems definiert. Als Reverse-Path wird über das Element der jeweils letzte Intermediary durch eingesetzt. Nun wird noch der Absender per E-Mail definiert und das sendende Objekt per GUID eindeutig identifiziert. Die eigentliche Botschaft steht im Element .
Wird die Botschaft nun vom System B empfangen, so werden einige Elemente entsprechend angepasst, damit die Botschaft auch korrekt weitergeleitet werden kann. In erster Linie werden die folgenden Intermediaries neu definiert und erstmals der Return-Path eingesetzt, damit an dieser Stelle bereits der Rückweg gesichert ist. Der Quelltext wird damit wie folgt angepasst, wobei ich die betroffenen Stellen in Fettschrift hervorhebe (Listing 2).
Der erste Eintrag für das Botschaftsrouting wurde entfernt, da das System B bereits erreicht wurde. Für den Reverse-Path trägt sich das System B nun selbst in das Element mit einer entsprechenden Codierung ein. Damit ist dem nächsten Intermediary der Rückweg bereits bekannt. Der Rest der Botschaft bleibt unverändert und wird auch sofort weitergeleitet. Sehen wir uns nun noch die Situation auf dem System C etwas genauer an, da hier erneut die Botschaft angepasst wird (Listing 3).

Zusammenfassung

Diese sehr einfache Darstellung sollte Ihnen nun den Botschaftsverlauf einmal picturelich und im Quelltext darstellen. Natürlich werden die Botschaften wesentlich aufwändiger ausfallen, je mehr Intermediaries zu durchlaufen sind. Zu guter Letzt kommt natürlich auch noch der Body mit der eigentlichen Botschaft hinzu. Es wird aber sehr schnell deutlich, wie SOAP-RP im praktischen Einsatzfeld funktioniert und verarbeitet wird.

LINKS

Geschrieben von
Volkmar Großwendt
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.