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

Dear Colleagues,

I would like to propose some requirements coming out of this exchange.

Note: replace the term 'entity' below with whatever term we agree for
the 'thing' that is bound to (or implements a) role in a particular run
of an instance of a choreography (examples role = seller; entity that
provides that role in a particular run of a choreography = Amazon.

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

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

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.

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.

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

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     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: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Ricky Ho
Sent: 18 April 2003 05:34
To: Assaf Arkin
Cc: public-ws-chor@w3.org
Subject: Re: Change of participants



Assaf, thanks for feedback !  My comments embedded.

At 01:40 PM 4/17/2003 -0700, Assaf Arkin wrote:
>First, can we view it in a more generic sense as a conversation where
>participants can join and leave?

We certainly can take this more generic view.  But I try to explore
whether 
certain roles (e.g. initiator) has some distinct behavior, although it
is 
not very clear to me at this moment.


>Second, can we make a distinction between roles and participants. Roles
>are not bound - they should be defined as part of the choreography. A 
>seller is always a seller. Participants are bound and they could 
>change. It could be Amazon today and CDNow tomorrow.

I mean the same thing as you, maybe just the terminology 
difference.  "Role" is like a named variable and "Participant" is like a

value.  Binding is like an assigning a value to a variable.  (e.g.
seller = 
"Amazon")


>For the choreography to be defined there need to be at least two roles
>otherwise no one is communicating. No value for services talking to 
>themselves ;-)

Of course, but I think the question is whether these two roles need to
be 
bound at the creation of the choreography instance, or whether the
second 
role can be bound one day later.  And my vote is the former.


>For the choreography to start you need one participant to be bound to 
>one role, otherwise nothing will happen. Everything else is optional.

This one participant must be the initiator who send the first message.
But 
to whom he sends the message... Isn't the participant who receive the 
message also need to bind to another role  ?  Then there must be at
least 
two roles being bound when the choreography start.


>At some point a participant for some role may have no further 
>contribution to the choreography, but the choreography must progress. 
>At this point do we force the choreography to stop because a 
>participant has no contribution to make? Do we force the participant to

>send "I am alive, I have nothing to say, but I am alive" messages ?

"Inactive" is different from "leaving" (or "unbound").  "Inactive" is to

describe the "role" while "leaving" is to describe a participant.  For 
example, once the order is place 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 replaced by participant "UPS").


>Can you explain the value that these restrictions bring to the 
>definition of the choreography?

Back to the Amazon selling use case, should Amazon define each online 
transaction as one choreography instance ? or should Amazon define a 
"RunTheBusiness" choreography which has only one instance running for
many 
many years ?

I think this restriction may help to limit the life span of a 
choreography.  And this reflects most real life scenarios.  When a buyer

switch to a different seller, he is starting a new conversation rather
than 
using the existing conversation.  Can you give me a real life example
where 
changing the initial two roles doesn't start a new conversation ?

A participant is NOT equivalent to a web service endpoint.  Changing an 
endpoint is not the same as a role rebind.  E.g. Amazon can change its 
endpoint address and pass the endpoint reference around to other 
participants (somewhat like passing channel in mobile process calculus),

but this is NOT a role rebind.  But Amazon may appoint Fedex as the
shipper 
and send the endpoint of Fedex to the buyer.  This is a role binding.

Rgds, Ricky


>arkin
>
>
>Ricky Ho wrote:
>
>>
>>For point 2a, is this related to multi-party choreography ?  I can't
>>imagine a use case of participant change in a bi-party choreography.
>>
>>In multi-party choreography, we need to look into the constraints of 
>>such changes.  For example, in a buyer/seller/shipper choreography, I 
>>see "changing a shipper" can still be the same choreography instance.
>>But I have a hard time to understand if the "seller" can be changed,
even 
>>harder if the "buyer" is changed.
>>
>>So I'm thinking a stricter one ...
>>1) For a choreography to start, there needs to be at least two roles
>>being binded.
>>2) These two initial role binding cannot be changed
>>
>>as well as a looser one ...
>>1) For a choreography to start, there needs to be at least one role 
>>(the
>>initiator) being binded.
>>2) The initiator role binding cannot be changed.
>>
>>Comments ?
>>
>>Rgds, ricky
>>
>>At 12:04 PM 4/17/2003 -0700, Martin Chapman wrote:
>>
>>>As per my action point here is a list of proposed requirements 
>>>extracted from the minutes of the tues 8 April con call.
>>>
>>>1. A Choreography should be independent of message formats
>>>
>>>2. A Choreography may have run time changes:
>>>    a. the actual participants can vary
>>>    b. the actual choreography can vary [ed: I think we ruled this 
>>>out but have listed it for completeness]
>>>
>>>3. It should be possible to query the state of a Choreography
>>>
>>>4. Error/fault handling and compensation features need to be able to 
>>>be expressed in the language.
>>>
>>>5. Choreographies should be composable (into a hierarchy)
>>>
>>>
>>>Martin.
>>>
>>>_________________________________________________________________
>>>Martin Chapman                                 500 Oracle Parkway
>>>Consulting Member of Technical Staff           Ms 4op990
>>>Oracle                                         Redwood Shores,
>>>P: +1 650 506 6941                             CA 94065
>>>e: martin.chapman@oracle.com                   USA
>
>
>--
>"Those who can, do; those who can't, make screenshots"
>
>----------------------------------------------------------------------
>Assaf Arkin                                          arkin@intalio.com
>Intalio Inc.                                           www.intalio.com
>The Business Process Management Company                 (650) 577 4700
>
>
>This message is intended only for the use of the Addressee and may 
>contain information that is PRIVILEGED and CONFIDENTIAL. If you are not

>the intended recipient, dissemination of this communication is 
>prohibited. If you have received this communication in error, please 
>erase all copies of the message and its attachments and notify us 
>immediately.
>
>
>

Received on Monday, 28 April 2003 07:21:16 UTC