Tony,

I'm not an expert on Schema, but I don't think you can derive elements by extension. (You can derive types, but not elements -- correct me if I'm wrong.) But either way -- you can't derive a wsdl:message from another wsdl:message. Each message part definition must refer to a schema element definition -- so any deriving you do will have to be in your schema definitions.

The WS-I requirement is that each operation must have a unique qname. A qname (fully qualified name) consists of a namespace and a local name. The input messages can be in the same namespace as long as they have different local names.Or they may have the same local name as long as they belong to different namespaces. I'm not sure why you think it might be easier to create multiple namespaces rather than multiple elements within a single namespace.

Note that your elements can share the same type. Perhaps that's what you're thinking of? Let me give you an example:

Let's say you have a calculator service which supports add and subtract operations. Both operations take two floats in and return a float.

I would create one type ("input") and use it for the two input elements:

<definitions name="calculator" targetNamespace="urn:calculator"
     xmlns="http://schemas.xmlsoap.org/wsdl/";
     xmlns:calc="urn:calculator" >
<types>
<schema name="calculatorTypes" targetNamespace="urn:types"
     xmlns:"http://www.w3.org/2001/XMLSchema";
     xmlns:types="urn:types" >
<complexType name="input">
   <sequence>
       <element name=parm1 type="xsd:float"/>
       <element name=parm2 type="xsd:float"/>
   </sequence>
</complexType>
<element name="add" type="types:input"/>
<element name="subtract" type="types:input"/>
<element name="result" type="xsd:float"/>
</schema>
</types>
<message name="result">
   <part name="body" element="types:result"/>
</message>
<message name="addRequest">
    <part name="body" element="types:add"/>
</message>
<message name="subtractRequest">
    <part name="body" element="types:subtract"/>
</message>
<portType name="calculator">
   <operation name="add">
         <input message="calc:addRequest"/>
         <output message="calc:result"/>
   </operation>
   <operation name="subtract">
         <input message="calc:subtractRequest"/>
         <output message="calc:result"/>
    </operation>
</portType>

(notice that I made this conform to the "wrapped" style convention -- my wrapper input element names are the same as my operation names)

If you wanted to use separate namespaces, it would look something like this:

<definitions name="calculator" xmlns="http://schemas.xmlsoap.org/wsdl/";
     targetNamespace="urn:calculator"
     xmlns:calc="urn:calculator"
     xmlns:types="urn:types"
     xmlns:add="urn:add"
     xmlns:sub="urn:subtract" >
<types>
<schema targetNamespace="urn:types"
        xmlns="http://www.w3.org/2001/XMLSchema"; >
<complexType name="input">
   <sequence>
       <element name=parm1 type="xsd:float"/>
       <element name=parm2 type="xsd:float"/>
   </sequence>
</complexType>
<element name="result" type="xsd:float"/>
</schema>
<schema targetNamespace="urn:add"
        xmlns:types="urn:types"
        xmlns="http://www.w3.org/2001/XMLSchema"; >
<element name="request" type="types:input"/>
</schema>
<schema targetNamespace="urn:subtract"
        xmlns:types="urn:types"
        xmlns="http://www.w3.org/2001/XMLSchema"; >
<element name="request" type="types:input"/>
</schema>
</types>
<message name="result">
   <part name="body" element="types:result"/>
</message>
<message name="addRequest">
    <part name="body" element="add:request"/>
</message>
<message name="subtractRequest">
    <part name="body" element="sub:request"/>
</message>
<portType name="calculator">
   <operation name="add">
         <input message="calc:addRequest"/>
         <output message="calc:result"/>
   </operation>
   <operation name="subtract">
         <input message="calc:subtractRequest"/>
         <output message="calc:result"/>
    </operation>
</portType>

But somehow this seems a lot more complicated to me.

Another way to do it is to define the "request" element in one schema, then <xsd:include> the element in a second schema -- but I don't know how well all the WSDL tools support included element definitions.

Anne


At 06:54 PM 1/15/2004, you wrote:


Hi Anne,

Thanks for your clarification.

So, if the WS-I BP 1.0 requirement is to ensure that each operation have a unique input message for (Doc/Lit based SOAP messaging) then it seems we can possibly satisfy that requirement by allowing the one operation's input message be derived-by-extension fromanother operation's input message.

Are there any restriction that the derived-by-extension input message

is defined in a different namespace, possibly?

Thanks again.



-----Original Message-----

From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]

Sent: Thursday, January 15, 2004 5:38 AM

To: [EMAIL PROTECTED]

Subject: Re: Can AXIS 1.1 Web Services have operations sharing same

Requests/Responses?



Tony,

I can't answer your question regarding the behavior of Axis, but according

to the WS-I Basic Profile, each operation must have a unique message

signature, which is defined by the qname of the child element of the

<env:Body> element. (When using Doc/Literal, the child element of the

<env:Body> is the element specified in the input message body <part>

element attribute.) Therefore each operation must use a unique input

message. No such restriction exists for the output message.

Anne

At 11:18 AM 1/15/2004, you wrote:

>In AXIS using the WSDL2Java tool it seems that for Document style SOAP

>messages, i.e., Doc/Lit messaging option, there is a limitation that if we

>have more than two or

>more operations for a given web service then each of those web services

>have to

>have different (i.e., unique) Request and Response types defined as part

>of the

>wsdl:message component definition:

>

>- Ops1Request

>- Ops1Response

>- Ops2Request

>- Ops2Response

>

>where Ops1Request and Ops1Response will be processed by the web service's

>Ops1 operation, and Ops2Request and OpsResponse would be processed by

>the web service's Ops2 operation.

>

>Is it possible for some of the operations that are defined as part of the WSDL

>interface specification to re-use the Request and Response type for different

>operations?

>

>Or, is true that AXIS 1.1 run-time has problems in handling multiple

>operations within a web service?

>Does AXIS 1.1 depend on the unique request types such that Axis framework

>knows exactly which operation that it should dispatch to?

>

>Is there a workaround for this in AXIS 1.1 and/or recommendation of how we

>should

>design the WSDL interface spec?

>

>Isn't this behaviour consistent with WSDL 1.1?

>

>Thanks for your help.

>


Do you Yahoo!?
Yahoo! Hotjobs: <http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/mail_footer_email/evt=21482/*http://hotjobs.sweepstakes.yahoo.com/signingbonus>Enter the "Signing Bonus" Sweepstakes




Reply via email to