Chapter 14: Web Services Interoperability, Part 2: Sending Binary Data

Up to this point in the book, the discussions and samples of interoperability using XML Web services have shown request/response style method calls. In our previous samples, we've seen clients in both .NET and Java ask for recommendations to buy and sell stocks and then for the Web service to reply with an appropriate value. These examples are fine for demonstrating data returning from a method, but sometimes an application has a requirement to send or receive binary data . Examples of binary data that an application might need to send or receive are a file (possibly even an executable file) from a Web site, an attachment to an e-mail (such as a document or file), and a collection of images (such as a photo album or collection of JPEG files). We need to provide a way for .NET and J2EE applications to use Web services to exchange these types of information. More importantly, we need to accomplish this in a platform-independent manner so that a Java client can receive a binary attachment from a .NET Web service, and vice versa.

In this chapter, we will explore the concepts of exchanging binary data using a Web service. We'll start by looking at a specification known as DIME (Direct Internet Message Encapsulation), and then examine how DIME can be implemented by using both Microsoft WSE (Web Services Enhancements) 1.0 Service Pack 1 and GLUE 4.0.1 (a product of The Mind Electric). The sample will show how to pass a document created in Microsoft Word between a Java Web services client, a .NET Web service, and a .NET Web services client. After looking at this implementation, we'll briefly discuss other proposed specifications and ideas about where the industry is heading.

DIME and WS-Attachments

Direct Internet Message Encapsulation, as its name suggests, is a specification that covers a message format for sending binary data over the Internet. A link to the latest draft of the specification and additional information can be found at the following address: http://msdn.microsoft.com/ webservices /understanding/ specs /default.aspx?pull=/library/en-us/dnglobspec/html/dimeindex.asp .

A DIME message can be used to deliver a binary payload, as defined by the sending application. The DIME message can be contained in one or more records; each record has a payload length value that specifies the number of bytes in the payload. The type of the payload can also be defined (for example, a media type). Chunking allows the payload to be split, and an ID associated with a record allows it to be cross-referenced within the message.

So, given that it's been possible to send binary attachments over the Internet for years , why is DIME used for sending attachments via Web services instead of other formats? If you have worked with e-mail programs, you might have heard of the term MIME, which stands for Multipurpose Internet Message Encapsulation. This is the format used when sending attachments and documents with an e-mail message. An earlier specification of how attachments could be sent via Web services and SOAP, named SOAP messages with Attachments (SwA), was actually based on a SOAP message that used MIME to bind an attachment. This specification was coauthored by Microsoft and Hewlett Packard in December 2000.

The Microsoft DIME specification offers advantages over SwA in two major areas: enhanced performance and interoperability. DIME is more lightweight than MIME and doesn't require any encoding of the binary data. This in turn makes parsing quicker and memory allocation generally more efficient. DIME also has a simpler syntax than MIME ”which makes it less flexible than MIME, but leads to better interoperability between parsers. For additional information on DIME vs. MIME, I recommend the following MSDN article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/ service01152002.asp .

DIME defines a mechanism by which arbitrary data can be delivered in a collection of formatted records, but to send this type of data over a Web service requires a link between the DIME data and the Web service itself. This link is provided by the WS-Attachments specification.

WS-Attachments defines a primary SOAP message part and secondary parts. As the previous MSDN article implies, you can think of this as a stack of paper attachments bound with a paper clip, with a memo on top. The memo, which equates to the primary SOAP message, contains the list of other attachments (secondary parts ) in the stack of paper.

WS-Attachments indicates that the primary SOAP message part must be contained in the first record of an associated DIME payload. The primary SOAP message part is able to reference its secondary parts by using an href attribute. As with HTML, the href attribute can be used to reference an external URL. By using WS-Attachments this can also be the ID of a secondary part.

So, where does this leave us? The .NET and Java interoperability samples you'll see in this chapter use the DIME specification to pass an attachment between a .NET and Java client. As we look at future specifications toward the end of the chapter, you should be able to see how the specification can be used today and what could be in store for future applications.