Mark,
If the request contains:
<s:Body xmlns:s="[soapNamespace]">
<submitDocument xmlns="[yourNamespace]">
<requestA>someArg</requestA>
</submitDocument>
</s:Body>
Then a WS-I compliant server will use the yourNamespace}submitDocument
element as the message signature and dispatch it accordingly.
If you have defined the contents of the <submitDocument> element to be
a choice or a substitution group, then it will not qualify as wrapped
doc/literal. The wrapped convention requires that the wrapper element
be defined as a <sequence>.
My guess is that you will experience a lot of interop issues with a
service like this.
You would do better to define two separate operations for "requestA"
and "requestB".
Anne
Anne
On 9/12/07, Mark Airey <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is something that I have been attempting to understand myself. I
> am developing a wrapped style service that publishes one operation, but
> this operation looks at the wrapped element to determine what to do.
> For example if the request is
> <submitDocument><requestA>someArg</requestA></submitDocument> my service
> sees the requestA element, validates it against the proper schema, and
> instantiates ClassA to gather and return data. If the request is
> <submitDocument><requestB>someOtherArg</requestB></submitDocument> my
> service sees the requestB element, validates it against the proper
> schema, and instantiates ClassB to gather and return data. I have
> defined a substitution group for the valid request elements. Is this
> WS-I compliant? It works for me, but I have had some trouble getting an
> automated test tool to generate a client it can use via the wsdl.
>
> Mark
>
> > Oliver,
> >
> > The WS-I Basic Profile specifies that each operation must have a
> > unique signature. (The SOAP and WSDL specifications don't address this
> > issue, therefore it's unspecified.) On a practical level, the SOAP
> > engine requires some means to determine how to dispatch the request,
> > therefore it needs some type of signature.
> >
> > Per the WS-I BP, an operation's signature is defined as the qualified
> > name of the child element of the SOAP Body element. If you define the
> > input message part for one of your operations as element="xsd:any",
> > you would have no way to differentiate that operation from any other
> > operation. Therefore, if you want to expose multiple operations in the
> > service, you must define unique wrapper elements for each one.
> >
> > Axis follows the WS-I BP signature requirements. Axis2 allows for
> > other methods to specify the signature, such as the SOAPAction header
> > or a WSA Action value.
> >
> > Anne
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
