Using MTOM to set up binary streams

The SOAP Message Transmission Optimization Mechanism is a building-block spec that DPWS profiles so that specifications built on top can use it in a consistent and device-friendly way.  MTOM isn't used in any of DPWS's messages, but it is available to solution authors and is included in many specs built on DPWS.

In short, MTOM is a way to link binary MIME attachments into the SOAP envelope*.  The simplest example is a print job: using MTOM, you can send a SOAP message that describes the print job, and attach the binary document as a MIME attachment inside the HTTP connection.  MTOM lets you link the MIME and SOAP together.  This seems like an obvious way to package data, but let's imagine what would happen without that binding: the sender would have to encode the binary document into some form (likely base64) and then inline it into the SOAP message.  There are a lot of disadvantages in this approach, most notably that the receiver can't really process the SOAP until it consumes the entire binary document, which could be very large.  This would be a huge problem for devices, which are often memory-limited and which rely on streaming large documents as they cannot buffer them in entirety.

That last sentence hints at a neat fringe benefit of MTOM: it allows the sender and receiver to establish a binary stream with a SOAP message header.  This is a really convenient way to open a stream like this, since the stream can coexist on the port used to send SOAP traffic, and there's a natural association between the strongly-typed SOAP contents and the more flexible stream data.  Conceptually, MTOM doesn't distinguish between well-bounded documents and open-ended streams, although solutions are often written with either one of these in mind.

A good example of the stream pattern is the DPWS-based Windows SideShow Bitmap driver, which uses the SendSideShowFrameStream operation to open a stream connection, which is linked inside the FrameStream element.  The SOAP message contains some useful parameters about the stream, and the stream contains bitmaps.

There are, naturally, disadvantages and limitations to this approach.  The stream itself is unidirectional (although you may be able to set up simultaneous request/response streams), and even though a SOAP message can contain multiple MTOM sections, only one stream can be active at a time.  Every stream must be prefaced with a SOAP message, and the data inside is completely untyped.  But even with these limitations, using MTOM to set up streams is incredibly handy in DPWS applications.

To use MTOM in your application, simply include the xs:base64Binary schema type in an element.  This type will become a pointer to the MIME section containing your binary document or stream data.  WSDAPI automatically interprets this type and provides IWSDAttachment pointers for easy access to the binary data.

* Note: MTOM is actually a bit more complex than this, and is organized into a generic optimization mechanism and a MIME serialization.  But in the context of DPWS, it really is just a way to link MIME sections into SOAP.