You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/10/25 19:42:16 UTC
SAAJ / OM [Re: [Axis2] - OM API
Eran Chinthaka wrote:
>
>
> Then we were discussing about a JDom like api for programmer convenience.
>
>
>
> If we make our AXIOM Soap specific we can create another layer on top
> of the existing OM API and provide the Axis developer with a good API
> than the current one. (We can differ the impl of this new API, but I
> just want to bring this up, as we really need to give a good API for
> the programmers and this is not that urgent J J)
>
>
>
> For example, there are classes for SOAPMessage, SOAPPart,
> SOAPEnvelope, SOAPHeader, SOAPBody (These may extend from OMElement,
> but has specific functionalities). From the SOAPEnvelope you can get
> SOAPHeaders or add headers, remove them etc.,
>
i though implementing SAAJ was already a requirement?
the problem is that SAAJ is build around WSA and not MTOM/XOP and
exposes peculiarities of attachments ...
so i think we should have OM implementation support SAAJ and DOM API
(subset required for security) but keep OM core small and flexible to
allow adding new APIs on top of it (such as MTOM specific/optimized).
i think we should discuss in dept what is required in OM to support MTOM
- in particular binary objects representation - i do not think we want
to store BASES64 encoded text nodes as it would defeat purpose of MTOM ...
alek
--
The best way to predict the future is to invent it - Alan Kay
RE: SAAJ / OM [Re: [Axis2] - OM API
Posted by Eran Chinthaka <ch...@opensource.lk>.
My suggestion to think about SAAJ api for OM, is not to integrate SAAJ with
OM.
My suggestion was to think of an interface as SAAJ has to OM.
BTW : if you look at the deserialization context of Axis 1.x, it was there
to give the soap xml infoset a SOAP like API. Deserialization context had
methods like getEnvelope, getHeaders, getBody. So my suggestion is to burn
these things in to the OM api itself.
When we give this SAAJ like api to OM, the engine developer and the handler
developer has a better API to access the SOAP infoset.
Note that OM is SOAP specific now, so we can make this more and more SOAP
specific.
My Suggestion is as follows.
1. Rename the Document interface as SOAPMessage
2. getRootElement of the SOAPMessage should return an instance of
SOAPEnvelope.
3. SOAPEnvelope has methods to getSOAPHeader returning SOAPHeader,
getSOAPBody returning SOAPBody and/or methods to get attachments (I don't
know much abt MTOM, comments ??)
4. SOAPHeader has methods to get allHeaders, headers with mustUnderstand
true, headers with specific actor, and add or remove headers
5. SOAPBody has methods to addFaults, add or remove BodyElement, add a
document
6. SOAPEnvelope, SOAPHeader, SOAPBody, SOAPFault are extensions to the
OMElement interface.
________________________________
Eran Chinthaka
Lanka Software Foundation
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Tuesday, October 26, 2004 8:41 AM
To: axis-dev@ws.apache.org
Subject: Re: SAAJ / OM [Re: [Axis2] - OM API
We explicitly decided *not* to require SAAJ and DOM in the core ..
otherwise we might as well have just used DOM and be done with it.
I prefer to layer on the SAAJ API on top of the base OM stuff rather
than make that be the only one. We cannot limit our chance to improve/
innovate because the damned standard is stuck in the previous
century.
Sanjiva.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Monday, October 25, 2004 11:42 PM
Subject: SAAJ / OM [Re: [Axis2] - OM API
> Eran Chinthaka wrote:
>
> >
> >
> > Then we were discussing about a JDom like api for programmer
convenience.
> >
> >
> >
> > If we make our AXIOM Soap specific we can create another layer on top
> > of the existing OM API and provide the Axis developer with a good API
> > than the current one. (We can differ the impl of this new API, but I
> > just want to bring this up, as we really need to give a good API for
> > the programmers and this is not that urgent J J)
> >
> >
> >
> > For example, there are classes for SOAPMessage, SOAPPart,
> > SOAPEnvelope, SOAPHeader, SOAPBody (These may extend from OMElement,
> > but has specific functionalities). From the SOAPEnvelope you can get
> > SOAPHeaders or add headers, remove them etc.,
> >
> i though implementing SAAJ was already a requirement?
>
> the problem is that SAAJ is build around WSA and not MTOM/XOP and
> exposes peculiarities of attachments ...
>
> so i think we should have OM implementation support SAAJ and DOM API
> (subset required for security) but keep OM core small and flexible to
> allow adding new APIs on top of it (such as MTOM specific/optimized).
>
> i think we should discuss in dept what is required in OM to support MTOM
> - in particular binary objects representation - i do not think we want
> to store BASES64 encoded text nodes as it would defeat purpose of MTOM ...
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
Re: SAAJ / OM [Re: [Axis2] - OM API
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
We explicitly decided *not* to require SAAJ and DOM in the core ..
otherwise we might as well have just used DOM and be done with it.
I prefer to layer on the SAAJ API on top of the base OM stuff rather
than make that be the only one. We cannot limit our chance to improve/
innovate because the damned standard is stuck in the previous
century.
Sanjiva.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Monday, October 25, 2004 11:42 PM
Subject: SAAJ / OM [Re: [Axis2] - OM API
> Eran Chinthaka wrote:
>
> >
> >
> > Then we were discussing about a JDom like api for programmer
convenience.
> >
> >
> >
> > If we make our AXIOM Soap specific we can create another layer on top
> > of the existing OM API and provide the Axis developer with a good API
> > than the current one. (We can differ the impl of this new API, but I
> > just want to bring this up, as we really need to give a good API for
> > the programmers and this is not that urgent J J)
> >
> >
> >
> > For example, there are classes for SOAPMessage, SOAPPart,
> > SOAPEnvelope, SOAPHeader, SOAPBody (These may extend from OMElement,
> > but has specific functionalities). From the SOAPEnvelope you can get
> > SOAPHeaders or add headers, remove them etc.,
> >
> i though implementing SAAJ was already a requirement?
>
> the problem is that SAAJ is build around WSA and not MTOM/XOP and
> exposes peculiarities of attachments ...
>
> so i think we should have OM implementation support SAAJ and DOM API
> (subset required for security) but keep OM core small and flexible to
> allow adding new APIs on top of it (such as MTOM specific/optimized).
>
> i think we should discuss in dept what is required in OM to support MTOM
> - in particular binary objects representation - i do not think we want
> to store BASES64 encoded text nodes as it would defeat purpose of MTOM ...
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>