| [hyades-dev] Proposal for state change events in IExecutionComponents |
In the execution and data collection groups, we've been discussing a change in the way IExecutionComponent state changes are communicated. Attached is a proposal for this and corresponding source changes. -Kim Kim Coleman PurifyPlus Development IBM Rational Software, Cupertino, CA kcoleman@xxxxxxxxxx
Execution State Change Interfaces
=================================
This is a proposal to change our notion of execution state and how state
change notification occurs, building on the code changes Richard
circulated last week. There are two key facets:
- The notion of state, or at least of a state change, should be extensible.
What's interesting about the state of a IExecutionComponent is in the
eye of the beholder.
- Use an event model for state change notification
In the new model, state changes manifest as events. If you're interested in
a state change event, you register a listener with the appropriate
IExecutionComponent. When that IExecutionComponent's state changes, it
notifies all listeners.
Representation of state
-----------------------
I'm of at least two minds about this and would like some input from the
group. Currently, state is just an integer. I offer up the following
three variations for consideration, in increasing order of flexibility:
1. Integer is the right representation for state. You can decorate state
change events with additional information, as needed, but state remains
a simple atomic value.
2. State becomes a class that encapsulates the int value and therefore
can easily be extended as needed.
3. State becomes an abstract class with no predefined notion of the data
representation. It can be specialized to represent #2, above. Or
perhaps even more cleanly, to represent each supported state as a
distinct type: ExecCompReadyState, ExecCompSuspendedState, etc.
If we really want state (rather than just the change events) to be
extensible, it needs to be a class.
The notion of specialing the state class for each "value" of state is
the most extensible and gets us out of the business of managing the
uniqueness and/or meaning of integer state values. But it is a little
grotty because it requires using instanceOf to test the test of an
execution component.
I've compromised for now by implementing #2, but anticipate additional
changes based on feedback.
Here's a summary of all the proposed changes. Code changes based on Richard's
not-checked-in drop of May 7 are also attached.
Changes to existing interfaces
------------------------------
IExecutionComponent
- Remove the individual state related methods (isInactive, isReady, etc.)
and replace them with a more generic getState() method. The current
implementation requires changing the interface in order to extend the
notion of state, thereby impacting all implementors.
Richard and Antony have defined LocalExecutionComponent and LocalSession
classes, which could easily export methods like isInactive(), if required,
but I'm not a big fan of two ways to do the same thing, so I've removed 'em.
- IExecutionComponents notionally manage a collection of state change
listeners, so they grow the following methods:
void addExecCompStateChangeListener(IExecCompStateChangeListener);
void removeExecCompStateChangeListener(IExecCompStateChangeListener);
void fireStateChange(IExecCompStateChangeEvent);
- LocalExecutionComponent grows a collection of state change listeners
and implementations of the above methods.
New Interfaces and classes
--------------------------
IExecCompState
- empty interface
ExecutionComponentState
- this is the simple integer realization.
- READY, etc. constants are defined here.
IExecCompStateChangeEvent
IExecutionComponent getTarget()
IExecCompState getState()
LocalExecCompStateChangeEvent
- instantiation of the above, for LocalExecutionComponent
IExecCompStateChangeListener
- has only one method, stateChanged(), which is the entry point for
state change notification.
LocalExecCompStateChangeListener
- an implementation of IExecCompStateChangeListener which listens for
state changes on LocalExecutionComponents.
Attachment:
StateChangeSrc.zip
Description: Zip archive