SOAP DIME - Direct Internet Message Encapsulation

Gut gebettet

Von Volkmar Großwendt

Möchte man SOAP-RP-Botschaften über bestimmte Transportprotokolle versenden, so muss man auf DIME als Bindung an das Protokoll zurückgreifen. Wählt man als Transportprotokoll z.B. TCP oder UDP, so wird die eigentliche SOAP-Botschaft in den DIME-Record eingebunden. DIME als Protokollbindung verfügt aber nur über drei Parameter, die den Inhalt gezielt beschreiben. Damit stellt DIME eine einfache, aber leistungsstarke Möglichkeit dar, SOAP-Botschaften in ein bestimmtes Transportprotokoll zu verpacken bzw. an dieses zu binden. Dieser Artikel beleuchtet DIME und seinen Aufbau und baut auf den Artikel SOAP RP aus der letzten Ausgabe des Java Magazins auf.

SOAP – SOAP-RP und DIME

Da DIME mit dem SOAP-RP (SOAP-Routingprotokoll) direkt in Verbindung gebracht werden sollte, möchte ich in aller Kürze die wichtigsten Aspekte von SOAP und SOAP-RP ansprechen. SOAP stellt in erster Linie ein Protokoll für den Datenaustausch von Anwendungen untereinander dar. Die Protokollstruktur basiert auf XML und ermöglicht somit ein flexibleres Nachrichtenhandling als es mit HTTP und den RPCs als eigenständige Lösungen möglich wäre. SOAP besteht dabei aus drei wesentlichen Säulen, die dieses Messaging erst sinnvoll agieren lassen. Zum Einen steht hier der Begriff Envelope, der den Inhalt und die Verwendung einer SOAP-Nachricht beschreibt. Zum Zweiten verwendet man einen Satz an Auszeichnungsregeln, um die unterschiedlichen Datentypen und Instanzen einer Nachricht anwenden zu können und entsprechend zu verpacken. Die dritte Form behandelt die Möglichkeiten, Remote Procedure Calls (RPC) in eine SOAP-Message einzubetten und somit die Anfragen und Ergebnismeldungen verarbeiten zu können. Hierbei kann SOAP mit einer Vielzahl an vorhandenen Protokollen umgehen und somit mit diesen kombiniert werden.
Die Datentypen, die in SOAP angewendet werden können, lehnen sich in erster Linie an die XML-Spezifikation an. Sie finden die detaillierten Deklarationen aller möglichen Datentypen wie einfache Typen, Strings, Aufzählungsobjekte und Arrays in der Spezifikation XML-Schemas, Teil 2 vom W3C-Konsortium.
Da beim klassischen Versenden einer Botschaft von System A zu System X auf direktem Wege das Routing im Internet immer aufwändiger wird, kommt SOAP RP ins Spiel. SOAP RP ist in der Lage, während des Routings mit verschiedenen Protokollen und Transportlayern umgehen zu können. Als Ausgangssystem für eine SOAP-Botschaft wird ein Sender A vorausgesetzt, das Zielsystem beschreiben wir mit Empfänger X. Alle dazwischen liegenden Systeme reichen die Botschaft 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 Transportprotokolles mit dem Botschaftsheader einer SOAP-Message.

Verwendungszweck von DIME

DIME wurde speziell dafür geschaffen, derzeit bestehende Problematiken in verschiedenen Protokollen wie das RMP (record marking protokoll) oder auch des LMP (layered multiplexing protokoll) zu umgehen. Zusätzlich bietet DIME auch die Möglichkeit, sich an verschiedene Transportlayer wie TCP/IP, UDP oder aber auch http anzubinden und somit eine flexible Botschaftsversendung zu ermöglichen. Zudem definiert DIME auch gleich einen zusätzlichen Medientyp, der unter der MIME-Spezifikation als application/dime geführt wird. Die folgenden Ziele wurden dabei klar definiert und erreicht:

  • Unterstützung für verschiedene Datentypen, verschlüsselte Daten, XML-Dokumente
    aller Art, XML-Fragmente und Dateninseln sowie auch Binärdaten für z.B. Bilddateien
    in GIF- oder JPEG-Formaten.
  • Unterstützung für eine Vielzahl von Records, die alle in Zusammenhang mit der eigentlichen Botschaft stehen. Somit könnte eine DIME-Botschaft z.B. ein Textdokument und eine Viezahl dazu gehörender Anlagen wie wiederum Textdokumente, Binär oder Bilddateien transportieren.
  • Unterstützung für Datentypen und Records,
    deren Ausgangsgröße zum Zeitpunkt des Versendens nicht bekannt ist. Dies ist für
    alle Fälle vorgesehen, wo z.B. eine Datenbankabfrage erst nach der Ausführung
    eine bestimme Ergebnismenge oder einen anderen Datenstream zur Verfügung stellt.
    Hier ist die ursprüngliche Datengröße vorerst nicht bekannt.
  • Unterstützung für die Identifikation der zu transportierenden Typen. Der Typ wird hier in einem
    der drei Parameter von DIME definiert und ermöglicht damit einen Rückschluss auf
    die zu transportierenden Daten.
  • Unterstützung für die zu transportierenden Daten über eine so genannte Global Unique ID (GUID). Dieses Verfahren ermöglicht eine
    eindeutige Zuweisung von Objekten und Datentypen, die auch auf der Seite einer
    Anwendung ausgewertet werden kann.

DIME selbst wird nicht als Protokoll bzw. als Transportschicht angesehen. Vielmehr wird eine DIME-Botschaft an ein vorhandenes Transportprotokoll gebunden und verwendet dieses als Layer für die Kommunikation. In Frage kommen hier in erster Linie natürlich TCP, UDP und http. Es sind aber auch andere Transportlayer wie SMTP etc. möglich.
Mit DIME können Sie nun jedweden Anwendungstyp in die Botschaft einbinden, der nach dem MIME-Format message/rfc822 deklariert worden ist. Eine DIME-Botschaft kann dann wiederum in einen DIME-Record eingebettet werden, der mit dem Parameter application/dime definiert worden ist.

Aufbau einer DIME-Botschaft und eines DIME-Records

Ein DIME-Record ist die kleinste Einheit in einer DIME-Botschaft und repräsentiert entweder die Botschaft selbst oder einen bestimmten Datentyp zu einer Botschaft. Es muss mindestens immer ein Record als Botschaft selbst definiert werden. Weitere Records können dann zu dieser Botschaft hinzugefügt werden und erweitern diese dann um bestimmte Datenblöcke, die in direkten Zusammenhang mit der Botschaft stehen. Ich verweise hier nochmals auf das Beispiel mit dem Textdokument, das gleichzeitig eine Menge an Anlagen wie weitere Textdokumente, Binärdateien oder Grafiken mit sich führen kann.
Zuvor noch ein Wort bzw. Schema über den Aufbau der kompletten Botschaft, die aus einem oder mehreren Records bestehen kann und nach den folgenden, in der Abpictureung 1 bezeichneten Schemata, angeordnet ist. Die Records verfügen über keine feste Indizierung bzw. Reihenfolge und müssen demnach in der benötigten Reihenfolge in die Botschaft integriert werden.
Der DIME-Record ist von variabler Länge und setzt sich aus verschiedenen Datenfeldern zusammen. Sehen Sie hierzu bitte die Abpictureung 2, in der Sie den Aufbau eines Records vorfinden werden. Die Funktion und Anwendung der einzelnen Datenfelder werde ich Ihnen dann in der Tabelle 1 näher vorstellen.

Abb. 2: Der Aufbau eines DIME-Records im Detail.

Nun kommen wir zum Aufbau eines Records in DIME. Der Record besitzt in sich eine feste Struktur, die Sie in der Abpictureung 1 sehen können. Beachten Sie an dieser Stelle besonders, das ein Record durchaus binären und ausführbaren Code beinhalten kann, der, wenn auf dem Zielsystem ausgeführt, ohne Weiteres auch Schaden anrichten kann. Man denke hier an Trojaner oder andere Virenprogramme, die hiermit durch jede Firewall, sofern Sie http als Transportprotokoll verwenden, gelangen können. Nun aber zu den Records und deren Aufbau.
In der Tabelle 1 möchte ich Ihnen nun den Aufbau des Records und die Bedeutung der einzelnen Datenfelder aufzeigen. Die Felder haben unterschiedliche Größen, die Sie in der Tabelle ebenfalls finden können.

Geschrieben von
Von Volkmar Großwendt
Kommentare

Schreibe einen Kommentar

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