Re: [AM] modelling the state of a service

> I think Ashley is heading in the right direction here. Another approach
> (based on preference, not superiority) that I prefer is to have the
> subordinate nodes report back (via events) to the supervisory node (the
> service). The events sent back would provide the information to permit the
> service to maintain its state via state machine instead of calculate by
> polling subordinates.

FWIW, I follow a rule about when to use a calculated (derived) state.

Imagine that, because of a memory corruption, you lose the current state
value of state machine. If it could be re-established by computation from
the states and/or attributes of other state machines, then it should be a
derived state rather than a stored state. This is the same rule that one
uses for deciding whether an attribute should be stored or derived -- for
instance, if you lose the Total Amount ($) of an Order you could recalculate
by adding together the amount of each Order Line, and this indicates that
Total Amount should be a derived attribute.

Note this is very much a pure "modelling" view. There is then the "design"
issue of how the value of a derived state is refreshed.  Polling as an
option but, in general, not the only one. Again, exactly the same issue of
value refresh exists with derived attributes.

Rgds
Ashley

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------