- From: Gary Brown <gary@enigmatec.net>
- Date: Thu, 24 Feb 2005 19:30:23 -0000
- To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor@w3.org>
- Message-ID: <008301c51aa7$4cf85190$0300a8c0@LATTITUDEGary>
MessageHi Tony
If this proposal is accepted, then I think it would need to reference the response's 'messageLabel' (as mentioned in Arthur's email) in the exchange element.
However, what is to prevent a MEP having multiple request messages? Is this covered in WSDL2?
Although we do have a charter to bind to WSDL2, I am not sure that CDL necessarily needs to be so literal in the way that it expresses the interactions that will map to a particular MEP. We do need to ensure that CDL could describe the message exchanges that may be defined within a WSDL definition, but I don't think this needs to necessarily be confined to a single interaction.
For example - if you have a MEP that has one request followed by two responses, then one approach would be to model it with two interactions, the first having the req-resp exchange elements and the second interaction having the second response exchange.
At model verification time, the overall sequence of message exchanges for the interactions in CDL could be compared against those in the WSDL definition - and if the second response is not found to follow the initial req-resp in all cases, then this would generate an error.
Regards
Gary
----- Original Message -----
From: Tony Fletcher
To: public-ws-chor@w3.org
Sent: Thursday, February 24, 2005 4:28 PM
Subject: Issue 996 - A proposal
Dear Colleagues,
I am informed by the Web Service Description group that WSDL 2.0 in its current draft form is able to describe the possibility of having several response messages for a (single) request message (refer to http://lists.w3.org/Archives/Public/public-ws-chor/2005Feb/0024.html).
As a resolution for Issue 996 I therefore propose that the following changes are made to the CDL specification:
1) It is made clear that an 'interaction' element can only have one 'exchange' element with action="request".
2) That an 'interaction' element can have more than one 'exchange' element with action="response".
a) the responses occur in the lexical order the are written in (i.e. with no wrapping element they occur in the sequence they are written)
b) if the responses, or a subset of them, are contained within a 'choice' element then one but only one of the responses in the choice occur
c) if the responses, or a subset of them, are contained within a 'set' element then they all may occur and in any order
3) The text with regard to causeException as left as is, that is there can be zero, one, or more exception causing (or fault) messages listed as responses in an interaction and they form an implicit 'choice' group (that is only one of them can occur).
4) If there are multiple responses defined then a CDL endpoint may emit an exception causing message after emitting one or more normal responses according to the definition. It is invalid to emit a normal response after emitting an exception causing message. A receiver may choose to receive a normal response message after receiving an exception causing message (within a single interaction definition) as it may have been generated before the exception causing message or may ignore it and just act on the exception causing message.
5) Amend the CDL schema as follows:
<complexType name="tInteraction">
<complexContent>
<extension base="cdl:tExtensibleElements">
<sequence>
<element name="participate" type="cdl:tParticipate"/>
<element name="exchangeGroup" type="cdl:tExchangeGroup" minOccurs="0" maxOccurs="unbounded"/>
<element name="timeout" type="cdl:tTimeout" minOccurs="0" maxOccurs="1"/>
<element name="record" type="cdl:tRecord" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
<attribute name="channelVariable" type="QName" use="required"/>
<attribute name="operation" type="NCName" use="required"/>
<attribute name="align" type="boolean" use="optional" default="false"/>
<attribute name="initiate" type="boolean" use="optional" default="false"/>
</extension>
</complexContent>
</complexType>
<complexType name="tExchangeGroup">
<complexContent>
<extension base="cdl:tExtensibleElements">
<choice>
<element name="exchange" type="cdl:tExchange"/>
<element name="choice" type="cdl:tChoiceExchange"/>
<element name="set" type="cdl:tSetExchange"/>
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="tChoiceExchange">
<complexContent>
<extension base="cdl:tExtensibleElements">
<sequence>
<element name="exchange" type="cdl:tExchange"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="tSetExchange">
<complexContent>
<extension base="cdl:tExtensibleElements">
<sequence>
<element name="exchange" type="cdl:tExchange"/>
</sequence>
</extension>
</complexContent>
</complexType>
Examples:
So the following would all become valid.
A)
<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>
B)
<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>
<choice>
<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>
</choice>
<exchange name="D" informationType="DType" action="respond">
<send variable="tns:D"/>
<receive variable="tns:D"/>
</exchange>
<exchange name="F" informationType="FType" action="respond">
<send variable="tns:F" causeException="true"/>
<receive variable="tns:F" causeException="true"/>
</exchange>
</interaction>
C)
<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>
<set>
<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>
</set>
<exchange name="D" informationType="DType" action="respond">
<send variable="tns:D"/>
<receive variable="tns:D"/>
</exchange>
<exchange name="F" informationType="FType" action="respond">
<send variable="tns:F" causeException="true"/>
<receive variable="tns:F" causeException="true"/>
</exchange>
</interaction>
Note: I added the 'set' element as seemed to be a logical extension of the ideas. If other are uncomfortable with it then I would be happy to see it removed. I think the sequence and choice possibilities for multiple responses will cover at least 80% of the cases.
Best Regards Tony
A M Fletcher
Cohesions (TM)
Business transaction management software for application coordination 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)
Received on Thursday, 24 February 2005 19:30:46 UTC