Re: Proposal against issue 1001

Hi all,


I presume "conversion" is really "conversation".

Cheers

Steve T

On 20 Apr 2005, at 09:08, Gary Brown wrote:

> 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 13:39:45 UTC