Understanding MTOM - Loosely Coupled Thinking - Site Home

MTOM combines the composability of Base 64 encoding with the transport efficiency of SOAP with Attachments. Non-XML data is processed just as it is with SOAP with Attachments SWA – the data is simply streamed as binary data in one of the MIME message parts. (The MTOM processing model is described in greater detail below.)

MTOM is composed of three distinct specifications:

MTOM CORE describes an abstract feature for optimizing the transmission and/or wire format of a SOAP 1.2 message by selectively encoding portions of the message, while still presenting an XML Infoset to the SOAP application. Use of the Abstract SOAP Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path, providing no mandatory convention for optimization of SOAP transmission through intermediaries.
XOP (XML-binary Optimization Packaging) specifies the method for serializing XML Infosets with non-XML content into MIME packages. XOP provides an alternate serialization that is fully compatible with a MIME package, including an XML document as the root portion of the package. XOP streams the non-XML attachment as one of the MIME message parts. The MIME attachment is processed and temporarily treated as base-64 encoded text immediately prior to serialization of the message. For example, a WS-Security layer creating a digital signature would use the non-XML data to calculate the signature by streaming it through a base-64-encoding layer. The base-64-encoded data is temporary, used only for creating the signature (it is never actually transferred, stored or serialized anywhere).

MTOM Processing Model - click for a larger view

During deserialization the processing layers that access the attachment would do so through the base-64-encoding layer (again, this is a temporary representation that occurs just before serialization).

The Resource Representation SOAP Header Block specification defines a SOAP header block that can carry resource representations within SOAP messages. The Representation Header Block is designed to be used when the RECEIVER has limited ability to retrieve the resource (due to access restrictions or unreasonable overhead processing due to the size of the resource to be retrieved). The Representation Header Block can also be used when multiple references to the same resource are required but duplication of the resource is undesirable. The example below illustrates a sample application of the Representation Header Block. The referenced Content Package is attached as a MIME part and the (simulated) base-64 encoded value was generated during Infoset processing (as mentioned above).

(Please accept my apologies for the formatting issues - Community Server keeps adding multiple line breaks and I'm tired of fighting it...)

<soap:Envelope
     xmlns:soap='http://www.w3.org/2002/12/soap-envelope'
     xmlns:rep='http://www.w3.org/2004/08/representation'
     xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
<soap:Header>
    <rep:Representation
          resource='http://example.org/myPackage.zip'>
      <rep:Data xmlmime:contentType='application/zip'>
          /aWKKapGGyQ=
    </rep:Data>
    </rep:Representation>
</soap:Header>
<soap:Body>
    <x:MyData xmlns:x='http://example.org/mystuff'>
      <x:name>Learning About Web Services</x:name>
      <x:img src='http://example.org/myPackage.zip'/>
    </x:MyData>
</soap:Body>
</soap:Envelope>

What About SOAP with Attachments and DIME?

Why not simply use SOAP with Attachments (SwA) or DIME (Direct Internet Message Encapsulation)?

There are two disadvantages to using SwA:

SwA defines a way for binding attachments to a SOAP envelope using the multipart/related MIME type - this is the same attachment/encapsulation mechanism used for e-mail. MIME is inefficient because it uses text strings to delineate boundaries between parts. Consumers must scan the entire message to find the string value used to delineate a boundary.
MIME cannot be represented as an XML Infoset – this effectively breaks the web services model since attachments cannot be secured using WS-Security.

The DIME specification was created to address performance issues when processing MIME attachments. DIME avoided having to scan the entire message to locate boundaries because the length of the attached files was encoded in the message header, enabling large attachments to be processed in “chunks”. While DIME provided a more efficient processing model it still didn’t provide an infoset model for the message and attachment.

MTOM provides a compromise between the MIME model and the Web services model (an infoset representation is available – see the MTOM processing model above). MTOM messages are valid SWA messages, lowering the cost of supporting MTOM for existing SWA implementations. MTOM attachments are streamed as binary data within a MIME message part, making it fairly easy to pass MTOM attachments to SWA or receive SWA attachments into an MTOM implementation.

Stay tuned for code samples - coming soon!