axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: SAAJ / OM [Re: [Axis2] - OM API
Date Thu, 28 Oct 2004 05:30:53 GMT
Eran Chinthaka wrote:

> 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.
>
i think we can maintain XML and SOAP specific parts separately by simply 
having OmSoapEnvelope extends OmElement and in OmSoapEnvelope add SOAP 
specific methods like

OmSoapEnvelope extends OmElement {
OmSoapHeader getSoapHeader()
// ...
}

MTOM will require additional support during parsing and in OM model to 
allow flexible handling of children so pointer (reference) to binary 
data is stored but still BASE64 representation can be reproduced when 
needed.

how does this sound ?

i think we should look *really* hard how to cover all basis: DOM L2/L3, 
SAAJ (how many versions?), MTOM and streaming, and in general ability to 
add other APIs on top of AXIOM and handle XmlBeans, JAXB, Castor 
efficiently ... i think MTOM and streaming are the biggest challenges.

other interesting use of OM would be to allow to attach arbitrary 
annotations such as in case of WSDL2.

thanks,

alek

> ________________________________
>
> 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" <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
>
>>
>
>>
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message