Re: [AM] modelling the state of a service

"Philippe Back (High Octane)" <[email protected]> Tue, 17 Feb 2004 10:14:52 +0100
Newsgroups gmane.comp.programming.modeling.agile
Message-ID <[email protected]>
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" <[email protected]>
To: <[email protected]>
Sent: Monday, 16 February, 2004 14:33
Subject: Re: [AM] modelling the state of a service


> Scott Ambler Sent Mon, 16 Feb 2004 07:58:15 -0500
> >
> >At 12:05 PM 2/16/2004 +0000, Ian Chamberlain 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?
> >
> 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
>
>

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