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 Thursday, 5 May 2005 20:09:46 UTC