W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2005

Issue 996 - A proposal

From: Tony Fletcher <tony_fletcher@btopenworld.com>
Date: Thu, 24 Feb 2005 16:28:10 -0000
To: <public-ws-chor@w3.org>
Message-ID: <000001c51a8d$d5442110$6401a8c0@corp.choreology.com>
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 <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)
 
Received on Thursday, 24 February 2005 16:28:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:07 UTC