RE: Choice of response message in WSDL

Dear Arthur,
 
Sorry for the delay in replying to you.  I read your email when it came and
thought 'I should to reply to that', then went on to other things and forgot
to come back to it.  I was reminded on the WS-Choreography call yesterday.
 
So if I understand it correctly you are saying that WSDL 2.0 will provide
ways of having more than one response message for a request message.  The
pattern I was using is close (not quite correct syntax from what you said)
to what is needed for the case were you have request followed by response
message, followed by another response message, or one of a choice of fault
messages.  However, I understand you to say there is a different way of
stating that you have a request message followed by a response message or a
different type of response message or one of a number of fault messages.
 
If that is the case then I think that is good.  I hope all this will be well
covered in the new Primer for WSDL 2.0 and I shall have to have a read of
that.
 
Thank you for your help and clarifications.
 
Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com <http://www.choreology.com/> 
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: 26 January 2005 17:32
To: Tony Fletcher
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: RE: Choice of response message in WSDL



Tony, 

As I understand it, your example is of a service that returns either B or C
but not both in response to a given input, i.e. it is a request-response
message exchange pattern. 

The syntax you propose is used in WSDL 2.0 to describe a more complex
message exchange pattern, i.e. one that returns two output messages. The
complete syntax requires that you reference a MEP URI that decribes the MEP,
and that each output message element also includes a messageLabel attribute
to identify the role played by each of the output messages. 

In fact you could achieve your desired result by defining a new MEP that has
1 input role and 2 output roles, but the MEP specification would state that
the two output roles are mutually exclusive. I am not actually suggesting
this as a solution, just an illustration of the semantics of multiple output
elements in WSDL 2.0. 

There is a difference between messages and faults. Listing multiple faults
means that any of them may occur. The MEP specifies when they may occur.
Typically, a single fault occurs. To be completely consistent, we could have
required that only a single fault be specified and that its content be
specified by a wrapper type if more then one "real" type occurs. 

The motivation for this design comes from programming languages which allow
you to list Exception classes in a throws clause, e.g. 

public Response operation(Request x) throws Exception1, Exception2, ...,
ExceptionN 

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/ 



"Tony Fletcher" <tony.fletcher@choreology.com> 
Sent by: www-ws-desc-request@w3.org 


01/26/2005 08:48 AM 


To
Arthur Ryman/Toronto/IBM@IBMCA 

cc
<www-ws-desc@w3.org>, <www-ws-desc-request@w3.org> 

Subject
RE: Choice of response message in WSDL

	




Dear Arthur, 
  
Thank you very much for your response. 
  
I regard this solution as a viable workaround, but I still view it as a
'workaround'.  I understand that this solution of having a single wrapper
with internal divisions, as in your example below, works for both WSDL 1.1
and proposed 2.0.  Loosing the wrapper in the binding is a new twist that
could be useful. 
  
However I was looking for a way of expressing, in the *abstract* description
of the Web Service that there are two, or more, regular (i.e. not fault)
messages allowed as a response to a given request message (so that messages
(elements) B and C appear directly in the Description and there is no
requirement for the artificial element BorC).  This does not seem to be
duplicating schema at all, but just allowing one to state that this request
message has these possible defined responses and these possible defined
fault responses, all of which seems to me to be appropriate for a
description of the abstract services.  I understand that you do already
support this for fault message responses so extending to response messages
seems a logical step (and a concluding one in that it does not open any
floodgates). 
  
However, if you have already discussed this at length and the case has been
lost I shall peacefully retire (disappointed!). 
  
PS  to be clear using your example I am looking for the following (or
something that means the same) to be legal: 
<interface name="Responder">
   <operation name="abc">
       <input message="tns:A"/> 
        <output message="tns:B"/>
        <output message="tns:C"/>
      <outfault name="fault" message="tns:F"/>
   </operation>
</interface> 

and similarly: 
<interface name="Requestor">
<operation name="abc">
       <output message="tns:A"/> 
        <input message="tns:B"/>
        <input message="tns:C"/>
      <infault name="fault" message="tns:F"/>
   </operation>
</interface> 
  
Best Regards, 
Tony                           


 <http://www.choreology.com/>  	Tony Fletcher 
Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK 

Phone:   	+44 (0) 1473 729537 

Mobile: 	+44 (0) 7801 948219 

Fax:     	+44 (0) 870 7390077 

Web: 	 <http://www.choreology.com/> www.choreology.com 

CohesionsT 

Business transaction management software for application coordination 

Work: tony.fletcher@choreology.com 

Home:  <mailto:amfletcher@iee.org> amfletcher@iee.org

-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: 24 January 2005 20:28
To: Tony Fletcher
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: Choice of response message in WSDL


Tony, 

The WSDL 2.0 WG discussed the message issue at length, and the conclusion
was that if we added support for constructs like "choice" then we would we
slowly but surely reproduce a lot of XSD. There were many requests for more
control over the parts of a message. The solution we adopted was to discard
the WSDL 1.1 <message> and <part> elements altogether and simply use XSD
Global Element Declarations (GEDs) directly. 

The key point about this design is that the GED is viewed as an abstract
message definition. The concrete details come in at the binding level. The
binding rules are simple in the case where the concrete message is the same
as the abstract message, e.g. for SOAP, the simple case is to use the GED as
the <body> content of the SOAP <envelope> 

In your case, the idea would be to define a GED, BorC, whose content model
was a choice of the two response messages: 

<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/choicy"
xmlns:tns="http://example.com/choicy"> 
       <element name="B" type="string"></element> 

       <element name="C" type="string"></element> 

       <element name="BorC"> 
               <complexType> 
                       <choice> 
                               <element ref="tns:B"></element> 
                               <element ref="tns:C"></element> 
                       </choice> 
               </complexType> 
       </element> 

</schema> 

The WSDL 2.0 interface (aka portType) is: 

<interface name="Responder">
   <operation name="abc">
       <input message="tns:A"/> 
        <output message="tns:BorC"/>
      <outfault name="fault" message="tns:F"/>
   </operation>
</interface> 


This introduces a top level wrapper element <BorC> that you probably don't
want in the concrete SOAP message. The solution is to modify the SOAP
binding rules, i.e. to copy the content of the GED into the <body> rather
than the entire GED including that unwanted root element. 

FYI, we have had a related request to allow more flexibility in our SOAP
binding to permit muliptle children in the <body>. The binding rule: "copy
the element content into the <body>" would work for your case and the
multiple children case. 

Does this binding approach satisfy your requirement? 

Note that the fault issue is handled at the MEP level. We have several
predefined MEPs already that specify how and when fault elements occur. See
part 2. [1] 

[1] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/ 

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/ 



"Tony Fletcher" <tony_fletcher@btopenworld.com> 
Sent by: www-ws-desc-request@w3.org 


01/24/2005 01:30 PM 




To
<www-ws-desc@w3.org> 

cc

Subject
Choice of response message in WSDL


	





To the W3C Web Service Description Group, 
 
[Please copy me directly on responses as while I am on the WS-Choreography
mailing lists I am not on the Web Service Description mailing lists - Thank
you.] 


In the Last Call version of the WS-Choreography specification several
exchange elements are allowed in an interaction element.  One is the request
going in one direction and the others must be in the reverse direction.
Only one of these is allowed to be the 'normal' response message, all the
others must be fault messages. 
 
The case I am particularly interested in seems to be supported by neither
WS-Choreography at present nor WSDL 2.0  and I wonder if it should be.   (I
understand that WSDL 2.0 could support what I propose as an extension,
though I make  this comment to the WSD group with the aim of making it a
standardised feature.) 
 
Suppose I have request - response protocol pair but there can be several
distinct response messages.  So I want to say the request message is A and
the response is B or C (or possibly fault message X or Fault message Y). 
 
I realise that of course you can write it as five (in this case) one way
interactions, but that looses the request response semantic.  You could also
re-write the protocol to only use a single response message and internally
to the response message have different parameter values that give the
semantics of B or C - and likewise one can re-write the Fault message to
combine X and Y, but why should one have to change the protocol to suit
WSDL? 
 
In WS-Choreography I would like to be able to write, for example, something
like: 
<interaction name="ABCF" channelVariable="tns:aChannel" operation="a"> 
     <participate relationshipType="SuperiorInferior"
fromRole="tns:Superior" toRole="Inferior"/> 
     <exchange name="A" informationType="Atype" action="request"> 
             <send variable="tns:A"/> 
             <receive variable="tns:A"/> 
      </exchange> 
      <exchange name="B" informationType="BType" action="respond"> 
             <send variable="tns:B"/> 
             <receive variable="tns:B"/> 
       </exchange> 
       <exchange name="C" informationType="CType" action="respond"> 
             <send variable="tns:C"/> 
             <receive variable="tns:C"/> 
       </exchange> 
       <exchange name="F" informationType="FType" action="respond"> 
             <send variable="tns:F" causeException="true"/> 
             <receive variable="tns:F" causeException="true"/> 
       </exchange> 
</interaction> 
 
and in the corresponding Web Service description  I would like to be able to
write something like: 
<portType name="Requester">
   <operation name="abc">
        <output message="tns:A"/>
        <input message="tns:B"/>
        <input message="tns:C"/>
        <fault name="fault" message="tns:F"/>
   </operation>
</portType>
<portType name="Responder">
   <operation name="abc">
        <input message="tns:A"/>
        <output message="tns:B"/>
        <output message="tns:C"/>
        <fault name="fault" message="tns:F"/>
   </operation>
</portType> 
 
or with explicit choice construct: 
<portType name="Requester">
   <operation name="abc">
        <output message="tns:A"/>
        <choice> 
             <input message="tns:B"/>
            <input message="tns:C"/> 
        </choice>
        <fault name="fault" message="tns:F"/>
   </operation>
</portType>
<portType name="Responder">
   <operation name="abc">
        <input message="tns:A"/>
        <choice> 
             <output message="tns:B"/>
            <output message="tns:C"/>
         </choice>
      <fault name="fault" message="tns:F"/>
   </operation>
</portType> 
 
I would be quite happy to have either some sort of explicit 'choice'
construct around the multiple responds that are regular permitted responses
and therefore do not have cause exception set, or an implicit choice as we
currently have for multiple exception causing responses. 
  

Best Regards, 
Tony                           



 <http://www.choreology.com/>  	Tony Fletcher 
Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK 

Phone:   	+44 (0) 1473 729537 

Mobile: 	+44 (0) 7801 948219 

Fax:     	+44 (0) 870 7390077 

Web: 	 <http://www.choreology.com/> www.choreology.com 

CohesionsT 

Business transaction management software for application coordination 

Work: tony.fletcher@choreology.com 

Home:  <mailto:amfletcher@iee.org> amfletcher@iee.org


Choreology Anti virus scan completed