[OGSA-BES-WG] [Fwd: BES Comments]

[Karl Czajkowski]

If I am not mistaken, I think there is a mismatch between Paul's
expected use of the state machine and the (perhaps underspecified)
assumptions of the BES authors.

I think the BES authors are taking for granted an idiomatic "Grid
monitoring" viewpoint which emphasizes steady-state conditions as
descriptive summaries of past activity, while downplaying the
transitions or transient events.  The BES implementation might have
actions associated with transitions, but the main monitoring view is
meant to be the conditions between events.

In other words: we do not usually assume that the client viewed all
transitions, but that he wants to be able to determine the relevant
actionable state from a single view of the "current steady
state". There are a variety of reasons for this, including a more
self-healing distributed system (observer and observed can converge to
stable conditions) and more efficient aggregation and indexing
(observer can export a meaningful merged model of many resources'
conditions).

I think this condition/event dichotomy is the gut reasoning behind
both wanting multiple container-level termination states and not
wanting self-transitions on a state.  As a condition, if you started
in the state and ended in the state with no intervening state, then
you never left the state, as it is impossible to not be in some state!

As a client, I will not get a stream of "self transitioned" events
with any descriptive information.  What Chris suggested is to indicate
sub-conditions to indicate, in a more domain-specific way, how the
system really did change temporarily to another observable
steady-state condition, one that could still be interpreted as Pending
in the overall condition model.


karl

-- 
Karl Czajkowski
karlcz at univa.com