Re: Proposal against issue 1001

Hi,

I don't see the need for a distinction between a choreography and 
conversation instance, because the choreography instance (as you have 
described it) is just the 'endpoint projection' of the conversation 
instance.

Your statement "whereas in the case of a CDL conversation session one groups 
only message exchanges and not actions" - the actions that occur between 
conversation elements (and their identities) are implicitly associated with 
the same identity as an effect of the communications that have occurred. For 
example, if we have the following endpoint projection:

<receive op="foo" >
    <identity name="id" />
</receive>

<assign fromVariable="var1" toVariable="var2" />

<send op="bar" >
    <identity name="id" />
</receive>

then when this endpoint receives a message, which causes it to be associated 
with a session that has the appropriate 'id' value extracted from the 
message, then the assignment will automatically follow within that same 
session instance, which will then result in the send for that session 
instance (which has the same 'id' value) being performed. Therefore the 
"conversational" identity (as you refer to it) would be associated with the 
identity of the 'id' value, and the assignment (i.e. the choreography 
session instance) would also be associated with the same identity based on 
the 'id' value.

Hope this clarifies the approach.

Regards
Gary


----- Original Message ----- 
From: "Gary Brown" <gary@pi4tech.com>
To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>; "Steve 
Ross-Talbot" <steve@pi4tech.com>
Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
Sent: Wednesday, April 20, 2005 6:38 PM
Subject: 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 Sunday, 24 April 2005 19:57:21 UTC