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). 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) 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). 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). Just a bunch of suggestions. Your remarks and critiques are welcome. Best regards, -- John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
