XML-binary Optimized Packaging

Die Spezifikation XML-binary Optimized Packaging (XOP) wurde vom World Wide Web (W3C) am 25. Januar 2005 standardisiert. SOAP Message Transmission Optimization Mechanism (MTOM) verwendet XOP im Kontext von SOAP und MIME over HTTP.

XML ist ein gängiger Standard für die Datenübertragung. XML ist ein vielfach eingesetzter Standard für den Austausch korrekt formatierter Dokumente, da er sich auf einfachen, lesbaren und strukturierten Text bezieht. Das SOAP-Messaging in Web-Services basiert auf XML (bzw. auf XML Infoset mit SOAP 1.2). Benutzer möchten traditionelle Formate wie PDF, GIF, JPEG und ähnliche Formate und gleichzeitig ein XML-Modell verwenden. Der Wunsch, XML in bereits vorhandene Datenformate zu integrieren, war ein Thema, das die XML-Community lange Zeit und dauerhaft vor ein Problem gestellt hat. Benutzer möchten häufig die strukturierten, erweiterbaren Markup-Konventionen von XML nutzen, ohne die vorhandenen Datenformate aufzugeben, die der Syntax von XML 1.0 nicht ohne Weiteres entsprechen.

Mit der Verbreitung von SOAP-Messaging in Web-Services ist der nächste Schritt festzulegen, wie nicht textbasierte Daten, wie z. B. Bilder und Workflowdaten, zusammen mit der Nachricht gesendet werden. Beispiel: Sie möchten ein gescanntes Dokument im Format .jpeg zwischen zwei Anwendungen übertragen. Es stellt sich die Frage, ob diese Daten von den verschiedenen Anwendungen interpretiert werden können.

Der Nutzen von XML und Web-Services besteht größtenteils in der Möglichkeit, generische XML-Tools für die Bearbeitung von Inhalten verwenden zu können. Viele XML-Tools und -Standards für die Beschreibung und Bearbeitung von XML (wie z. B. Parser, XPath, XQuery, XSLT, XML-Verschlüsselung, digitale Signatur und XML-Schema) sind nicht für die Bearbeitung von Daten wie Bildern, die nicht textbasiert sind, ausgestattet. Diese XML-Tools eignen sich nicht für Inhalte, die nicht XML-basiert sind. Diese Tools erfordern Text. Die Herausforderung besteht darin herauszufinden, wie nicht textbasierte Daten (oder binäre Daten) in XML eingebettet oder XML zugeordnet werden können, d. h., eine Methode zu finden, um eine Binärdatei bei Bedarf einer SOAP-Nachricht zuzuordnen.

Codierung ist die einzige Möglichkeit, binäre Daten direkt in eine XML-Welt zu integrieren. Normalerweise können Sie Binärdaten in ein XML-Dokument einbetten, indem Sie die Daten mit Base 64 als Test codieren. Base 64 ist eine Serialisierung, die es seit einiger Zeit gibt, die ohne Vorbereitungs- oder Anpassungsaufwand implementiert werden kann und Plattforminteroperabilität bietet. Der Datentyp "xsi:base64binary" unterstützt diese Serialisierung im XML-Schema. Base 64 codiert Ihre Binärdaten in eine Textdarstellung, die in ein XML-Dokument gepackt werden kann. Base 64 nimmt Ihre Bindärdaten und übersetzt sie in eine Serie von ASCII-Zeichen, indem drei Oktette gleichzeitig codiert werden. Jedes Oktett besteht aus acht Bits. Die drei Oktette werden mit vier druckbaren ASCII-Zeichen aus einem Symbolvorrat von 64 ASCII-Zeichen dargestellt. Auf allen Plattformen kann diese Konvention für die Codierung und Decodierung verwendet werden. 6-Bit-ASCII ist ein gängiges Format, bei dem keine Sonderzeichen behandelt werden müssen. Bei größeren Nachrichten wirkt es sich jedoch auf die Leistung aus.

Für Anwendungen, die einen zügigen Betrieb erfordern, ist Base 64 möglicherweise nicht die richtige Lösung. Wenn Sie solche Inhalte indexieren, abfragen, umsetzen, verschlüsseln, signieren oder beschreiben möchten, müssen Sie einen anderen Mechanismus verwenden.

Die erste Spezifikation für Anhänge, bekannt als SOAP with Attachments (SwA), wurde entwickelt. Die Grundidee von SwA ist die, dass der binäre Nachrichtenabschnitt (der Anhang) als MIME-Anhang (Multipurpose Internet Mail Extensions) betrachtet wird. MIME ist eine häufig eingesetzte Spezifikation für die Formatierung von E-Mail-Anhängen, die kein ASCII-Format haben. SwA spezifiziert, dass der SOAP-Hauptteil eine Referenz auf den MIME-Nachrichtenabschnitt (den Anhang) enthalten darf, für die einfach ein URI verwendet wird. Der binäre Abschnitt wird nach Referenz angehängt.

Die wenigen Nachteile von SwA sind im Folgenden aufgeführt:
  • SwA mangelt es an Benutzerfreundlichkeit und Interoperabilität. Die SOAP-Infrastruktur wurde um den SOAP-Rahmenanweisung (Envelope) herum entwickelt, was für Anhänge nicht so gut geeignet ist. Ein Anhang bedeutet bei SwA, dass zwei Datenmodell in einer Nachricht verwendet werden. Diese beiden Datenmodell funktionieren in der vorhandenen XML-Technologie nicht.
  • SwA funktioniert nicht mit dem modularen Charakter von SOAP. Insbesondere Standards, wie z. B. WS-Security, wurden nicht speziell für Anhänge geschrieben. WS-Security muss für alle Daten funktionieren, die digital signiert oder verschlüsselt werden müssen, und das gilt auch für alle Daten im Anhang. Wenn der Zugriff auf diese Daten jedoch nicht möglich ist, funktioniert dies nicht, und die Signatur ist ungültig.

Häufig möchten Benutzer ihre vorhandenen Nicht-XML-Formate unverändert beibehalten und von den XML-Tools und der XML-Infrastruktur als nicht transparente Oktettfolgen behandeln lassen. Ein solcher Ansatz unterstützt eine problemlose Koexistenz gängiger Formate wie ".jpeg" und ".wav" mit XML. XOP macht die Vewrendung Base64-codierter Daten ein wenig realistischer. Derzeit unterstützt XOP nur die Optimierung Base64-codierter Daten.

Die Verwendung von XOP bedeutet, dass Instanzen des XML-Typs "base64Binary", sofern aktiviert, über MIME-Anhänge transportiert werden. Wenn XOP verwendet wird, kann die Implementierung die Daten automatisch codieren. XOP verwaltet das Datenmodell der XML-Nachricht, weil Anhänge als Base64-codierte Daten behandelt werden. Wenn ein XML-Stack die XOP-Codierung versteht, muss Ihre Anwendung überhaupt nicht geändert werden. Wenn die Anwendung beispielsweise auf ein Bild im Format ".jpeg" zugreifen möchte, kann sie den Zeichenwert des Inhalts als Base64-codierte Zeichenfolge abrufen.

XOP ist eine Möglichkeit, sich MIME-Nachrichten in einem Datenaustausch vorzustellen, mit der Benutzer zufrieden sind und die Benutzer bereits für viele andere Daten verwenden. Das XOP-Format verwendet Multipart-MIME für die Einbindung unaufbereiteter binärer Daten in ein XML-1.0-Dokument, ohne auf die Base64-Codierung zurückgreifen zu müssen.

Eine zugehörige Spezifikation, SOAP Message Transmission Optimization Method (MTOM), gibt dann an, wie dieses Format an SOAP gebunden wird. Mit den Standards XOP und MTOM sollte sich die Leistung von SOAP 1.2 verbessern. XOP und MTOM zusammen bilden die bevorzugte Methode für die Mischung von binären Daten und textbasierter XML. Mit MTOM und XOP in Kombination können Sie die Abschnitte der Nachricht auswählen, die als Binärdaten über die Verbindung gesendet werden sollen, und gleichzeitig das Infoset aufrecht erhalten. Mit Hilfe dieser Standards können binäre Daten außerhalb der SOAP-Rahmenanweisung (Envelope) als Nachrichtenabschnitt angehängt werden. Anders als bei SwA werden die binären Daten jedoch nahezu so behandelt wie in der SOAP-Rahmenanweisung, d. h. als ein InfoSet.

XOP definiert einen Serialisierungsmechanismus für XML Infoset mit binärem Inhalt, der derzeit auf die Paketmechanismen von SOAP und MIME nicht anwendbar ist, aber auf jeden XML-Infoset- und anderen Paketmechanismus. Andererseites eignet sich XML nicht als allgemein anwendbarer Paketmechanismus.

Ein XOP-Paket wird erstellt, indem eine Serialisierung des XML Infoset in ein erweiterbares Paketformat (wie z. B. MIME) gestellt wird. In XOP wird MIME nicht für die eigentliche Paketerstellung in der Verbindung wiederverwendet. Ausgewählte Teile des Inhalts, bei denen es sich um Base64-codierte binäre Daten handelt, werden extrahiert und erneut codiert, d. h., die Daten werden aus Base64 decodiert und in das Paket gestellt. Die Positionen dieser ausgewählten Teile sind in XML mit einem speziellen Element markiert, das eine Verknüpfung zu den gepackten Daten über URIs enthält.

Die SOAP-Verarbeitungsengines führen, kurz bevor die Nachricht die Verbindung erreicht, eine temporäre Base64-Codierung der binären Daten durch. Diese temporäre Codierung ermöglicht dem SOAP-Prozessor, die Base64-Daten zu bearbeiten, z. B. eine WS-Signature der Daten in den Header zu stellen. Es besteht kein Bedarf an einer kostenintensiven Decodierung auf der andere Seite, und der Prozess funktioniert auch umgekehrt.

Implementierungen von MTOM und XOP sind in Java™ (JAX-WS) verfügbar.

Das folgende Beispiel zeigt ein XML Infoset vor der XOP-Verarbeitung (SOAP):
<soap:Envelope
      xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
      xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
      <m:sig xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>
Dieses Beispiel zeigt ein XML Infoset, das als XOP-Paket (SOAP) serialisiert wird.
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo 
  xmlmime:contentType='image/png'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig 
  xmlmime:contentType='application/pkcs7-signature'><xop:Include 
    xmlns:xop='http://www.w3.org/2004/08/xop/include' 
    href='cid:http://example.org/my.hsh'/></m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_xop
Dateiname:cwbs_xop.html