axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@opensource.lk>
Subject Re: SAAJ / OM [Re: [Axis2] - OM API
Date Tue, 26 Oct 2004 02:40:32 GMT
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" <aslom@cs.indiana.edu>
To: <axis-dev@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
>
>


Mime
View raw message