On Fri, May 2, 2008 at 2:21 AM, Kenneth Kalmer <[EMAIL PROTECTED]> wrote: > > So its processes, they're well defined, and work. The code that runs > them have gone through so many permutations I don't even want to think > about it, and we still haven't reached "process nirvana". I'm hoping a > foray into ruote will prove promising for these and other issues we're > facing as a young dev team. Given the number of actors (and perceived > ease of adding new ones) we should be able to cover all our existing > angles (SQS, ActiveRecord, DRb, REST) as well as some neat > refactoring. Scaling and distribution should also be a breeze due to > the ability to make an "engine housing" that can just be spawned > wherever to help take on some of the work.
Hello Kenneth, I hope I got most of your [real world / front line] scenarii, looks like you're having challenges and fun. Maybe a first rule of thumb would be to avoid Ruote if the business process is transient/instantaneous, Ruote is a long-running capable interpreter somehow. So for business processes that can be reduced to "def bp (a, b) a + b; end" it's overkill. (BTW, thanks for using the new nickname "ruote", so much easier to type). (Warning, long and boring prose ahead, not sure if I reply to any of the [F]AQ) It seems that the queue(s) are central/common to your architectures. So a ruote engine would have to listen to queues / post to them. You also mention your idea of having a queue client that spawns engines for "processing" of certain messages. Would be an interesting piece of software (and not only limited to Ruote I guess). The Ruote engine generally "listens" to two kind of "messages" : launchitems and workitems. Launchitems are request for launching an instance of a process definition (running a program), they come with a payload (aka attributes aka fields). Workitems (generally) were emitted out of the engine before coming back with their payload modified. Workitems are tokens moving inside the execution tree and they sometimes "exit" the engine to be handled by a participant. Participants are expecting two kind of messages from a ruote engine : workitems and cancelitems. Workitems got explained (a bit) in the previous paragraph. Cancelitems are emitted by an engine when the branch of a process instance gets cancelled (maybe the whole process) and that branch contains a participant that emitted a workitem, the real participant has to be notified (it potentially has to stop its work / discard the workitem). That's for the basics. A Ruote engine provides you a language for passing around hashes (workitem payloads) and patiently wait for replies (you can define timeouts). Somehow I guess, the question is, do you really need Ruote ? You've already got a loosely coupled architecture based on queues and it works. Maybe you'd like to benefit from having "process definitions" instead of "the code is neither here or there". The way I see your architecture, you could have a unique [implementation of] a queue consumer with a rule table, which would trigger a piece of code depending on the content of the message being consumed. Some pieces of code would push messages back on the queue. (Erlangish flavour). Each rule + consequence could be regarded as a method signature + method body in an open interpreter. The disadvantage would be that all the business processes are intertwined together (a set of top level methods called via a message queue). Ruote could help having a focus on a [business] process A vs [business] process B, via process definitions. Could an organization have a mix of the All Message Queue interpreter with a bit of Ruote BP execution ? Why not. That would deserve writing down a set of rule of thumbs / rule of engagement / policy. (I'm really not replying to your questions, just barely establishing a parallel with the reflection you detailed). One sure thing : Ruote should be easy to try and to discard if not necessary or simply not fitting an architect / team / organization mindset. No worries. > Sidenote, we're using the rufus-scheduler in several of our projects > with great success, thanks for the hard work on that baby. Oh thanks :) > Looking forward to an interesting conversation on the topic, and > please pardon me if I mess up the terminology for certain things. I'm > still digesting most of the lacking documentation/examples on the site > :) Sorry for the prose, not even a decent answer, and for borrowing your terminology. Your questions, feedback, critique, reports and patches are welcome. Thanks for your interest and for sharing details of your architecture. Looking forward to this conversation. Ciao, -- 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 -~----------~----~----~----~------~----~------~--~---
