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

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

From: Ricky Ho <riho@cisco.com>
Date: Mon, 28 Apr 2003 08:14:35 -0700
Message-Id: <>
To: "Fletcher, Tony" <Tony.Fletcher@choreology.com>, <public-ws-chor@w3.org>

Embedded ...

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

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 
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 

>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,
Received on Monday, 28 April 2003 16:59:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:01 UTC