- From: Ricky Ho <riho@cisco.com>
- Date: Mon, 28 Apr 2003 08:14:35 -0700
- 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
>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 Monday, 28 April 2003 16:59:29 UTC