- From: Gary Brown <gary@pi4tech.com>
- Date: Mon, 25 Apr 2005 21:35:10 +0100
- To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>, "Steve Ross-Talbot" <steve@pi4tech.com>
- Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
Hi Nick, >From the example you have given, it appears to be a similar approach, except that our proposal does not need to distinguish between identity types, but instead relates them across channelTypes using the terms "derived", "association" and allows "primary" and "alternate" on the same channelType. Therefore our proposal meets the requirements you are outlining in your example. Regards 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: Monday, April 25, 2005 6:23 PM Subject: Re: Proposal against issue 1001 > Hi, > > As shown in my example below, you can have many conversation instances > (convId=1, 2, ...) > per choreography instance (chorId=12345). > > The different conversation instances (convId=1, 2, ...), allow message > routing to the appropriate > receive (projected at the receiving endpoint), even though they are all > part > of the same choreography > instance (chorId=12345). > > Also, note that the choreography instance spans many participants, as it > provides the business > transaction context that encapsulates all these distributed entities. > > > -- > Nick > > ----- 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: Sunday, April 24, 2005 12:57 PM > Subject: 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 Monday, 25 April 2005 20:35:30 UTC