W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2005

RE: Relationship issue example

From: Tony Fletcher <tony_fletcher@btopenworld.com>
Date: Thu, 17 Mar 2005 19:40:47 -0000
To: "'Gary Brown'" <gary@enigmatec.net>, <public-ws-chor@w3.org>
Message-ID: <000601c52b29$38f019c0$6501a8c0@corp.choreology.com>
Dear Gary,
My current short answer is:  I think we should leave as is, and yes I think
it is fine to have a single choreography description document describe what
are actually two, or more, totally disconnected choreographies - I think we
should allow that design freedom - even if it does seem a bit strange.
The slightly longer answer is:  From the point of view of a single endpoint
there are degrees to which they are involved in what is happening (message
wise) in the choreography from being involved with everything to not being
involved at all in some part.  Consider a choreography with just two
participants each of which have just one role and these two roles 'talk' to
each other.  In this case both roles are involved in each and every
interaction in the choreography.  But if you think about it this is really a
particular case and not the general case.  With three participants and four
roles say A<-->B<-->C then Participant B is involved in all the
interactions, but A has no involvement with the B<-->C interactions and thus
the B<-->C interactions are just the same as D<-->E interactions as far as A
is concerned (it has no involvement and no visibility of either set of
interactions.  In general it is only the choreography designer that can
'see' (or whatever word you would like to use - a bit philosophical this!)
the complete choreography, or a monitor that has access to all the
interactions (/channels).  It seems to me this is as true for the 
 A<-->B<-->C<-->D case as for the  A<-->B  C<-->D case.
Finally a question for you.  I have done a quick hack on the choreography
example that you sent (so I may not have got all the details of the syntax
correct, but hopefully you will understand what I intend).  Is it still
legal CDL?  (If it is I intend to make a further modification and comeback
with another somewhat philosophical question - and if it is not legal I
would appreciate knowing why.
Best Regards     Tony
A M Fletcher
Cohesions  (TM)
Business transaction management software for application coordination
www.choreology.com <http://www.choreology.com/> 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Gary Brown
Sent: 16 March 2005 10:53
To: public-ws-chor@w3.org
Subject: Relationship issue example

This is an example where a choreography has been defined with 4 participant
types. However the choreography consists of two sub-choreographies that have
no connection between them. Therefore, even though the two
sub-choreographies are performed in sequence, there are no common
participants between each of the sub-choreographies, and therefore no
sequential ordering in terms of a global model.
One way to solve this problem would be to suggest/enforce that both of the
sub-choreographies need a common participantType. However, this may require
that the common participant type is the one that 'initiates' the second
sub-choreography, as it would be the only one that knows when the first
sub-choreography has completed.
If there is no linkage between the different sub-choreographies (i.e. common
participants), then we would need to ask whether this is a valid
choreography - as in reality it is describing two completely independent
choreographies within the one CDL document.
Example has been attached and pasted below (although not formatted).
<?xml version="1.0" encoding="UTF-8"?>
<package name="relationship" author="GB" version="1.0"
targetNamespace="mynamespace" xmlns="
type="description">Example to show issue with relationships in different
choreographies</description><informationType name="string"
type="xs:string"/><token name="string" informationType="string"/><roleType
name="roletype1"><behavior name="behavior1"/></roleType><roleType
name="roletype2"><behavior name="behavior2"/></roleType><roleType
name="roletype3"><behavior name="behavior3"/></roleType><roleType
name="roletype4"><behavior name="behavior4"/></roleType><relationshipType
name="rel1"><role type="roletype1"/><role
type="roletype2"/></relationshipType><relationshipType name="rel2"><role
type="roletype4"/></relationshipType><participantType name="part1"><role
type="roletype1"/></participantType><participantType name="part2"><role
type="roletype2"/></participantType><participantType name="part3"><role
type="roletype3"/></participantType><participantType name="part4"><role
type="roletype4"/></participantType><channelType name="channelType1"><role
name="channelType2"><role type="roletype4"/><reference><token
name="string"/></reference></channelType><choreography name="mainchoreo"
root="true"><relationship type="rel1"/><relationship
type="rel2"/><choreography name="subchoreo1"><relationship
type="rel1"/><variableDefinitions><variable name="chan1"
channelType="channelType1"/></variableDefinitions><interaction name="first
interaction" operation="firstOp" channelVariable="chan1"><participate
relationshipType="rel1" fromRole="roletype1" toRole="roletype2"/><exchange
name="first request" informationType="string"
horeography name="subchoreo2"><relationship
type="rel2"/><variableDefinitions><variable name="chan2"
channelType="channelType2"/></variableDefinitions><interaction name="second
interaction" operation="secondOp" channelVariable="chan2"><participate
relationshipType="rel2" fromRole="roletype3" toRole="roletype4"/><exchange
name="first request" informationType="string"
equence><perform choreographyName="subchoreo1"><description
type="description">Perform subchoreo1</description></perform><perform
choreographyName="subchoreo2"><description type="description">Perform

Received on Thursday, 17 March 2005 19:41:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:07 UTC