Message Transmission Optimization Mechanism
SOAP MTOM is a standard that is developed by the World Wide Web Consortium (W3C). TOM describes a mechanism for optimizing the transmission or wire format of a SOAP message by selectively re-encoding portions of the message while still presenting an XML Information Set (Infoset) to the SOAP application.
There are many reasons why we might want to send binary attachments, such as images or files, along with a web services request. There are ways to accomplish this, such as:
- Encoding with base64 inline in the SOAP payload. However, encoding inline tends to enlarge the size of the SOAP message. Note that base64 encoding might double the size of the binary data.
- Encoding the messages using SOAP with Attachments (SwA) and to follow the Web Services Interoperability Organization (WS-I) Attachments Profile. WebSphere Application Server currently supports this method.
- Providing optimization of binary message transportation using XML-binary Optimized Packaging (XOP). Optimization is available only for binary data or content. MTOM uses XOP in the context of SOAP and IME over HTTP.
XOP defines a serialization mechanism for the XML Infoset with binary content that is not only applicable to SOAP and MIME packaging, but to any XML Infoset and any packaging mechanism. It is an alternate serialization of XML that just happens to look like a MIME multipart/related package, with an XML documents as the root part. That root part is very similar to the XML serialization of the document, except that base64-encoded data is replaced by a reference to one of the MIME parts, which is not base64 encoded. This reference enables us to avoid the bulk and overhead in processing associated with encoding. Encoding is the only way a binary data can fit directly into an XML world.
If MTOM mapping generation is disabled, then XOP is disabled. If XOP is disabled, the binary data are not sent using MIME attachments. Instead, the binary data is base64 encoded as usual.
The MTOM specification is defined in three different parts:
- An abstract feature for optimized transmission or wire format
for SOAP messages. This feature is abstract in the sense that the description of the optimization technique as well as the behavior
of the SOAP processors at sender, receiver and intermediaries is generic
and does not include any references to technologies such as MIME,
HTTP, and so forth. The optimization technique centers around ensuring
a SOAP envelope Infoset view for the SOAP processors while encoding
selectively certain contents of the SOAP Envelope Infoset that are
accessible as canonical lexical representation of the xs:base64Binary
data type.
Implement these abstract features requires concrete specification of two aspects: the optimized wire format and how the optimized wire format flows on a particular transport
- The second part of the MTOM specification addresses the serialization aspect and depends normatively upon MIME Multipart/Related XOP packaging. The serialization aspect is where MTOM relates to XOP.
- As a concrete SOAP HTTP binding level feature, MTOM expands upon the serialization. This part describes how HTTP binding can be used to transport the XOP packages that are holding the SOAP MTOM messages. This part also puts some restrictions on the possible serializations of the SOAP MTOM messages as XOP packages, such as use of XML 1.0 only.
The JAX-WS adds support for sending binary data attachments using MTOM. JAX-WS is the centerpiece of a newly re-architected API stack for web service that includes JAX-WS 2.0, JAXB 2.0, and SAAJ 1.3. The API stack is sometimes referred to as the integrated stack. JAX-WS is designed to take the place of JAX-RPC in web services and web applications.
Attachment approach
Attachment by value or by reference has been the widely accepted technique for handling opaque data in XML-formatted messages.
- By value is when the opaque data content is embedded as an element or as an attribute using either base64 or hexadecimal text encoding approach, which is codified in the XML schema as data types xs:base64Binary and xs:hexBinary, respectively.
- By reference is when the opaque data content is referenced externally as element or as attribute using a URI, which is codified in the XML schema as data type xs:anyURI.
The use of either of these two techniques has its advantages and disadvantages. MTOM is the specification that is focused on resolving these inherent attachments problems.
A different standard is defined by World Wide Web Consortium (W3C) and is called SOAP with Attachments (SwA). SwA was developed as a way to package SOAP messages with attachments. Because some vendors do not support SwA, SwA can be replaced by the more powerful MTOM and XOP mechanisms. SwA and TOM are conceptually similar, and both encode binary data as a MIME attachment in a MIME document. Using MIME attachments improves the performance of large binary payloads transport.
Additional differences between SwA and MTOM include:
- MTOM uses a standard called XOP, which defines a XOP reference that exists within the SOAP payload. This reference points to the IME attachment containing the binary data.
- With MTOM, the XOP reference logically includes the binary data into the XML Information Set (Infoset). With SwA, the href points to data that is not only physically outside the XML document but is not logically included within its Infoset.
- With MTOM, binary attachments can be logically signed as if they were part of the SOAP XML document.
- In additional to IBM, Microsoft .NET supports MTOM, which eliminates some of the interoperability problems found with SwA. Interoperability was treated as the main goal when the co-submitters discussed the suggested modifications.
The MTOM attachment approach takes advantage of the SOAP infrastructure while also gaining transport efficiencies provided by SOAP with Attachment (SwA) solution.
SOAP 1.2 and SOAP 1.1
SOAP 1.1 is based on the XML specification. Likely, the SOAP 1.1 implementation will continue to exist for a few years. For those who are still running SOAP 1.1, there is now an interoperable way to use MTOM for attachments support. SAP, Oracle, Microsoft, and IBM have submitted a SOAP 1.1 Binding for MTOM 1.0 specification to W3C, which defines how MTOM can be used with SOAP 1.1 payloads. The specification details the necessary modifications to the SOAP MTOM and XOP specifications necessary to successfully use these technologies with SOAP 1.1. See the specification to learn more details.
MTOM is a SOAP Version 1.2 feature, which is based on the Infoset. See the XML information set documentation to learn more.
Without MTOM, the data is encoded in whatever format is described in the schema (base64 or hex) and then is contained in the XML document.
SOAP message with an <xsd:base64Binary> element:
... other transport headers ...
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>
When MTOM is enabled, the binary data that represents the attachment is included as a MIME attachment to the SOAP message.
MTOM-enabled SOAP message with attachment data:
... other transport headers ...
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>
... binary data goes here ...
--MIMEBoundaryurn_uuid_0FE43E4D025F0BF3DC11582467646812--
Subtopics
- XML-binary Optimized Packaging
XML-binary Optimized Packaging (XOP) specification was standardized by the World Wide Web (W3C) on January 25, 2005. SOAP Message Transmission Optimization Mechanism (MTOM) uses XOP in the context of SOAP and MIME over HTTP. - XML information set
XML Information Set (Infoset) is a World Wide Web Consortium (W3C) specification, dated February 4, 2004. An XML information set is an abstract model of the information stored in an XML document. The information set establishes a separation between data and information in a way that suits most common uses of XML. Several of the concrete XML data models are defined by referring to XML information set items and their properties.
Related:
