OK, so it actually is that much quicker to use XMLStreamWriter and
writeStartElement(), writeEndElement() instead of createOMElement() and
the like? What is the reason for this?
I experimented a little with the generated Axis2 stubs, and added a
simple
env.toStringWithConsume();
just to see how this "preliminary consumation" of the AXIOM model
influences the invocation time. To my surprise this didn't quite change
the invocation time that much ...
Is there any good documentation on AXIOM and stream parsing available? I
definitely need to understand AXIOM a lot better before I am able to
make significant process here ...
thanks for your help,
philipp
Davanum Srinivas wrote:
> For best performance, lot of effort mind you :) is to use OMDataSource
> (see test case in AXIOM svn) on the send side. You will have to use
> the serialize method the gives you XMLStreamWriter and you can write
> out the xml directly to the output stream. On the other side, you can
> get a XMLStreamReader using getXMLStreamReaderWithoutCaching on the
> returned OMElement. using that you can read whatever pieces you need
>> from the response.
>
> thanks,
> dims
>
> On 7/2/07, Philipp Leitner <[EMAIL PROTECTED]> wrote:
>> Hi Dims,
>>
>> I already expected something like this ... I just couldn't find much
>> optimization in the generated ADB stubs - I probably just looked at
the
>> wrong places ...
>>
>> Currently my AXIOM code is quite naive. I am using the
"createOMElement"
>> and "createOMText" methods of OMFactory to iteratively create my SOAP
>> payload, and invoke the service using the ServiceClient interface
>>
>> <snip>
>> ServiceClient sender = new ServiceClient();
>> OMelement result = sender.sendReceive(axisOp);
>> </snip>
>>
>> /philipp
>>
>> Davanum Srinivas schrieb:
>> > Philipp,
>> >
>> > Am afraid the key to performance is not ServiceClient vs
>> > OperationClient as you rightly pointed guessed. The key is AXIOM
>> > itself and its usage. If you post your code with request/response
>> > sample then we may be able to help. But the best way to
understand is
>> > to look at the generated code for ADB databinding. All tricks we
know
>> > in terms of perfomance gets into the generated code :)
>> >
>> > thanks,
>> > dims
>> >
>> > On 7/2/07, Philipp Leitner <[EMAIL PROTECTED]> wrote:
>> >> Hi list,
>> >>
>> >> I have a question rg. performance of the ServiceClient compared
to the
>> >> OperationClient interface.
>> >>
>> >> Personally, I would expect the performance* to be roughly the
same for
>> >> both interfaces since ServiceClient is just a more convenient
wrapper
>> >> for simple tasks.
>> >>
>> >> But now I have measured the invocation times (as defined below),
and
>> >> found that my "handwritten" client (which uses ServiceClient and
>> AXIOM)
>> >> takes about 4 times as long as the stubs generated by wsdl2java
(which
>> >> use the OperationClient interface) to produce a result against the
>> same
>> >> service. I guess the reason for this performance boost of the
>> client is
>> >> either that (a) the OperationClient interface is for some reason
a lot
>> >> faster than the ServiceClient interface or that (b) there is some
>> tricky
>> >> optimization going on somewhere in the ADB stubs that I failed to
>> see so
>> >> far.
>> >>
>> >> Has anybody any insight here that could help me to improve my
>> >> self-produced client, or any other information that would help me
>> >> understand the differences here?
>> >>
>> >> thanks in advance,
>> >> philipp
>> >>
>> >> P.S.: I also did a few comparisons with other frameworks (WSIF and
>> >> XFire), and Axis2 seems to be doing quite well so far. Definitely
>> >> quicker than WSIF, and in a good tie with XFire (but I still have
>> to do
>> >> a lot to get really conclusive results here).
>> >>
>> >>
>> >> *in this context I mean with performance the time between
calling eg.
>> >> ServiceClient.sendReceive() and the response being returned to the
>> >> client.
>> >>
>> >>
---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
