wood burning stoves 2.0*
The moose likes Web Services and the fly likes Apache Axis wsdl2java tool Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "Apache Axis wsdl2java tool" Watch "Apache Axis wsdl2java tool" New topic
Author

Apache Axis wsdl2java tool

Chad McGowan
Ranch Hand

Joined: May 10, 2001
Posts: 265
I have used the Axis wsdl2java tool to create the classes needed for a document style web service.
It creates RPC stubs and skeletons, just as it does for an rpc style web service.
Is this correct? It seems that there is a performance hit when using RPC stubs to access a document style web service.
Mark Secrist
Ranch Hand

Joined: Jul 01, 2003
Posts: 89
When you say it generates RPC stubs & skeletons, what do you mean. The big difference in document vs rpc is what is passed to the web service. The stubs and skeleton code will actually look pretty much the same. So, the difference is in what defines the types being exchanged. With rpc, it is the native langauge the service is implemented in. If you use encoding, the SOAP envelope will try to help, which is where much of the performance hit comes from. With Document style exchanges, the types are defined using XML schema(s) and tends to provide a bit more flexibility in terms of the kind of information being exchanged.
Hope this helps.
Mark
Originally posted by Chad McGowan:
I have used the Axis wsdl2java tool to create the classes needed for a document style web service.
It creates RPC stubs and skeletons, just as it does for an rpc style web service.
Is this correct? It seems that there is a performance hit when using RPC stubs to access a document style web service.
Chad McGowan
Ranch Hand

Joined: May 10, 2001
Posts: 265
Originally posted by Mark Secrist:
When you say it generates RPC stubs & skeletons, what do you mean. The big difference in document vs rpc is what is passed to the web service. The stubs and skeleton code will actually look pretty much the same. So, the difference is in what defines the types being exchanged. With rpc, it is the native langauge the service is implemented in. If you use encoding, the SOAP envelope will try to help, which is where much of the performance hit comes from. With Document style exchanges, the types are defined using XML schema(s) and tends to provide a bit more flexibility in terms of the kind of information being exchanged.
Hope this helps.
Mark

I am referring to the code generated from Axis compared to what used to be generated from Apache SOAP 2.2.
Basically, when you use the wsdl2java tool in Axis, you get a Service interface, a stub, and a bunch of serializable classes. You get this regardless of the style (document or rpc).
My question is- why do I need this serialization when using the document style? It seems like overkill. Is this because Axis is now JAX-RPC compliant?
Using Apache SOAP 2.2 on a document wsdl, you don't get the serializable classes or the remote interfaces, you only deal with the Message class.
I am questioning this because I am seeing significant performance problems using Axis over Apache SOAP for 'document' style web services.
The code produced by SOAP 2.2 is getting results back about 4x faster.
[ July 02, 2003: Message edited by: Chad McGowan ]
Mark Secrist
Ranch Hand

Joined: Jul 01, 2003
Posts: 89
OK, so there is no reason you have to use the serialization/de-serialization code. You can think of it as convenience functionality. It is perfectly acceptable to create a call object where you simply set the body of the SOAP message to be the XML document. Likewise, you could get the return document back as a SOAP body and process it. However, you are still doing some form of "serialization/deserialization" simply by the fact that you will need to process the XML documents as DOM objects (or using SAX on the return document). That raises two questions then.
1. Do you want to write your code at this level?
2. Can you write document processing code that is as efficient and performs as well or better than what the platform can do.
In some cases, the answer may be Yes to both. However, I believe in most cases, the answer would be No to both.
Now, to your question about Apache SOAP. I don't know how good the support was for document style exchanges or the serialization/deserialization was. This may be a reason why you would choose to do it yourself (at least on the Apache SOAP server side).
Originally posted by Chad McGowan:

I am referring to the code generated from Axis compared to what used to be generated from Apache SOAP 2.2.
Basically, when you use the wsdl2java tool in Axis, you get a Service interface, a stub, and a bunch of serializable classes. You get this regardless of the style (document or rpc).
My question is- why do I need this serialization when using the document style? It seems like overkill. Is this because Axis is now JAX-RPC compliant?
Using Apache SOAP 2.2 on a document wsdl, you don't get the serializable classes or the remote interfaces, you only deal with the Message class.
I am questioning this because I am seeing significant performance problems using Axis over Apache SOAP for 'document' style web services.
The code produced by SOAP 2.2 is getting results back about 4x faster.
[ July 02, 2003: Message edited by: Chad McGowan ]
Chad McGowan
Ranch Hand

Joined: May 10, 2001
Posts: 265
Mark, Thanks for your input. I agree with you that most times you do not need to reinvent the wheel and write your own implementation of soap. I'm just trying to get a feel for why Axis does some of the things that it does.
At this stage I am not that concerned about performance... if it becomes an issue, then will be the time to address it. I just found it interesting that Axis was that much slower than Apache SOAP, all other things being the same.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Apache Axis wsdl2java tool