W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: [Reqs] Some proposed requirements based on RE: Change of participants

From: Tony Fletcher <tony_fletcher@btopenworld.com>
Date: Thu, 1 May 2003 19:49:45 +0100
To: "'Ricky Ho'" <riho@cisco.com>, <public-ws-chor@w3.org>
Message-ID: <1057787677.IAA22192@phantom.w3.org>

Dear Ricky,

Sorry to be a little slow getting around to replying to this one in my mail
stack.

Yes, I agree with you that this more of a 'fact of life' than a true
requirement on the language.  We might have it as a 'best practice' to have
a limited, achievable goal for each Choreography instance, but I guess we
would not want to prevent, via the nature of the language, someone designing
an Choreography that was actually an 'infinite loop' - once started it
would, in principle at least' run for ever.  I was trying to pick up on the
idea that you and Assaf seemed to be agreeing on that, in the main,
choreographies should have a well defined purpose and not run for ever.

I think will be true that each 'global model' will (certainly should) have a
well defined purpose.  Within that there will be a purpose in including each
role that is included.  Each entity (or participant - whatever the agreed
term is) that plays a particular role will have there on purpose in agreeing
to play that role.

I think I agree with your other comments as well.  I was trying to make a
positive proposal for requirements from what you and others had been saying,
and I am quite happy to see which ones stand and which ones fall, or get
modified.

Best Regards     Tony
A M Fletcher
 
Cohesions 1.0 (TM)
 
Business transaction management software for application coordination
 
Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0) 7801
948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)


-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com] 
Sent: 28 April 2003 16:15
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: Re: [Reqs] Some proposed requirements based on RE: Change of
participants


Embedded ...

>1)  Each choreography instance should have a specific goal and should 
>end when that goal is achieved (or a fatal error condition is 
>encountered.

This is a good guideline for people who design the choreography flow.  But 
I'm not sure this is relevant to us (who define the choreography model 
itself).
In a multi-party choreography, each party has his own goal.  Are we talking 
about ALL parties fulfill (or give up) their goal before the choreography 
instance end ?


>2)  A Choreography starts with a minimum of two entities bound to 
>specific roles.

I think the same way before.  But I think this is less clear after seeing 
Assaf's comment.
For example, if I'm a seller who want to start a choreography instance to 
conduct an Auction.  Lets say this auction is open to public and the seller 
no idea about who will buy.  Does it mean that the choreography cannot be 
started until the seller receive the first proposal ?
I think the minimum requirement is at least one role being binded, not sure 
about two role.


>3)  Entities may be brought into the choreography (and bound to a 
>specified role) at any point in the choreography as demanded or 
>permitted by the choreography definition.

One entity can also bind to more than one roles of the same choreography 
instance.


>4) Subject to at least 2 roles with entities bound to them remaining, 
>entities may leave the choreography (and thus be unbound from a 
>specified role) at any point in the choreography as demanded or 
>permitted by the choreography definition.

Not sure about the first statement ("subject to at least 2 bound roles 
remaining ...")
I think any roles can leave or join at any time as long as the choreography 
flow definition demand or permit.


>5)  "Inactive" is different from "leaving" (or "unbound").  "Inactive" 
>is to describe the "role" while "leaving" is to describe an entity 
>(/participant).  For example, once an order is placed and shipment 
>arrange, all the interactions are between the role "buyer" and role 
>"shipper".  The role "seller" is "inactive" but not "unbound".  On the 
>other hand, the role "shipper" is very "active" even though the 
>participant "Fedex" has already left that role (and been replaced by 
>participant "UPS").
>
>{Triggered by subsequent emails}
>
>6)  A Choreography instance specifies a finite and specified number of 
>roles.  (It does not permit new roles to be defined at runtime.)

+1.  But the number of entities that can be bound SIMULTANEOUSLY to one
role doesn't have to be finite.


>7)  A Choreography instance specifies whether just a single entity may
>be bound to a particular specified role, or a specified number
>sequentially, or an arbitrary number sequentially.
>It is for further study as to whether more than one entity can be bound
>to a specified role concurrently.


Best regards,
Ricky
Received on Thursday, 1 May 2003 14:48:45 GMT

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