RE: A view on Participants and Roles

Dear Matthew (and others),
 
Although it can get rather messy after several iterations. I have decided to
embed my comments this time around, so please see below.
 
Best Regards     Tony
A M Fletcher
  Tel:+44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 tony_fletcher@btopenworld.com         (also amfletcher@iee.org)
 
-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Matthew Rawlings
Sent: 03 August 2006 21:33
To: public-ws-chor@w3.org
Subject: RE: A view on Participants and Roles



Tony -

 

I prefer your definition of the association between participant, role, and
message types to the specification's definition. The main difference in your
definition from the CDL specification is the association from Participant to
Role becomes aggregation rather than composition. This would all be much
clearer to picture with a metamodel for CDL. 

 

<Tony>I do not claim any credit or originality!  It is all 'received
wisdom'! </Tony>

 

Can I deduce from your statement "a participant without a role. .has no way
of participating in the choreography beings described." that you mean that a
Participant type has no identity other than as the aggregate of its Role
types? In other words, the Roles types are the sole definition and identity
of the Participant. This implies combinations of Roles types must be unique
if this is the identity of Participants. This also implies if I change the
Role types realized by the Participant type then this creates a new
Participant type. This statement I do not prefer. 

 

 <Tony>Well of course in XML you can always put something that is only
partly defined - an idea for the future - in as a comment.  I was referring
to a participant as a 'proper' part of the choreography when I said that if
it does not have at least one role then it has no way to send or receive a
message so it therefore can not participate in the choreography.  Now a
Participant Type, and therefore participants derived from it may have other
definitions apart from roles, such as variables.  Also although it may seem
rather odd, I do not see any reason why one should be barred from defining
two different participant types (distinguished by their name, at least.
There may be good reasons for doing that in a particular situation, though I
can not think of any for the moment.  Thus I would suggest that participant
types (and indeed participants) are distinguished by their names and not by
the combinations of role (types) they include.  However, with regard to your
last sentence above if you change the role (types) in a participant (type),
then de facto you have changed the definition and in that sense do have
something new and different.</Tony>

 

If we extrapolated from your argument for why Participant types must have at
least one Role type ".thus has no way of participating." does this also
require every Role type be associated with at least one Participant type?
<Tony>Yes, otherwise that role type can be omitted from the choreography
(the CDL XML document) without changing the actual choreography (the allowed
sequences of messages).</Tony> Would this also extend to every Channel type
being used at least once, and every Information type, and so on for all the
base types? Your definition of the cardinality of the associations would be
much clearer with a metamodel for CDL.

<Tony>Essentially Yes, for the same reason.  If they are not used then the
can be omitted without changing the actual choreography.  If pushed I would
have to admit that while one must define everything that is used, it can be
considered a matter of taste as to whether you ban the definition of things
that are not used.  I am not sure what happens in Java or C## and other such
programming languages if one defines data types, classes and the like and
then do not use them.  I suspect that is allowed, but a compiler might throw
out a warning message - and it would probably be useful if it did.  You
could say it should be the same in CDL.  The practice of defining types that
are not used should not actually be banned (but model checkers should
flag).</Tony> 

 

For a long running choreography that evolves (such as air traffic control
procedures or interaction on a 25 year swap contract), then it is important
that the difference when between amending a Participant type and creating a
new Participant type is understood by all implementers of the revised
choreography. 

<Tony>I am almost certainly doing the Working Group an injustice, but I am
not sure that this 'requirement' has been given much consideration.  If you
wish to swap out a choreography description that is governing (or being used
to police) an actual executing choreography, then I there is nothing to stop
you - as far as I am aware nothing in CDL would prevent this, but equally
there is nothing to specifically support it either.  It would be up to the
designer to either make changes that did not impact the choreography, i.e.
were essentially cosmetic, or ensure that one or more of the endpoints
participating in the choreography were changed simultaneously.  With care
you could make a sensible and smooth update, but you could also get it
horribly wrong and find that either the choreography description no longer
matched the evolving choreography, or worse, that the endpoints actually
could no longer exchange messages in a useful manner.  I actually do not see
a real distinction between amending a participant type (upping the version
number) and creating a new participant type.  Having criteria for when to
just change the version number and when to give it a completely new name can
be useful indicators of the degree of change, and perhaps the ability to
preserve backwards / forwards compatibility according to some criteria, but
at the end of the day an change is a change and something new has been
created.</Tony> 

 

Presumably this also means I cannot distinguish between Participants that do
not participate and non-Participants that do not participate? For example
how can I identify the presence but non-participation of the deceased at
their own funeral? 

<Tony>Not sure that the analogy of the last sentence holds!  With respect to
the first there are two things you might be referring to.  Firstly there is
the CDL XML document.  This is finite and can be examined for Participant
Types that are not used as the 'basis' of participants, and also for
participants will never  be able to send a message.  There can be
choreographies that include Participant types and participants based on
those types that are only used under certain conditions, that is if the
choreography evolves in a certain way.  It seems to me that that is fine and
certainly should allowed.  For instance, one hopes one will not have to
involve a breakdown service when travelling by car, but if you do breakdown
you certainly will be glad to be able to contact them!</Tony> 

 

<Tony>The above comments are my current thoughts, but I am always open to
(gentle) persuasion and being (re-)educated!</Tony> 

 

Matthew Rawlings

+44 791 539 7824