No it's not less sleep, or more coffee, or anything else :-).
Correct me if I am wrong, but I am under the impression that axis does not use SOAP action at all when invoking a service.
If someone wants to use doc\literal service to have multiple operations he has to explicity map the operation and the doc\literal element in the wsdd -at least that's what I heard.
Try writing something like this in the wsdd for each operation.
<operation name="methodName" qname="operNS:ElementName" xmlns:operNS="uri" returnQName="returnName" returnType="rtns:returnType" xmlns:rtns="uri" > </operation>
Can you please let me know if this works ?
Well, this doesn't do what I want to do (although I'm glad you mentioned it; now I understand the purpose of the <operation> element). But it still uses the SOAP Body's child element to map to a Java method. If I have two operations that take a PurchaseOrder as an input message, this technique will not be able to determine which operation to invoke.
However, as Anne mentioned, WS-I Basic Profile prohibits what I want to do:
5.6.7 Wire Signatures for Operations
An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique wire signature.
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.
So basically we shouldn't define document/literal services that have two operations with the same input message. It certainly makes sense for interoperability. It just means clients need to add an extra element to the message.
I wonder how .NET handles it?
Mike
--
Mike Woinoski Pine Needle Consulting mailto:[EMAIL PROTECTED]
