W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

Re: Definition of Choreography

From: Paul Prescod <paul@prescod.net>
Date: Sun, 20 Oct 2002 15:59:20 -0700
Message-ID: <3DB33548.4010902@prescod.net>
To: "Mathews, Walden" <walden.mathews@tfn.com>
CC: "'www-ws-arch@w3.org '" <www-ws-arch@w3.org>

Mathews, Walden wrote:
> Paul,

> There's a lot of overlap in that.
> A state is a set of (pre) conditions. 

Is that true? I think a state is more than that.

 > ...  A guard is just a small elaboration of a precondition.

Could you tell me your definition of "guard" is? I think that there is 
more than one definition.

http://www.cse.unsw.edu.au/~cs2110/PDF/precondguards-notes.pdf says :

 > The two concepts of preconditions and guards are frequently confused,
 > but in this lecture we will attempt to show that they are very
 > different.

 > Preconditions and guards appear to be similar, but in fact
 > they [are] diametrically opposed concepts.

> In general, preconditions are assumptions that are necessary for 
> the successful completion of behaviour. They are the part of 
 > the contract, between the user of an operation and the
 > implementor of an operation, that must be met by the user
 > of the operation.
> Guards are used to select between different states and 
 > inputs. A guard ensures that some condition is satisfied;
 > there is no assumption.

Perhaps you could endorse this definition or provide one.

> All that's left is the event
 > (trigger).  Are you saying that the mention of events in such
> a model adds an unacceptable complexity?  I wouldn't think so.

I think that the imposition of event ordering adds unneccessary 
complexity. The "state" can always be represented as a ticket or token 
in the message and expressed merely as a precondition. But I only 
express it that way to build a bridge between the state machine model 
and the in-message model. But I don't think there is even a need to 
think in terms of states: just use preconditions directly tied to 
business needs ("declared business rules").

> I think the "state machine" is closer to what you are proposing
> than it is to the procedural alternative.

Well "procedural" is a way of implementing a "procedure". A state 
machine is also fine as an implementation technique. My point is that 
neither of them needs to be in the public interface to a service.

  Paul Prescod
Received on Sunday, 20 October 2002 19:00:13 UTC

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