On Sun, Nov 9, 2008 at 7:59 AM, John Mettraux <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 8, 2008 at 5:56 PM, Kenneth Kalmer <[EMAIL PROTECTED]> wrote: >> >> What I can't seem to figure out (be it a mental block or whatever >> other reason), is how to use ruote to manage these processes. Would >> ruote take over the communication between the processes, or do we >> stick to XMPP/AMQP and have WorkItems in the message paylods? Are the >> process definitions kept in a single repo and shared among each >> utility involved in the process? Are the actors actually related to >> how we pass WorkItems around (ie, ActiveRecord, or XMPP, or AMQP/SQS)? >> I've been reading the other newbie mails as well, but seems everyone >> has solved that part of the problem for themselves and moved on. >> >> I guess what I'm asking for is the names of classes that would by >> inserted in the various point above, considering it is a vastly >> distributed system with independent components running all over the >> show. > > Hi Kenneth, > > at first, a few remarks about aasm vs ruote. > > act_as_a_state_machine (aasm) is great for tracking the state of > resources, and I feel sometimes like proposing ruote for doing the > coordination of resource states (higher level).
Makes sense, exactly what I had in mind. > You could have a virtual resource named Process and describe its > states and transitions in aasm-speak. I'm unfortunately not an aasm > user, I've just studied it a bit in order to know when to apply it and > especially to know what developers are leveraging it for. > > One particular thing I don't know about aasm is how you do the > management of (states, transitions) sets with it. Ruote being an > interpreter for multiple processes is OK with having various versions > of a process definition running at the same time. > > (I have an impression : ruote == stored proc && aasm == triggers, but > this is vague and probably inadequate) AASM transitions are handled via events define with the class/model. Quick example would be: class GenericServer < ActiveRecord::Base acts_as_state_machine :initial => :pending state :pending, :enter => :trigger_automation state :active, :enter => :send_welcome_mail event :activate, :from => :pending, :to => :active def trigger_automation end def send_welcome_mail end end Then you'll simply call the banged event to transition from 'pending' to 'active', ie. GenericService.new.activate! Callbacks are defined when states are entered and left. I think I have an idea what you mean with the route = stored procs && assm = triggers idea, but I'll play with it a bit more... > Now you have an architecture where XMPP and Queues play an important > role and that feels sound (btw, thanks for open sourcing your work : > http://github.com/kennethkalmer/powerdns-on-rails that's cool). Likewise :) > If I take a look at your first process, in ruote speak it would look like : > > ---8<--- > class GenericProvisioning0 < OpenWFE::ProcessDefinition > sequence do > participant ref='staff' activity='provision service' > participant ref='client' activity='approve provisioning' > unless='${f:approved_by_staff}' > participant ref='automation' activity='emit order' > participant ref='support' activity='review result' > end > end > --->8--- > > Seems like the participant 'staff', 'client' and 'support' are > classical "human task" participants, could be covered by the > ActiveParticiant > (http://github.com/jmettraux/ruote/tree/r0.9.19/lib/openwfe/extras/participants/activeparticipants.rb) > > The participant 'automation' would require some work... Maybe something like : > > ---8<--- > require 'yaml' > require 'jabber-simple' # gem ? > > module OpenWFE > module Extras > > class JabberParticipant > include OpenWFE::LocalParticipant > > def initialize (options={}) > > @block = block > > @im = Jabber::Simple.new(options[:account], options[:password]) > > @im.received_messages do |msg| > workitem = decode_workitem(msg) > reply_to_engine(workitem) > end > end > > def consume (workitem) > target = workitem.attributes['target'] > @im.deliver(target, encode_workitem(workitem)) > end > > protected > > def decode_workitem (msg) > YAML.load(msg.body) > end > def encode_workitem (wi) > YAML.dump(wi) > end > end > > end > end > --->8--- > > Then you'd have to bind that participant in the engine : > > ---8<--- > engine.register_participant( > "automation", > OpenWFE::Extras::JabberParticipant.new( > :account => "[EMAIL PROTECTED]", :password => > "joburg222")) > --->8--- > > That would be one way of doing it. Note that the participant code > contains the dispatching and the receiving implementation. > > That's just for XMPP (well Jabber), I guess it's easy to derive code > for other asynchronous or synchronous mechanisms. > > In the end, you could use Ruote to interpret your high-level process > definitions and "orchestrate" your services/agents/participants. Could > be interesting to separate tactical stuff (business processes) from > technical stuff (local states and triggers). Orchestration is exactly what I was looking for ultimately. Finite state machines are wonderful when used in a small setting, but 100's of states (albeit finite), is not worth the headache. I've seen us get caught in the trap of using states to define process steps, and then we quickly wipe the board clean and start again. By this time you can imagine the board begin spotless, hence looking outside the AASM box. > Just a bunch of suggestions. Your remarks and critiques are welcome. > Best regards, As always John, you're kindness and patience towards newbies is nothing short of inspirational. I'll help people out with my own projects in a similar way. Thanks for the help, I'll get cracking on a fictional workflow to see if I can wrap my head around this and will pass feedback along. Regards -- Kenneth Kalmer [EMAIL PROTECTED] http://opensourcery.co.za --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-users?hl=en -~----------~----~----~----~------~----~------~--~---
