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 reference https://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
