Thanks all for your pointers.
Regards
Jaya
On 9/4/05, Mike Woinoski <[EMAIL PROTECTED]> wrote:
>>Supposing I've to extract the operation name from a SOAP Envelope I got into
>>my code, can I safely assume that for all styles and uses (doc-lit, rpc-enc)
>>the first child element of body has its localPart as the operation Name, or
>>are there any hitches in making that decision
>
>
> You can assume this for rpc/encoded but not for document/literal. Basic
> doc-lit sends and receives documents defined by schemata external to the web
> service (i.e. XSD files included in the WSDL contract) and it doesn't require
> an enclosing element named after the operation.
Right, and this is explicitly stated in the WS-I Basic Profile 1.0:
R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in
wire signatures that are different from one another.
The Profile defines the "wire signature" of an operation in a
wsdl:binding to be the fully qualified name of the child element of the
soap:Body of the SOAP input message it describes...In the case of
rpc-literal binding, the operation name is used as a wrapper for the part
accessors. In the document-literal case, since a wrapper with the operation
name is not present, the message signatures must be correctly designed so
that they meet this requirement.
I believe that's why Axis defines an <operation> element in the <service>
definition in server-config.wsdd:
<operation name="processEmployees" qname="ns1:processEmployees"
returnQName="ns1:processEmployeesReturn" returnType="xsd:int"
soapAction="" xmlns:ns1="http://www.ltree.com/types"
xmlns:xsd=" http://www.w3.org/2001/XMLSchema">
<parameter qname="ns1:emps" type="ns1:Employee"/>
</operation>
The <operation> defines a mapping between the child element of the SOAP Body in
the request ("qname" attribute) to the method in the implementation class
("name" attribute). If the operation follows the wrapper-style convention, Axis
doesn't need the <operation> definition.
Mike
--
-- Jaya
