RE: [ebxml-msg] SOAP 1.2 MTOM and ebMS v3

["Dale Moberg" <dmoberg@us.axway.com>]

David Webber asks:

How does this relate to ebMS v3 ?

  http://www.w3.org/TR/soap12-mtom/

 Is it just transparent - in that if two ebMS are using SOAP 1.2 with MTOM - then they can exchange transmissions accordingly - but controlled by the CPA and ebMS settings? 

 

Neither the ebMS 3.0 core specification nor any of the two initial conformance profiles has much to say about MTOM/XOP functionality. It has been discussed from time to time but no business use case has been discovered. sWa (SOAP with Attachments), however, still has use cases so it is supported. MTOM is billed as an optimization technique for moving infosets around. So the idea is that some element in the S:Body might be some base64 encoded string because that element’s text node might really be binary data, edifact data, or some data that can’t be directly placed into XML. XOP and MTOM allow you to put that content into a MIME body part to avoid the base64 expansion overhead. This is a fairly special case. Normally the attachment use case is that some totally other kind of data is to be transmitted along with an XML message. The XML schema would not in general have a place to include this data—it is not part of the document definition. So the optimization is inapplicable for most real commercial attachment use cases because the attachment data is not part of the infoset to be moved around! At least that is my impression. Maybe extension points will be engineered into message sets for this purpose, but none have come to our attention.

 

Or is MTOM re-inventing ebMS routing and handling and therefore likely to cause chaos?

 

I can’t see that MTOM has anything to do with the ebMS routing/handling functionality. I am not certain that MTOM is at all concerned about MSH to/from “application” issues. What exactly happens when the S:Body infoset hits the final SOAP node is cloaked in mystery, and up to the implementation totally as far as I can tell. But that is pretty much the same for ebMS 2 or 3 except that we have some standardized metadata (role, action, service, etc) that is available for implementations to use to tie up to upper layers of BPM. So I would say that there will be no more chaos than normal.