Re: SOAPAction to decide method-call

[Anne Thomas Manes]

It's a bad idea to use rpc/literal because quite a few major SOAP stacks (.NET, BEA, SAP, etc) don't support it.

What you should use is document/literal with the "wrapped" convention. If you are generating the WSDL using java2wsdl, specify that you want the "wrapped" style. If you are using the WSDL First approach, then you must design your WSDL according to the "wrapped" convention. Please see my blog entry for information about the "wrapped" convention:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html

I'll also repeat the basic rules here:

1. "Wrapped" is a form of document/literal, therefore it must follow all the rules defined for document/literal. When defining a document/literal service, there can be at most one body part in your input message and at most one body part in your output message. You do *not* define each method parameter as a separate part in the message definition. (The parameters are defined in the types section, instead.)
   
2. Each part definition must reference an element (not a type) defined, imported, or included in the types section of the WSDL document. These element definitions are "wrapper" elements (hence the name of this convention). You define your input and output parameters as element structures within these wrapper elements.
   
3. A wrapper element must be defined as a complex type that is a sequence of elements. Each child element in that sequence will be generated as a parameter in the service interface.
4. The name of the input wrapper element must be the same as the operation name.
5. The name of the output wrapper element should be (but doesn't have to be) the operation name appended with "Response" (e.g., if the operation name is "add", the output wrapper element should be called "addResponse").
   
6. In the binding definition, the soap:binding should specify style="document" (although this is the default value, so the attribute may be omitted), and the soap:body definitions must specify use="literal" and nothing else. You must not specify the namespace or encodingStyle attributes in the soap:body definition.

The reason why "a" is invoked regardless of whether you request "a" or "b" is that (per the behavior defined in the WS-I Basic Profile), a SOAP server dispatches the request based on the signature of the message. The WS-I Basic Profile requires that each SOAP message must have a unique signature. The signature is determined by the QName of the child element of the <soap:Body> -- and in your case the QName for both methods is the same -- "x".  Axis supports mapping a QName to only one method, therefore it always maps it to "a". Axis does not use the SOAPAction header for dispatching.

When using rpc/encoded or rpc/literal, the SOAP engine always generates a wrapper element for the request, and the QName is always the same as the method name. When using the wrapped document/literal style, you define your own wrapper element for the request, and the QName is again always the same as the method name. When using any of these approaches, Axis automatically knows how to dispatch the request. When using unwrapped document/literal, your input message must have at most one body part, but the QName of that body part does not have to be the same as the method name. BUT the QName must be unique for each method. You also must tell Axis how to map that QName to the appropriate method using operation tags in the WSDD.

Note that the SOAPAction header has not been deprecated for SOAP 1.1. The SOAP 1.1 spec requires that a SOAPAction header must be included in all HTTP SOAP requests. But the SOAPAction header provides only a "hint" for dispatching, which a SOAP engine can use to optimize the dispatching process, but in all cases, the QName signature overrides the SOAPAction.

The SOAPAction header is not used in SOAP 1.2. The functionality has been replaced by the Action attribute in WS-Addressing.

Regards,
Anne

On 11/9/05, Guy Rixon <[EMAIL PROTECTED]> wrote:

IIRC, the SOAPAction header is deprecated. If you have freedom to change the
WSDL contract, then your service would do better as rpc/literal than
document/literal: this wraps x in the name of the operation and allows
dispatching based only on the SOAP content, not on the transport details.

However, I wasn't aware that SOAPAction support was missing/broken in Axis.

On Wed, 9 Nov 2005, Per Steffensen wrote:

> Hi
>
> I have a document/literal Axis webservice (EJB provided). It contains to
> operations "a" and "b" that take that same kind of parameter "x". I
> generate client stubs to call the webservices though java client code. I
> have looked at the request send over the wire (using af http sniffer),
> when calling "a" and "b" respectivly. The only difference between the
> two request is the SOAPAction header. It is "a" and "b" respectivly. But
> it is the method "a" on the EJB that is called to in both cases. I have
> operation-tags in server-config.wsdd for both operations, and I have put
> soapAction attributes on them. Any idea why it does not work? Why is
> method "b" on the EJB not called when I call method "b" on the generated
> client stubs (and SOAPAction header is "b" in the request)?
>
> Kind regards, Steff
>

Guy Rixon                                       [EMAIL PROTECTED]
Institute of Astronomy                          Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA          Fax: +44-1223-337523