- From: Yaron Goland <ygoland@bea.com>
- Date: Tue, 19 Aug 2003 12:22:45 -0700
- To: "'Monica Martin'" <monica.martin@sun.com>, <jdart@tibco.com>
- Cc: <public-ws-chor@w3.org>
Retry parameters are a consequence of reliable messaging, something I thought we all agreed would exist below the Choreography definition level. > -----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 Friday, 22 August 2003 03:03:37 UTC