Three new specs were released as W3C recommendations today...XML-binary Optimized Packaging (XOP), SOAP Message Transmission Optimization Mechanism (MTOM), and Resource Representation SOAP Header Block (RRSHB).

They are all interrelated... XOP is the XML mechanism that is the building block for MTOM (SOAP implementation of XOP which does not dictate wire protocol binding), and RRSHB is an expansion of the SOAP HTTP binding to support MTOM/XOP.

In a nutshell, all of this stuff has one essential purpose: Freeing you from having to encode binary data into base64 when you serialize a SOAP message. Basically, base64 is a really heavyweight encoding scheme, that adds a TON of fat. By allowing binary octet data to actually be transmitted unencoded (and under certain circumstances, relayed across SOAP processors unencoded) instead of taking the serious encoding hit, the bandwith requirements of moving large messages around is reduced significantly. Not only that, but the CPU overhead of doing the base64 encoding/decoding is also alleviated. And yet another, though smaller, benefit is that less buffer resources are required on both ends of the pipe (assuming both ends can deal with the data in it's raw format). Of course, some operations may require access to the data in base64, so a SOAP sender or reciever may have to encode/decode it anyways (I think XML-Signature requires binary data to be addressable in base64?)... but it still gets the bandwidth reduction when it is transmitted over the wire.

I can see a lot of benefit to this.

For example, this makes digital media transmission over web services a whole lot more appealing (as opposed to scrapping together a proprietary protocol). SOAP-routed media could turn out to be quite interesting. I know folks have tried to do it with Web Services, and gave up in frustration due to the bandwidth hit... but now the hit isnt there... it's now basically raw media data wrapped in some dandy XML metadata... fascinating...

Another use I can see is just around the corner when ADO.NET 2.0 datasets support REAL binary serialization instead of the "serialize to pseudo-xml, and call it 'binary'" serialization of ADO.NET 1.x. In a purist sense, we know it's bad form (argue it here, here, and here) to send datasets over web services "Data on the Inside vs. Data on the Outside" and all that. But I tend to agree with the opinion that in most cases once we commit to sending a dataset in a message, it becomes "opaque" like an image or any other binary data would be... and doesn't really break the purist view (come on, squint real hard with me). So passing a large dataset in binary format is perfectly acceptable to me, and these new specs will make it significantly more viable. One of the major debate points against datasets over webservices has been the bloat it causes... but with binary serialization and XOP/MTOM, that arguement fades fast.

Of course like anything else, I am sure someone somewhere will find a way to abuse the specs and I will be griping about it later.