axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [Axis2] SOAP streamning vs optimized OM (and DOM) [Re: [Axis2][FYI] ActiveSOAP
Date Wed, 22 Sep 2004 13:39:56 GMT wrote:

> On 22 Sep 2004, at 07:56, Aleksander Slominski wrote:
>> Ias wrote:
>>> See .
>>> (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.

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 

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



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

View raw message