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

[Christopher Smith]

Thanks for the clarification, Karl. I was thinking that I didn't express
this very well.

-- Chris


On 28/11/06 19:37, "Karl Czajkowski" <karlcz at univa.com> wrote:

> 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