RE: [ws-chor] 7/28/2003: Reqts 1.0 Comments

My $0.02c would be that the choreography definition should specify *what*
decision has to be made but not *how* the decision is made as it is
implementation dependent. For example decisions that can validly go in a
choreography are:
- Loops, for example sending the same message multiple times as in sending a
"request for quote" to multiple suppliers
- Decisions, for example specifying a compensating action if a message is
not delivered.

David

-----Original Message-----
From: Monica Martin [mailto:monica.martin@sun.com]
Sent: Sunday, August 17, 2003 1:57 PM
To: jdart@tibco.com
Cc: ygoland@bea.com; public-ws-chor@w3.org
Subject: Re: [ws-chor] 7/28/2003: Reqts 1.0 Comments




>> Goland: Where I think the real confusion is coming is from the term 
>> 'control logic'.
>> What I specifically mean is that when a web service has an option for 
>> which
>> message it can send next then the logic the web service uses to 
>> choose must
>> not be expressed in the choreography definition.
>
> Dart: What about something like an iteration facility (which is a very 
> simple example of control logic, IMO). If the iteration count is < 3, 
> you send a message, otherwise you don't. I think this is probably 
> necessary given the other requirements.
>
> mm1:  There was some offline discussion in the F2F whether we should 
> keep the control logic separate or not.  I think we need to discuss 
> this more fully and understand how enables the binding to choreography 
> instance (see conversation with Burdett, Cummins and I).

I think you may very well need some type of business retry parameters in 
order to accommodate business requirements.