Skip to main content

How MTOM and Streaming Improve Performance for Large Binary Messages?

Posted in

Sending and receiving binary data has traditionally been a problem when implementing SOAP messaging, primarily because XML is a text-oriented encoding mechanism.

To form part of a SOAP message body, you must encode the binary data as base64 data. This encoding results in a portable format for the data that can be encoded as XML, but can generate a message that may be inefficient to transmit due to its increased size. Also, XML parsers often need to read all of the data for a message into memory before they can process it. Therefore, they can require lots of memory to buffer the data.

WCF offers two efficient alternatives for transmitting large binary messages. These are MTOM encoding and streaming.

MTOM is a World Wide Web Consortium, or W3C, standard that evolved from SOAP with Attachments and Direct Internet Message Encapsulation.

By using MTOM, the WCF runtime splits any binary data in the SOAP message from any text data. The text data is packaged as a standard SOAP message. The binary data is transmitted as attachments that contain unencoded binary data. The SOAP message contains placeholders that contain references to the binary data. These references indicate where that data was located in the original message. When the message arrives at its destination, the WCF runtime rebuilds the original message from the SOAP message and the binary attachments.

Using MTOM typically results in a smaller message than using base64 encoding. However, a receiving application must reconstruct and buffer the entire message before it can process it.

Streaming is a data-transfer mechanism that enables the receiver to start processing the data before the entire message has been received. WCF transmits the stream in manageable chunks to the receiver, which can start to process the data immediately. By using streaming, neither the sender nor the receiver requires a large buffer to hold the message.

During streaming, the sender obtains a .NET Framework input/output stream and then passes the stream to the receiver. If the service passes data to the client application, the stream is passed as a return value from an operation. If the client application passes data to the service, the stream is passed as a parameter to the operation. The receiver then starts to read from the stream that the WCF runtime created and closes the stream after the data transfer completes.

Streams can impose restrictions on your service, such as the type of security that you can use. For example, if you use streaming, you cannot use message-level encryption, so you need to resort to transport-level security to protect streamed messages