Message Transmission Optimization Mechanism Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Web Services provides the backbone of Service Oriented Architecture that enables the communication among the application over the Internet. Web Services provides very efficient way of integrating various applications that are running on different platforms and using different types of messaging paradigm. Web Services allows transfer of any type of information in any encryption format. Different techniques have been used to attach binary files in SOAP messages. This paper presents a study of Message Transmission Optimization Mechanism (MTOM) technique for Web Service attachments.


Nowadays, the businesses involve very flexible networks working with business applications that are spread across and within the organizational boundaries. The main challenge here is to integrate such heterogeneous systems and interoperate among them. To attain this functionality Service Oriented Architecture comes up, which is mainly consists of Web Services which are used to expose the functions of business applications.

Web Services are available as services to other applications and can be accessed through internet. So, all kind of internet protocols, encryption decryption methodologies can be applied to web services. It also provides the loose coupling, reuse of services for interacting with different services. Web Services use the XML as messaging data format to communicate with other applications. XML provides a meta-language, which provides an easy way to write specialized languages like WSDL, SOAP in order to express complex operations between clients and services. The major aspect of performance of web services depends on the time required to transfer the SOAP message from server to client. The bigger the message the more time will be required for message transfer. In general, the SOAP messages are very efficient in sending text data in a structured way. However, the problem comes when the data exchange consists of binary data such as multimedia data like images, video or documents like text documents, pdf files or any other binary data like executable files. The binary data can be passed along with the SOAP message as an attachment or it can be embed into the message itself. When such data is attached to SOAP, the overall size of SOAP message will increase. Also serializing the binary data into XML is not always sensible, especially data like large images, MPEG movies, etc. Therefore, some kind of optimization needs to be applied in order to reduce the overall size of message. There are some techniques that allow doing this task. MTOM, SwA, DIME are some of the example techniques that support the attachment of binary data to SOAP message. In this paper we will look into the MTOM technique, how it works, its advantages and disadvantages over other similar techniques.

Message Transmission Optimization Mechanism (MTOM)

What is MTOM?

SOAP Message Transmission Optimization Mechanism (MTOM) is a standard developed by the W3C - World Wide Web Consortium. MTOM provides a mechanism to optimize the transmission of a SOAP message by re-encoding particular portions of the message and at the same time presenting the information set in an XML format to the SOAP application [4]. In other words, it is "the use of MIME to optimize the bit stream transmission of SOAP messages that contain significantly large base64Binary elements" [1].


The main reason to use MTOM is to improve the performance of web services operations while handling the binary data efficiently.

As the internet technology and the use of web applications started growing up, there comes many reasons to send binary attachments, such as images or other binary files, along with a Web services request. There are 2 major aspects that need to taken into consideration while dealing with large transfers over internet. First, transfer as less as possible in terms of size in bytes of data, so that less amount of bandwidth will be used. Second, instead of completely reading the message into server side buffer and then sending it to client, it's always important and efficient to send the data chunk byte by byte, in a stream. There are many techniques that are being used to send binary data over web services, such as:

Inline use of base64Binary encoding: Here the binary data is included directly inside the SOAP payload by using the base64Binary Encoding. However, this direct inclusion of binary data into the SOAP increases their size by 33%, which can significantly affect the transfer time of message if the binary objects are very large [3].

Using SOAP with Attachments (SwA): The binary data is encoded using SwA formatting which allows the attached content to be referred from SOAP body elements and from SOAP header elements as well. This method provides the capability to deliver the SOAP messages along with attachments of binary data while using any protocol that is capable of delivering MIME content.

Using XML-binary Optimized Packaging (XOP) and MTOM: It provides optimization of binary message data transportation. This optimization is available and should be used only for binary data or content. MTOM uses XOP in the context of SOAP and MIME over application layer protocol HTTP [5]. It provides the benefits of both of the above where the data attachment is actually sent outside the SOAP message with just a reference to it but it looks like that the attachment is embedded into the SOAP message.


MTOM and XOP go hand in hand and often referred as MTOM/XOP. XML-binary Optimized Packaging abbreviated as XOP is a standard and can be used for any XML-based format; MTOM is just a description of how XOP is layered into the SOAP HTTP transport. XOP is an alternate method of serialization of XML. The main issue that MTOM/XOP tackles is the transmission of unknown binary data along with the response XML document.

Working of XOP

XOP processing engine takes the XML as input and serialize it into the MIME multipart/related package message. Also, if there is any base64Binary data present in the SOAP message, then XOP engine recognize that and packages it separately inside the MIME message. The new encoded size of the binary data is considerably smaller than the original one, because the attachments are processed and encoded in binary format. "The XOP processing converts the XML in the SOAP message to XOP format by replacing the base64Binary data with a special <xop:Include> element that references the relevant MIME attachment using a URI" [1].

Fig. 1: SOAP message packaged with MTOM

The modified SOAP message is called the XOP document and it creates the root document within the modified message. Also, the new modified XML document marks the locations of those converted binary data packages with special elements with the URI that identifies the respective data location. As shown in above fig. 1 the XOP package consists of both XOP document and binary attachments together. When this XOP package is applied to the SOAP MTOM specification, the XOP package is considered as a MIME message in MTOM format. A typical MTOM message is identified by a Content-Type with a type of "application/xop+xml". This can be seen in following diagram:

Fig. 2: Sample content-type header

In contrast to normal traditional approaches deals in handling of binary data in XML documents, it's not mandatory for the XOP to have binary data encoded in base64Binary format. The data can be represented in its original format as octet streams. An application, which make use of MTOM and parses the XOP package, can directly use the octet streams, or it can calculate the base64 binary format for that particular octet stream.

Working of MTOM

MTOM provides a concrete implementation for using XOP to optimize the transmission of SOAP messages across web service invocation. It specifies how XOP is layered and embedded into the SOAP HTTP transport. It also describes how to serialize a SOAP envelope using the XOP format and MIME Multipart/Related packaging. While using MTOM, the de-serialization of this transferred response SOAP message is done according to the standard XOP formatting technique.

Fig. 3: Working of MTOM

The above diagram shows the working of web service that uses MTOM for sending binary data across applications over SOAP message. Following steps are carried out in this process:

Sender of binary data has MTOM enabled web service. It creates the SOAP message similar to this one, where binary data is present inside tns:data tag.






The XOP processing engine present on client's side application server will detect the binary data that have format type similar to xs:base64Binary. It then takes decision whether it has to use XOP or not. This decision is based on the size of data to be transmitted. It then converts it into binary MIME multipart/related XOP package. This package contains SOAP message in XML format and binary attachment as a separate part. IT replaces the binary64 encoding data into an <xop:include> element that referring to the raw bytes being transmitted. Also, it attaches the The modified SOAP message will be something similar to this:




<tns:data><xop:Include href="cid:[email protected]"/></tns:data>





content-id:<[email protected]>


content-transfer-encoding: binary

Fig. 4: MTOM attachment format

The above diagram shows the modified sample MTOM attachment as a MIME document after XOP processing. Here the body part contains the URI reference to the MIME part which is binary version of attached base64binary encoded data. Also the body part can be signed/ encrypt to follow the WS-Security standard.

This modified SOAP message is sent across to the other application over internet.

The MTOM enabled web service at other end receives the message. Over there MTOM will detect the embedded format of SOAP message by looking at the XOP header part, and delegate the task to XOP processing engine.

XOP processing engine extracts out the binary data from the XOP package pass it in the desired format.

Optimizing the MTOM use

Make MTOM enabled on both server and client side (that means both applications participating in the web service operation).

In order to use MTOM functionality efficiently, provide a minimum threshold value for MTOM to get active. Otherwise, even the small amount of data will also get translated into binary MIME format, and thus taking extra processing time. So to avoid that provide a reasonable MTOM_THRESHOLOD_VALUE.

Use file caching mechanism provided by MTOM for incoming attachments. This gives the web service application server container the ability to handle very large attachments without buffering them in memory at any time. Also, if possible increase the Cache size, so that bigger chunk can be loaded into the cache.

Comparison with other techniques

SOAP with attachments (SwA) and WS-Attachments over DIME are the two other techniques that allow sending binary data over the internet across web services call.

SwA and MTOM are conceptually similar, and both encode the binary data present in SOAP message as a MIME attachment in octet/stream format. But the major difference between MTOM and SwA is that the SwA does not provide support for WS-Security, posing threat to sending binary attachments in secure way and to establish trust boundaries that spread across multiple organizations. Also not all vendors provide support for SwA. Due to this problem, "the W3C has decided to move away from SWA and adopt MTOM as the sole recommendation for attaching non-XML resources to SOAP messages "[5]. In addition to that author also said that "MTOM was designed to fix the issues with SWA, enabling it to work within the composable model of the Advanced Web services specifications and MTOM messages are actually valid SWA messages" [5].

The DIME (Direct Internet Message Encapsulation) specification was also created to deal with performance issues while processing MIME attachments. DIME provided a more efficient processing model, but still it failed to provide info set model for the message and attachment [6].  MTOM provides a compromise between the MIME model and the Web services model. MTOM provides backward compatibility to SwA, where all MTOM messages are valid SWA messages. Thus the MROM attachments can be easily passed to SwA applications or even to receive SwA attachments into MTOM application. "The MTOM attachment approach takes advantage of the SOAP infrastructure while also gaining transport efficiencies that are provided by SOAP with Attachment (SwA) solution "[3].

Following table shows the comparison on MTOM with other two techniques used for sending binary data across web service over the internet.

WS-Attachments over DIME






Potentially great



Poor cannot support WS-Security



Very good

Poor cannot support WS-Security


When to use

While interoperating with an existing DIME and WS attachment implementations

When not to interoperate with Microsoft platforms

The best choice for interoperability is MTOM

Microsoft support

ASP.NET with WSE 2.0


ASP.NET with WSE 3.0 & WCF supports MTOM

JAX-WS support


By default

When enabled

Axis support


1.x, 2.0



In this paper, the thorough explanation of usage of MTOM/XOP and its advantages over other techniques used for sending binary data over web services has been given. As per Young Yang, "MTOM/XOP provides optimized SOAP message transmission, which boosts the performance of web service" [2]. Now the frameworks like Axis, CXF, and Fuse provide in built support for MTOM. This results in increasing popularity to send binary data along with SOAP messages.