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: [Axis2] SOAP streamning vs optimized OM (and DOM) [Re: [Axis2][FYI] ActiveSOAP
Date Wed, 22 Sep 2004 13:39:56 GMT
jastrachan@mac.com wrote:

> On 22 Sep 2004, at 07:56, Aleksander Slominski wrote:
>
>> Ias wrote:
>>
>>> See http://radio.weblogs.com/0112098/2004/09/21.html#a506 .
>>> (I saw Steve's comment :-)
>>>
>>> I found that some code of ActiveSOAP, particularly, 
>>> SoapEndpointServlet and
>>> SoapService reminded me of what I wrote in my private box for Axis 2 
>>> before
>>> I came in UK. I tried to use StAX to process SOAP message from HTTP 
>>> servlet,
>>> and that's exactly ActiveSOAP is now doing. Regarding
>>> marshalling/unmarshalling between XML instances and Java objects, it 
>>> shows
>>> some example for XMLBeans, but surely possible to integrate with 
>>> JAXB 2.0.
>>> It could be a good reference for Axis 2.
>>>
>> I agree with Chris Fry comments that access to whole envelope for lot 
>> of use cases (!) is a necessity
>
>
> I agree that often accessing the whole envelope in some kinda object 
> model is useful. Though there are many cases where it doesn't matter - 
> it all depends on which WS-protocols you're implementing. If you're 
> implementing a SOAP router or intermediary, then often there's no need 
> to look at the body so it can just be streamed efficiently, for example.
>
> However one of the main reasons for creating ActiveSOAP - other than 
> for creating efficient intermediaries - is to allow different object 
> models to be plugged in, whether JAX-RPC / SAAJ, one of the DOMish 
> APIs, JAXB, XMLBeans, XStream, Castor etc. It'd also be trivial on a 
> QName or SOAP body bases, to transform a sub-graph of a SOAP envelope 
> too if that were required - either using a custom Handler or via TrAX 
> / STX etc.
>
James,

this is very good goal and i would like to see reusable StAX->binding 
plugins :)

now if you use more than one plugin (like Castor to transform header, 
XmlBeans for body etc) where you plan to store resulting Java object 
models?

i think it is good idea to allow creation of pipeline for receiving SOAP 
message that can do set of transformations to XML infoset representing 
SOAP Envelope gradually transforming it to a form required by app (like 
POJO for headers or body, SAX stream for body etc.) and reverse of it 
when sending SOAP message ...

>
>> and exposing DOM is also required so i think AXIS2 AXIOM direction is 
>> right on target.
>>
>> moreover people tend to overestimate importance of streaming for 
>> small messages - when messages are small then performance difference 
>> between streaming and just loading whole SOAP envelope into optimized 
>> memory structure is small or very small  (especially if XML tree 
>> model/parser is optimized for small messages such as XB1/XPP3 in 
>> XSOAP/XSUL) but even for big messages difference may be much smaller 
>> (until one runs out of memory) than expected for example see 
>> performance differences between XSOAP/Java and gSOAP/C++
>
>
> Agreed - like anything use the right tool for the job. When processing 
> XML though, there are many right tools depending on the use case; 
> StAX, SAX, DOM, SAAJ, JAXB, XMLBeans, XStream et al, have strengths 
> and weaknesses depending on what you're doingl. One of the main aims 
> of ActiveSOAP is to be able to efficiently pipeline XML events to the 
> right tool for the given request - at a header or body or entire 
> envelope level - rather than dictating JAX-RPC / SAAJ on everyone, 
> irrespective of what they're doing.
>
>

i think there should be many tools and developers should have choice 
(and yes i think Darwin approach to software development is good ...)

thanks,

alek

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


Mime
View raw message