Re: Proposal against issue 1001

Hi Nick

Firstly, in terms of our proposal, there is no difference between a conversion and choreography session (as per your definitions) - all message exchanges and actions are performed in the same 'global' session - i.e. it is a logical session that spans across all participants in a choreography that are actively involved in a particular business transaction instance.

Therefore it is not necessary to define them as separate concepts on the channelType. The only thing that is required is to provide a clear indication of what purpose an identity plays in relating a channel instance to a session instance - which is what the "association", "derived".... types are for in our spec.

BTW - cc'ed to public list as I think others need to get involved in this discussion, especially as there is not much time remaining.

Regards
Gary

----- Original Message ----- 
  From: Nickolas Kavantzas 
  To: Gary Brown ; Steve Ross-Talbot 
  Sent: Wednesday, April 20, 2005 12:25 AM
  Subject: Re: Proposal against issue 1001


  Here is my simple clarification question:

  What is a session? Is it a Conversation session, 
  a Choreography session, either, both?

  In the case of a Conversation session, then this is
  defined in CDL today as a collection of one or more
  message exchanges (ixns).

  In the case of a Choreography session, then this is
  defined in CDL today as the performance of the actions
  defined within a choreography definition.

  IMHO, one session type is not mutually exclusive of the other and I think that we can
  use your latest proposal with some changes to accomodate both session types!



  Below are examples:


  <channelType chT1>
    <role="r1"/>

    <choreoSession>
       <token="OrderId">
    </choreoSession>
  </channelType>

  <channelType chT2>
    <role="r2"/>

    <choreoSession>
       <token="OrderId">
    </choreoSession>
  </channelType>

  <channelType chT3>
    <role="r3"/>

    <choreoSession>
       <token="OrderId">
    </choreoSession>

    <convSession>
       <token="SupplierId">
    </convSession>
  </channelType>

  <channelType chT4>
    <role="r4"/>

    <choreoSession>
       <token="OrderId">
    </choreoSession>

    <convSession>
       <token="SupplierId">
    </convSession>
  </channelType>


  <choreo a>
    <seq>
       <!-- this ixn i1 is a marked as a Choreography initiator interaction and as such it
            initiates a choreo instance using the OrderId="12345" as the 
            Choreo Instance Value --> 
       <ixn name"i1" initiate="true">
          <ch1Var_chT1 OrderId="12345"/>
       </ixn>

       <!-- the ixns i2, i3 join the choreo inst above using the OrderId="12345" 
            as the Choreo Instance Value -->
       <ixn name"i2" >
          <ch2Var_chT1 OrderId="12345"/>
       </ixn>

       <ixn name"i3" >
          <ch3Var_chT2 OrderId="12345">
       </ixn>

       <par>
          <!-- the ixns i4, i4CB, i5, i5CB join the choreo inst above using the OrderId="12345" 
            as the Choreo Instance Value.

            Additionally:
              a) ixn i4 also initiates a new conversation session 
                 using the SupplierId="1" as the Conversation Inst Value
              b) ixn i4CB callbacks within the existing conversation session 
                 using the SupplierId="1" as the Conversation Inst Value

              c) ixn i5 also initiates a new conversation session 
                 using the SupplierId="2" as the Conversation Inst Value
              d) ixn i5CB callbacks within the existing conversation session 
                 using the SupplierId="2" as the Conversation Inst Value
            -->
          <seq>
           <ixn name"i4" >
             <ch4Var_chT3 OrderId="12345" SupplierId="1" />
           </ixn>

           <ixn name"i4CB" >
              <ch4CBVar_chT4 OrderId="12345" SupplierId="1" />
           </ixn>
          </seq>

          <seq>
           <ixn name"i5" >
             <ch5Var_chT3 OrderId="12345" SupplierId="2" />
           </ixn>

           <ixn name"i5CB" >
             <ch5CBVar_chT4 OrderId="12345" SupplierId="2" />
           </ixn>
          </seq>

       </par>
    </seq>
  </choreo>


  --
  Nick

    ----- Original Message ----- 
    From: Gary Brown 
    To: Nickolas Kavantzas ; Steve Ross-Talbot ; 'WS-Choreography List' 
    Sent: Tuesday, April 19, 2005 12:08 PM
    Subject: Re: Proposal against issue 1001


    Hi Nick

    Actually the initial proposal in November is very similar to the current proposal - they are both about how a channel instance is identified in the context of a session instance.

    I would prefer discussion through email.

    Regards
    Gary
      ----- Original Message ----- 
      From: Nickolas Kavantzas 
      To: Steve Ross-Talbot ; 'WS-Choreography List' 
      Cc: Gary Brown 
      Sent: Tuesday, April 19, 2005 7:13 PM
      Subject: Re: Proposal against issue 1001


      Steve/Gary,


      A) If i remember correctly, we spent ~1h discussing this isssue at the Redwood Shores 
      F2F in Nov 2004 and at that time the proposals you guys made were all
      about *session identity*:

      1)  Correlation Issue: Pre-Proposal (Thursday, 11 November)
       http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0052.html

      2)  Correlation proposal (Thursday, 18 November)
      http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0070.html

      3)  Updated correlation proposal (Friday, 19 November)
      http://lists.w3.org/Archives/Public/public-ws-chor/2004Nov/0074.html


      B) Then we spent ~1h in the Boston F2F discussing this new
      proposal, which is not about session identity. 

      But, there were many questions/concerns raised by me, Martin, Charlton, 
      Abbie (the minutes should have this recording) regarding this approach.


      I would like to understand why there is such a difference between the two proposals you guys made?
      We can have a bried discussion about this in today's call, or we can do it through email.


      Thanks,

      --
      Nick

      ----- Original Message ----- 
      From: "Steve Ross-Talbot" <steve@pi4tech.com>
      To: "'WS-Choreography List'" <public-ws-chor@w3.org>; "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
      Cc: "Gary Brown" <gary@pi4tech.com>
      Sent: Tuesday, April 19, 2005 9:18 AM
      Subject: Re: Proposal against issue 1001


      Hi Nick,

      Thanks (as ever) for you prompt response. I think that we have some mix 
      up along the line and I think this has caused a degree of confusion or 
      uncertainty around issue 1001. To be clear from our side the issue that 
      was raised was related to correlating multiple channel instances within 
      a choreography session - it was not about providing session identity. 
      This may be an issue in and of itself but is not central to issue 1001. 
      Issues relating to session identity we see as separate and if you wish 
      to raise them yourself then that is fine too.

      The proposal addresses the issue that was raised (correlating multiple 
      channel instances), and is important in achieving endpoint monitoring 
      and end point generation. This is why we raised the issue in the first 
      place.

      While we understand your points about sessions they are not required to 
      resolve issue 1001. Rather than mix these issues up let us concentrate 
      on issue 1001 and the proposal to resolve issue 1001. What we need from 
      you in particular and the group are comment raised against this 
      proposal, to enable us to either defend the proposal, or identify gaps 
      that need to be addressed as they relate to issue 1001.

      Cheers

      Steve T
      >
      >>
      >> PROPOSAL:
      >> http://lists.w3.org/Archives/Public/public-ws-chor/2005Feb/0032.html
      >>
      >> We would ask the WG members to raise issues against this proposal by
      >> email rather than using a conf call.
      >>
      >> Best
      >>
      >> Steve T
      >>
      >>
      >>
      >>
      >
      >
      >

Received on Wednesday, 20 April 2005 08:09:07 UTC