- From: Paul Prescod <paul@prescod.net>
- Date: Sun, 20 Oct 2002 15:59:20 -0700
- 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