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 17:25:20 UTC