Is it that Axis provides a communication style (message) that isn't part of
the specs?
Yes, the Axis Message style is not part of JAX-RPC. However, there is a lot of confusion about exactly what "message-style" means.
The WSDL spec defines "document-style" operations as opposed to "rpc-style" operations. SOAP messages for rpc-style operations contain an extra wrapper element around the actual message data, and the tag name of that wrapper is the same as the operation that is being invoked. Document-style operations do not have that wrapper element. As far as WSDL is concerned, that's the only difference between the two.
The WSDL spec also defines "request-response" operations and "one-way" operations. request-response operations are like procedure calls, where the client blocks until it receives a response. One-way operations are like sending email; the client doesn't block. Here's where the confusion comes in:
1. Document-style operations can be either request-response or one-way.
Many people seem to think that document-style implies one-way only.
Axis handles request-response document-style operations very nicely:
Your service implementation method can define JavaBean parameters and
does not need to muck around with XML explicitly. You can generate WSDL
from your Java source using Java2WSDL, or you can start with a customized
WSDL file and generate service templates using WSDL2Java --server-side.
Your clients use WSDL2Java to generate stubs that use JavaBean parameters. 2. When you implement a document-style service with Axis, you have 3
different options for writing the Java implementation. You choose
the option you want by specifying the "style" attribute on the
<service> element in your deploy.wsdd file when you deploy the service.
style may be "document", "wrapped", or "message" (covered very nicely
in the Axis User's Guide). But no matter
which service style you choose, the actual SOAP message is still exactly
the same. What changes is the signature of the Java method that you
write to implement the service, and the way Axis deserializes the SOAP
message before calling your service method. 3. (I'm not 100% sure about the following. Axis experts?) To define a
document-style request-response operation, use
"<service provider='java:RPC'>" in deploy.wsdd. "RPC" here really
means "request-response operations", not "rpc-style operations the extra
wrapper element". I believe the only time you
specify provider="java:MSG" is when you define <service style='message'>The JAX-RPC spec does not discuss anything like the Axis concept of service style. The coding style discussed in the JAX-RPC spec is the Axis "document" style, where the service implementation and clients work with JavaBean arguments and return types. If you want to write Java code for document-style services that will work with any JAX-RPC implementation (Axis, JWSDP, etc.), use <service style='document'> in deploy.wsdd. (Note that deploy.wsdd is Axis-specific.)
"Message-style" is a term that is sometimes used as a synonym for "document-style", and is sometimes used to mean "a one-way document-style operation implemented with a message provider like JAXM or JMS". However, when Axis users say "message-style", they usually mean "document-style with <service style='document'>". Welcome to Babel.
The Castor article you referenced discusses document-style services, and that seems to be the way the industry is heading. So, for interoperability between different platforms (Java, .NET, Perl), use document-style operations. For portability between Java implementations (Axis, JWSDP), write your service implementation using JavaBeans (not Element[], Document, etc.) and use "<service style='document'>".
Hope this helps, Mike
If that's the case, then that is definitely an issue. I think my confusion is being compounded by an article I just read (http://www-106.ibm.com/developerworks/library/ws-castor/) that very strongly promotes this exact style. In fact, I was going to recommend it as a solution to the original question, but after reading the follow-up posts, I saw that that solution was being specifically discarded. Is it a non-standard solution? Are there interop issues with it? Or is it just the "axis" way of doing things and if one where to change to another implementation, they would need to rebuild based on that implementation's preferred methodology? Can you tell I like to ask questions? heh
It doesnt seem to me that web services are quite at this level of maturity but that should be the goal.
And a good one at that!
Thanks, Gene
--
Mike Woinoski Pine Needle Consulting mailto:[EMAIL PROTECTED]
