Grundlegendes zu DIME und WS-Attachments

Veröffentlicht: 16. Jan 2003 | Aktualisiert: 23. Jun 2004

Von Matt Powell

In diesem Artikel werden die Grundlagen für Anlagen beschrieben, einschließlich der Grundkonzepte, die dem Verpacken und der Abgrenzung von Nachrichten zugrunde liegen. Anschließend wird beleuchtet, wie DIME und WS-Attachments aus diesen Konzepten erwachsen sind.

Auf dieser Seite

 Einführung
 SOAP-Nachrichten und Anlagen
 DIME und MIME
 Schlussfolgerung

Einführung

XML ist großartig. Diese Sprache hat einen Industriestandard für die Darstellung von Daten, das Ausdrücken von Datenbeziehungen und die Interaktion mit Daten geschaffen, der so universell anerkannt wird, dass inzwischen jede Computerplattform XML-Unterstützung bietet. Diese universelle Akzeptanz von XML ist einer der Schlüsselfaktoren für die Akzeptanz von SOAP und Web Services, da sie die Interoperabilität zu etwas sehr Realem macht. Trotz der Leistungsstärke von XML gibt es im weit gefassten Bereich des Anwendungsdesigns eine Vielzahl von Szenarios, in denen es wesentlich mehr Sinn machen würde, Nicht-XML-Daten an einen Web Service zu senden. So wäre es z.B. sinnvoll, binäre Daten (z.B. ein JPEG-Bild) zusammen mit einer SOAP-Nachricht zu senden. Oder Daten einfach zusammenzupacken. Beispielsweise könnte eine SOAP-Nachricht eine andere SOAP-Nachricht enthalten, wie dies häufig bei E-Mail-Nachrichten der Fall ist, an die andere E-Mail-Nachrichten angehängt sind. Die DIME-Spezifikation (Direct Internet Message Encapsulation) bietet einen Mechanismus für das Zusammenpacken von Daten. WS-Attachments (in Englisch) definiert, wie DIME verwendet werden kann, um Anlagen zu SOAP-Nachrichten hinzuzufügen, und wie Sie aus dem DIME-Paket heraus auf diese Anlagen verweisen.

SOAP-Nachrichten und Anlagen

Bevor E-Mails allgegenwärtig wurden, wurden in der Geschäftswelt Memos bevorzugt eingesetzt. Memos waren angesichts des Variationspotenzials dieses Mediums relativ stark strukturiert. Sie besaßen eine abgegrenzte Kopfzeile mit Feldern für An, Von und Betreff, einen Nachrichtentext sowie eine Fußzeile, die unter anderem Platz für die Auflistung von Anlagen bot. Anlagen waren zusätzliche Informationen, die aus einer Reihe von Gründen nicht unbedingt in den Nachrichtentext der Memo aufgenommen werden sollten. Dabei konnte es sich um von einem anderen Autor erstellte Berichte handeln, z.B. eine Fotokopie einer Rechnung, ein anderes Dokument, oder sogar um ein anderes Memo, das mit dem ersten Memo in Zusammenhang stand. Der Grund für die Bezeichnung "Anhang" bzw. "Anlage" bestand darin, dass sie ursprünglich mit Hilfe einer Büroklammer, Heftklammer oder Ähnlichem am Originalmemo befestigt waren.

Das Interessante an Memos mit Anlagen ist die Liste der angehängten Dokumente im Originalmemo. Wenn sie an das Originalmemo angehängt sind, wieso enthält dieses dann zusätzlich eine Liste? Kann der Leser nicht einfach die Seiten durchblättern und selbst sehen, was an das Memo angehängt ist? Eine der Antworten auf diese Frage ist: "Nicht, wenn sie fehlen." Eine Seite kann leicht beim Transport oder beim manuellen Sortieren der Zettel im Kopierraum verloren gehen. Der Leser würde dann bei Erhalt des Dokuments merken, dass etwas fehlt. Ein Mechanismus, um das Problem fehlender Anlagen zu vermeiden, besteht darin, das Memo zusammen mit den Anlagen in eine Mappe oder einen Umschlag zu legen. Die zusätzliche Verpackung der gesamten Informationen bietet ein zusätzliches Maß an Sicherheit dafür, dass alle Bestandteile zusammen beim Empfänger ankommen. Der Empfänger weiß darüber hinaus, wenn in dem Memo auf einen Bericht verwiesen wird und der Umschlag eine beigefügte Kopie des Berichts enthält, dass die genannte Berichtversion mit dem Memo beigefügten Bericht identisch ist. Wenn zwar auf den Bericht verwiesen wurde, dieser jedoch nicht dem Memo beigefügt war, stellt sich natürlich die Frage, wo der Bericht abgeblieben ist. Wurde er gefunden musste geklärt werden, ob er mit der im Memo genannten Berichtsversion identisch ist.

Im Zeitalter der Web Services besteht nach wie vor die Notwendigkeit, einer Nachricht zusätzliche Informationen beizufügen. Bei SOAP-Nachrichten gibt es mehrere Gründe, wieso das Beifügen von zusätzlichen Informationen wünschenswert ist. Zunächst einmal ist ein Szenario vorstellbar, in dem wir auf eine andere SOAP-Nachricht verweisen müssen, genauso wie ein Memo auf ein anderes Memo verweisen kann. Anders als die Druckversionen von Papiermemos können digitale Daten in einem universell anerkannten Format wie XML in erweiterbare XML-Dokumente eingefügt werden. Es sind jedoch Situationen denkbar, in denen wir die zusätzlichen Daten nicht in die Original-SOAP-Nachricht einfügen möchten. Beispielsweise wenn das Format der zusätzlichen Daten eine ineffiziente oder platzraubende Konvertierung in XML bedeutet (z.B. bei Mediendateien) oder auch wenn die XML-Daten so codiert sind, dass sie neu codiert werden müssten, um in das übergeordnete Dokument eingefügt werden zu können. Das Anhängen von zusätzlichen Informationen an eine SOAP-Nachricht kann daher weiterhin sinnvoll sein.

Darüber hinaus ist es wichtig, ein Memo und seine Anlagen auch bei SOAP-Nachrichten zusammen verpacken zu können, da auch hier die Möglichkeit besteht, dass ein Teil der Informationen unterwegs verloren geht oder verändert wird. Eine SOAP-Nachricht könnte beispielsweise einen Verweis auf ein XML-Dokument in Form eines URL enthalten, doch das XML-Dokument wird zwischen dem Verfassen der SOAP-Nachricht und ihrem Eingang beim Empfänger geändert. Die Möglichkeit, das XML-Dokument zusammen mit der SOAP-Nachricht zu verpacken, ist eine wichtige Funktion, die Bestandteil jeder Anlagenarchitektur sein muss.

DIME: Verpacken von SOAP-Nachrichten mit Anlagen

Es gibt eine Reihe von Möglichkeiten, eine SOAP-Nachricht und ihre Anlagen zu verpacken. In der Streamingwelt des Internets ist es wichtig, dass unser Verpackungssystem einen Mechanismus für das Übergeben der unterschiedlichen Bestandteile in einem einzigen Stream bietet. Dies ermöglicht das Übergeben der Pakete über die derzeit gängigen Protokolle, wie TCP, HTTP und SMTP. Das bedeutet jedoch unweigerlich, dass eine Verpackungslösung zwischen dem Ende eines Paketteils und dem Beginn des nächsten klar unterschieden werden muss und einen Mechanismus benötigt, der anzeigt, dass ein Paket vollständig ist.

Für eine Anwendung, die ein Paket in einen Stream schreibt, wäre ein zusätzliches Feature äußerst nützlich. Für große Datenmengen bietet es sich an, kleinere Datenmengen an das Paket streamen zu können, um nicht alle Daten gleichzeitig im Arbeitsspeicher aufbewahren zu müssen. Dieses Konzept wird als "Chunking" bzw. "Abschnittsbildung" bezeichnet. Dem Empfänger eines Streamingpakets bietet das Chunking ähnliche Speicherplatzvorteile.

Ein weiterer Vorteil für Anwendungen, die Streamingpakete verarbeiten, ist die Möglichkeit, jeden im Paket enthaltenen Bestandteil zu identifizieren. In der Welt der Papiermemos erfolgte dies in der Regel durch einen Verweis auf den Autor des angefügten Dokuments. Leider konnte sich dies gelegentlich als problematisch erweisen, da möglicherweise zwei Anlagen von demselben Autor im Umlauf waren. Natürlich kann dieses Problem gelöst werden, indem sowohl das Datum als auch der Autor oder bei Bedarf sogar der Betreff angegeben werden. Doch was machen Sie z.B. mit einem Foto, das nicht die ganzen nützlichen Headerinformationen enthält, die Memos bieten? Anwendungen für Streamingpakete benötigen einen definitiven Mechanismus für das Identifizieren aller Bestandteile eines Pakets. Außerdem wäre es schön, wenn wir identifizieren könnten, welche Art von Daten jeder Paketteil enthält.

All diese Features eines Paketmechanismus sind grundlegende Funktionen für Anwendungen, die SOAP-Nachrichten mit Anlagen verarbeiten. Die DIME-Spezifikation (Direct Internet Message Encapsulation) behandelt diese Aspekte auf minimale und effiziente Weise.

Das DIME-Paket

DIME ist ein Paketmechanismus, der es ermöglicht, mehrere Datensätze mit willkürlich formatierten Daten zusammen zu streamen. Die Datensätze werden nacheinander in den Stream serialisiert und durch einen effizienten binären Header abgegrenzt. Im ersten Datensatz in einer DIME-Nachricht ist das MB-Flag (Message Begin) im Header gesetzt und im letzten Datensatz ist das ME-Flag (Message End) gesetzt. Der Header enthält zudem einen Abschnitt fester Länge, der eine einfache Berechnung der absoluten Länge des Datensatzes ermöglicht. Die effiziente Ermittlung von Datensatzlängen ist wichtig, damit in einem Datenstream schnell von einem Datensatz zum nächsten gewechselt werden kann.

Für große Datensätze oder Datensätze, deren Datengröße anfänglich nicht bekannt ist, hat DIME einen "Datensatzchunk" definiert. DIME verwendet Datensatzchunks, um die Aufteilung eines einzelnen Datensatzes in mehrere Teile zu unterstützen.

Jeder Datensatzchunk besitzt, wie normale Datensätze, einen Header und eine Nutzlast. Ein Datensatzchunk setzt jedoch das CF-Flag (Chunk Flag) im Header. Dies zeigt an, dass die Daten Bestandteil eines Chunkdatensatzes sind und weitere Daten für diesen Datensatz folgen. Die Daten für den Chunkdatensatz werden seriell aus den folgenden Datensatzchunks gelesen, bis der letzte Datensatzchunk ermittelt wird. In diesem ist das CF-Flag nicht mehr gesetzt. Abbildung 1 veranschaulicht eine DIME-Nachricht mit fünf Datensätzen. Die letzten drei Datensätze sind Datensatzchunks, die zusammen einen einzelnen Chunkdatensatz bilden.

Abbildung 1. Eine DIME-Nachricht, die Datensatzchunks enthält.

Neben Informationen zur Datensatzlänge und einigen Flags enthält der DIME-Datensatzheader die verwendete DIME-Version, Typinformationen über die Daten in der Nutzlast des Datensatzes, eine ID für die eindeutige Kennzeichnung jedes Datensatzes und Unterstützung für das Hinzufügen von optionalen Informationen, die mit einem bestimmten Datensatz übertragen werden können. Der Typ, die ID, die optionalen Daten und die Nutzlast für einen Datensatz können unterschiedliche Längen aufweisen. Daher beginnt der Datensatzheader mit einem Abschnitt fester Länge, der die Version, die Flags und die Längen der vier Bereiche variabler Länge im Datensatz enthält. Sobald wir die Position des Anfangs eines Datensatzes kennen, ist das Finden des Anfangs des nächsten Datensatzes genauso einfach wie das Hinzufügen der Länge des festen Abschnitts im Header (12 Byte) zu den Längen der optionalen Daten, der ID, des Typs und der Datenabschnitte, die allesamt aus festen Positionen im Header gezogen werden.

Abbildung 2. Das DIME-Datensatzformat

Einer der Vorteile von DIME besteht darin, dass für den Inhalt eines DIME-Datensatzes keinerlei Einschränkungen gelten. Tatsächlich kann die Nutzlast eines DIME-Datensatzes eine andere DIME-Nachricht enthalten. Der enthaltene Datensatz muss als Datensatztyp einfach Folgendes anzeigen: "application/dime".

Weitere Informationen zum Format von DIME-Nachrichten finden Sie im Artikel von Jeanine Hall Gailey, "An Introduction to DIME", in der Dezember 2002-Ausgabe des MSDN Magazine (in Englisch).

WS-Attachments: Definition der Verwendung von DIME für das Senden einer SOAP-Nachricht mit Anlagen

DIME ist einfach ein Mechanismus für das Verpacken einer Sammlung von willkürlich formatierten Datensätzen. Es werden keine Anforderungen für den Inhalt von Datensatznutzlasten, den Inhalt der ID-Felder oder die Art der Verkapselung einer SOAP-Nachricht in einer DIME-Nachricht festgelegt. WS-Attachments definiert auf der Grundlage der Konzepte, die wir weiter oben in Bezug auf Memos mit beigefügten Dokumenten erörtert haben, wie viele Dokumente kombiniert werden können und wie sie aufeinander verweisen. Des Weiteren wird definiert, wie DIME-Verpackung eingesetzt werden kann, um die Anlagenfunktionalität für Web Services bereitzustellen.

Das Wichtigste beim Definieren eines Anlagenmechanismus für SOAP-Nachrichten ist die Möglichkeit, identifizieren zu können. Das heißt, die Definition einer SOAP-Nachricht und einer Anlage. Wenn Sie einen Stapel Papiermemos erhalten, der mit einer Büroklammer zusammengehalten wird, ist sofort klar, welche Nachricht das Hauptmemo ist: Das Hauptmemo ist die erste Nachricht oben im Stapel. Das Hauptmemo die Nachricht, auf der unten die Anlagen aufgelistet sind. Bei SOAP-Nachrichten mit Anlagen werden wir die Hauptnachricht als "Primären Teil der SOAP-Nachricht" bezeichnen. Alle beigefügten Artikel werden als "Sekundäre Teile" bezeichnet. WS-Attachments legt fest, dass der primäre Teil der SOAP-Nachricht im ersten Datensatz einer DIME-Nachricht enthalten sein muss. Dies erinnert daran, dass sich das Hauptmemo stets ganz oben im Stapel befindet.

Der nächste Aspekt, den es zu berücksichtigen gilt, ist die Möglichkeit, aus dem primären Teil der SOAP-Nachricht heraus auf die Anlagen zu verweisen. Genauso wie ein Memo auf die beigefügten Dokumente verweist, muss eine SOAP-Nachricht auf die angehängten Anlagen verweisen können. WS-Attachments definiert die Verwendung des href-Attributs für einen solchen Verweis. Das href-Attribut ist ein URI, der bei Bedarf verwendet werden kann, um auf einen HTTP-URL zu zeigen. WS-Attachments definiert jedoch auch die Möglichkeit, über das ID-Feld des DIME-Datensatzheaders auf einen bestimmten DIME-Datensatz zu verweisen. Wenn ein sekundärer Teil einer DIME-Nachricht folgende ID hat:

uuid:6FF57C24-74A1-426f-92D9-98861E105B4F

kann der primäre Teil der SOAP-Nachricht, der auf diese Anlage verweist, wie folgt aussehen:

<?xml version='1.0' ?>  
<s:Envelope  
xmlns:s="https://schemas.xmlsoap.org/soap/envelope/"  
xmlns:mes="http://example.org/message/response">  
<s:Body>  
<mes:responseMesssage> 
<responseTo  
href="uuid:6FF57C24-74A1-426f-92D9-98861E105B4F"/>  
<messageText>Hello World!</messageText> 
</mes:responseMessage> 
</s:Body>  
</s:Envelope>

Das responseTo-Element im Nachrichtentext hat ein href-Attribut, das die ID des DIME-Datensatzes spezifiziert. Vermutlich sind die Daten im DIME-Datensatz eine andere SOAP-Nachricht, auf die diese Nachricht antwortet. Der Empfänger dieser DIME-Nachricht muss nicht erst die Nachricht zurückverfolgen, auf die der primäre Teil der SOAP-Nachricht antwortet, sondern findet diese einfach im angegebenen zweiten Teil der DIME-Nachricht.

Wir verweisen hier zwar vom primären Teil der SOAP-Nachricht auf einen sekundären Teil der DIME-Nachricht, ähnliche Verweise können jedoch auch von einem sekundären Teil aus erfolgen, so dass zwei sekundäre Teile aufeinander verweisen. Des Weiteren kann der sekundäre Teil sogar auf den primären Teil der SOAP-Nachricht verweisen.

WS-Attachments definiert zudem im Detail, wie eine SOAP-Verbundnachricht in einer HTTP-Anforderung gesendet werden kann. Dies ist vergleichsweise ähnlich mit dem alleinigen Senden des primären Teils der SOAP-Nachricht. Die einzige Ausnahme besteht darin, dass der HTTP-Content-Type-Header auf "application/dime" gesetzt werden muss und der Text der HTTP-Anforderung nicht die SOAP-Nachricht, sondern die DIME-Nachricht ist.

DIME und MIME

Neben DIME gibt es noch einen weiteren gängigen Mechanismus für das gemeinsame Verpacken von mehreren Datenteilen. Dabei handelt es sich um die MIME-Spezifikation (Multipurpose Internet Mail Extensions) und insbesondere um MIME Multipart. MIME Multipart wird für eine Reihe von Verwendungszwecken eingesetzt, doch am häufigsten für das Senden von E-Mail-Nachrichten mit Anlagen. Natürlich besteht auch hier ein Zusammenhang zu unserer Erörterung von Memoanlagen und dem Senden von E-Mails mit Anlagen. Es ist logisch, dass die von DIME angegangenen Probleme auch mit MIME gelöst werden können. Es gibt sogar eine ältere Spezifikation namens SOAP with Attachments (in Englisch), die mit Hilfe von Microsoft erstellt wurde und MIME Multipart verwendet, um das Anlagenproblem für SOAP-Nachrichten zu lösen. Aber warum wurde DIME dann überhaupt entwickelt?

Zunächst einmal müssen wir einige grundlegende Unterschiede zwischen MIME Multipart und DIME begreifen. Wie DIME besitzt MIME Multipart eine Reihe von "Datensätzen", die jeweils über einen Header und eine Nutzlast verfügen. Anstatt Datenlängen zu verwenden, um anzugeben, wo der nächste Header beginnt, verwendet MIME Multipart eine Trennzeichenfolge. Die Trennzeichenfolge wird zu Beginn der MIME-Nachricht angegeben und zwischen die einzelnen Datensätze eingefügt. Code, der eine MIME-Nachricht analysiert, muss die Daten nach der Trennzeichenfolge durchsuchen, um zu wissen, wo der nächste Datensatz beginnt.

Der MIME Multipart-Ansatz zielt darauf ab, den Absendern von MIME-Nachrichten in einem Datenstrom eine größere Effizienz zu ermöglichen. Die Absender müssen nicht vorab wissen, wie groß die von ihnen gesendete Datenmenge ist. Sie streamen die Daten einfach, bis sie am Ende angelangt sind und hängen dann die Trennzeichenfolge an.

Das Problem bei diesem Ansatz sind mögliche Ineffizienzen auf Empfängerseite. Wenn Sie einen Datensatz erhalten, wissen Sie nicht, wie groß dieser ist. Sie können versuchen abzuschätzen, wie groß der zuzuweisende Empfangspuffer sein muss. Jedoch müssen Sie sich unweigerlich auf Situationen gefasst machen, in denen mehr Daten gesendet werden, als Sie zugewiesen haben. Der Puffer muss neu zugewiesen werden und nun wissen Sie immer noch nicht, ob er groß genug ist für die eingehenden Daten.

Ein verwandtes Problem ist die Schwierigkeit, die Datensatzgrenzen zu finden. Beispielsweise ist eine Anwendung, die ein Verbunddokument liest, nicht an den nächsten drei Datensätzen in einem bestimmten Stream interessiert. Mit dem MIME-Ansatz zur Lösung dieses Problems muss sie jedoch jedes einzelne Byte dieser drei Datensätze inspizieren. Das Durchsuchen jedes einzelnen Datenbyte auf den Anfang der Trennzeichenfolge ist äußerst mühselig im Vergleich zum DIME-Ansatz, bei dem Sie direkt von Datensatz zu Datensatz wechseln können, da DIME die Datenlängen im Datensatzheader angibt.

Die Probleme hinsichtlich der Puffergröße und beim Auffinden der Datensatzgrenzen können natürlich mit einem MIME-basierten Ansatz gelöst werden. MIME ist hinsichtlich der Verwendungsmöglichkeiten für die Datensatzheader sehr flexibel und viele Entwickler fügen ihren MIME-Datensätzen Content-Length-Header hinzu. Es stellt sich jedoch die Frage: Warum werden überhaupt Trennzeichenfolgen verwendet, wenn wir die Länge des Datensatzes bereits kennen? Wenn Sie sich entscheiden, den Datensätzen einen Content-Length-MIME-Header hinzuzufügen, besitzt der Absender nicht mehr die Flexibilität, die Daten einfach bis zum Ende streamen zu können. Stattdessen muss er die Gesamtgröße des Datensatzes kennen, bevor er überhaupt mit dem Senden beginnen kann.

Das Problem, dass Sie vor dem Senden von Daten deren Größe wissen müssen, lässt sich natürlich ebenfalls beheben. Ebenso wie DIME Unterstützung für Chunking bietet, könnte auch in MIME Multipart eine Chunkinglösung für dieses Problem entwickelt werden. Doch versuchen Sie sich mal vorzustellen, wie die von uns beschriebene Lösung jetzt aussehen würde.

Letztendlich sind wir zu der Schlussfolgerung gekommen, dass eine MIME Multipart-Lösung: 1) die Inhaltslängen der Datensätze enthalten sollte, das heißt 2) die Trennzeichenfolge, die die Datensätze abgrenzt, ist nicht mehr erforderlich, und 3) muss ein Chunkingmechanismus definiert werden, um das Problem der unbekannten Datengrößen zu lösen. Wenn Sie darüber nachdenken, wie Sie diese Probleme im MIME Multipart-Framework lösen können, werden Sie sich bald fragen, ob es nicht eine einfachere Lösung für diese Probleme gibt. Angesichts der einfachen Verarbeitung des Abschnitts fester Länge eines DIME-Datensatzheaders und des einfachen Wechsels zwischen Datensätzen in einer DIME-Nachricht liegen die Vorteile des DIME-Ansatzes auf der Hand.

Es muss betont werden, dass einfache Vorgehensweisen einen zusätzlichen wichtigen Vorteil für Web Services darstellen. Interoperabilität ist ein wesentlicher Grund dafür, wieso Web Services so beliebt sind. Der Schlüssel zu einer erfolgreichen Interoperabilität ist Einfachheit. Code, der einfach zu schreiben und zu entwerfen ist, kann problemlos auf einer Vielzahl von Plattformen reproduziert werden. Wenn Sie z.B. ein Verbunddokument von einer Windows-Plattform an eine Unix-Plattform senden möchten und das Format des Verbunddokuments einfach gehalten ist, das heißt ohne viele zusätzliche Regeln und großen Interpretationsspielraum, ist die Wahrscheinlichkeit recht groß, dass das Dokument auf beiden Plattformen verstanden wird.

Ein gutes Maß für die Einfachheit ist die Anzahl von Zeilen, die für das Implementieren der Lösung erforderlich ist. Vergleichen Sie einmal die Logik, die für das Implementieren einer DIME-Lösung erforderlich ist, mit der Logik einer MIME Multipart-Lösung. MIME Multipart erfordert spezielle Logik, um Trennzeichenfolgen zu erstellen, die in den gesendeten Daten höchstwahrscheinlich gar nicht vorkommen. Zudem ist zusätzliche Logik erforderlich, um die Daten auf die Trennzeichenfolgen hin zu durchsuchen. Es ist eine Headeranalyselogik erforderlich, die eine variable Anzahl von Headern variabler Länge verarbeiten kann, die über Zeichenfolgenvergleiche analysiert wurden. Die komplexeste Aufgabe beim Erstellen oder Analysieren eines DIME-Datensatzes ist vermutlich die Verarbeitung der Bitreihenfolge der Ganzzahlen, die im Abschnitt fester Länge der Datensatzheader übergeben werden. Wenig Komplexität bedeutet auch wenige Bugs und Auslegungsmöglichkeiten. Dies sollte die Interoperabilität vereinfachen.

Schlussfolgerung

DIME und WS-Attachments stellen eine einfache und effiziente Lösung für das Verpacken von Anlagen mit SOAP-Nachrichten dar. Sie ermöglichen das Einfügen von Daten beliebigen Formats in eine SOAP-Nachricht, so dass JPEG-Bilder, digital signierte Dokumente, sekundäre SOAP-Nachrichten und sogar andere DIME-Pakete gemeinsam mit der SOAP-Hauptnachricht gesendet werden können. Zudem definieren sie einen Mechanismus, mit dem aus der SOAP-Nachricht im Paket heraus auf die angehängten Daten verwiesen werden kann. Eine Reihe von Web Services-Toolkits unterstützen bereits DIME und WS-Attachments. In diesem Bereich werden für die Zukunft weitere Implementierungen erwarten. Das Beifügen von Anlagen zu SOAP-Nachrichten wird schon bald eine Standardfunktion von Web Services und Web Service-Konsumenten sein.

Links zu verwandten Themen

•  Understanding DIME and WS-Attachments