Marc Hadley's Blog

August 2004 Archives

Attachments for SOAP

This week has seen a bumper crop of specification releases in the area of SOAP attachments. On Tuesday WS-I released the final version of Attachments Profile 1.0 along with the associated Basic Profile 1.1 and Simple SOAP Binding Profile 1.0. On Thursday W3C released Candidate Recommendations of XML-binary Optimized Packaging (XOP), SOAP Message Transmission Optimization Mechanism (MTOM) and the Resource Representation SOAP Header Block.

So, you may be asking yourself, what are the differences between the WS-I and W3C approaches and do I need to worry about them ?

• The WS-I approach assumes that there is a SOAP envelope and one or more associated attachments. E.g. one could envision an insurance claim that consists of a SOAP envelope containing an XML based insurance claim in the SOAP body plus a photo of the crash scene as a JPEG attachment. The WS-I attachment profile defines how to use the WSDL MIME binding to describe the presence of attachments, the details of how to use MIME to create a package of a SOAP envelope and its associated attachments, and a standard mechanism to reference attachments from within the SOAP envelope.
• In contrast, the central conceit of the W3C approach is that there is no such thing as an attachment to a SOAP message but instead all of the data of interest is contained within the infoset of the SOAP Envelope itself. Using the example above this might entail a SOAP envelope containing an XML based insurance claim in the SOAP body with an embedded photo of the crash scene. Unfortunately XML cannot directly contain binary data so the photo would need to be encoded using base64 prior to embedding. MTOM/XOP describe how to serialize such a SOAP envelope without incurring the penalty of base64 encoding by extracting those parts of the message that would require base64 encoding (i.e. the photo) and instead serializing them as separate parts in a MIME package.

The serialized form of the two approaches is remarkably similar (there's only so many ways to boil an egg) but processing semantics differ. E.g. if I use XML signature to sign the insurance claim in the WS-I approach then I would actually be signing the reference to the photo rather than the photo bytes (WS-I is working on a solution to this in the Basic Security Working Group), if I do the same in the W3C approach then I would sign the base64 serialization of the photo (at the cost of having to do the base64 encoding that XOP/MTOM would otherwise avoid after all).

To answer the second part of my question (do I need to worry about the differences): the JAX-RPC 2.0 (JSR 224) and JAXB 2.0 (JSR 222) Expert Groups are working hard to make sure that use of either mechanism is as transparent to Java developers as possible. These two specifications will support use of either approach and will hide as much of the complicated plumbing and conceptual doublethink as is practical. I expect the next drafts of both specifications to address attachments support.

This work is licensed under a Creative Commons License.