Need for MTOM

Exchanging different types of binary files between business entities is a common business need. To be transmitted within a SOAP message, these files must be represented as binary data.

Using the default SOAP serialization, only characters are allowed to be transferred within a SOAP XML message. Therefore, for binary data to be transferred within a SOAP message, it must be encoded as characters using base64 encoding.

Binary data encoded as base64 is represented as text. This text is then transferred as part of the SOAP message. Now, this can drastically increase the message size, which can become an issue especially over low-bandwidth networks.

To solve the size problem, Message Transmission Optimization Mechanism (MTOM) is a standard that optimizes binary data transmission by representing this data in its raw format, instead of being base64 encoded. This raw binary data is then referenced by the SOAP message as an attachment representing binary data in its raw format, results in a much reduced message size, when compared with the same message using the base64 encoding.

MTOM

In this diagram, you see an illustration of a SOAP message carrying a binary file. This file has to be base64 encoded in order to be carried by the SOAP message.

Now using MTOM, the binary file does not need to be base64 encoded anymore; instead MTOM is usually used with another standard – called the XML-binary Optimized Packaging or (XOP).

XOP specifies a way to package the raw binary data into a MIME attachment that is then referenced by the SOAP message.

Now when the receiver gets the message, it inspects the XOP element in order to find the MIME attachment.

base64 Encoded Binary

To better understand MTOM, let’s compare a SOAP message carrying binary data and the same message when MTOM is used. This is a SOAP message which contains binary data. This is a typical result of applying the text message encoder. Here binary is embedded within the message after being base64 encoded. So what you’re seeing here in the body of the message, is binary data being represented as text using the base64 encoding.

MTOM Encoded Binary

Now, an MTOM/XOP SOAP message on the other hand looks like this.

• The Content-Type HTTP header is set to “multipart related”. Multipart indicates the presence of a MIME attachment part in addition to the main message part.
• The start parameter indicates which part of the MIME message is the root XOP document.
• Now Content-ID in general identifies a part of the MIME message. In this case, this part is the root XOP document. So, this start parameter points to the root XOP document which in this case, is the main message part.
• The <xop:Include> element in the main message part, points to an Id, which identifies a message part holding the binary attachment.
• This Id, matches the value of the Content-ID of the binary attachment. This is the mechanism by which MTOM uses XOP to reference a binary attachment, while the main SOAP message carries only the XML data.

WCF MTOM Encoding

MTOM in the Channel Layer

Recall from module 2 that WCF differentiates between serialization and encoding.

While serialization defines how a Message object is transformed into Xml Infoset, encoding refers to the conversion of the Xml Infoset into an array of bytes that can be sent using a transport protocol.

WCF provides a set of encoders, that are responsible, on the sender side, for turning the in-memory message into a byte stream or byte buffer, that can then be sent across the network.

On the receiver side, WCF encoders turn the sequence of bytes back into an in-memory message.

Now lets see encoding options we have in WCF, one of which of course will be the MTOM encoder.

WCF Encoders

Encoding options matter mostly when message size and thus performance is an important issue.

• The BinaryMessageEncoder, represents a Message as a binary version of XML using a binary format protocol published by Microsoft – called “.NET Binary Format: XML Data Structure. This results in the most compact message size. However, this encoder is ideal for WCF-to-WCF communcaiton and is mostly not interoperable.
• The TextMessageEncoder is the default encoder. Messages are represented as Text in a SOAP message. You can control the SOAP version to be 1.1 or 1.2, but either way, message size is large because of the textual representation demands of XML, such as the use of brackets and namespaces. Any binary data moving around, is base64 encoded in order to be carried within the SOAP message. This further increases the message size.

• The MTOMMessageEncoder is similar to the TextMessageEncoder in that messages are also represented as SOAP 1.1 or 1.2 Text. However, instead of base64 encoded binary data within the message, this binary data is encoded using MTOM as raw bytes, and is then referenced  – using the XOP standard – as an attachment from within the SOAP message. This has the benefit of not using binary encoding thus restraining message size while still being able to pass binary data in an interoperable manner because both MTOM and XOP are interoperable. Now the real benefit of MTOM will be evident only when transmitting large binary data, becasue it can actually reduce performance if the binary data size is small. The reason is that MTOM does have an overhead caused by generating the separate MIME attachment. So unless the binary data size is large, no need to pay the penalty of attachment generation. For this reason, WCF defines a threshold of 1 kilo bytes. MTOM will only be used if the base64 encoding results in data size that is above this threshold.

The MTOM encoder is of course the one that uses MTOM standard and the one you will see in action in a moment.