RE: Definition of Choreography

>> 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.

I think it's true, yes.  State is a set of conditions, that's all.
And "pre-conditions" is just language that anticipates state change.

>> ...  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.

In the context of state machinery, the term guard seems pretty
well defined and agreed on.  It's a piece of state whose relevance
only obtains when some event or trigger has occurred; otherwise,
it's not an important component of state.  "Guard condition" is
a frequently-used phrase, and a telling one.  I admit I got the term
from Booch, who adapted a lot of his state modeling stuff from more
seminal works, like that of Harel.  I don't know if Harel used the
term "guard", but I'm looking into it, in case it matters...

>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.

I'll work on providing one, Paul, as I don't think this one is
very high quality.  Among other reservations I have with it, I don't
think "assumptions" are in the equation at all.


>> 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 agree with your first statement, but I also think state models
don't commit the sin of "imposing event ordering".

I honestly don't believe your last sentence above is making a real
distinction: "use preconditions directly tied to business needs" sounds
precisely like state modeling to me, albeit somewhat informal.  Is it
the formality you object to?

>> 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.

Granted, the machine itself is an implementation.  I thought we were
talking about models.  There's no way you can get on an escalator without
doing some state modeling, and it has nothing to do with the motor or
gears that drive the stairway.  The states that flash through your head
just before you step are contractual, essential and fully in the public
domain.

I don't believe that all (or even any) business applications that intend
to use the web for their transactions *need* a formalized state model
in order to run, but that's partly because of the low cost of missteps in
that environment.  On the other hand, I see no reason why an application
should shy away from describing (formally or informally) its intended and
valid client states for those who could appreciate the information.

I piped up with the state machinery stuff in response to Mike Champion's
request to see what it might look like, not because I think it's part of
some needed "choreography".  I have no opinion on that.

Walden Mathews

Received on Sunday, 20 October 2002 21:25:18 UTC