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]
