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] Can OM with differed building really be so effective in Axis2?
Date Tue, 05 Apr 2005 02:33:03 GMT
Eran Chinthaka wrote:

>Hi,
>
>  
>
>>Thanks to all. From your replies, I get a clearer understanding about
>>"deferred binding". And I totally agree with the memory efficiency
>>mentioned by Eran. However, I still have not seen the evident reasons
>>that can enhance the round-trip performance. When a parsed SOAP body
>>is not necessary in provider, "deferred parsing" is sure to be
>>efficient. But if the provider needs a parsed one, I can not see the
>>performance benefits.
>>
>>I think whether the body content will be parsed twice depends on the
>>provider's implementation. Axis1.x does not have to parse the body
>>twice if the provider can reuse the pre-parsed results. In fact, from
>>the class "org.apache.axis.providers.java.RPCProvider" in Axis1.x, we
>>can see the process well: XML stream ==(SAX API)==> buffered SAX
>>events ==(replay with XXXDeserializer)==> Java objects. It parsed only
>>once! And data binding was done at the same time.
>>    
>>
>
>Wait wait. Who told you that the body will be parsed twice. It will happen
>like this.
>
>If some one before the provider requires to "touch" the body, the OM will
>build its object structure in the memory. This is called caching. But one
>has the option of setting this feature off, if he needs. (Use case : WSS4J
>handler).
>
>When you reach provider, he can ask either for OM or the pull events.
>Sometime one might need the raw input stream.
>If body is already being parsed and the object model has been built, when
>provider requires body, OM will provide him with that. OM hides the
>complication to the provider, by not showing him whether the object
>structure is fully built, half built, or not built at all. 
>  
>
so it is complicated and the question is whet is a breakpoint even point 
between just parsing small message with a simple no deferring OM impl 
and parsing large messages with a deferred building i.e. what is cost of 
complexity put into every OMElement (so xml  building is not dne until 
requested and streaming can happen) versus just using simple tree of 
OMElements that get built at one...

>So OM is there to do all the hard work. 
>

>Mind you, we will not parse the SOAP
>message, at any time.
>  
>
? not parsing SOAP message?

alek

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


Mime
View raw message