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 On 9/10/07, Oliver Charlet <[EMAIL PROTECTED]> wrote: > > thanks Anne for your comments. > > re. 2 - : is that a standard? I see, that axis generates a wsdl with a > wrapper tag for each operation in the service (in case of a message style > implementation). But is that a documented must do? I understand the > advantages, but still think this is a little overhead, if I just want to > switch from the usual binding to a raw xml implementation. Obviously the > wsdl should be pure semantics and not depending upon the style of > implementation. > ----------------------- > oliver charlet > software development > > 11-041 Olsztyn, Poland > > [EMAIL PROTECTED] > ----------------------- > > > Anne Thomas Manes schrieb: > Some more guidance on this: > > There are a couple of reasons why you might have to use a wrapper element: > 1- If you want to send more than one root element in a single SOAP message > 2- If you want your service to expose more than one operation > > Hope this helps, > > Anne > > On 9/7/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > Oliver, > > Your WSDL message definition is not valid. > > It should be: > > <message name="operationA"> > <part name="content" element="xsd:any"/> > </message> > > Alternatively, you might want to define a wrapper element for your > message content, in which case you would define the message thus: > > <message name="operationA"> > <part name="content" element="tns:operationA" /> > </message> > > and you would also have to define the operationA element in your > <types> section: > > <types> > <xsd:schema targetNamespace="[tns]"> > <xsd:element name="operationA type="xsd:anyType"/> > </xsd:schema> > </types> > > Anne > > On 9/7/07, Oliver Charlet <[EMAIL PROTECTED]> wrote: > > > Hi y'all, > > I am having trouble to get to work a setup that seems to be rare, but > which for me is rather practical: > > 1) I have a wsdl, that defines a schema for the input of a message, i.e. > I want the content of the soap body to of that schema. This wsdl is used > to communicate with the users of the service - of course. > 2) I don't want a Java Binding, because I simply want to take the raw > XML from the body and do something with it (like serializing to filesystem). > 3) So I create a "bottom up" service implementation, that uses the > message style Element[] operationA(Element[] elms) signature. > 4) I use the wsdlFile tag to serve the original wsdl to the user, when > he asks for it using ...?wsdl on the Service URL > > now the problem: > When I do 3), Axis would theoretically create a generated wsdl, that > would define my operation message part as: > <message name="operationA"> > <part element="operationA" type="xsd:anyType"/> > </message> > that means, that in my case the actual payload of the incoming message > would need to be inserted into the operationA-Tag that was defined by > axis at the time of deployment as shown above. > After I do 4), axis still expects that Tag "operationA" to be inside the > soap body. But now I have a service that does not reflect the published > wsdl, which after 4) is the original one defining the payload to be an > instance of the schema inside it - without the operationA-Tag. > That means, that any user trying to access my service, reading the > public wsdl will get an error, because axis expects a different soap > message. > > This is a little complicated to explain - but still I hope, that someone > can give me a hint on how to do this the right way. > Again here is what I want to achieve: > - have an initial wsdl > - create a "generic" service implementation handling pure XML, avoiding > generation of XML-JAVA bindings > - publish the initial wsdl instead of the generated one > - make this scenario work... > > Thanks for any help > :oliver > > -- > ----------------------- > oliver charlet > software development > > 11-041 Olsztyn, Poland > > [EMAIL PROTECTED] > ----------------------- > > > --------------------------------------------------------------------- > 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] > > > --------------------------------------------------------------------- > 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]
