- From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
- Date: Wed, 25 May 2005 19:36:50 -0700
- To: "Gary Brown" <gary@pi4tech.com>, "Martin Chapman" <martin.chapman@oracle.com>, <steve@pi4tech.com>
- Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
- Message-ID: <012d01c5619b$c57c73e0$538e1990@us.oracle.com>
Hi all,
I am still confused with the 'choreography session' text in your proposal.
Below I have included the thread that occured between me and Gary few weeks back and has
the example that I wrote to demonstrate the difference between the
two types of sessions.
Can you please clarify based on my example below?
Thanks,
Nick
----- 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 10:23 AM
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
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
----- Original Message -----
From: Gary Brown
To: Nickolas Kavantzas ; Martin Chapman ; steve@pi4tech.com
Cc: 'WS-Choreography List'
Sent: Wednesday, May 25, 2005 4:22 AM
Subject: Re: Editorial changes for issue 1001
Hi,
I have not seen any comments back regarding the editorial changes for the proposal related to issue 1001.
As this issue has failed to get discussion time on the conference calls, and time is short before the next f2f, can I have feedback via email?
I would prefer not to get into the same situation as with the fault handling issue, i.e. that it primarily gets discussed on the calls, as this has proven time consuming. I would like to get the objections raised and discussed via email.
Regards
Gary
----- Original Message -----
From: Gary Brown
To: 'WS-Choreography List'
Sent: Friday, May 06, 2005 11:47 AM
Subject: Editorial changes for issue 1001
SECTION 2.3.4 ChannelTypes
======================
1) Remove:
A ChannelType MAY describe the type of the instance identity of an entity implementing the behavior(s) of a party being the target of an information exchange.
2) Amend:
A ChannelType MAY describe the type of the instance identity of one or more logical conversations between parties, where each conversation groups a set of related information exchanges.
to:
A ChannelType MAY describe the type of the instance identity of one or more logical conversations between parties, where each conversation groups a set of related information exchanges. The ChannelType instance identity can be used to correlate multiple conversations (channel instances) within the same choreography session.
3) Syntax change from:
<identity>
<token name="qname"/>+
</identity>?
</channelType>
to:
<identity usage="primary"|"alternate"|"derived"|"association" >
<token name="qname"/>+
</identity>*
</channelType>
4) Replace the text from "The OPTIONAL element identity MAY ....." up until the end of the section 2.3.4:
Replace:
The OPTIONAL element identity MAY be used for describing the type of the instance identity of an entity implementing the behavior of a party and of a logical conversation between parties. The type of the instance identity and the different conversations are distinguished by a set of Tokens as specified by the name attribute of the token element within the identity element.
The following rule applies for ChannelType:
* If two or more ChannelTypes SHOULD point to roleTypes that MUST be implemented by the same logical entity or organization, then the specified roleTypes MUST belong to the same ParticipantType. In addition, the identity elements within the Channel Types MUST have the same number of Tokens with the same informationTypes specified in the same order
The example below shows the definition of the ChannelType "RetailerChannel" that realizes a point of collaboration with a Retailer. The ChannelType identifies the roleType of the Retailer as the "Retailer". The information for locating the Retailer is specified in the reference element, whereas the instance of a process implementing the Retailer is identified for correlation purposes using the identity element. The element passing allows only a Channel of "ConsumerChannel" Type to be passed in a request information exchange through a Channel of "RetailerChannel" Type.
<channelType name="RetailerChannelType">
<passing channel="ConsumerChannelTYpe" action="request" />
<roleType typeRef="tns:RetailerType" behavior="retailerForConsumer"/>
<reference>
<token name="tns:retailerRef"/>
</reference>
<identity>
<token name="tns:purchaseOrderID"/>
</identity>
</channelType>
with:
The OPTIONAL list of identity elements MAY be used to associate a unique identity for each instance of the ChannelType. The identity is defined by a set of Tokens specified by the name attribute of the token element within the identity element. If two identity elements are specified within the same or different ChannelType elements, that have the same set of named tokens in the same order, then they are considered to represent the same identity type.
The identity element has a mandatory usage attribute which defines the purpose of the identity in the context of the ChannelType. The values for this attribute are:
(i) primary
This means that the identity is created by the initial message on an instance of this ChannelType. A channel type must have only one 'primary' identity field. For example,
<channelType name="OrderChannel" >
<identity usage="primary" >
<token name="OrderId" />
</identity>
</channelType>
This means that all messages (requests and responses) exchanged on this 'OrderChannel' must contain the 'OrderId' field.
(ii) alternate
This classification is used to establish an alternative identity for a ChannelType instance. The alternate identity can be initialized based on any message within the channel instance's conversation (i.e. it does not have to be the first). If it is not the first message, then the message must also contain either the channel instance's primary key, or another previously initialized alternate identity, to bind the identity to the channel instance. Once the alternate identity has been bound to the channel instance, subsequent messages that only contain that alternate identity will be correlated to the channel instance.
For example,
<channelType name="OrderChannel" >
<identity usage="primary" >
<token name="OrderId" />
</identity>
<identity usage="alternate" >
<token name="TxnId" />
</identity>
</channelType>
In this example, an 'OrderChannel' channel instance will be identified initially by the value of the 'OrderId' field. However, at some point in the conversation, a message will be exchanged containing the 'TxnId' field. Once this message has occurred, subsequent messages on this channel instance can be correlated based on either the primary 'OrderId' field, or the alternate 'TxnId' field.
(iii) derived
This means that the identity will be derived from a message sent on the current channel instance (conversation), but it does not directly determine the identity of that current channel instance. Subsequently another channel instance (of the same or different Channel Type) will reference this identity value in its 'primary' identity field, and that will cause the referencing channel instance to become correlated with the current channel instance in the same choreography session.
An example of the 'derived' identity would be:
<channelType name="OrderChannel" >
<identity usage="primary" >
<token name="OrderId" />
</identity>
<identity usage="derived" >
<token name="DeliveryId" />
</identity>
</channelType>
<channelType name="DeliveryChannel" >
<identity usage="primary" >
<token name="DeliveryId" />
</identity>
</channelType>
In this example, the 'OrderChannel' channel instance is identified by the 'OrderId', and at some point during its conversation, it will exchange a message that contains the 'DeliveryId' information. Although this identity is not relevant from the perspective of the 'OrderChannel', it can subsequently be used to determine the identity of the 'DeliveryChannel' channel instance, and consequently bind the 'DeliveryChannel' instance to the same choreography session as the original 'OrderChannel' channel instance.
(iv) association
This classification is used to indicate that this channel instance is correlated to a previous channel instance identity, and therefore the same choreography session. The identity with this classification is not used to determine the identity of the current channel instance, only to establish the association with a previous channel instance within the same choreography session. The identity can either relate to another identity definition (in another Channel Type) that has a classification of 'primary'/'alternate', or that was derived (i.e. has the 'derived' classification). The initial message in the channel instance MUST contain the information to resolve this identity field.
An example of the 'association' identity type would be:
<channelType name="OrderChannel" >
<identity usage="primary" >
<token name="OrderId" />
</identity>
</channelType>
<channelType name="SupplierChannel" >
<identity usage="association" >
<token name="OrderId" />
</identity>
<identity usage="primary" >
<token name="SupplierName" />
<token name="OrderId" />
</identity>
</channelType>
This example shows how a choreography can contain a single 'OrderChannel' channel instance, and zero or more 'SupplierChannel' channel instances correlated with it based on an 'association' to the identity established for the 'OrderChannel' channel instance.
Received on Thursday, 26 May 2005 02:37:07 UTC