• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Apache Axis wsdl2java tool

 
Ranch Hand
Posts: 265
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 265
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 89
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 265
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
reply
    Bookmark Topic Watch Topic
  • New Topic