How do I mark SOAP service 'MTOM enabled'

Question

This is not Java specific question, but let's have an example in Java: It is a standard practice in the Java world to add xmime:expectedContentTypes="*/* to base64 elements to enable MTOM processing on the server side - it results in the @XmlMimeType annotation, use of DataHandlers instead of byte arrays etc. While this description is of course greatly simplified, xmime:expectedContentTypes="*/* is usually recognized as 'MTOM ready' by the developers (and more importantly also by the implementing libraries) when seen in the schema. From what I've gathered from the examples, the situation is the same in the C# world.

It does however make no sense to me - the attribute specifies what kind of data we might actually expect in the XML, not that it can be used together with MTOM. I have also not found any direct connection between expected content type and MTOM in any RFC or similar document for SOAP 1.1.

My question can be phrased in two ways:

1. How does the service make clear that it accepts / serves binary data as MTOM attachments in the request / response?
2. How does the client correctly recognize that the binary data can be sent / obtained by using MTOM attachments for the given service?

Answer 1

It seems you are slightly confused between attachments, SOAP Attachment and MTOM.

SOAP-Attachment was first introduced in December 2000 as a W3C note (not a specification) and defined an extension to the transport binding mechanisms defined in SOAP 1.1. In particular, this note defined:

a binding for a SOAP 1.1 message to be carried within a MIME multipart/related message in such a way that the processing rules for the SOAP 1.1 message are preserved.The MIME multipart mechanism for encapsulation of compound documents can be used to bundle entities related to the SOAP 1.1 message such as attachments.

In simple terms, it defined a mechanism for multiple documents (attachments) to be associated with SOAP message in their native formats using a multipart mime structure for transport. This was achieved using a combination of "Content-Location" and "Content-ID" headers along with a set of rules for interpreting the URI that was referred to by "Content-Location" headers.

A SOAP message in this format can be visualized as below (encapsulated as multipart/mime):

This is also the format that you might have worked with when you used SAAJ, but is not recommended anymore, unless you are working with legacy code. The W3C note was later revised to a "feature" level in 2004 (along with SOAP 1.2) and was eventually superseded by SOAP MTOM mechanism.

SOAP Message Transmission Optimization Mechanism (MTOM) is officially defined as not one, but three separate features that work together to deliver the functionality:

1. "Abstract SOAP Transmission Optimization Feature" describes an abstract feature for optimizing the transmission and/or wire format of the SOAP message by selectively encoding portions of the message, while still presenting an XML infoset to the SOAP application.

2. "An optimized MIME Multipart/Related serialization of SOAP Messages" describes an Optimized MIME Multipart/Related Serialization of SOAP Messages implementing the Abstract SOAP Transmission Optimization Feature in a binding independent way.

3. "HTTP SOAP Transmission Optimization Feature" describes an implementation of the Abstract Transport Optimization Feature for the SOAP 1.2 HTTP binding.

If you read the second document, you will realize that "attachments" has been replaced with XML binary optimized "packages" or XOP.

A XOP package is created by placing a serialization of the XML Infoset inside of an extensible packaging format (such a MIME Multipart/Related, see [RFC 2387]). Then, selected portions of its content that are base64-encoded binary data are extracted and re-encoded (i.e., the data is decoded from base64) and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs.

In simple terms, this means that instead of encapsulating data as "attachment" in a multipart/mime message, the data is now referred to by a "pointer" or links. The following diagrams may assist in understanding:

Now that we have the background, let us come back to your questions.

1. How does the service make clear that it accepts / serves binary data as MTOM attachments in the request / response? It does not. There is no concept of an attachment with MTOM, and thus a server can't declare that it accepts attachments.

2. How does the client correctly recognize that the binary data can be sent / obtained by using MTOM attachments for the given service? Like I said above, there is no way for a client to do this as "attachments" are not supported.

Having said that, there is yet another W3C spec on XML media types that states:

The xmime:contentType attribute information item allows Web services applications to optimize the handling of the binary data defined by a binary element information item and should be considered as meta-data. The presence of the xmime:contentType attribute does not changes the value of the element content.

When you enable MTOM using xmime:contentType and xmime:expectedContentTypes="application/octet-stream (* should not be used), the generated WSDL will have an entry like this:

<element name="myImage" xmime:contentType="xsd:base64Binary" xmime:expectedContentTypes="application/octet-stream"/> This is server's way of declaring that it can receive an XML binary optimized package (which could be broken down into multipart MIME message).

When the client sees the above, the client knows server can accept XML binary optimized packages and generates appropriate HTTP requests as defined Identifying XOP Documents:

XOP Documents, when used in MIME-like systems, are identified with the "application/xop+xml" media type, with the required "type" parameter conveying the original XML serialization's associated content type.

Hope that helps!