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

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

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 19 Aug 2003 17:16:55 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1D4E@c1plenaexm07-b.commerceone.com>
To: "'Monica Martin'" <monica.martin@sun.com>, jdart@tibco.com
Cc: ygoland@bea.com, public-ws-chor@w3.org
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.
Received on Saturday, 23 August 2003 07:42:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:01 UTC