SOAP makes provisions for sending binary files across the transport protocol by encoding the binary data with base64 and attaching the encoded data to the SOAP message.
This adds overhead on both the sending and receiving ends by adding an encoding or a decoding step. It also bloats the data encoded (this can be a significant bloat for large files). You could encounter problems if the attached files don't share the same character encoding. DIME (Direct Internet Message Encapsulation) allows you to send binary data so you can overcome these limitations.
The DIME specification provides a way to send binary data across the transport protocol by defining the data length and type attached in a few simple headers. The remaining data is the original, raw binary data. You can also use DIME messages to encapsulate SOAP messages and XML data. Multiple attachments, including chunked attachments, are divided into DIME records. Each record contains headers that describe the record that you're parsing.
A DIME generator produces DIME messages, which a DIME interpreter consumes. The DIME interpreter reads the DIME message in a serial fashion. The first five bits of the DIME record are the DIME version used to create the message. The next bit is the message begin (MB) flag, marking the first record of the DIME message. Only one record in the message can contain the MB flag. The next bit is the message end (ME) flag, which is the last record in the DIME message. Only one record can contain the ME flag; this signals the interpreter that this record is the last record in the DIME message. The next bit specifies that the records' contents have been chunked.
The remaining bits are as follows:
- Type_T (4 bits): the structure and format of the Type field
- Reserved (4 bits): reserved for future use
- Options_Length (16 bits): the length of the Options field in bytes
- ID_Length (16 bits): the length of the ID field in bytes
- Type_Length (16 bits): the length of the Type field in bytes
- Data_Length (32 bits): the length of the Data field in bytes
- Options: any additional data that the interpreter can use
- ID: a URI that uniquely identifies the record
- Type: the type of data in the record
- Data: the binary data
There is no requirement that says SOAP must contain a DIME message or vice-versa. However, if you're going to use DIME to send a SOAP message, then the first record must contain the primary SOAP message. When you send the message as a DIME message, you must specify the Content-type HTTP header as "application/dime". The WS-Attachments specification further defines additional rules to follow when using DIME to encapsulate SOAP messages.
Here's an example of a DIME message:
0001 1 0 0 0010 0000 0000000000000000
0001 0 1 0 0001 0000 0000000000000000
[55,206 bytes of JPEG image data]
In this example, spaces separate the header data, and hyphens separate each header for clarity. If you look at the Type_T bits, you'll see that there are two different values: 0x01 (which specifies a MIME type) and 0x02 (which specifies a URI type). The SOAP message record is a URI type whose value is "http://www.w3.org/2003/05/soap-envelope". The JPEG image record is a MIME type whose value is "image/jpeg". The SOAP message can easily cross-reference the image with the UUID that the ID header field defines. The rest of the DIME message is pretty self-explanatory.
In order to utilise DIME messages, you can use the available tools in various languages (i.e., instead of writing your own generator and interpreter).
- In the Microsoft realm: SOAP Toolkit 3.0
- In .NET: Microsoft.Web.Services2.Dime Namespace
- For PHP: PEAR::Net_DIME package
- For Perl: DIME-Tools-0.03 package