- From: Monica Martin <monica.martin@sun.com>
- Date: Tue, 26 Aug 2003 21:09:33 -0600
- To: ygoland@bea.com
- Cc: jdart@tibco.com, public-ws-chor@w3.org
Yaron Goland wrote: >Retry parameters are a consequence of reliable messaging, something I >thought we all agreed would exist below the Choreography definition level. > mm1: Remember that retry parameters (at least in BPSS technical specification and in use) occur at the business level as well (which is not reliable messaging). > > > >>-----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 Tuesday, 26 August 2003 23:05:04 UTC