a clarification on channel usage.

In view of the discussion at F2F London, I send below
a text which makes explicit the interference between
distinct runs of a choreography descriptions. After
my presentation at F2F London, this point was raised
and was clarified by other WG members. It was agreed
that this point may better be made explicit (I stress
that the text as I wrote is intended to make explicit
what has been understood by editors and some of the
WG members, and nothing else).

By this and by the use of nested choreographies, the
"encoding" of session as I noted in my presentation
at F2F (page 65/66) has turned out to be unnecessary.
I thank participants at F2F for clarification of this
point, and correct that part in my presentation.

The attached text has three sections. In (1), two
versions of the text I propose for the inclusion in
the spec are listed, one using "must" and another without.
This is because I am not sure whether the use of "must"
is appropriate or not. I then give some comments to the
text, to be sure that the idea is clearly communicated.
I am happy to receive further clarification/corrections.
In Part (3), I list those parts which may be fit to
have the clarification inserted.

My apologies this got late.

Best wishes,

kohei

(1) Two versions of the text.

(1-1) version 1 (without must).

Distinct instances of a (top-level or enclosed) choreography, if
they ever run in a temporarily overlapped fashion, are not assumed
to interfere with each other in their involved communication
actions.  In other words, given a choreography description,
interactions belonging to one of its instances are assumed to be
logically, hence executionally, distinguishable from those in
another.

(1-2) version 2 (with must).

Distinct instances of a (top-level or enclosed) choreography, if
they ever run in a temporarily overlapped fashion, must not
interfere with each other in their involved communication actions.
In other words, given a choreography description, interactions
belonging to one of its instances must be logically, hence
executionally, distinguishable from those in another.

(2) Comments.

Terminology: I used the term "instance". I am not sure this term
can be used for denoting a run of a top-level choreography (the
attribute name "choreographyInstanceId" seems to be used only for
enclosed choreographies). We can use the term "runs" instead of
"instances". I also used "temporarily ovelapped" instead of "in
parallel" or in "concurrent" to be concrete about what is meant.

Another comment: The current versions do not mention a concrete
way to realise the requirement. We can say something like: "this
may be realised by the usage of distinct channel instances". If a
shared URL is used, this means some co-relation information is
used for realising this idea.

A further comment: As I noted in my talk, one of the typical
instances where such "sessions" become important, is when we reuse
the same choreography for indefinite number of clients. For
example, if we have a Seller/Buyer protocol, it is natural to
consider a single seller would have many buyers and vice versa, so
that it is natural (and economical) to consider this one protocol
may be instantiated into multiple instances. This follows the
spirit of choreographies, as the current CDL doc says:

   A Choreography defines re-usable common rules, that govern the
   ordering of exchanged messages and the provisioning patterns of
   collaborative behavior, agreed between two or more interacting
   parties.

If we however allow, for example, "indefinite number of buyers"
etc. in one choreography, this issue may be partly solved. 
However in this case too we need distinguishability of interactions
between distinct "runs". I hope candidate clarifications below

(3) Possible sections to be inserted.

The above text or its revised version can be in any appropriate
section. As candidates,

(3-1) 2.4.5, choreography section, as the new fifth paragraph (after
the single-sentence paragraph, "A non-root choreography is enabled
when performed").

(3-2) 2.4.7, life-line section, as the new second paragraph.

(3-3) 2.3.4. channel type section, as the new second paragraph, if
channel instances are mentioned.

[end]

Received on Saturday, 25 June 2005 22:43:19 UTC