Marc Hadley's Blog

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.

Comments

• J2EE and .NET interoperability
  Microsoft published an article that discusses Attachments:

  http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/opaquedata.asp

  Also, here is a note about JAX-RPC 1.1.2

  https://jax-rpc.dev.java.net/whitepaper/1.1.2/attachments.html
  

  Posted by: sullis on August 27, 2004 at 07:50 AM

• J2EE and .NET interoperability
  Interesting article from Microsoft. I'd note that a couple of the objections to SwA are no longer valid though. Specifically the WS-I attachment profile is now final and both the WSS TC at OASIS and the WS-I Basic Security Profile WG are jointly working on a solution to integrate attachments with WSS.

  I'd also note that DIME didn't really solve the buffering problem since it only provides a length for each chunk rather than an overall length for the reassembled data.

  On the binary XML question, the article ignores the work going on at ISO/ITU-T to standardise ASN.1 based binary serializations. You can find out more about that at the following URLs: https://jwsdp.dev.java.net/fast/ and http://java.sun.com/developer/technicalArticles/WebServices/fastWS/.

  Posted by: mhadley on August 27, 2004 at 08:27 AM

• If I understand this correctly, WS-I attachments does not reduce the transmitted message size when sending binary data (it still has the 4/3 increase that comes from base64 encoding)? The MS paper seemed to imply that when using SwA (which will now be WS-I attachments), the binary data could be sent at original size because of MIME encoding. However, I thought MIME still uses base64 for binary data.

  If this is the case, then MTOM/XOP is the only standard that solves the issue of having a large message size increase, it seems (that and Sun's FWS, but excluding FWS for now).

  I have an application where I need to send large message sizes (approximately 2MB) through a web service, but cannot handle a 1/3 increase in the size. No standard seems to solve that problem yet, so I'm looking for which one(s) will solve this in a year or so. It looks like this is just MTOM/XOP, am I wrong?

  Posted by: alchemista on October 04, 2004 at 03:08 PM

• No, the WS-I and MTOM attachment schemes both have the benfit of being able to send binary data without base64 encoding. When transmitted over an 8-bit safe path there's no need to apply any 7 bit safe transfer encoding to binary MIME parts.

  Posted by: mhadley on October 04, 2004 at 03:46 PM

• Thought this may be relevant to this Blog
  "Interoperability With Patterns and Strategies for Document-Based Web Services" http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns2/index.html

  Posted by: sameer_t on January 28, 2005 at 06:36 AM

This work is licensed under a Creative Commons License.