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

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

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>
Message-ID: <00c801c36687$452d4a40$12cccf0c@bea.com>

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

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