Re: Proposal against issue 1001

Hi Nick,

The problem is that I don't understand the need to distinguish the identity 
type - what benefit does this provide to the CDL designer?

Will it change the way endpoints are generated/monitored?

Can you elaborate on what you think this distinction adds, or if it is not 
added, what we would not be able to do?

Thanks
Gary

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


> Hi Gary,
>
> I think that what you've described below as a 'logical session' fits the 
> CDL
> choreography session type,
> whereas in the case of a CDL conversation session one groups only message
> exchanges and not actions:
>
> a) In the WS-CDL spec, Section 2.4.7 Choreography Life-line, we have
> specified how a choreo session
> is initiated by using an ixn-initiator. A Choreo includes all types of
> actions, including ixns.
>
> b) In the WS-CDL spec, Section 2.3.4 Channel Types, we have defined that 
> the
> conversation session is
> identified using the identity element of a channel.
>
>
> As I said below, it is great that your proposal can be used for both types
> of sessions. So, i propose to make
> the following change by including a new attribute that indicates what the
> identity element is used for:
>    a) identifying a choreography instance
>            or/and
>    b) identifying a conversation instance
>
>
>
> <channelType ...>
>    <identity sessionType="choreography"|"conversation" >
>
>    </identity>
>    ...
> </channelType>
>
>
> Thanks,
>
> --
> Nick
>
> ----- Original Message ----- 
> From: Gary Brown
> To: Nickolas Kavantzas ; Steve Ross-Talbot
> Cc: 'WS-Choreography List'
> Sent: Wednesday, April 20, 2005 1:08 AM
> Subject: 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 
> di
> scussion, 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 17:38:35 UTC