There's more than one way to do things | |
PerlMonks |
Re: Design question: handling hundreds of state machines in a Web contextby sundialsvc4 (Abbot) |
on Jan 02, 2013 at 21:07 UTC ( [id://1011346]=note: print w/replies, xml ) | Need Help?? |
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:
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.
In Section
Seekers of Perl Wisdom
|
|