The two levels of MTOMness and other meditations
WSE 3 replaces DIME and WS-Attachments with a new W3C recommendation known as MTOM (Message Transmission Optimization Mechanism) for a whole host of reasons Mark outlines in his What's New article. The MTOM spec is actually layered on something called XML-binary Optimized Packaging (XOP). When you set RequireMtom to true on your shiny new WSE 3 proxy, that means all the messages sent will be MIME encoded, but it doesn't necessarily mean the messages sent will reach the second level and include XOP parts. For example, this is a perfectly legal MTOM message:
content-type: application/xop+xml; charset=utf-8; type="text/xml; charset=utf-8"
<soap:Envelope xmlns:xop="https://www.w3.org/2004/08/xop/include" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema" >
Sure the contents of <b> could go into a separate part that is referenced by the <xop:Include> that takes the data's place, but in this case the <xop:Include> would actually be bigger than the data it's replacing plus adding new MIME boundaries and the headers for the part new can also wipe out any savings from not base 64 encoding the data.
When it comes time to serialize a message WSE has several decisions to make:
- Should I use MTOM? If no, just use regular xml serialization and send the message. If yes, encode the message in MIME and serialize each element in the infoset with an eye towards XOP optimizations.
- Should I use XOP? If not base 64, no. If base 64 and large enough to see savings, create a new MIME part that will have the binary data and replace the binary data in the infoset with a <xop:Include> referencing that new part.