Many products like JAXWS-RI use MTOM in an improvised manner. If the size of the attachment is less than a specific threshold (ideally 1KB) then the binary data is transmitted as base64-encoded due to the overhead mentioned above. But if the attachment is above the threshold size then it's transmitted as defined in the MTOM specification. Refer to Lising 3 for a sample SOAP message for MTOM.

Fast Infoset
Fast Infoset is a standard for specifying a representation of an instance of the XML Information Set using ASN.1 binary encodings. Fast Infoset specifies a binary format for XML documents and Fast Infoset documents are faster to serialize and parse and smaller in size than the equivalent XML documents.

Fast Infoset can also be used to handle attachments efficiently. As said above, as Fast Infoset describes binary encoding of the XML Information Set it allows for the direct embedding of binary data. In a way, Fast Infoset does what MTOM/XOP can do and a lot more. The performance of a Web Service with Fast Infoset is better than MTOM. Though Fast Infoset is being support by various platforms and frameworks, it's not popular yet; it's still emerging. This is definitely a promising technology and should be explored more.

Limitations: Not human-readable, not self-describing and tightly coupled since both the sender and receiver need to have the Fast Infoset processor. Once encoded as Fast Infoset, the XML can't be validated against the schema.

Securing Attachments
With the ever-increasing adoption of SOAP as the messaging protocol in organizations and the need to send sensitive data as attachments to the SOAP message has called for matured mechanisms for securing attachment payloads. The traditional WS-* specifications like plain WS-Security can work only for securing the XML content in the SOAP message but not the binary attachments that traverse outside the SOAP message. Hence, the binary data sent as base64-encoded can be secured using WS-Security, but as already seen, this comes with a heavy price tag in the form of overhead if the data is huge. One way of securing attachments can be the use of transport-level security like HTTPS. But HTTPS can't provide features like encrypting part of the SOAP message. Also, HTTPS is unsuitable for a multiple-hops scenario.

There's been some amount of work done in this area. OASIS came out with a specification, Web Services Security SOAP Messages with Attachments (SwA) Profile 1.1, an extension to WS-Security that describes how SOAP attachments can be secured for attachment integrity, confidentiality, and origin authentication, and how a receiver can process such a message.

Conclusion
With an ever-growing number of enterprises embracing Web Service technologies and with demand for sending binary data on the rise, many techniques for handling attachments came to the fore. This paper tried to identify various such techniques in use and evaluate them by detailing the pros and cons.

References:
  •   SOAP Attachment State of the Art by Miko Matsumura
www.infoq.com/news/SOAP-Attachment-State-of-the-Art

  •   Transferring Data securely using the MTOM Standard Part 1 by Digg, Reddit, Del.icio.us and DZone
http://microsoft.apress.com/asptodayarchive/73639/ transferring-data-securely-using-the-mtom-standard-part-1

  •   Evolution of Web Services Attachments Technologies by Canyang Kevin Liu and Sanjay Patil
www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/ uuid/3b28e590-0201-0010-968f-e10ed5328191

  •   Boost Web Service Performance in JAX-WS with Fast Infoset by Young Yang
http://java.sun.com/developer/technicalArticles/xml/fastinfoset/

  •   Web Services Security SOAP Messages with Attachments (SwA) Profile 1.1
www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf

  •   W3C MTOM specification
www.w3.org/TR/soap12-mtom/