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

RE: Issue 998 - State that sequential lexically ordering is the default for interpretation of CDL

From: Tony Fletcher <tony_fletcher@btopenworld.com>
Date: Fri, 18 Mar 2005 20:07:24 -0000
To: "'Gary Brown'" <gary@enigmatec.net>, <public-ws-chor@w3.org>
Message-ID: <000b01c52bf6$1b297c60$6501a8c0@corp.choreology.com>
Dear Gary and others,
 
Having had a careful look at the specification including the schema I now
see that you are quite correct - I wish someone had pointed that out on the
call!!
 
More than that the schema is carefully crafted such that you can only ever
have one activity in series except within an explicit SEQUENCE, PARALLEL or
CHOICE construct.  So my second solution has already been adopted!  So we
could leave as is, which I suspect is what folk will be inclined to to do,
or we could do what I was originally suggesting, which would be to relax
this rule, allow a series of activities to legally occur and make the
semantics implicitly 'sequence' by adding the default rule.
 
I have to say that this was not immediately obvious.  It is from the schema,
and can be inferred from the informal schema fragments found in the body of
the specification.  
 
Suggested changes to clarify the situation for others:
In Section 2.4.5 Choreographies 8th paragraph change from: A Choreography
MUST contain an <emph>Activity-Notation</emph>. The Activity-Notation
specifies the actions of the Choreography that perform the actual work.  
 
to: A Choreography MUST contain a single <emph>Activity-Notation</emph>. The
Activity-Notation MAY contain within it other Activity-Notations and it
specifies the actions of the Choreography that perform the actual work. 
 
So that has dealt with activities, and I think the situation with the
elements "below" activities is clear so that brings us back to
choreographies which is the subject of your other email on relationships
which I have attached to this mail as I am going to reply to that one as
well.
 
Here I am going to change my position because I think choreographies are
different.  Normally (possibly though what is normal may vary and be subject
to debate!!) one might expect a root choreography to drive the complete
choreography description and for the complete evolution to be shown in a
connected manner.  I think this is what you are wanting to restrict CDL to.
I agree it is perhaps the usual case as I have just said, but I do not think
it has to be the only one.  If you add a third choreography as in the
attached XML doc and there is no default lexical ordering rule (my original
point) then we can say that the rules of CDL mean that choreography 1 will
happen first as that is marked as the root, but we can not tell the order of
choreographies 2 and 3.  They may happen on either order, or overlapped /
concurrently.
 
One has to remember that at one level a choreography description is just
marks on paper or bits in a computer.  It is a description of something, not
the thing itself.  So if someone has chosen to put three actually
independent choreographies in a description (perhaps so that one or other
can be cut and pasted / XIncluded into another description I think that is
just fine.  We already have the problem of what makes a particular endpoint
start up a choreography and which choreography description (out of many
potential ones) is it obeying.  This situation adds the different but
similar type of problem of what makes the 2nd and 3rd choreographies start
up and what determines there ordering (concurrency).  In an actual instance
of execution of a choreography description they may be some link that is
hidden i.e. not described in the choreography description, or it may be that
this choreography description is not intended to ever be executed, it is
just a repository of useful choreographies for use elsewhere.
 
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: Gary Brown [mailto:gary@enigmatec.net] 
Sent: 16 March 2005 17:05
To: Tony Fletcher; public-ws-chor@w3.org
Subject: Re: Issue 998 - State that sequential lexically ordering is the
default for interpretation of CDL


Hi Tony
 
I believe a workunit can only have one immediate child activity, so if you
wanted more than one activity, you would need to place them inside a
sequence, parallel or choice anyway.
 
Regards
Gary

----- Original Message ----- 
From: Tony Fletcher <mailto:tony_fletcher@btopenworld.com>  
To: public-ws-chor@w3.org 
Sent: Wednesday, March 16, 2005 2:32 PM
Subject: Issue 998 - State that sequential lexically ordering is the default
for interpretation of CDL

Dear Colleagues,
 
I was hoping to illustrate the point of this issue by taking some of the
examples from the the specification directly, but unfortunately they are all
a bit too simple in that they only have one activity in a series.  The point
I am addressing comes into play when there is more than one activity in
series in the choreography description not wrapped in an explicit SEQUENCE,
PARALLEL or CHOICE construct, which is currently permitted.  So I have just
taken a couple of partially filled out examples to illustrate the point.
 
Are:


<workunit  name="StockCheck" 

           guard="cdl:getVariable('StockQuantity','','"/Product/Qty"', 

                                  '"tns:Retailer") > 10')"            

           block="false" >

   ... <!--some activity -->

   ... <!--some other activity -->

</workunit>

 
and 


<workunit  name="StockCheck" 

           guard="cdl:getVariable('StockQuantity','','"/Product/Qty"', 

                                  '"tns:Retailer") > 10')"            

           block="false" >

   ... <!--some other activity -->

   ... <!--some activity -->

</workunit>




the same?  (Where typically 'some activity' would be an interaction and
'some other activity' would be a different interaction.)

Another pseudo example:



<workunit  name="StockCheck">

   ... <interaction name="1" ...>

   ... <interaction name="2" ...>

</workunit>

workunit  name="StockReplenish">

   ... <interaction name="3" ...>

</workunit>

and



workunit  name="StockReplenish">

   ... <interaction name="3" ...>

</workunit>

<workunit  name="StockCheck">

   ... <interaction name="2" ...>

   ... <interaction name="1" ...>

</workunit>

 

I hope this makes the point clear  One solution is to include a default
ordering statement in the specification as the issue suggests.  Another
solution is to declare all of the above examples illegal CDL and state that
when more than one activity is placed lexically next to another (and they do
not have to be of the same type) then they MUST be wrapped with and explicit
SEQUENCE, PARALLEL or CHOICE activity.

 

 Best Regards,

Tony                           


 <http://www.choreology.com/> 

Tony Fletcher

Technical Advisor 
Choreology Ltd.
68, Lombard Street, London EC3V 9L J   UK


Phone:  

+44 (0) 1473 729537


Mobile: 

+44 (0) 7801 948219


Fax:    

+44 (0) 870 7390077


Web:

 <http://www.choreology.com/> www.choreology.com


CohesionsT


Business transaction management software for application coordination



Work: tony.fletcher@choreology.com 


Home: amfletcher@iee.org


 




attached mail follows:


Regarding the example, it appears what you have done is promote the inner
choreography to the top level, as removed another inner choreo and placed
its interaction in the main choreo. Looks fine to me.
 
The problem we face is how relevant is the global model? In my example I
represented a sequence, but if there is no connection between the two sub
choreographies, what is to stop them being performed the other way around,
or concurrently, and therefore not conforming to the global model.
 
On the other hand, it is possible that the 'participants', although not
connected within the CDL model, so actually have some hidden connection that
always enforces the sequence, but it is not observable.
 
Which is the correct view?
 
Regards
Gary

----- Original Message ----- 
From: Tony Fletcher <mailto:tony_fletcher@btopenworld.com>  
To: 'Gary Brown' <mailto:gary@enigmatec.net>  ; public-ws-chor@w3.org 
Sent: Thursday, March 17, 2005 7:40 PM
Subject: RE: Relationship issue example

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


Hi
 
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).
 
Regards
Gary
 
 
 
 
<?xml version="1.0" encoding="UTF-8"?>
<package name="relationship" author="GB" version="1.0"
targetNamespace="mynamespace" xmlns="
<http://www.w3.org/2004/12/ws-chor/cdl>
http://www.w3.org/2004/12/ws-chor/cdl"><description
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="roletype3"/><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
type="roletype2"/><reference><token
name="string"/></reference></channelType><channelType
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"
action="request"><send/><receive/></exchange></interaction></choreography><c
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"
action="request"><send/><receive/></exchange></interaction></choreography><s
equence><perform choreographyName="subchoreo1"><description
type="description">Perform subchoreo1</description></perform><perform
choreographyName="subchoreo2"><description type="description">Perform
subchoreo2</description></perform></sequence></choreography></package>





image002.gif
(image/gif attachment: image002.gif)

Received on Friday, 18 March 2005 21:32:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:28 GMT