Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News SOAP Attachment State of the Art

SOAP Attachment State of the Art


The problem of large binary attachments to SOAP has long been an issue in Web Services based SOA implementations.

Colin Adams of in his blog, posts a great overview of SOAP attachment technology standards and specifications. Referring to the practice of encoding binary as text and stuffing it into SOAP, he writes:

There is an obvious drawback. Performance takes a noticeable hit for larger messages. Firstly, the Base 64 adds 30% to the size of the original binary format due to the 4(characters):3(binary bytes) ratio, incurring a greater latency over the wire, and secondly there is some expensive decoding and encoding to be done at either end. Particularly the decoding and some tests indicate factors of 3-4 times slower performance. However, for the most part it is certainly an option for smaller messages and is guaranteed to have excellent interoperability.

For larger messages and applications that require speedy operation, Base 64 is not the solution.

People recognized fairly early on after the birth of SOAP that they needed a way to attach a binary file to a SOAP message. This was exactly the approach of the first “attachment” specification that came about. But it failed.

The response to this was the development of SOAP with Attachments specification, which was criticized in this blog for bringing two data models and breaking the composability of the message and the ability to work with standards such as WS-Security. Colin goes on to describe the state of the art in resolving some of these complex challenges.

SOA takes on many incarnations, including large attachment, asynchronous document styles. Attachments can include huge PDF documents, images or even executable binaries (much less common). In some use cases, email messages can be transformed through an intermediary into SOAP and back, and attachment handling can be one of those use cases. Attachments may not be a crucial issue in your SOA, but should they be neccesary, this blog entry provides a terrific review of the state of the art for this practice.



Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Great article: SOAP growth pains

    by Guy Crets,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Indeed a great article! The MTOM/XOP recommendations finally brought a consensus.

    Still, it remains strange to see how ebXML back in 2001 already defined SOAP with attachments with digital signatures based on XML signing! Many other B2B standards such as RosettaNet, AS2 and the BizTalk framework are also based on a MIME structure. Almost all vendors endorsed/implemented SOAP with Attachments (SwA), with one notable exception, Microsoft. Microsoft came up with the awful DIME.

    SwA made sense and its disadvantages are exaggerated in my opinion: a WS mediation framework or ESB will have to manage extra context information (e.g. HTTP headers) outside the XML infoset anyway.

    Anyway, the attachments story is a very nice example of the growth pains of web services.

  • SwA Performance Is Really Bad

    by Frank Cohen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    How bad?

    Read my findings in chapter 4 of my new book FastSOA at The writer's draft of the chapters are available for free download for the next month or two. In this chapter I show the scalability problems in using SOAP with Attachments and other encoding styles.

    -Frank Cohen

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p