Web Services existed before the principles of SOA were defined but they came into the limelight after it was realized that they were ideal for implementing services and hence form the building blocks of SOA.

SOAP and the Need for Attachments
SOAP is a specification that details how to encode the information to be exchanged in a Web Service. It's become a standard messaging protocol for Web Services. Since it's an XML-based, it's lightweight and stateless. SOAP can be used over various protocols like HTTP, HTTPS, SMTP, and FTP, but it's mostly used over HTTP. In the early days of Web Services and SOAP, because of the XML nature of SOAP, it wasn't possible to exchange non-XML data in a standard and efficient way. As the use of SOAP messages increased in organizations for exchanging information, the need to send non-text information (binary data) has also become important.

Use Cases
Let's take a look at a couple of use cases in which attachments are useful. In the banking domain, banks and financial institutions exchange paper-based financial instruments for clearing. In a few countries, to eliminate the overhead involved in exchanging physical checks, the banks have been mandated to move to an image-based solution, where the financial instruments must be digitized. In this new solution, banks have to transfer images of the checks along with the supplementary data. The supplementary data being small can go as XML content and the images of checks can be sent as attachments to the SOAP messages.

It's also a common requirement for sending binary data in the insurance domain. A Web Service application processing insurance claims requires images of the vehicle that met with an accident along with the claim document. In this case too images of the vehicle can be sent as attachments to the SOAP message, while the claim document itself can be sent as XML content in the SOAP message.

Since XML is a text-based format, it's difficult to include binary data in it. One solution is to embed the binary data as text using base 64 encoding. But the drawback to this method is that the performance degrades as the size of the attachment increases. The base 64 adds an extra 30% to the size of the original binary format because of the 4(characters):3(binary bytes) ratio, incurring a greater bandwidth over the network. And there's also overhead in encoding and decoding. However, it's certainly a good option for smaller attachments and has excellent interoperability but it's not an option for larger attachments. So a need arose for a better way to handle binary data.

Technologies Used for Attachments in SOAP
MIME (Multi-purpose/Multimedia Internet Mail Extensions)
One solution that emerged as a standard to send attachments in SOAP is MIME, in which binary information is sent as an attachment outside the SOAP message. MIME was originally devised for sending attachments in e-mail. MIME is streaming-friendly and so can handle bulky payloads smoothly.

Limitation: The limitation in MIME is due to the use of text strings in a MIME package to delineate boundaries between parts. To find a boundary, the whole message has to be scanned for that string. If a part, by coincidence, contains that delimiter string, boundaries of the parts can't be detected correctly.

DIME (Direct Internet Message Encapsulation)
To overcome the limitation in MIME, DIME was proposed as an alternative standard, which uses offset values as a delimiter instead of a string. Though less flexible than MIME, DIME describes a simpler message format, which in turn provides for faster and more efficient message processing.

XOP (XML-binary Optimized Packaging)
XOP defines how to serialize SOAP messages with binary contents, preserving the XML Infoset. It's a generalized concept and also used for SOAP.

Standards for Attachments in SOAP
SwA (SOAP Messages with Attachments)
SwA was the first standard that tried to address the problem of sending attachments with SOAP. SwA is a W3C standard for attaching binary data along with SOAP envelope using SOAP 1.1 and MIME. SwA uses the HREF attribute and Content-ID MIME header to relate attachments to SOAP message parts. B2B standards such as ebXML, RosettaNet, AS2, and the BizTalk Framework use SwA as the messaging layer for its flexibility.

Limitations: SwA doesn't well define how to clearly describe an attachment in WSDL. An attachment by way of SwA meant two data models in one message and these two data models don't operate with existing XML technology, i.e., fail to provide a common logical view. And all the limitations of MIME hold true for SwA as well.

WS-Attachments
WS-Attachments use DIME for SOAP attachments. But, since most enterprises had already started using SwA and since the shortcomings in SwA, because of its use of MIME, weren't that severe, WS-Attachments with DIME didn't get adopted as a standard. It didn't gain much momentum due to the lukewarm response from industry practitioners. Refer to Listing 1 for a sample SOAP message for WS-Attachments.

Limitations: All the limitations of SwA also hold true for WS-Attachment except for the limitation of MIME, which was overcome by using DIME.

Attachment Profile 1.0
Though SwA was widely used, there were still two main concerns with SwA. First, there is no mechanism to identify from WSDL 1.1 that binary data is attached in the SOAP message. And second, there is no way to map MIME parts to corresponding WSDL message parts. SwARef introduced by Attachment Profile 1.0 solved these problems. Refer to Listing 2 for a sample SOAP message for SwARef.

PASwA (Proposed Infoset Addendum to SOAP Messages with Attachments)
PASwA emerged to address some of the shortcomings of SwA. PASwA aims at providing a common logical view to SOAP messages with attachments by using XML infoset. It defines a set of constructs to create a relationship between the SOAP message and its attachments. The principles of PASwA got grouped into four categories in W3C: (i) XML-binary Optimized Packaging (XOP); (ii) SOAP Message Transmission Optimization Mechanism (MTOM); (iii) SOAP Resource Representation Header; and (iv) Assigning Media Types to Binary Data in XML.