he technologies of Message Transmission Optimization Mechanism (MTOM
) and XML-Binary Optimized Packaging (XOP
) are concerned with the fundamental issue of binary data transmission, which is of great importance to web service performance. Since becoming W3C standards in 2005, XOP and MTOM have been quickly and widely adopted in next-generation SOAP engines. In hindsight, one has to wonder why they were not proposed earlier in the development of web services or as part of the original SOAP specification.
This article introduces MTOM and XOP, discusses the problems they address, and then uses an example to demonstrate how to work with them in JAX-WS 2.0.
Challenges That MTOM/XOP Addresses
The issue MTOM/XOP tackles is the coordinated transport of opaque binary data in conjunction with an XML document. The two traditional approaches for handling this issue are:
- Embedding such data in XML as text-encoded octets with type xs:base64Binary or xs:hexBinary
- Referring to the binary data with a URI of type xs:anyURI in the XML document, with the opaque data bundled alongside using a package format (e.g., SwA and WS-Attachment)
Unfortunately, these approaches suffer from performance and interoperability problems. The first one bloats the message size (with UTF-8 text encoding, base64 encoded data expands by a factor of 1.33x, and hexadecimal encoded data expands by a factor of 2x). It also carries the overhead of processing costs, especially when decoding back into binary. In the second approach, the data is external to the XML document and isn't part of the message Infoset. As a result, layered technologies for processing and describing XML and SOAP need to provide one set of solutions for the XML component of their data and another set of solutions for the external components (e.g., DIME and multipart MIME). This not only complicates all the entities working with such messages, but also brings interoperability issues because no standard model governs how SOAP intermediaries process the referenced data; existing technologies such as XML signature and encryption weren't really designed with such referenced data in mind.
For a detailed and well-written analysis of those challenges, refer to "XML, SOAP and Binary Data", a white paper from BEA and Microsoft written by Adam Bosworth and Don Box, et al.
How XOP Works
XOP extracts binary data in an XML document and serializes them into packages located inside an extensible packaging format such as MIME Multipart/Related. The new XML document marks the locations of those binary data packages with special elements that contain URI identifying the corresponding location.
Unlike traditional approaches for handling binary data in XML documents, XOP does not require encoding binary data in base64. The data can take its original format as octet streams. An application parsing an XOP package may work directly with the octet stream, or if appropriate, compute the base64 binary character representation from this stream.
Listing 1 and Listing 2 are SOAP messages that contain the same content in transmission over HTTP, but Listing 2 shows the message as serialized using the XOP format into a MIME Multipart/Related package. Look at the .../book/coverImage and .../book/sample/content elements in Listing 1. Both contain base64-encoded streams. In Listing 2, those base64-encoded streams are replaced with xop:Include elements, each of which contains an attribute href pointing to a MIME part through a URI following the cid:URI schema. The MIME parts contain the actual binary data in octet streams.
The W3C recommendation, XML-binary Optimized Packaging, specifies the various constructs in an XOP package, such as the syntax and semantics of the xop:Include element and its href attribute. It also specifies how to create and interpret an XOP package using the original XML document as the reference. By the specification, XOP works only with XML elements of xs:base64Binary type.
How MTOM Addresses These Challenges
MTOM provides a concrete implementation for using XOP to optimize the transmission and/or wire format of SOAP messages. It describes how to serialize a SOAP envelope using the XOP format and MIME Multipart/Related packaging (note that MIME Multipart/Related is not required in XOP). Following the rules specified, MTOM serializes a SOAP message into a MIME Multipart/Related XOP package with one body part (the root) that contains an XML representation of the modified SOAP envelope and additional parts that contain the binary representation of each element of the xs:base64Binary type. With MTOM, deserialization of this transferred SOAP message follows the standard XOP approach.
MTOM further specifies a concrete implementation of this mechanism for SOAP HTTP binding. For example, it requires placing the MIME headers of the resulting MIME Multipart/Related XOP package in HTTP headers and the rest of the package into the HTTP body.
You can identify MTOM in a SOAP message transmission over HTTP by the following four attributes:
- The application/xop+xml media is present.
- The media type of the HTTP message is multipart/related.
- The media type of the root part of the MIME Multipart/Related package is application/xop+xml.
- The start-info parameter indicates a content type of application/soap+xml.
Note that the W3C MTOM specification considers only SOAP 1.2. On April 2006, IBM, Microsoft, SAP, and Oracle submitted SOAP 1.1 Binding for MTOM 1.0 to the W3C to cover SOAP 1.1. This document, while reflecting the difference between SOAP 1.1 and SOAP 1.2, keeps the essential features of MTOM untouched. Following this member submission, the above-mentioned start-info parameter of the root part of the MIME Multipart/Related package becomes text/xml instead of application/soap+xml in SOAP 1.1. (Listing 2 shows a SOAP 1.1 example.)
With this background information covered, the next section will illustrate how to work with MTOM/XOP in JAX-WS 2.0, which is part of Java SE 6.0, (and its reference implementation) using a sample web service.