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.

Listing A shows an example of a DIME message.

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 utilize DIME messages, you can use
the available tools in various languages (i.e., instead of writing
your own generator and interpreter).

Keep your developer skills sharp by automatically signing up for TechRepublic’s free Web Development Zone newsletter, delivered each Tuesday.