You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by HaoRan Zheng <hr...@gmail.com> on 2005/04/02 08:24:11 UTC
Can OM with differed building really be so effective in Axis2?
Hi all,
Sorry for bothering everybody. I'm not sure whether this question is
appropriate for this maillist. If not, please apprise me and I'll
never commit it again:)
I'm very interested in Axis2 and I know performance is a big goal of
Axis2. But, I really wonder whether the differed building can help to
enhance the performance a lot AT SERVER SIDE. My suspicion is based on
the follow points:
(a). Almost all the SOAP services need the parsed SOAP envelope (the
echoXML sample service maybe an exception), so differed building does
not mean no building. That is to say, parsing and building is
unavoidable mostly.
(b). At server side, we won't design any unnecessary arguments. So we
need parse the SOAP message entirely; even partial parsing won't be
feasible at server side.
I know it is an improvement to choose the pull-parsing with StAX. At
least it is one-time parsing while Axis 1.x used the replay mechanism
to process the pre-parsed SAX events. But I do want to know, how much
performance enhancement can benefit from the OM with differed
building? Could anyone explain it to me? Thank you so much!
Regards,
HR, Zheng
Re: [Axis2] Can OM with differed building really be so effective
in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Venkat Reddy wrote:
>However, the case of round-trip performance includes time spent by the
>service provider in preparing response, which might need to parse the
>body content.
>
but it may not need it for example if it is forwarding message ...
>Still, I think, if we consider doc/literal service, the
>body content now parsed only once - that is, by the provider. It
>would have been un-necessary for axis engine to parse the body if the
>service provider has to do it anyway. Though, i'm not sure if Axis 1.2
>engine parses the body content for doc/lit or not.
>
>
it is good use case but i think for small message (<1K) it does not
make much of difference performancewise ... creating few short lived
strings and object is heavily optimized in modern JVMs ...
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: XML views and flexible/efficient databindg [Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Venkat Reddy <vr...@gmail.com>.
On Apr 5, 2005 8:16 AM, Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
> that is the reason why i think some kind of a next generation of
> XmlBeans that allows to create any number of views (i would not call
> then databinding) on top of existing Infoset subtree (backed by AXIOM
> for example) would be optimal - you have a Java view (so it is easier to
> access and manipulate XML) and that view is not disconnected from XML
> infoset so you can modify XML infoset directly if needed (do XPath
> whatever) and XML schemas validation rules can be integral part of Java
> view to facilitate creation of "valid" XML
>
Isn't this "java view" on infoset, nothing but DOM API for java?
- venkat
Re: XML views and flexible/efficient databindg [Re: [Axis2] Can OM
with differed building really be so effective in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>>Isn't this "java view" nothing but DOM API for java?
>>>
>>>
>>java view has java methods such as get/setTtile derived from XML schemas
>>or similiar data binding description - calling get/setTitle manipualtes
>>XML infoset.
>>
>>
>Axis2 allows you to implement such an implementation of data
>binding. It has its price (as does everything) but it'll work
>just fine.
>Are you volunteering to write such a beast? Cool!
>
>
too bad that XmlBeans does not allow such level flexibility even though
XML Schemas does - there is no reason why should have XML schemas
applied to all you document and not just to fragments and each fragment
may have actually multiple XML schemas (multiple views)
i already prototyped multiple XML views (XB1) and have it working
(XSUL1/2) though i am not sure it can work in AXIS2 as infrastructure as
it must support (multiple) views so my OM has support to discover list
of existing views for given XML Information Item and for casting XML
Infoset Items into a view (dynamic wrapping).
what i did is similar to XmlBeans but there can be 0..n views so when
working with XML Infoset directly there is no Java binding luggage
unless you need it - you create view only when you need it and for what
you need it to do - moreover multiple views are supported so multiple
handlers can create each own view on the same header or body. however i
do not XS generator so i write validation by hand ...
i discovered few interesting things about it (all code is now in XB1
which is part of XPP3/MXP1) and now i am experimenting with next
generation design that benefits from those lessons ofr cleaner code and
more flexibility.
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: XML views and flexible/efficient databindg [Re: [Axis2] Can OM
with differed building really be so effective in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>>Isn't this "java view" nothing but DOM API for java?
>>>
>>>
>>java view has java methods such as get/setTtile derived from XML schemas
>>or similiar data binding description - calling get/setTitle manipualtes
>>XML infoset.
>>
>>
>Axis2 allows you to implement such an implementation of data
>binding. It has its price (as does everything) but it'll work
>just fine.
>Are you volunteering to write such a beast? Cool!
>
>
too bad that XmlBeans does not allow such level flexibility even though
XML Schemas does - there is no reason why should have XML schemas
applied to all you document and not just to fragments and each fragment
may have actually multiple XML schemas (multiple views)
i already prototyped multiple XML views (XB1) and have it working
(XSUL1/2) though i am not sure it can work in AXIS2 as infrastructure as
it must support (multiple) views so my OM has support to discover list
of existing views for given XML Information Item and for casting XML
Infoset Items into a view (dynamic wrapping).
what i did is similar to XmlBeans but there can be 0..n views so when
working with XML Infoset directly there is no Java binding luggage
unless you need it - you create view only when you need it and for what
you need it to do - moreover multiple views are supported so multiple
handlers can create each own view on the same header or body. however i
do not XS generator so i write validation by hand ...
i discovered few interesting things about it (all code is now in XB1
which is part of XPP3/MXP1) and now i am experimenting with next
generation design that benefits from those lessons ofr cleaner code and
more flexibility.
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: XML views and flexible/efficient databindg [Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> >Isn't this "java view" nothing but DOM API for java?
> >
> >
> >
> java view has java methods such as get/setTtile derived from XML schemas
> or similiar data binding description - calling get/setTitle manipualtes
> XML infoset.
Axis2 allows you to implement such an implementation of data
binding. It has its price (as does everything) but it'll work
just fine.
Are you volunteering to write such a beast? Cool!
Sanjiva.
Re: XML views and flexible/efficient databindg [Re: [Axis2] Can OM
with differed building really be so effective in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Venkat Reddy wrote:
>On Apr 5, 2005 8:16 AM, Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
>
>
>>that is the reason why i think some kind of a next generation of
>>XmlBeans that allows to create any number of views (i would not call
>>then databinding) on top of existing Infoset subtree (backed by AXIOM
>>for example) would be optimal - you have a Java view (so it is easier to
>>access and manipulate XML) and that view is not disconnected from XML
>>infoset so you can modify XML infoset directly if needed (do XPath
>>whatever) and XML schemas validation rules can be integral part of Java
>>view to facilitate creation of "valid" XML
>>
>>
>>
>
>Isn't this "java view" nothing but DOM API for java?
>
>
>
java view has java methods such as get/setTtile derived from XML schemas
or similiar data binding description - calling get/setTitle manipualtes
XML infoset.
alek
--
The best way to predict the future is to invent it - Alan Kay
XML views and flexible/efficient databindg [Re: [Axis2] Can OM with
differed building really be so effective in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
HaoRan Zheng wrote:
>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.
>
>
that is why i think "buffered SAX events" should have been a lightweight
DOM from beginning (and that is what i hope AXIOM is now) - having AXIOM
should save one from "replay with XXXDeserializer" as SAAJ/DOM view
could be grafted directly on AXIOM XML tree without replay
as of data binding: i have less and less conviction that creating pure
Java objects (POJO) from XML is a good idea - XML is *not* POJO and if
you have only POJO you need to maintain (somehow automatic?) very
complicated mappings to reconstruct XML from POJO during serialization
(i think JiBX attempts to do that).
that is the reason why i think some kind of a next generation of
XmlBeans that allows to create any number of views (i would not call
then databinding) on top of existing Infoset subtree (backed by AXIOM
for example) would be optimal - you have a Java view (so it is easier to
access and manipulate XML) and that view is not disconnected from XML
infoset so you can modify XML infoset directly if needed (do XPath
whatever) and XML schemas validation rules can be integral part of Java
view to facilitate creation of "valid" XML
>So, from the "round-trip" view, "deferred binding" can not achieve
>remarkable performance enhancement mostly. Because mostly we need the
>parsed SOAP body in provider.
>
>
if you need SOAP Body parsed (for example in message level security or
WS-RM) then yes - but if you just have header you do not always need to
parse SOAP body.
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] Can OM with differed building really be so effective
in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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
RE: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Eran Chinthaka <ch...@opensource.lk>.
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 OM is there to do all the hard work. Mind you, we will not parse the SOAP
message, at any time.
I think now it's the best time for you to go and read the OM Tutorial found
here (http://ws.apache.org/axis2/OMTutorial.html).
>
> So, from the "round-trip" view, "deferred binding" can not achieve
> remarkable performance enhancement mostly. Because mostly we need the
> parsed SOAP body in provider.
>
> Anyway, I think I got my answer. And I will study the OMPerf test by Eran
> later.
Well, OMPerf tests are not mine. They are the results of our team effort. ;)
Regards,
-- Eran Chinthaka
>
> Thanks again:)
>
> Regards,
> HaoRan Zheng
>
> On Apr 4, 2005 1:26 PM, Venkat Reddy <vr...@gmail.com> wrote:
> > It should read "deferred" and not "differed".
> >
> > Regarding performance, i agree with Eran about how Axis engine saves
> > time by skipping parsing of body.
> >
> > However, the case of round-trip performance includes time spent by the
> > service provider in preparing response, which might need to parse the
> > body content. Still, I think, if we consider doc/literal service, the
> > body content now parsed only once - that is, by the provider. It
> > would have been un-necessary for axis engine to parse the body if the
> > service provider has to do it anyway. Though, i'm not sure if Axis 1.2
> > engine parses the body content for doc/lit or not.
> >
> > -venkat
> >
> >
> > On Apr 4, 2005 8:14 AM, HaoRan Zheng <hr...@gmail.com> wrote:
> > > Thank you Eran, so much!
> > >
> > > There is another thing I want to make sure. Is "differed building" a
> > > clerical error? Should it be "deferred building", or it has different
> > > meaning? I see the former expression full of the Axis2 documents, such
> > > as architecture guide and AXIOM tutorial.
> > >
> > > On Apr 4, 2005 10:19 AM, Eran Chinthaka <ch...@opensource.lk>
> wrote:
> > > >
> > > > Re-sending with [Axis2] prefix
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Sorry for bothering everybody. I'm not sure whether this question
> is
> > > > > appropriate for this maillist. If not, please apprise me and I'll
> > > > > never commit it again:)
> > > > >
> > > > > I'm very interested in Axis2 and I know performance is a big goal
> of
> > > > > Axis2. But, I really wonder whether the differed building can help
> to
> > > > > enhance the performance a lot AT SERVER SIDE. My suspicion is
> based on
> > > > > the follow points:
> > > > >
> > > > > (a). Almost all the SOAP services need the parsed SOAP envelope
> (the
> > > > > echoXML sample service maybe an exception), so differed building
> does
> > > > > not mean no building. That is to say, parsing and building is
> > > > > unavoidable mostly.
> > > > > (b). At server side, we won't design any unnecessary arguments. So
> we
> > > > > need parse the SOAP message entirely; even partial parsing won't
> be
> > > > > feasible at server side.
> > > > >
> > > > > I know it is an improvement to choose the pull-parsing with StAX.
> At
> > > > > least it is one-time parsing while Axis 1.x used the replay
> mechanism
> > > > > to process the pre-parsed SAX events. But I do want to know, how
> much
> > > > > performance enhancement can benefit from the OM with differed
> > > > > building? Could anyone explain it to me? Thank you so much!
> > > > >
> > > > > Regards,
> > > > > HR, Zheng
> > > >
> > > >
> > >
> >
XML views and flexible/efficient databindg [Re: [Axis2] Can OM with
differed building really be so effective in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
HaoRan Zheng wrote:
>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.
>
>
that is why i think "buffered SAX events" should have been a lightweight
DOM from beginning (and that is what i hope AXIOM is now) - having AXIOM
should save one from "replay with XXXDeserializer" as SAAJ/DOM view
could be grafted directly on AXIOM XML tree without replay
as of data binding: i have less and less conviction that creating pure
Java objects (POJO) from XML is a good idea - XML is *not* POJO and if
you have only POJO you need to maintain (somehow automatic?) very
complicated mappings to reconstruct XML from POJO during serialization
(i think JiBX attempts to do that).
that is the reason why i think some kind of a next generation of
XmlBeans that allows to create any number of views (i would not call
then databinding) on top of existing Infoset subtree (backed by AXIOM
for example) would be optimal - you have a Java view (so it is easier to
access and manipulate XML) and that view is not disconnected from XML
infoset so you can modify XML infoset directly if needed (do XPath
whatever) and XML schemas validation rules can be integral part of Java
view to facilitate creation of "valid" XML
>So, from the "round-trip" view, "deferred binding" can not achieve
>remarkable performance enhancement mostly. Because mostly we need the
>parsed SOAP body in provider.
>
>
if you need SOAP Body parsed (for example in message level security or
WS-RM) then yes - but if you just have header you do not always need to
parse SOAP body.
alek
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
One other reason for deferring the building of the body: If Axis2
is used to implement an intermediary scenario (like a gateway)
then the current model allows the payload to be simply streamed
thru without fully parsing. (Our current model forces us to run
it thru StAX but I'd like to look at that in the future to get
to the stream and directly pass thru.)
Sanjiva.
----- Original Message -----
From: "HaoRan Zheng" <hr...@gmail.com>
To: "Venkat Reddy" <vr...@gmail.com>
Cc: <ax...@ws.apache.org>
Sent: Monday, April 04, 2005 1:44 PM
Subject: Re: [Axis2] Can OM with differed building really be so effective in
Axis2?
> 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.
>
> So, from the "round-trip" view, "deferred binding" can not achieve
> remarkable performance enhancement mostly. Because mostly we need the
> parsed SOAP body in provider.
>
> Anyway, I think I got my answer. And I will study the OMPerf test by Eran
later.
>
> Thanks again:)
>
> Regards,
> HaoRan Zheng
>
> On Apr 4, 2005 1:26 PM, Venkat Reddy <vr...@gmail.com> wrote:
> > It should read "deferred" and not "differed".
> >
> > Regarding performance, i agree with Eran about how Axis engine saves
> > time by skipping parsing of body.
> >
> > However, the case of round-trip performance includes time spent by the
> > service provider in preparing response, which might need to parse the
> > body content. Still, I think, if we consider doc/literal service, the
> > body content now parsed only once - that is, by the provider. It
> > would have been un-necessary for axis engine to parse the body if the
> > service provider has to do it anyway. Though, i'm not sure if Axis 1.2
> > engine parses the body content for doc/lit or not.
> >
> > -venkat
> >
> >
> > On Apr 4, 2005 8:14 AM, HaoRan Zheng <hr...@gmail.com> wrote:
> > > Thank you Eran, so much!
> > >
> > > There is another thing I want to make sure. Is "differed building" a
> > > clerical error? Should it be "deferred building", or it has different
> > > meaning? I see the former expression full of the Axis2 documents, such
> > > as architecture guide and AXIOM tutorial.
> > >
> > > On Apr 4, 2005 10:19 AM, Eran Chinthaka <ch...@opensource.lk>
wrote:
> > > >
> > > > Re-sending with [Axis2] prefix
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Sorry for bothering everybody. I'm not sure whether this question
is
> > > > > appropriate for this maillist. If not, please apprise me and I'll
> > > > > never commit it again:)
> > > > >
> > > > > I'm very interested in Axis2 and I know performance is a big goal
of
> > > > > Axis2. But, I really wonder whether the differed building can help
to
> > > > > enhance the performance a lot AT SERVER SIDE. My suspicion is
based on
> > > > > the follow points:
> > > > >
> > > > > (a). Almost all the SOAP services need the parsed SOAP envelope
(the
> > > > > echoXML sample service maybe an exception), so differed building
does
> > > > > not mean no building. That is to say, parsing and building is
> > > > > unavoidable mostly.
> > > > > (b). At server side, we won't design any unnecessary arguments. So
we
> > > > > need parse the SOAP message entirely; even partial parsing won't
be
> > > > > feasible at server side.
> > > > >
> > > > > I know it is an improvement to choose the pull-parsing with StAX.
At
> > > > > least it is one-time parsing while Axis 1.x used the replay
mechanism
> > > > > to process the pre-parsed SAX events. But I do want to know, how
much
> > > > > performance enhancement can benefit from the OM with differed
> > > > > building? Could anyone explain it to me? Thank you so much!
> > > > >
> > > > > Regards,
> > > > > HR, Zheng
> > > >
> > > >
> > >
> >
>
Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by HaoRan Zheng <hr...@gmail.com>.
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.
So, from the "round-trip" view, "deferred binding" can not achieve
remarkable performance enhancement mostly. Because mostly we need the
parsed SOAP body in provider.
Anyway, I think I got my answer. And I will study the OMPerf test by Eran later.
Thanks again:)
Regards,
HaoRan Zheng
On Apr 4, 2005 1:26 PM, Venkat Reddy <vr...@gmail.com> wrote:
> It should read "deferred" and not "differed".
>
> Regarding performance, i agree with Eran about how Axis engine saves
> time by skipping parsing of body.
>
> However, the case of round-trip performance includes time spent by the
> service provider in preparing response, which might need to parse the
> body content. Still, I think, if we consider doc/literal service, the
> body content now parsed only once - that is, by the provider. It
> would have been un-necessary for axis engine to parse the body if the
> service provider has to do it anyway. Though, i'm not sure if Axis 1.2
> engine parses the body content for doc/lit or not.
>
> -venkat
>
>
> On Apr 4, 2005 8:14 AM, HaoRan Zheng <hr...@gmail.com> wrote:
> > Thank you Eran, so much!
> >
> > There is another thing I want to make sure. Is "differed building" a
> > clerical error? Should it be "deferred building", or it has different
> > meaning? I see the former expression full of the Axis2 documents, such
> > as architecture guide and AXIOM tutorial.
> >
> > On Apr 4, 2005 10:19 AM, Eran Chinthaka <ch...@opensource.lk> wrote:
> > >
> > > Re-sending with [Axis2] prefix
> > > >
> > > > Hi all,
> > > >
> > > > Sorry for bothering everybody. I'm not sure whether this question is
> > > > appropriate for this maillist. If not, please apprise me and I'll
> > > > never commit it again:)
> > > >
> > > > I'm very interested in Axis2 and I know performance is a big goal of
> > > > Axis2. But, I really wonder whether the differed building can help to
> > > > enhance the performance a lot AT SERVER SIDE. My suspicion is based on
> > > > the follow points:
> > > >
> > > > (a). Almost all the SOAP services need the parsed SOAP envelope (the
> > > > echoXML sample service maybe an exception), so differed building does
> > > > not mean no building. That is to say, parsing and building is
> > > > unavoidable mostly.
> > > > (b). At server side, we won't design any unnecessary arguments. So we
> > > > need parse the SOAP message entirely; even partial parsing won't be
> > > > feasible at server side.
> > > >
> > > > I know it is an improvement to choose the pull-parsing with StAX. At
> > > > least it is one-time parsing while Axis 1.x used the replay mechanism
> > > > to process the pre-parsed SAX events. But I do want to know, how much
> > > > performance enhancement can benefit from the OM with differed
> > > > building? Could anyone explain it to me? Thank you so much!
> > > >
> > > > Regards,
> > > > HR, Zheng
> > >
> > >
> >
>
Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Venkat Reddy <vr...@gmail.com>.
It should read "deferred" and not "differed".
Regarding performance, i agree with Eran about how Axis engine saves
time by skipping parsing of body.
However, the case of round-trip performance includes time spent by the
service provider in preparing response, which might need to parse the
body content. Still, I think, if we consider doc/literal service, the
body content now parsed only once - that is, by the provider. It
would have been un-necessary for axis engine to parse the body if the
service provider has to do it anyway. Though, i'm not sure if Axis 1.2
engine parses the body content for doc/lit or not.
-venkat
On Apr 4, 2005 8:14 AM, HaoRan Zheng <hr...@gmail.com> wrote:
> Thank you Eran, so much!
>
> There is another thing I want to make sure. Is "differed building" a
> clerical error? Should it be "deferred building", or it has different
> meaning? I see the former expression full of the Axis2 documents, such
> as architecture guide and AXIOM tutorial.
>
> On Apr 4, 2005 10:19 AM, Eran Chinthaka <ch...@opensource.lk> wrote:
> >
> > Re-sending with [Axis2] prefix
> > >
> > > Hi all,
> > >
> > > Sorry for bothering everybody. I'm not sure whether this question is
> > > appropriate for this maillist. If not, please apprise me and I'll
> > > never commit it again:)
> > >
> > > I'm very interested in Axis2 and I know performance is a big goal of
> > > Axis2. But, I really wonder whether the differed building can help to
> > > enhance the performance a lot AT SERVER SIDE. My suspicion is based on
> > > the follow points:
> > >
> > > (a). Almost all the SOAP services need the parsed SOAP envelope (the
> > > echoXML sample service maybe an exception), so differed building does
> > > not mean no building. That is to say, parsing and building is
> > > unavoidable mostly.
> > > (b). At server side, we won't design any unnecessary arguments. So we
> > > need parse the SOAP message entirely; even partial parsing won't be
> > > feasible at server side.
> > >
> > > I know it is an improvement to choose the pull-parsing with StAX. At
> > > least it is one-time parsing while Axis 1.x used the replay mechanism
> > > to process the pre-parsed SAX events. But I do want to know, how much
> > > performance enhancement can benefit from the OM with differed
> > > building? Could anyone explain it to me? Thank you so much!
> > >
> > > Regards,
> > > HR, Zheng
> >
> >
>
Re: [Axis2] Can OM with differed building really be so effective
in Axis2?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Chathura Herath wrote:
>Hi Eran, HaoRan Zheng,
>
>One more thing.. There is another point that will give us a performance
>improvement. If our data binding tool is working on StAX or SAX, which I
>believe we are and will, then we ll have a direct OM pull stream --> Java
>Object conversion.
>
that is true for 'vanilla' SOAP without securit or reliability 'flavors'
- adding only those two aspects in the mix make everything to perform
much slower and data binding is anything but simple in such cases and
performance gains may be very small especially if size of SOAP:body is
much smaller than size of all SOAP:headers ...
>There will be no intermediary object model such as DOM .
>This will be desirable for our performance.
>
>
that is always good idea to avoid building XML tree that may not be
neede (like in case of XML message forwarding by intermediary) except
when it can not be avoided then a small implementation that is optimized
for memory size and performance (in that order) is important and that is
what i think AXIOM is for - very fast way to process XML infoset ...
alek
--
The best way to predict the future is to invent it - Alan Kay
RE: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Chathura Herath <ch...@opensource.lk>.
Hi Eran, HaoRan Zheng,
One more thing.. There is another point that will give us a performance
improvement. If our data binding tool is working on StAX or SAX, which I
believe we are and will, then we ll have a direct OM pull stream --> Java
Object conversion. There will be no intermediary object model such as DOM .
This will be desirable for our performance.
Regards,
Chathura
> -----Original Message-----
> From: HaoRan Zheng [mailto:hrzheng@gmail.com]
> Sent: Monday, April 04, 2005 8:45 AM
> To: axis-dev@ws.apache.org; chinthaka@opensource.lk
> Subject: Re: [Axis2] Can OM with differed building really be so effective
> in Axis2?
>
> Thank you Eran, so much!
>
> There is another thing I want to make sure. Is "differed building" a
> clerical error? Should it be "deferred building", or it has different
> meaning? I see the former expression full of the Axis2 documents, such
> as architecture guide and AXIOM tutorial.
>
> On Apr 4, 2005 10:19 AM, Eran Chinthaka <ch...@opensource.lk> wrote:
> >
> > Re-sending with [Axis2] prefix
> > >
> > > Hi all,
> > >
> > > Sorry for bothering everybody. I'm not sure whether this question is
> > > appropriate for this maillist. If not, please apprise me and I'll
> > > never commit it again:)
> > >
> > > I'm very interested in Axis2 and I know performance is a big goal of
> > > Axis2. But, I really wonder whether the differed building can help to
> > > enhance the performance a lot AT SERVER SIDE. My suspicion is based on
> > > the follow points:
> > >
> > > (a). Almost all the SOAP services need the parsed SOAP envelope (the
> > > echoXML sample service maybe an exception), so differed building does
> > > not mean no building. That is to say, parsing and building is
> > > unavoidable mostly.
> > > (b). At server side, we won't design any unnecessary arguments. So we
> > > need parse the SOAP message entirely; even partial parsing won't be
> > > feasible at server side.
> > >
> > > I know it is an improvement to choose the pull-parsing with StAX. At
> > > least it is one-time parsing while Axis 1.x used the replay mechanism
> > > to process the pre-parsed SAX events. But I do want to know, how much
> > > performance enhancement can benefit from the OM with differed
> > > building? Could anyone explain it to me? Thank you so much!
> > >
> > > Regards,
> > > HR, Zheng
> >
> >
Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Posted by HaoRan Zheng <hr...@gmail.com>.
Thank you Eran, so much!
There is another thing I want to make sure. Is "differed building" a
clerical error? Should it be "deferred building", or it has different
meaning? I see the former expression full of the Axis2 documents, such
as architecture guide and AXIOM tutorial.
On Apr 4, 2005 10:19 AM, Eran Chinthaka <ch...@opensource.lk> wrote:
>
> Re-sending with [Axis2] prefix
> >
> > Hi all,
> >
> > Sorry for bothering everybody. I'm not sure whether this question is
> > appropriate for this maillist. If not, please apprise me and I'll
> > never commit it again:)
> >
> > I'm very interested in Axis2 and I know performance is a big goal of
> > Axis2. But, I really wonder whether the differed building can help to
> > enhance the performance a lot AT SERVER SIDE. My suspicion is based on
> > the follow points:
> >
> > (a). Almost all the SOAP services need the parsed SOAP envelope (the
> > echoXML sample service maybe an exception), so differed building does
> > not mean no building. That is to say, parsing and building is
> > unavoidable mostly.
> > (b). At server side, we won't design any unnecessary arguments. So we
> > need parse the SOAP message entirely; even partial parsing won't be
> > feasible at server side.
> >
> > I know it is an improvement to choose the pull-parsing with StAX. At
> > least it is one-time parsing while Axis 1.x used the replay mechanism
> > to process the pre-parsed SAX events. But I do want to know, how much
> > performance enhancement can benefit from the OM with differed
> > building? Could anyone explain it to me? Thank you so much!
> >
> > Regards,
> > HR, Zheng
>
>
[Axis2] Can OM with differed building really be so effective in Axis2?
Posted by Eran Chinthaka <ch...@opensource.lk>.
Re-sending with [Axis2] prefix
>
> Hi all,
>
> Sorry for bothering everybody. I'm not sure whether this question is
> appropriate for this maillist. If not, please apprise me and I'll
> never commit it again:)
>
> I'm very interested in Axis2 and I know performance is a big goal of
> Axis2. But, I really wonder whether the differed building can help to
> enhance the performance a lot AT SERVER SIDE. My suspicion is based on
> the follow points:
>
> (a). Almost all the SOAP services need the parsed SOAP envelope (the
> echoXML sample service maybe an exception), so differed building does
> not mean no building. That is to say, parsing and building is
> unavoidable mostly.
> (b). At server side, we won't design any unnecessary arguments. So we
> need parse the SOAP message entirely; even partial parsing won't be
> feasible at server side.
>
> I know it is an improvement to choose the pull-parsing with StAX. At
> least it is one-time parsing while Axis 1.x used the replay mechanism
> to process the pre-parsed SAX events. But I do want to know, how much
> performance enhancement can benefit from the OM with differed
> building? Could anyone explain it to me? Thank you so much!
>
> Regards,
> HR, Zheng