- From: Steve Ross-Talbot <steve@pi4tech.com>
- Date: Thu, 26 May 2005 09:16:40 +0100
- To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
- Cc: "Gary Brown" <gary@pi4tech.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>, "Martin Chapman" <martin.chapman@oracle.com>
Dear Nick, Not sure I follow you questions. If they are still bound in the wider issues you raised concerning things over and above the issue at hand then they are irrelevant as agreed in the last conf call we had on this topic. It was agreed to proceed with the proposal against the issue at hand and the wider issue, if you wish, could be raised as a separate issue. To date the wider issue has not been raised by anyone and so the issue at hand is all that matters. If the proposal provides a solution to the issue at hand (1001) then we should examine it against that issue alone. Best Steve T On 26 May 2005, at 03:36, Nickolas Kavantzas wrote: > 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 08:16:55 UTC