axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <atma...@gmail.com>
Subject Re: SOAPAction to decide method-call
Date Wed, 09 Nov 2005 12:02:59 GMT
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 <gtr@ast.cam.ac.uk> 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 gtr@ast.cam.ac.uk
> Institute of Astronomy Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
>

Mime
View raw message