RE: [Axis2] Importance of SwA (Need Your Feedback)

[Ben Malek, Hamid]

Thank you Dims, Paul, and Thilina for you kind replies.   I certainly will be happy to help you guys with this if you need to. My contact info is at the end of this email. If you want me to help you with this, use my personal contact info as I may not be able to read all the emails from the mailing list.   [Thilina]: "MTOM specification is designed to be backward compatible with the SOAP with Attachments specification. Even though the representation is different, both technologies have the same wire format. We can safely assume that any SOAP with Attachments endpoint can accept a MTOM optimized messages and treat them as SOAP with Attachment messages - Any MTOM optimized message is a valid SwA message. Because of that Axis2 does not define a separate programming model or serialization for SwA. Users can use the MTOM programming model and serialization to send messages to SwA endpoints."   [Hamid]: Thilina, I know very well what the MTOM specification is saying, and I agree with you that MTOM is a particular case of SwA, but the converse is not true. And that is where the problem is (for example, a mutipart/related MimeMessage is a very good example of an SwA message that is not an MTOM message). MTOM does not only differ from SwA by the use of XOP or not (the way the Mime Headers are written down on the wire is not the same when the message is SwA versus MTOM message. For example, the value of the Content-Type Mime Header is not the same for a MimeMessage versus an MTOM message). ebXML processors as well as many other SwA processors expect a MimeMessage format on the wire, not an MTOM format. If you read the spec of ebms-2 for example, you will see the mime format well specified in the spec, and the MSH processor will throw a fault if the mime headers are not consistent with the spec. This is not about parsing (SAAJ and other parsers may be able to parse both format).   [Thilina]: We can always come up with a separate API, as I have mentioned in my reply to your earlier mail. May be you can start working on it as Dims suggested:).   [Hamid]: I don’t know if that is a good idea to have two different APIs. I know that you believe that Axiom should stay an XML infoset, but I don’t believe like you that it will break the goal of Axiom to add functionality to the Axiom API to allow MimeMessage format on the wire when serialized. Since everything that circulates inside Axis2 is from the Axiom Object Model, I think it would better to just add the functionality to the Axiom API itself. For example, when you call the method ServiceClient.sendReceive(OMElement elem), you want this API to work correctly regardless of whether you specify MTOM format or MimeMessage format.   [Thilina]: BTW try to convince the the ebms guys to use MTOM. SwA is just a submission to W3C. AFAIK it never came out of W3C as a spec. IMHO SwA is fast out dating.   [Hamid]: I indeed suggested to ebMS-3 TC to support MTOM in the core spec (as an addition to SwA), and I presented all the positive arguments, but the TC decided to do this in the second part of the spec and not in the first part. It is not that simple to just ignore SwA and replace it with MTOM. SwA is well alive and has a big deployment. Whether it is out-dated or not does not change anything in the matter. For example, we all say that Cobol is dead but the reality is that 70% of the transactions are done in Cobol. We have designed the ebMS-3 spec very differently from the ebms-2 spec (for very good reasons), and one of the feedback we got when our spec was in public review was the “backward compatibility” issue. Big companies such as TMobile (which has thousands of deployed software) were not very happy to know that ebMS-3 SOAP headers were not the same thing as those of ebMS-2. Below is an extract of TMobile feedback:   ================================ Extract of TMobile feedback =======================================    From Gait Boxman (TIE) : This is a major change and will certainly mean that we can no longer reuse a lot of the coding done for ebMS2. It will also mean a serious migration problem. I hope you didn't rule out SwA use, because the last thing I want to do is to push data through an XML parser that doesn't need to do anything with it. The separation of control data from the payload as a *very good thing*, and should be kept. IMO, the ebMS handler should not touch payloads ever. If I pass it a zipped executable or PDF on one side, it should come out on the other side bitwise identical. While I'm sure it's possible to do this by embedding the info inside XML after some wrapping and encoding, I don't want to push that data through the XML parser in the SOAP handler, if only to ensure it doesn't stall. ================================ End of feedback ===================================================   This is just to say that you cannot replace the wide-spread MimeMessage format of SwA with MTOM format and expect everybody to follow you and be happy just because the parsers can parse both formats. The reality is much more complex.   Hamid. (office): 408-746-6107  Email: [EMAIL PROTECTED]