axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Malek, Hamid" <>
Subject RE: [Axis2] Importance of SwA (Need Your Feedback)
Date Thu, 20 Jul 2006 02:47:25 GMT
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


[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.



(office): 408-746-6107


View raw message