Re: Co-relation on channels.

Hi Gary,

Thank you for your clarifications. Nobuko and I now see the need of  (a) tokens and  (b) alternate,
and will be looking forward to examples for (d). For (e), if such a feature is not needed in standard 
business protocols, we believe it can be ignored at this point (but we can take a note for future).

For (c), we agree it does not hamper our initial efforts to use this and other features for verification. 
As you noted, some further bits of inspection of this point can also be beneficial. This tactics will go 
well since the current form is easier to analyse than a more dynamic form (we surely have several 
methods to do this, but the main point would be which is easier and more natural to write while 
conforming to what is available in execution *and* is relatively easily analysable).

kohei
----- Original Message ----- 
From: "Gary Brown" <gary@pi4tech.com>
To: "'WS-Choreography List'" <public-ws-chor@w3.org>
Sent: Thursday, May 05, 2005 9:09 PM
Subject: Re: Co-relation on channels.


> 
> Just to provide a response to each of the concrete points that Kohei has 
> made:
> 
> > (a) We cannot see why identification of a session needs to incorporate
> > the ordering of tokens (the last line of the first para of "Possible
> > Solution"). Unless necessary it may be better not to use ordering info.
> >
> 
> GB: The ordering of tokens is only referred to in the case where a set of 
> tokens are used as a "composite" identity key - for example, we may have an 
> identity that is made up of the "OrderId" and the "SupplierId". The reason 
> that ordering is important, is that the same 'identity type' (i.e. OrderId + 
> SupplierId) may then be used in other Channel Types, to represent the same 
> identity value, and therefore ordering is important to ensure that the 
> identity types across these channel types are the same.
> 
> 
> > (b) We cannot see the need of "alternate". This may complicate static
> > checking unless very clearly declared that it is an alias of a primary
> > ID (aliases are in general troublesome). If not necessary, we hope
> > this can be taken off.
> >
> 
> GB: Without the ability to define 'alternate' identities for a channel 
> instance, it would force a choreography designer to ensure that all messages 
> exchanged on the channel instance had the same identity field(s). From a 
> business acceptance/adoption perspective, this is considered too 
> restrictive.
> 
> 
> > (c) We believe when a channel is passed, its associated usage value
> > should also be passed. Channel instances are real interaction points
> > (say URIs), while identity tokens offer corelations. As in type
> > passing in lambda/pi-calculi, it is consistent to send this info
> > together with a channel.  So this may be made mandatory.
> >
> 
> GB: Unfortunately, the technology on which a choreography may be executed 
> will not always permit the passed channel to carry all the required 
> information - for example, currently web services can only pass the URL to 
> the service endpoint, but this is not enough information to identify the 
> specify endpoint session (or channel instance within that session). 
> Therefore from an execution perspective we may need to have additional 
> verification to ensure that the receiving participant has the necessary 
> identity information to continue to use the passed channel instance 
> correctly. This area does require further work, but should not interfere 
> with initial model checking work.
> 
> 
> > (d) We could not check in detail the differences between Gary's
> > original proposal and Nick's one. This seems design issues rather
> > than logical issues, so it would be good to decide if we need
> > this functionality first. Then we can examine, through many
> > examples, the best way to write them down.
> >
> 
> GB: I plan to produce some examples for the primer, to explain the different 
> types of identity and their purpose.
> 
> > (e) In pi, we have new name generation to generate a session. Since
> > the same binding mechanism does not exist in CDL, some counterpart
> > (a notation for random ID generation as well as a way to read it
> > from a role instance's state) may be incorporated.
> >
> 
> GB: Not sure about this, but from my perspective we could view performing a 
> sub-choreography as creating new names and therefore session. My assumption 
> is based on the fact that when a channel variable is declared at the 
> beginning of the sub-choreo, it will effectively be created when the 
> sub-choreo is performed and will exist for the life of that sub-choreo.
> 
> 
> 
>

Received on Saturday, 7 May 2005 13:51:27 UTC