axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thilina Gunarathne" <cset...@gmail.com>
Subject Re: [Axis2] Importance of SwA (Need Your Feedback)
Date Wed, 19 Jul 2006 23:14:52 GMT
Hi,
Please see my reply to your earlier mail. Also some comments in line.

On 7/20/06, Ben Malek, Hamid <HBenMalek@us.fujitsu.com> wrote:
>
>
>
> Let me explain why it is important to fully support SwA in Axis2. As you
> know, ebMS is heavily built on SwA. The latest version of ebMS (ebMS-3) is
> still relying on SwA (support for MTOM will only be in the second part of
> the spec, but the B2B space will still be using SwA for many years to come).
> We have designed ebMS-3 specification in a way to make the convergence
> between ebXML and Webservices possible. With ebMS-3, it is easier to compose
> webservices with an MSH. However, not fully supporting SwA in Axis2 doesn't
> make things smoother.
>
>
>
> Consider the following example. Suppose you would like to have an axis2
> service that accepts an SwA message as input and returns an SwA as response.
> The SwA message could be for example a multipart/related
> javax.mail.internet.MimeMessage object. To accomplish this, you would write
> a MessageReceiver that constructs the MimeMessage from the axiom SOAP
> envelope and attachments object present in the MessageContext and hand it
> over to the service. When the service returns an SwA (that is a
> MimeMessage), the MessageReceiver would construct an axiom SOAP envelope
> that will be put in the response, and then it will extract the other parts
> of the MimeMessage and put them in an Attachments object that would be
> placed as a property of the MessageContext, and finally call the
> AxisService.send(msgContext) to tell Axis2 to process the handler chain and
> send the response back to the client. The problem with this is that the http
> transport senders would only serialize the axiom SOAP envelope back to the
> client without fetching the Attachments object present in the MessageContext
> and serializing the attachments as well. To correct this situation the
> service developer would have to also write his own http transport sender
> that takes into consideration the attachments property of the
> MessageContext. Doing this is not good, because the service developer should
> not write more than the service code and the MessageReceiver class.
Agreed. We need to do something to serialize the NON-MTOM attachments
in the MsgContxt attachments object.

>
>
>
> The other problem I mentioned in my previous email (see below) was the
> inability to construct an SwA message using only Axiom API. You may say that
> Axiom was designed only for MTOM and that Axiom by its nature is only for
> XML contents not something like a mutipart/related
> javax.mail.internet.MimeMessage format.
MTOM is backward compatible with SwA. SwA endpoints can receive MTOM
messages as SwA messages without any knowledge about MTOM in them.
IIRC Axis2 SAAJ impl uses this.

AXIOM can handle javax.activation.DataHandlers, Not MimeMessages.

>So, constructing a MimeMessage with
> Axiom API may sound as nonsense.
>There is a problem with thinking this way:
> Axis2 is built around Axiom and uses Axiom as its blood stream, while at the
> same time Axis2 does not provide any other APIs or other Object Model
> besides Axiom. Therefore, it becomes the responsibility of Axiom API to be
> able to handle SwA as well, even though it was only meant for XML contents.
*Disagree*.  AXIOM is an XML infoset representation. SwA does not fit
with XML infoset at any level. On the other hand MTOM+XOP does.  I do
not agree to hang SwA attachments in AXIOM. It simply will brake the
model and underlying objective of AXIOM.

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:).

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.

Thanks,
~Thilina

>
>
>
> Please let me know what your thoughts are.
>
>
>
> Thank you very much for the good work.
>
>
>
> Hamid.
>
>
> ________________________________
>
>
> From: Ben Malek, Hamid [mailto:HBenMalek@us.fujitsu.com]
> Sent: Tuesday, July 18, 2006 9:35 PM
> To: axis-user@ws.apache.org
> Cc: axis-dev@ws.apache.org
> Subject: RE: [Axis2] Help with SwA
>
>
>
> I have a big problem making Axis2 work fine with SwA.
>
> 1.    The first problem is that I could not find any documentation on how to
> programmatically construct a SwA SOAP message using AXIOM API only. You can
> only construct MTOM SOAP messages with Axiom but not SwA. The example of SwA
> given by axis2 is just reading a SwA message from a file (the file already
> contains a serialized SwA message).
>
> 2.    The second problem is that it seems to me so far that axis2 only
> support SwA in one direction only. That is, the axis servlet is able to
> parse a SwA message from the servlet input stream (and it stores the
> attachments in an Attachments object as a property of the MessageContext).
> However, this attachments object is not used anywhere in the code. This
> means that if a service is returning a SwA message (not an MTOM message),
> axis2 will only serialize the SOAP envelope without the attachments. The
> http transport senders only serialize the SOAP envelope on the wire but not
> the attachments (maybe they do it for an MTOM message, but they do not do it
> for a SwA message since the attachments object of the MessageContext is not
> used at all in the code except when parsing the input stream in the axis
> servlet).
>
>
>
> Please correct me if I am wrong.
>
>
>
> Thank you very much for any help.
>
>
>
> Hamid.


-- 
"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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message