On Sun, Nov 9, 2008 at 11:46 AM, Kenneth Kalmer
<[EMAIL PROTECTED]> wrote:
> 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.
OK, so I've figured most of this out spending a couple of hours inside
route-web and following the Tea Testing Team example. I think the
barrier initially was understanding where Rails stops, and ruote
begins. I'll spend some time on route-web2 and route-rest, just to get
more up to date and make sure I can navigate around the concepts.
I'll basically be persisting the engine and workitems in the database
with DbPersistedEngine & ActiveParticipant, and will need to build a
custom Jabber participant just like you said (more on this below).
>> Now you have an architecture where XMPP and Queues play an important
>> role and that feels sound...
>>
>> 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.
Yes, and no. What confused the living daylights out of me here was
this: Where does the engine run? Inside each participant? Only a
couple of minutes ago did I put this part of the puzzle together
(reading http://jmettraux.wordpress.com/2007/03/13/openwferu-over-amazon-sqs/).
In my case I would have the engine running in each instance of Rails
(no problem), and I would need the instance running inside a custom
Jabber bot (which would act the same way as SqsListener). Trying to
hook a background Jabber thread in Rails is going to be suicide, but I
can see how anyone would try and put a background thread in for
polling SQS.
Then just to make sure I've gotten my head around the separation of
the processes where the engine lives, and the participants live, I
could go as far running a copy of the engine inside every Jabber
participant. This would not be advisible since it would leave the DB
with legs wide open, but just to make sure I've got the concept right.
(What do I fork so I cant get this participant baked right in?)
>> 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.
Yip, this is still pretty much be the case still. Anything we
provision would be in a "pending" state by default, and remain in this
state as it traverses the business processes involved (no matter how
many steps or the duration of said process). The marriage between AASM
and ruote is a beautiful one once the lines have been drawn and the
responsibilities of each clearly defined. Only thing to note is that
some things that would have traditionally lived inside AASM
transitions would now become participants in the ruote process (like
email notifications).
I'll be building some actual code from all my messy notes today, will
shoot with more questions as I progress.
Best
--
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
-~----------~----~----~----~------~----~------~--~---
