Message Transmission Optimization Mechanism

SOAP Message Transmission Optimization Mechanism (MTOM) ist ein Standard, der vom World Wide Web Consortium (W3C) entwickelt wurde. MTOM beschreibt einen Mechanismus für die Optimierung des Übertragungs- bzw. Sendeformats einer SOAP-Nachricht durch selektive Neucodierung von Teilen der Nachricht bei gleichzeitiger Bereitstellung eines XML Information Set (Infoset) für die SOAP-Anwendung.

Es gibt viele Gründe für das Senden binärer Anhänge (z. B. Bilder oder Dateien) mit einer Web-Service-Anforderung. Hierfür stehen verschiedene Methoden zur Verfügung, z. B.:
  • Inline-Codierung mit Base64 in den SOAP-Nutzdaten. Die Inline-Codierung bedeutet in der Regel jedoch eine Zunahme der SOAP-Nachrichtengröße. Durch die Base64-Codierung kann sich die Größe der Binärdaten verdoppeln.
  • Codierung der Nachrichten mit SOAP with Attachments (SwA) und Konformität mit Web Services Interoperability Organization (WS-I) Attachments Profile. WebSphere Application Server unterstützt diese Methode derzeit.
  • Optimierung des Transports von binären Nachrichten mit XML-Binary Optimized Packaging (XOP). Diese Optimierung ist nur für Binärdaten und Binärinhalte verfügbar. MTOM verwendet XOP im Kontext von SOAP und MIME over HTTP.

XOP definiert einen Serialisierungsmechanismus für das XML Infoset mit binärem Inhalt, der derzeit auf die Konfektionierungsmechanismen von SOAP und MIME nicht anwendbar ist, aber auf jeden XML-Infoset- und anderen Konfektionierungsmechanismus. Er ist ein alternativer XML-Serialisierungsmechanismus, der nur zufällig wie ein "MIME multipart/related"-Paket aussieht und ein XML-Paket als Stammkomponente enthält. Diese Stammkomponente ist abgesehen davon, dass die nach Base64 codierten Daten durch eine Referenz auf einen der MIME-Abschnitte ersetzt werden, die nicht nach Base64 codiert ist, der XML-Serialisierung des Dokuments sehr ähnlich. Mit dieser Referenz können Sie den Großteil und den Aufwand für die Codierung während der Verarbeitung vermeiden. Codierung ist die einzige Möglichkeit, binäre Daten direkt in eine XML-Welt zu integrieren.

Wenn die Generierung von MTOM-Zuordnungen inaktiviert ist, ist XOP inaktiviert. Wenn XOP inaktiviert ist, werden die Binärdaten nicht mit MIME-Anhängen gesendet. Stattdessen werden die Binärdaten wie gewohnt nach Base64 codiert.

Die MTOM-Spezifikation ist in drei unterschiedlichen Teilen definiert:
  • einem abstrakten Feature für ein optimiertes Übertragungs- oder Sendeformat für SOAP-Nachrichten. Dieses Feature ist insofern abstrakt, dass die Beschreibung der Optimierungstechnik und des Verhaltens der SOAP-Prozessoren des Senders, des Empfängers und der zwischengeschalteten Stationen generisch ist und keine Referenzen auf Technologien wie MIME, HTTP usw. enthält. Dies Optimierungstechnik konzentriert sich auf die Gewährleistung einer Infoset-Sicht der SOAP-Rahmenanweisung (Envelope) für SOAP-Prozessoren und die gleichzeitige selektive Codierung bestimmter Inhalte des Infoset für die SOAP-Rahmenanweisung, die als kanonische lexikalische Darstellung des Datentyps "xs:base64Binary" zugänglich sind.

    Für die Implementierung dieser abstrakten Features müssen zwei Aspekte konkret spezifiziert werden: das optimierte Sendeformat und die Übertragung des optimierten Sendeformats in einem bestimmten Transport.

  • Der zweite Abschnitt der MTOM-Spezifikation bezieht sich auf den Serialisierungsaspekt und ist normalerweise von der "MIME Multipart/Related"-XOP-Konfektionierung abhängig. Der Serialisierungsaspekt ist die Beziehung zwischen MTOM und XOP.
  • Als konkretes Feature für die SOAP-HTTP-Bindungsebene erweitert MTOM die Serialisierung. Dieser Teil beschreibt, wie die HTTP-Bindung verwendet werden kann, um die XOP-Pakete zu transportieren, die die SOAP-MTOM-Nachrichten enthalten. Außerdem werden in diesem Teil verschiedene Einschränkungen für mögliche Serialisierungen der SOAP-MTOM-Nachrichten als XOP-Pakete, z. B. die ausschließliche Verwendung von XML 1.0, definiert.

Java™ API for XML Web Services (JAX-WS) bietet als neues Feature die Unterstützung für das Senden binärer Datenanhänge über MTOM. JAX-WS ist der zentrale Bestandteil eines frisch umgestalteten API-Stacks für Web-Services, der JAX-WS 2.0, JAXB 2.0 und SAAJ 1.3 umfasst. Der API-Stack wird manchmal auch als integrierter Stack bezeichnet. JAX-WS soll die Stelle Stelle von JAX-RPC in Web-Services und Webanwendungen einnehmen.

Ansatz für Anhänge

Anhang nach Wert oder nach Referenz war bisher eine allgemein akzeptierte Technik für die Bearbeitung nicht transparenter Daten in XML-formatierten Nachrichten.
  • Nach Wert bedeutet, dass der nicht transparente Dateninhalt als Elemednt oder Attribut über Base64- oder hexadezimale Textcodierung eingebettet wird, was im XML-Schema mit dem Datentyp "xs:base64Binary" bzw. "xs:hexBinary" spezifiziert ist.
  • Nach Referenz bedeutet, dass der nicht transparente Dateninhalt extern als Element oder Attribut über einen URI referenziert wird, was im XML-Schema als Datentyp "xs:anyURI" codiert ist.
Die Verwendung jeder dieser Techniken hat Vor- und Nachteile. MTOM ist die Spezifikation, die sich auf die Lösung dieser inhärenten Anhangsprobleme konzentriert.

Ein anderer Standard, der von World Wide Web Consortium (W3C) definiert wird, ist SOAP with Attachments (SwA). SwA wurde als Methode für das Packen von SOAP-Nachrichten mit Anhängen entwickelt. Da einige Anbieter SwA nicht unterstützen, kann SwA durch die leistungsfähigeren Mechanismen MTOM und XOP ersetzt werden. SwA und MTOM sind konzeptionell sehr ähnlich, und beide Mechanismen codieren binäre Daten als MIME-Anhang in einem MIME-Dokument. Die Verwendung von MIME-Anhängen verbessert die Leistung von Transporten mit binären Nutzdaten.

Weitere Unterschiede zwischen SwA und MTOM:
  • MTOM verwendet den Standard XOP, der eine XOP-Referenz in den SOAP-Nutzdaten definiert. Diese Referenz verweist auf den MIME-Anhang, der die binären Daten enthält.
  • Mit MTOM fügt die XOP-Referenz die binären Daten logisch in das XML Information Set (Infoset) ein. Mit SwA verweist das "href"-Element auf Daten, die sich nicht nur physisch außerhalb des XML-Dokuments befinden, sondern auch logisch nicht im Infoset enthalten sind.
  • Mit MTOM können binäre Anhänge logisch signiert werden, als wären sie Teil des SOAP-XML-Dokuments.
  • Neben IBM® unterstützt auch Microsoft .NET die Spezifikation MTOM, wodurch einige Interoperabiliätsprobleme, die mit SwA auftreten, wegfallen. Die Interoperabilität war eines der Hauptziele, als die vorgeschlagenen Änderungen von den Mitantragstellern besprochen wurden.
Der MTOM-Ansatz für Anhänge nutzt die SOAP-Infrastruktur und bietet gleichzeitig die Transporteffizienz, die mit der Lösung SOAP with Attachment (SwA) erreicht wird.

SOAP 1.2 und SOAP 1.1

SOAP 1.1 basiert auf der XML-Spezifikation. Die Implementierung von SOAP 1.1 wird wahrscheinlich noch einige Jahre weiter existieren. Für Benutzer, die immer noch mit SOAP 1.1 arbeiten, gibt es jetzt eine interoperable Methode, die MTOM-Unterstützung für Anhänge zu verwenden. SAP, Oracle, Microsoft und IBM haben eine Spezifikation mit dem Namen "SOAP 1.1 Binding for MTOM 1.0" bei W3C eingereicht, die definiert, wie MTOM für Nutzdaten der SOAP Version 1.1 verwendet werden kann. Die Spezifikation enthält eine detaillierte Beschreibung der erforderlichen Änderungen, die an den Spezifikationen SOAP MTOM und XOP vorgenommen werden müssen, um diese Technologien erfolgreich mit SOAP 1.1 zu verwenden. Weitere Einzelheiten finden Sie in der Spezifikation.

MTOM ist ein Feature von SOAP Version 1.2, das auf dem Infoset basiert. Weitere Informationen finden Sie in der Dokumentation zum XML-Informationsset.

Ohne MTOM werden diese Daten in dem Format codiert, das im XML-Schema beschrieben ist (base64 oder hex), und in das XML-Dokument eingefügt. Das folgende Beispiel zeigt eine SOAP-Nachricht mit einem Element <xsd:base64Binary>:

... weitere Transportheader ...
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?> 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <sendImage xmlns="http://org/apache/axis2/jaxws/sample/mtom">
      <input>
        <imageData>R0lGODl  ... more base64 encoded data ...  KTJk8giAAA7</imageData>
      </input>
    </sendImage>
  </soapenv:Body>
</soapenv:Envelope>

Wenn MTOM aktiviert ist, werden die binären Daten, die den Anhang darstellen, als MIME-Anhang in die SOAP-Nachricht eingefügt. Das folgende Beispiel zeigt eine MTOM-fähige SOAP-Nachricht mit Anhangsdaten:

... weitere Transportheader ...
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812; 
type="application/xop+xml"; start="<0.urn:uuid:0FE43E4D025F0BF3DC11582467646813@apache.org>"; 
start-info="text/xml"; charset=UTF-8

--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812
content-type: application/xop+xml; charset=UTF-8; type="text/xml";
content-transfer-encoding: binary
content-id: 
   <0.urn:uuid:0FE43E4D025F0BF3DC11582467646813@apache.org>

<?xml version="1.0" encoding="UTF-8"?> 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <sendImage xmlns="http://org/apache/axis2/jaxws/sample/mtom">
      <input>
        <imageData>
          <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" 
               href="cid:1.urn:uuid:0FE43E4D025F0BF3DC11582467646811@apache.org"/>
        </imageData>
      </input>
    </sendImage>
   </soapenv:Body>
</soapenv:Envelope>
--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812
content-type: text/plain
content-transfer-encoding: binary
content-id: 
         <1.urn:uuid:0FE43E4D025F0BF3DC11582467646811@apache.org>

... hier binäre Daten einfügen ...
--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812--

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_soapmtom
Dateiname:cwbs_soapmtom.html