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

Re: Issue 996 - A proposal

From: Gary Brown <gary@enigmatec.net>
Date: Mon, 28 Feb 2005 10:20:43 -0000
Message-ID: <004301c51d7f$2d18a890$0200a8c0@LATTITUDEGary>
To: "Tony Fletcher" <tony_fletcher@btopenworld.com>, <public-ws-chor@w3.org>
MessageHi Tony,

The MEP pattern only expresses the sequence of messages "on the wire" - where as CDL represents more than that. For example, it is possible that in between performing all the exchanges related to a single MEP pattern, that we may actually want to have a request response with another participant - which may return some information that is subsequently used in further exchanges within this complex MEP pattern.

Therefore I would suggest that having different parts of an MEP handled by more than one interaction activity is essential. This is why in my previous response I indicated that it should be the responsibility of the model verification tools to ensure that the behavior of the exchanges across multiple interactions is verified against the expected MEP.

Regards
Gary
  ----- Original Message ----- 
  From: Tony Fletcher 
  To: 'Gary Brown' ; public-ws-chor@w3.org 
  Sent: Saturday, February 26, 2005 4:01 PM
  Subject: RE: Issue 996 - A proposal


  Dear Gary,

  I have been thinking about your proposal and I think it works all right.  One concern is that it looks fine as you have written it but what if other stuff starts being inserted between the different parts of the one 'operation'?  Putting within an interaction bracket makes it clear (and the spec can and should state this) that all the enclosed exchanges are part of the same semantically coupled set of messages and the only things that can be interspersed between them are endpoint 'events', such as the current 'record' that are directly coupled to that message exchange.  So long as we keep the coupling then I am not too worried about the precise syntax.  (Or to put it another way I want to prevent people from being 'silly' and just scattering parts of the same 'myop' liberally around the description, just because the spec does not say you can not do that!)

  I am concerned that we somehow have the ability to say that a request message may have more than one valid response message associated with it.

  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)
  -----Original Message-----
  From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown
  Sent: 25 February 2005 09:00
  To: Tony Fletcher; public-ws-chor@w3.org
  Subject: Re: Issue 996 - A proposal


  Hi Tony

  Just to clarify, in my example below I was referring to an MEP where the two responses were received in sequence, so in this case there is no choice necessary - i.e. one response is not being favoured over another.

  However, if we wanted to model the two mutually exclusive response case, then it could be modelled as:

  <interaction op="myop" >
      <exchange action="request" />
  </interaction>
  <choice>
      <interaction op="myop" >
          <exchange action="response" name="firstResponse" />
      <interaction>
      <interaction op="myop" >
          <exchange action="response" name="secondResponse" />
      </interaction>
  </choice>

  This is similar to your solution but just externalises the choice outside the interaction. The only addition required here is to provide a name with the exchange response - which would map to the messageLabel in the WSDL (which answers your other question).

  Regards
  Gary
    ----- Original Message ----- 
    From: Tony Fletcher 
    To: 'Gary Brown' ; public-ws-chor@w3.org 
    Sent: Thursday, February 24, 2005 9:55 PM
    Subject: RE: Issue 996 - A proposal


    Dear Gary,

    Thank you for a thoughtful response - as always from you.  I have embedded a few responses below.

    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)
    -----Original Message-----
    From: Gary Brown [mailto:gary@enigmatec.net] 
    Sent: 24 February 2005 19:30
    To: Tony Fletcher; public-ws-chor@w3.org
    Subject: Re: Issue 996 - A proposal


    Hi 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. 
    <Tony>Very likely.  I agree we would need to study WSDL 2.0 in sufficient detail to determine what we would need to make a clear linkage, although if the responses have unique names I am not sure what they would add. </Tony> 

    However, what is to prevent a MEP having multiple request messages? Is this covered in WSDL2? 
    <Tony>Do not know.  Again we would need to study WSDL 2.0.  I said one request as I assumed that it was the request name that distinguished one 'operation' or set of request and allowable responses from another.  Do you have a particular 'use case' in mind, where you would need to do as a single unit rather than having the ability to send requests 'in parallel' (where each request had its own define pattern of allowed responses)?  Even if the multiple request case is theoretically possible I would have thought it is a bit of an 'edge' case and we could omit for an 80 - 90% case solution. </Tony>  

    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. 
    <Tony> I agree in principle - see above as well</Tony>

    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. 
     <Tony> But in this case it seems to me that you are 'favouring' one response over another.  If both are legitimate responses of equal standing, why should there be a need to treat them differently in the choreo description?</Tony>

    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.
    <Tony> Yes certainly should be able to check that the sequencing of messages according to the choreo description is supported by the WS description. (It may not be the only one supported in general.)</Tony>

    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 Monday, 28 February 2005 10:21:03 UTC

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