How does MTOM work?

Question

MTOM is the W3C Message Transmission Optimization Mechanism, a method of efficiently sending binary data to and from web services.

How does it work in general?

Sheetfed

Answer 1

If you put Wireshark (or enabled System.Net Logging) on the non-MTOM enabled service, you should see the SOAP requests with the binary data encoded as BASE64. Sending it as BASE64 increases the size of the binary data but (I assume) makes it more interoperable.

With MTOM, the SOAP messages are sent as MIME messages with the BASE64 encoding being replaced with a placeholder. The binary data is then placed between delimiters (which happens for each piece of binary data), and then placed at the end of the SOAP request. The binary data is then sent unencoded. IIRC, MTOM also determines whether sending it as a MIME message will increase the size of the SOAP call and if doesn't provide a saving, it will send it as a normal SOAP message.

This provides an example of what the message sent over the wire looks like.

Chuckwalla

"The binary data is then placed between delimiters" alternatively, a link to the binary data can be sent as part of the SOAP message to allow the binary data to exist outside the XML and to be downloaded, for example, on a cluster of HTTP/S servers for performance. This is called "By Reference" – Laverne

Answer 2

It all begins with the fact that SOAP is XML. And when you send anything other than text, for instance, an image - it has to be converted into a datatype that an XML processor can understand.

Without MTOM, your image will be converted to base64Binary and placed smack in the middle of your SOAP envelope. This conversion process makes the data fat.

<tns:data>A very looooooooooooooooooooooong base64Binary string</tns:data>

Here's a simple illustration:

With MTOM, the image will be transmitted outside the envelope as a MIME attachment - in short, it's sent according to its original datatype: a jpg, png, or gif. Of course it's still transmitted as binary data, but this time, there's no XML-related conversion, avoiding the computational overhead. XOP comes into the picture as it's the one that gives the location of the externalized image.

<soap:Envelope>
    <soap:Body>
        <tns:data>
            <xop:include href="SomeUniqueID-ThatLeadsToTheImage"/>
        </tns:data>
    </soap:Body>
</soap:Envelope>

Content-id: "SomeUniqueID"
Content-Type: image/png

image binary data here

Brussels

have you any sample code of this one, actually i required to understand what to include in <xop:include href="SomeUniqueID-ThatLeadsToTheImage"/>. I am somehow confuse in it. – Upstart

Can XOP include a image URL instead so that the client does not need to download/include the picture in memory? and server itself can download it instead? Or I am wishing fiction to be reality and there is no efficient way to send big images fast? All of the legacy JAXB classes totally destroy our reactor app with few rps with images round 1.5 mb :crying:. – Goldia

To reference Content-ID: "SomeUniqueID" it's <xop:include href="cid:SomeUniqueID" /> (cid referring to the Content-ID header of another message part), and the Content-Type header for such an HTTP request looks similar to Content-Type: multipart/related; type="application/xop+xml"; start="root-Content-ID"; start-info="text/xml"; boundary="my-multipart-boundary" – Tzong

Answer 3

There are a few factors that other answers don't mention. One might think why MTOM is not used as default since it's "faster" than Text message encoding (Base64). It's because MTOM is not faster always. MTOM should only be used on large message transfers because it comes with an overhead. For small size of messages, MTOM's performance will be worse than Text message encoding (Base64).

If MTOM is used for large messages, it's faster than Base64 since it uses raw binary for data transfer. To understand that, one should understand how Base64 works.

Base64 uses 6 bits (log2(64)) to represent 1 character which means that base64 uses 4 characters to represent 24 bits (3 bytes). So if the message size is n bytes, base64 will use 4*(n/3) bytes to represent your data which means it will be slower by 1/3 than MTOM.

Feudalism