Show TOC

SOAP Message Transmission Optimization Mechanism (MTOM)Locate this document in the navigation structure

Use

An advantage for modeling the payload of a message with XML Schema is that the transfered business content can later be transfered to a structured and readable form. The format of the payload is character string-based. Depending on the code page used, only a limited number of characters can be differentiated.

The format of binary data (photos, audio files, signatures, and so on) is more compact than the character string-based format of the payload but due to the larger value area of the binary data format it cannot be displayed with character string-based code pages.

There are therefore two approaches for transfering binary data with a message:

  • The binary data is transfered in compact binary format as a MIME attachment of the message. The advantage is the compact display of the data. The disadvantage is that you are not able to see the payload explicitly, it is an attachment to the message.

  • The binary data is converted to a character string-based format when creating the payload at the sender and transfered as content of an element of the payload. The advantage is the explicitly visible modeling of the data in the payload. The disadvantage is the memory-intensive display of the data which you do not usually need to acces during the transfer (or during a mapping).

SOAP Message Transmission Optimization Mechanism ( MTOM for short) is a performance optimization for transferring binary data using the SOAP protocol which includes the advantages of both approaches. Instead of including the binary data in the payload, the statement <xop:include> in the payload uses a GUID to refer to the MIME attachment that is sent in compact binary format with the message.

The MTOM standard recommended by the World Wide Web Consortium assumes that the binary data in the payload are stored as content of an element of type xsd:base64Binary.

For more information on MTOM, see http://www.w3.org/TR/soap12-mtom/Information published on non-SAP site.

Implementing MTOM in the Web Service Runtime

You can (de)activate MTOM optimization in the configuration of the Web service runtime for both direct (point-to-point) connections and for extended communication using the Integration Server. The MTOM optimization can be (de)activated for the following transport paths:

  • Direction communication (point-to-point). Here you can specify for the sender if MTOM optimization is to take place.

  • For transfering a message from a sender to the Integration Server using Web service adapter (adapter type WS).

  • For transfering a message from the Integration Server to a receiver using Web service adapter (adapter type WS). Here the Integration Server is the sender where the base64Binary binary data is stored before sending the message as an attachment according to MTOM.

What now has to be done at the sender to transfer the binary data in an MTOM-optimized way? Nothing. If the MTOM-optimization is activated, the application developer needs only the refer the binary data coded in base64Binary to the field that was modeled in the ES Repository as an element of type xsd:base64Binary. When creating the message, the Web service runtime automatically recognizes that the data can be stored as an attachment. If they are to be stored depends on the size of the data (if the binary data is not very large - such as a signature, for example - then it can be better not to store the data at all).