Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Design question: handling hundreds of state machines in a Web context

by sundialsvc4 (Abbot)
on Jan 02, 2013 at 21:07 UTC ( #1011346=note: print w/ replies, xml ) Need Help??


in reply to Design question: handling hundreds of state machines in a Web context

It appears to me, technically speaking, that you actually have a pretty well-defined situation:   each Web session can be identified (through login-information maintained by cookies) to belong to a particular “customer,” hence to a particular (by some means selected...) “state machine” (“workflow”), and hence, per-session, to a particular flow point (“present state”) within that workflow ... by which the current set of POST or GET inputs can be responded-to.

There are already numerous workflow-driven architectures in CPAN, e.g. POE, which, even if they are not entirely applicable, certainly can be used as architectural examples.   Yes, you probably will need to “hard-code the actions,” and there are many examples such as these of potential infrastructure. (Edit: AnyEvent?   Others?   Definitely ... check ’em out.   CPAN’s your oyster and your cornucopia ...)

Thinking off-the-shelf about this, I think that the individual request processing sequence (as implemented e.g. by Catalyst and supported by PostGres or whatever-other state backing store), would be:

  1. Identify the user session in the customary way.   (Catalyst handles this...)
  2. From the session information, determine what state-machine definition is being used and the present state.   Instantiate that state-machine and set it to the present state.
  3. Submit the inputs to the state machine and gather its response.
  4. Update the new-state information into the session data store.
  5. Return the information provided by the state-machine to the user.
  6. Clean-up in anticipation of the forthcoming next request.

In this model, it doesn’t matter how many users there are, nor how many finite state-machines (FSMs) there are, as long as the state machines follow some predictable taxonomy constructed from a reasonably flexible set of underlying, Perl-implemented primitive actions.   You instantiate the FSM, feed it inputs, save its new-state, return its outputs to the client, and you’re done.   That is certainly a well-trod footpath... and infinitely scalable.


Comment on Re: Design question: handling hundreds of state machines in a Web context

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1011346]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (5)
As of 2015-07-05 04:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (60 votes), past polls