WSE Series III : Sending Attachments thru Web Service

There are three different methods of sending attachments naely,

1. Base64 Encoding
2. SOAP attachments
3. DIME and WS-Attachments

Base64 Encoding:

In this method the attachment is included as binary data encoded in Base64 format inside a SOAP envelope. The XmlTextWriter class can be used to generate Base64 encoded attachments. The XmlTextReader class can be used to decode that binary stream back into the original data format. This mechanism is very resource intensive and the size of the encoded data is much higher than the actual data size. Say for example a 14KB binary file can become a 19KB text when encoded. Base 64 encoding has been around for some time and has probably received a bad rap for the opaque data problem. Base 64 encoding has some extremely nice benefits, such as its seamless integration in SOAP envelopes, it is a well-known standard, and it has better size efficiency than structured XML.

Interoperability: Excellent. Base-64-encoded data is understood on every platform that understands XML. Whether the opaque data included is in an interoperable form may be another question that is not already positively answered, like it is with the XML Representation approach. However, if you are sending opaque data and you are doing so with a Web service, then the interoperability issue has probably already been positively addressed.

Composability: Excellent. The fact that the data lives within the SOAP envelope means that all the WS-* specifications that Microsoft has developed with its partners will work seamlessly with a base-64-encoded XML element.

Efficiency: Modest. Although base-64-encoded data is usually more efficient from a message-size perspective than structured XML, as mentioned earlier, it still bloats the data by about 33% even when only single byte characters are used. The character set for base-64-encoded data does not require multi-byte characters, so if you can use UTF-8 encoding you can avoid the extra 100% increase in size. Of course you cannot mix single and multi-byte encodings within a single XML message, so if the rest of your SOAP envelope requires multi-byte encoding, then you have to live with the two-fold increase.

When to use: Base 64 encoding is probably the best way to pass opaque data if transport size efficiency is not your first concern. It will work seamlessly with higher-level WS-* protocols and is smaller than a standard XML encoding.

SOAP Attachments:

This is a much familiar method of binding a SOAP message with MIME enabling the usage of MIME encapsulation. In this mechanism there is a primary SOAP message and one or more attachments. SOAP with Attachments was the first attempt by Microsoft (along with Hewlett Packard) at solving the opaque data/attachments problem.

Interoperability: Potentially decent in the future with some notable exceptions. SOAP with Attachments is simply a W3C Note; it is not a W3C Recommendation or even a W3C Working Draft. Presumably, after the profile is final and conforming implementations are available, they should be interoperable. The problem is that when it comes to the attachments profile, WS-I is ignoring the fact that SwA breaks the Web services model. Among other issues, SwA specifically does not work with WS-Security at this time.

Composability: Poor. Without an encompassing SOAP envelope to build upon, SOAP with Attachment messages do not compose well with the WS-* specifications. In particular, a non-SOAP-message-based transport cannot support the recently finalized OASIS WS-Security specification.

Efficiency: Good. Although not as efficient and streamlined as the DIME and WS-Attachments approach, opaque data can be sent in its raw form without base 64 encoding. There are issues with buffering incoming data due to the lack of a length header on the message sections, but it is a viable solution to the problems around sending potentially large, opaque blocks of data.

When to use: If you have interoperable SOAP with Attachments implementations on all the platforms that you might want your Web service to be accessible from, then you might consider using SwA. If you find you are really only communicating between computers running the same platform, then the reason for using Web services (interoperability) is moot, and you might as well use a proprietary communication mechanism. Finally, you will specifically want to avoid SwA if you need OASIS-compliant WS-Security type signatures or encryption on your opaque data.

DIME and WS-attachments:

Direct Internet Message Encapsulation (DIME) is a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message construct. Each payload is described by a type, a length, and an optional identifier. Both URIs and MIME media type constructs are supported as type identifiers. DIME and WS-Attachments is a faster and more efficient solution to the attachments approach to opaque data compared to SOAP with Attachments, but has the same composability problems as SwA.

Interoperability: Modest. Although DIME is a simpler protocol than MIME that would bode well for its interoperable possibilities, efforts for creating widely interoperable DIME and WS-Attachment implementations have stopped. As with SwA, there is no recommendation for DIME or WS-Attachments at this time. Microsoft tools currently only support a DIME approach to attachments.

Composability: Poor. As is the case with SwA, a non-SOAP envelope approach to messaging like DIME and WS-Attachments limits the ability of the higher-level Web service specifications to properly work upon a message.

Efficiency: Very Good. DIME is a simple binary format for transmitting raw data and has support for such efficiencies as chunking and jumping easily between message records.

When to use: Web services are all about interoperability, and if DIME and WS-Attachments does not provide wide interoperability, then there is little reason to use it. If you are not interested in interoperability but believe DIME is attractive for its performance reasons, then you would probably be better off using other proprietary, high-performance solutions such as .NET Framework Enterprise Services. DIME and WS-Attachments also suffer from the same limitations as SOAP with Attachments, in that it is only viable if you do not require higher-level capabilities for your Web services. At this point the only real reason to be using DIME and WS-Attachments would be to interoperate with an existing DIME and WS-Attachment implementation.