Hi Kenneth, Thanks for your thorough explanation. I see that I was thinking in the right direction: launching ruote processes from within state transitions.
I agree with you that a pure statemachine which should handle the process you describe, will collapse on itself. The sheer amount of states and transitions is too big to handle. I have a lot of experience with this in a program of mine, and that's why I am looking for a better way to do things for the next version. In my current program a lot of feature- and customer requests have to be added constantly, and this has become a nightmare at this point. I was wondering: does the ruote process call the transition in your example? The other question I have is, should I stick with ruote <1.0 or is it a good idea at this point to switch to 2.x? I will investigate further and probably ask you more questions, if that's ok ;-) I do have an added handicap in that I just recently started with ruby. However a have a lot of people around me who are very experienced with ruby, and they are willing to help me, when I get stuck with the language. Kind regards, Gerben On 10 dec, 08:28, sjampster <[email protected]> wrote: > To serve the ruote community, I have posted an email conversation > between me, Kenneth Kalmer and John Mettraux down here. > > me: > I have been investigating the ruote docs quite a lot, especially the > different workflow implementation that are described. That looked very > good. I have made a small test app, where I started a ruote workflow > process from within a state_machine state. I think you do it the > opposite, right? > > I still am having some problems in seeing the combination between > state_machine and ruote and I was wondering if you could describe me > in more detail what advantage this combination will give? > Perhaps it will sink in tonight when I drive home, but perhaps you can > give me some more insight. > > kenneth: > So, state machines and workflows. I'm going to be verbose and all over > the show here but this is how we work in the ISP in a Box system [1]. > > We provision services for our clients, I'll step you through the > process of provisioning a domain throughout our infrastructure. You'll > need to have this gist close by for > referencehttps://gist.github.com/6e92e3aaecd28303742a > > Here we go. > > Domain is added to the system and is in the initial state of > 'pending'. A process is then launched to register the domain. The > process is responsible for handled DNS entries, domain registration, > validating the registration, handling errors, giving humans a chance > to intervene when needed. During this time the domain is effectively > 'locked in a pending state'. This shows how the state machine acts as > a locking mechanism. While a domain is 'pending' everyone is aware of > the fact that a process is running somewhere, attempting to register > the domain. I gave you about 60% of the real domain registration > process definition, but ours is a lot more complicated. Apart from new > domains there is also handling transfers of existing domains. > > Once the process is complete, it 'activates' the domain in IIAB. > Active domains can now be deleted, amongst other things. When the > state transitions to 'deleted' another process is fired off to clean > the domain from the DNS infrastructure. > > Hmm, came out shorter than I thought, but here is the synopsis: > > Use a state machine as a locking mechanism, and use the events > provided by the state machine to launch small processes. Use the > guards provided by the state machine to prevent stupid transitions > from happening. > > The reason I gave you such a verbose process definition without > explaining it is the following: Any state machine and developer would > collapse trying to model that in a pure state machine fashion. Yes, it > would collapse, I've been down that road before. But this doesn't mean > the model is only well suited for converting 'big state machines' into > smaller ones. I have plenty of processes that involve only two or > three participants that complete in a few seconds... > > I hope this helps, I don't want to blather on for ages on the topic, > please fire off your next set off questions to us both. I'll handle > the discussion mostly, and John thrives on hearing the possibilities > of his baby :) -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
