Forwarding Paul's email. -------- Original Message -------- Subject: RE: [OGSA-BES-WG] [Fwd: BES Comments] Date: Wed, 29 Nov 2006 14:31:40 -0700 From: Strong, Paul <pstrong@ebay.com> To: Christopher Smith <csmith@platform.com>, Karl Czajkowski <karlcz@univa.com>, Hiro Kishimoto <hiro.kishimoto@jp.fujitsu.com> CC: <ogsa-bes-wg@ggf.org> Thanks to both of you for helping me understand the reasoning behind the current description. I'd still suggest that clearly modeling the life-cycle of an activity, irrespective of one's perspective (i.e. the development of a specific interface), should provide a foundation for what control and monitoring capabilities you want the BES container to expose. Then one can attack the "what do I want to monitor?" question. That model should avoid the use of states as descriptions of past activity. Entangling states with transitions is fraught. This approach can typically lead to a great proliferation in the number of essentially equivalent states that result from different transitions, thus reducing overall clarity in the diagram. It also prevents the implementer from clearly identifying common elements, states etc. Modeling states and transitions separately does not mean that a client can't easily query the BES container to determine the state and last transition of an activity or a collection of activities. Anyway I will let this lie. You guys are more familiar with your problem space than I and as a group you have reached a consensus. All I will urge you to do is to provide clearer annotation and labeling of transitions so that your reasoning is clearly understood :o) Thanks for affording me the opportunity to comment and helping me gain a greater understanding of BES. Regards Paul -----Original Message----- From: Christopher Smith [mailto:csmith@platform.com] Sent: Wednesday, November 29, 2006 7:58 AM To: Karl Czajkowski; Hiro Kishimoto Cc: ogsa-bes-wg@ggf.org; Strong, Paul Subject: Re: [OGSA-BES-WG] [Fwd: BES Comments] 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@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
-- Hiro Kishimoto