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]
