- 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