[AM] modelling the state of a service

[Ian Chamberlain]

Hi All,

How about a real world modelling question for a change?

I'm trying to come up with a nice simple way to represent the current state
of a service, where the service consists of a number of processes spread
over several nodes.

For example the web server part of a web service might consist of two
clustered nodes running a web server listening to requests on port 80 and
passing the request to another node cluster to do the actual processing. For
the web server part of the service to be available at least one node has to
be available, running the web server process, listening on port 80 and able
to connect to the next tier. Other tiers would have similar combinations of
processes so in order to say the web service is actually available a path
through all the tiers must be traceable.

Depending on different combinations of states across the tiers you might
want to trigger alerts to notify the state of the service to operators.

Any suggestions that don't involve multiple levels of composite states
gratefully received.

Regards

Ian Chamberlain

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott Ambler]

Post by Ian Chamberlain
Hi All,
How about a real world modelling question for a change?

That would be too radical. ;-)

Post by Ian Chamberlain
I'm trying to come up with a nice simple way to represent the current
state of a service, where the service consists of a number of processes
spread over several nodes.
For example the web server part of a web service might consist of two
clustered nodes running a web server listening to requests on port 80 and
passing the request to another node cluster to do the actual processing.
For the web server part of the service to be available at least one node
has to be available, running the web server process, listening on port 80
and able to connect to the next tier. Other tiers would have similar
combinations of processes so in order to say the web service is actually
available a path through all the tiers must be traceable.
Depending on different combinations of states across the tiers you might
want to trigger alerts to notify the state of the service to operators.
Any suggestions that don't involve multiple levels of composite states
gratefully received.

How about a UML state machine diagram
(http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm) to model
the states and a UML deployment diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm) to model the
various nodes? Or perhaps just one of the two diagrams if it proves
sufficient on its own?

Post by Ian Chamberlain
Regards
Ian Chamberlain

- Scott


====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Ian Chamberlain]

Scott Ambler Sent Mon, 16 Feb 2004 07:58:15 -0500

Post by Scott Ambler

Post by Ian Chamberlain
Hi All,
How about a real world modelling question for a change?

That would be too radical. ;-)

Post by Ian Chamberlain
I'm trying to come up with a nice simple way to represent the current
state of a service, where the service consists of a number of processes
spread over several nodes.
For example the web server part of a web service might consist of two
clustered nodes running a web server listening to requests on port 80 and
passing the request to another node cluster to do the actual processing.
For the web server part of the service to be available at least one node
has to be available, running the web server process, listening on port 80
and able to connect to the next tier. Other tiers would have similar
combinations of processes so in order to say the web service is actually
available a path through all the tiers must be traceable.
Depending on different combinations of states across the tiers you might
want to trigger alerts to notify the state of the service to operators.
Any suggestions that don't involve multiple levels of composite states
gratefully received.

How about a UML state machine diagram
(http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm) to model
the states and a UML deployment diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm) to model the
various nodes? Or perhaps just one of the two diagrams if it proves
sufficient on its own?

I thought about a state diagram. Here are some of the issues I came up with:

A state diagram represents the state of one object - what is the object? The
service? What about the component pieces?
A service is made up of lots of components each with its own state - do I
use composite states?
How do I model the situation where if a process on one node fails the
service is still available but if it fails on two nodes the service is
unavailable? i.e. one event of a type is ok, two is not, unless we've
recovered in the meantime.

What most of this adds up to is how do I keep it simple? I ended up with a
"service compromised" state that had huge numbers of transitions to "service
available", each with a huge guard. I was just hoping someone had had come
up with a better way.

Regards

Ian Chamberlain

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Ashley McNeile]

Ian

It seems to me that this is a classic example of where the notion of a
calculated state is useful.

It would be used as follows:

- Each Node would have its own state (perhaps modelled with a state machine
for each node).

- The Service would be modelled with a state machine that has a derived
state, calculated from the states of the Nodes. If the count of nodes that
are down is two (or more) the calculated state of the Service is "service
compromised", otherwise it is "service OK". This state machine determines
what can and cannot happen at the Service level.

Calculated states (which are conceptually just like calculated or derived
attributes) have equal expressive power to guards, but avoid the transition
explosion you describe.

Calculated states are not (unfortunately) supported in any sensible way by
UML.

I can provide more information if you are interested -- let me know
privately.

Rgds
Ashley

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[r***@armassolutions.com]

Ian,

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.

This is supported via UML.

Regards,
Robert


-----Original Message-----
From: Ashley McNeile [mailto:***@metamaxim.com]
Sent: Monday, February 16, 2004 7:58 AM
To: ***@topica.com
Subject: Re: [AM] modelling the state of a service
Importance: Low


Ian

It seems to me that this is a classic example of where the notion of a
calculated state is useful.

It would be used as follows:

- Each Node would have its own state (perhaps modelled with a state machine
for each node).

- The Service would be modelled with a state machine that has a derived
state, calculated from the states of the Nodes. If the count of nodes that
are down is two (or more) the calculated state of the Service is "service
compromised", otherwise it is "service OK". This state machine determines
what can and cannot happen at the Service level.

Calculated states (which are conceptually just like calculated or derived
attributes) have equal expressive power to guards, but avoid the transition
explosion you describe.

Calculated states are not (unfortunately) supported in any sensible way by
UML.

I can provide more information if you are interested -- let me know
privately.

Rgds
Ashley

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Ashley McNeile]

Post by r***@armassolutions.com
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott Ambler]

Post by Ian Chamberlain

<snip>

A state diagram represents the state of one object - what is the object?
The service?

I'd say the service. It doesn't have to be the states of just one object.

Post by Ian Chamberlain
What about the component pieces?
A service is made up of lots of components each with its own state - do I
use composite states?

I'd look at the various states that the service could be in, and if
substating makes sense then do it.

If the physical components are important, a deployment diagram may be the
way to go as well.

Post by Ian Chamberlain
How do I model the situation where if a process on one node fails the
service is still available but if it fails on two nodes the service is
unavailable? i.e. one event of a type is ok, two is not, unless we've
recovered in the meantime.

How about a Node Fails transition. Model it with a contraint of [1 node
failed] and have it going back to the original state. Model it a second
time with [>1 node failed] got to the unavailable state. You'll also need
node recovered transitions as well. The unavailable state could have a
constraint of >1 node failed on it and the available state <= 1 node failed
to keep the diagram simple. You might want to consider not having the
transitions with only one node failed to simplify the diagram.

Post by Ian Chamberlain
What most of this adds up to is how do I keep it simple? I ended up with a
"service compromised" state that had huge numbers of transitions to
"service available", each with a huge guard. I was just hoping someone had
had come up with a better way.

Sometimes a complex problem needs a complex model to represent
it. Sometimes not.

- Scott

Post by Ian Chamberlain
Regards
Ian Chamberlain

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Philippe Back (High Octane)]

Ian,

For state machines I would use "exception" concept as seen in
http://www.jstatemachine.org/whitepaper.html (PDF at the bottom).

I spent some time trying to picture your situation and so:

- the physical configuration is not clear to me since I miss the details on
how the clusters (web on and the service fulfillment one) are deployed. Is
there a kind of load balancer in front ? DNS round obin ? Broadcast mode
like in Weblogic ? What's the technology used ?
If there is a cluster, I guess that we have to think about the state of the
service as the state of the service as perceived from the "web server
client" point of view.

There, it's basically: working or not and if we want to go further, it may
be :

FUNCTIONAL : OK | ERROR
TECHNICAL : OK | ERROR and if OK, we can get a "status", like "FULLY_OK" and
"PARTIALLY_OK_BE_CAREFUL", "SORRY_I_CANNOT_ACCEPT_REQUESTS_BUT_I_HEAR_YOU"


[:WebClientApp]------->O--[:ClusterMgt]---+-->O--[ws1:WebServer]------>O--[:
Plugin]--->O--[:ClusterMgt]--->O-[rh1:RqHandler]

|-->O--[ws2:WebServer]------>O--[:Plugin]--->/
\->O-[rh2:RqHandler]


CLIENTHW-----LAN---------CLUSTER1HW-----LAN----CLUSTER2HW

ws1 and ws2 are basically stateless things
plugin too, just connecting both blocks

The state of the service is perceived by :WebClientApp

So, nobody is responsible for "determining the global state of the service".

Choices are then:

1) use a client API so that the WebClientApp uses it. Basically useless
since it denies all advantage of using a standard webservice call.

2) have the services be able to reply to such a request.

If we pick option2:

- the API of the webservice in RqHandlers should contain a
"getOverallStateOfService()" and the RqHandler should be able to answer such
a question.

So, how can we model that ?

Concurrent states seem to be an option.
In order to support this, there is some communication to be exchanged
between the 2 RqHandler's.

And then, there appears to be the 2 levels of possible problems: Tech & Func
("I can[not] connect to you" or "you give me a "sorry I hear you but can't
handle that query right away").

I don't think a statechart will cut it. As you mention that you have a lot
of arrows.
A state-transition matrix with "superstates" zones may well do.

It seems to be that there is no single "owner" of the "determine the current
state" in what you described. So, the question as I see it is "how can we
agree if we are all at the same level"...

I would be very interested in reading about your ideas...

Philippe Back
www.highoctane.be


----- Original Message -----
From: "Ian Chamberlain" <***@hotmail.com>
To: <***@topica.com>
Sent: Monday, 16 February, 2004 14:33
Subject: Re: [AM] modelling the state of a service

Post by Ian Chamberlain
Scott Ambler Sent Mon, 16 Feb 2004 07:58:15 -0500

Post by Scott Ambler

Post by Ian Chamberlain
Hi All,
How about a real world modelling question for a change?

That would be too radical. ;-)

Post by Ian Chamberlain
I'm trying to come up with a nice simple way to represent the current
state of a service, where the service consists of a number of processes
spread over several nodes.
For example the web server part of a web service might consist of two
clustered nodes running a web server listening to requests on port 80 and
passing the request to another node cluster to do the actual processing.
For the web server part of the service to be available at least one node
has to be available, running the web server process, listening on port 80
and able to connect to the next tier. Other tiers would have similar
combinations of processes so in order to say the web service is actually
available a path through all the tiers must be traceable.
Depending on different combinations of states across the tiers you might
want to trigger alerts to notify the state of the service to operators.
Any suggestions that don't involve multiple levels of composite states
gratefully received.

How about a UML state machine diagram
(http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm) to model
the states and a UML deployment diagram
(http://www.agilemodeling.com/artifacts/deploymentDiagram.htm) to model the
various nodes? Or perhaps just one of the two diagrams if it proves
sufficient on its own?

A state diagram represents the state of one object - what is the object? The
service? What about the component pieces?
A service is made up of lots of components each with its own state - do I
use composite states?
How do I model the situation where if a process on one node fails the
service is still available but if it fails on two nodes the service is
unavailable? i.e. one event of a type is ok, two is not, unless we've
recovered in the meantime.
What most of this adds up to is how do I keep it simple? I ended up with a
"service compromised" state that had huge numbers of transitions to "service
available", each with a huge guard. I was just hoping someone had had come
up with a better way.
Regards
Ian Chamberlain
_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Paul Oldfield]

(responding to Ian)

Post by Ian Chamberlain
I thought about a state diagram. Here are some of the issues
A state diagram represents the state of one object - what is
the object? The service? What about the component pieces?
A service is made up of lots of components each with its
own state - do I use composite states?
How do I model the situation where if a process on one node
fails the service is still available but if it fails on two nodes the
service is unavailable? i.e. one event of a type is ok, two is
not, unless we've recovered in the meantime.

I've done this sort of thing a couple of times before. Each
service to a client depends on zero or more other services,
and each service has one or more clients. The clients
want information that means something to them.

This means that each service in the network has its own
state machine, and the state it's in depends on its own
state and the states of services it depends upon. Yet
the state the client is interested in will probably need
less detail. The client may only be interested in
'Working' or 'Not Working', or he may be interested
in other potential states. One system I worked on
reported several states; { Working, Reduced Throughput;
Reduced Functionality; Reduced Both; Emergency
Shutdown; Not Available } and if things got worse, it
failed to report at all. These were states that caused
different client behaviour, so were of interest to the
client.

Sometimes, different clients want different information;
in this system, one monitoring client wanted to know
when there was no fault-tolerance capacity left in
the supplier services to this service - e.g. unless
both suppliers of a service (or at least two) were
reporting 'Working', the service reported 'Not Fault
Tolerant' to the monitoring client.

Guidelines - keep a state machine on each node of the
service network; let the client needs drive what states
get reported; let the need for reporting these states
drive what states are recorded internally. Report
changes of state only when it would result in changed
behaviour on the part of the client. If he can't respond
differently he doesn't need to know.

The problem is complex, but don't make it harder than
it needs to be by trying to cut corners.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott E. Preece]

Depending on what kind of analysis you want to do on the model, you
can choose to model multiple sub-systems in various ways.

The "pure state machine" approach is to combine the multiple state
machines into one - the "whole system" state machine has nodes that
represent a state tuple containing one state from each of the
constituent machines). That is, you might have states with names like
"MachineA_Ready_and_MachineB_Ready"). This leads to state explosion and
also doesn't work if the number of machines in the cluster isn't fixed
(your model embeds the number of machines).

Another approach is to include conditionals on your state transitions,
so that you might have a transition labeled "Event X<at least one other
machine still Ready>". This allows you deal with an arbitrary number of
machines (the model doesn't explicitly embed the number of machines)
On the other hand, while it does explicitly point out where you have to
be able to determine the whole-system state, it doesn't give you any
particular guidance as to where to implement it.

Or you could go lightweight and model the common case in a state machine
and sequence diagram, with comments in the diagrams indicating where
such conditionals would need to be checked.

Or, you could make a "system manager" an explicit component that the
individual machines send messages to and make it responsible for
tracking the whole configuration. The downside to this is that it
implies an architecture.

Of course, a lot depends on what you want the model for. If you're
looking at availability requirements, you might really want a
queuing-theoretical (mathematical) model instead of a behavioral model.

scott

| From: Scott Ambler<***@ronin-intl.com>
| Date: Mon, 16 Feb 2004 07:58:15 -0500
|
| At 12:05 PM 2/16/2004 +0000, you wrote:
| >Hi All,
| >
| >How about a real world modelling question for a change?
|
| That would be too radical. ;-)
|
|
|
| >I'm trying to come up with a nice simple way to represent the current
| >state of a service, where the service consists of a number of processes
| >spread over several nodes.
| >
| >For example the web server part of a web service might consist of two
| >clustered nodes running a web server listening to requests on port 80 and
| >passing the request to another node cluster to do the actual processing.
| >For the web server part of the service to be available at least one node
| >has to be available, running the web server process, listening on port 80
| >and able to connect to the next tier. Other tiers would have similar
| >combinations of processes so in order to say the web service is actually
| >available a path through all the tiers must be traceable.
| >
| >Depending on different combinations of states across the tiers you might
| >want to trigger alerts to notify the state of the service to operators.
| >
| >Any suggestions that don't involve multiple levels of composite states
| >gratefully received.
|
| How about a UML state machine diagram
| (http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm) to model
| the states and a UML deployment diagram
| (http://www.agilemodeling.com/artifacts/deploymentDiagram.htm) to model the
| various nodes? Or perhaps just one of the two diagrams if it proves
| sufficient on its own?
|
|
|
| >Regards
| >
| >Ian Chamberlain
|
| - Scott
|
--
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il 61820
e-mail: ***@urbana.css.mot.com fax: [phone]
phone: [phone] cell: 217-433-6114 pager: ***@msg.myvzw.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Paul Oldfield]

(responding to Ashley, Ian)

... 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.

The last time I implemented something like this, we opted
for Polling because a service could fall over without
informing clients that it was about to do so - theoretically.
We considered 'heartbeat' messages as an alternative,
but polling won out because it only happened when the
information was needed.


Paul Oldfield
www.aptprocess.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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