In an environment of shared services, my team develops WSs using JaxWS. I have a peer whose team uses Axis and we have been unable to make dynamic calls to his services. (To be clear, security is NOT the issue)
I am being told I need to add the jar files that support Axis in order to make those dynamic calls.
Why? I ask...aren't these APIs following the same standard(s) (JSRs?)
Where to turn for clarification/education on this area?
I'm not sure what you mean by "dynamic calls", but one of the benefits of WS is that the standard is independent of the implementation. In other words, for developing the client it doesn't matter which implementation is used on the server. So, for accessing a service running on Axis, you can use Axis or some other implementation as the client (such as the JAX-WS RI or the Metro stack).
Can you be more specific what, exactly, "we have been unable" means? What have you tried, and what happened as a result?
Christopher McCauley wrote:I have a peer whose team uses Axis and we have been unable to make dynamic calls to his services.
Axis 1.x or Axis2 ?
In the case of Axis 1.x it is possible to expose a SOAP web service through the "rpc/encoded" messaging mode (See Which style of WSDL should I use?). Neither Axis2 nor JAX-WS (or any SOAP stack in the current generation) support "rpc/encoded" because of the insurmountable SOAP encoding interoperability problems. So it would be impossible to access an Axis 1.x "rpc/encoded" web service with an Axis2 or JAX-WS client. You would have to use the Axis 1.x client libraries and code against them to access the Axis 1.x "rpc/encoded" web service.
Is that what you mean?
Joined: Aug 19, 2005
Christopher McCauley wrote:Why? I ask...aren't these APIs following the same standard(s) (JSRs?)
Axis 1.x is based JAX-RPC (JSR-101/JSR-109)
JAX-WS is JSR-224
Design on Axis2 got started before JSR-224 really got going - so any JAX-WS (JSR-224) support is layered on top of Axis2 doing it's own thing (Web services and Axis2 architecture).