Hi Thilina, On 7/19/06, Ben Malek, Hamid <[EMAIL PROTECTED]> wrote:
I certainly will be happy to help you guys with this if you need to.
Thanks a lot. You are always welcome to join.
[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).
Axis2 supports receiving of SwA messages which are not MTOM. I agree that there are limitations like not supporting content location based addressing of MIME parts(supports content-id based addressing only).
[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.
OMElement as in ServiceClient.sendReceive(OMElement elem) represents the XML payload which goes inside the SOAP body. IMHO SwA attachments belong to the SOAP message level. They do not belong to the SOAP envelope or the XML payload, since they do not have defined relationship to the XML payload. According to what I understand MessageContext is the Axis2 entity which contains the SOAP message level information. I believe SwA attachments should be put in to MsgContext. I do not see any justifiable placeholder for SwA type attachments in XML representation of the payload. This is just how I feel:).
[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 ===================================================
Just to add my two cents, In Axis2 we don't parse any MTOM attachment through the parser. Even though it is hang in the AXIOM as a OMText object it just act as a place holder, the actual binary is deferred build (read only if needed). Axis2 can even stream the attachment content to the other end when the user didn't use it. I don't see any reason why the above scenario cannot be implemented using MTOM. It's doable with the same ease of doing it with SwA. Thanks again for the thought provoking conversation, ~Thilina
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]
-- "May the SourcE be with u" http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
