A(nother) (crude) ruote and amqp example
coffeeaddict
First off; since this is my first post, let me introduce:
My name is Hartog de Mik, I am dutch and have been messing around with
computers and programming languages since age 11 (I register 30,5
years now).
I have spent most of my time in web development, but have also
ventured on some other expeditions. A few years ago I have been
working with jBPM and have been intrigued by BPM stuff ever since.
Recently I stumbled across ruote as I tried to find a solution for
fortifying an order flow system done in Rails. I steered away from
ruote as there where to many uncertainties. I ended up with just a
state machine (for now) as the complexity of the flow (low) allows for
it.
In my spare time I still wanted to try ruote as the benefits of having
a true workflow engine could become necessary in the near future (and
I needed a new pet-project).
I have cooked up an example project, inspired by the ping-pong example
from amqp. (http://github.com/tmm1/amqp/blob/master/examples/mq/
pingpong.rb)
The project can be found on http://github.com/coffeeaddict/ruote-amqp-ping-pong/
I gladly accept any recommendations for improvements and critique on
my DSL (and ruby) coding style.
I hope the project can inspire / help those seeking (pointers-
to-)answers in the ruote and ruote-amqp fog
Kind regards,
Hartog de Mik
John Mettraux
On Sat, Sep 25, 2010 at 03:03:40AM -0700, coffeeaddict wrote:
>
> First off; since this is my first post, let me introduce:
>
> My name is Hartog de Mik, I am dutch and have been messing around with
> computers and programming languages since age 11 (I register 30,5
> years now).
>
> I have spent most of my time in web development, but have also
> ventured on some other expeditions. A few years ago I have been
> working with jBPM and have been intrigued by BPM stuff ever since.
>
> Recently I stumbled across ruote as I tried to find a solution for
> fortifying an order flow system done in Rails. I steered away from
Hello Hartog,
welcome here. I'm curious, what kind of uncertainties are you faced with (it's very useful info for us).
> I ended up with just a
> state machine (for now) as the complexity of the flow (low) allows for
> it.
>
> In my spare time I still wanted to try ruote as the benefits of having
> a true workflow engine could become necessary in the near future (and
> I needed a new pet-project).
>
> I have cooked up an example project, inspired by the ping-pong example
> from amqp. (http://github.com/tmm1/amqp/blob/master/examples/mq/
> pingpong.rb)
>
> The project can be found on http://github.com/coffeeaddict/ruote-amqp-ping-pong/
Looks fun !
> I gladly accept any recommendations for improvements and critique on
> my DSL (and ruby) coding style.
>
> I hope the project can inspire / help those seeking (pointers-
> to-)answers in the ruote and ruote-amqp fog
The ruote-amqp fog, err... project needs an active maintainer. I'm struggling with ruote, Torsten is the head of ruote-kit... Thanks for all those pointers !
I will come up with any remark I may have.
Thanks again, cheers,
--
John Mettraux - http://jmettraux.wordpress.com
Hartog C. de Mik
>
> On Sat, Sep 25, 2010 at 03:03:40AM -0700, coffeeaddict wrote:
> >
> > First off; since this is my first post, let me introduce:
> >
> >
> > Recently I stumbled across ruote as I tried to find a solution for
> > fortifying an order flow system done in Rails. I steered away from
> > ruote as there where too many uncertainties.
>
> Hello Hartog,
>
> welcome here. I'm curious, what kind of uncertainties are you faced
> with (it's very useful info for us).
- of the available MQ's
- and the ruby components required
Maturity:
- of amqp, ruote, ruote-amqp and all components related
Solvability:
- of problems due to lack of documentation
Maintainability:
- of the produced setup (but that is more an work-internal issue)
> > I gladly accept any recommendations for improvements and critique on
> > my DSL (and ruby) coding style.
> >
> > I hope the project can inspire / help those seeking (pointers-
> > to-)answers in the ruote and ruote-amqp fog
>
> The ruote-amqp fog, err... project needs an active maintainer. I'm
> struggling with ruote, Torsten is the head of ruote-kit... Thanks
> for all those pointers !
The fog is mostly due to poor documentation. The available examples
don't explain what they are doing, why they are doing it and for what
reason. (that includes my own example; but will be fixing that)
> I will come up with any remark I may have.
I look forwards to it ;-)
Grtz,
Hartog.
John Mettraux
On Sat, Sep 25, 2010 at 10:22:59AM +0000, Hartog C. de Mik wrote:
> On Sat, Sep 25, 2010 at 07:14:42PM +0900, John Mettraux wrote:
> >
> > On Sat, Sep 25, 2010 at 03:03:40AM -0700, coffeeaddict wrote:
> > >
> > > First off; since this is my first post, let me introduce:
> > >
> > > <snip; introduction>
> > >
> > > Recently I stumbled across ruote as I tried to find a solution for
> > > fortifying an order flow system done in Rails. I steered away from
> > > ruote as there where too many uncertainties.
> >
> > with (it's very useful info for us).
Many thanks !
> Stability:
> - of the available MQ's
> - and the ruby components required
>
> Maturity:
> - of amqp, ruote, ruote-amqp and all components related
>
> Solvability:
> - of problems due to lack of documentation
I have to protest here, ruote is not lacking documentation. I'm always struggling to bring more documentation on the table and always saying "if a point in the documentation is not clear, please say so".
Fact : whatever amount of documentation you write, people will complain (as if you had not written any documentation.
> Maintainability:
> - of the produced setup (but that is more an work-internal issue)
You forgot the point about responsivity of the mailing list ;-)
Thanks again !
Hartog C. de Mik
>
> On Sat, Sep 25, 2010 at 10:22:59AM +0000, Hartog C. de Mik wrote:
> > On Sat, Sep 25, 2010 at 07:14:42PM +0900, John Mettraux wrote:
> > >
> > > On Sat, Sep 25, 2010 at 03:03:40AM -0700, coffeeaddict wrote:
> > > >
> > > > First off; since this is my first post, let me introduce:
> > > >
> > > > <snip; introduction>
> > > >
> > > > Recently I stumbled across ruote as I tried to find a solution for
> > > > fortifying an order flow system done in Rails. I steered away from
> > > > ruote as there where too many uncertainties.
> > >
> > > welcome here. I'm curious, what kind of uncertainties are you faced
> > > with (it's very useful info for us).
>
> Many thanks !
>
> > Stability:
> > - of the available MQ's
> > - and the ruby components required
> >
> > Maturity:
> > - of amqp, ruote, ruote-amqp and all components related
> >
> > Solvability:
> > - of problems due to lack of documentation
>
> I have to protest here, ruote is not lacking documentation. I'm
> always struggling to bring more documentation on the table and
> always saying "if a point in the documentation is not clear, please
> say so".
Nothing personal! ;-) Ruote is the best documented of the components
used, my main concern where the amqp related components. Yes; the have
rdoc for (almost) every function used, and if you read all of them you
can build a notion of how the objects and components are to interface
and depend on one and other.
It is however very scattered, and requires a lot of creativity of the
person with the problem to find the right piece of information.
As an example; it took a lot of inspecting AMQP.logging to figure out
that the daemon-kit generated classes responded to no queue at
all.
Finding out where and how to set the reply queue was a matter of
using the right search terms in google, which in term require
knowledge of how message queues work. If you are new to this domain,
it is very hard to get answers from just the documentation. Imho the
documentation is then failing to be informative enough.
And I agree - no matter how much documentation you write, there will
always be complaints.
Grtz,
Hartog.
John Mettraux
Point taken for the ruote-amqp documentation. I will try to find some time to make it better (though I am not the original author).
I have had a look at your ping/pong example.
http://github.com/coffeeaddict/ruote-amqp-ping-pong
Congratulations for all the work ! I feel guilty because most of the work was induced by the lack of documentation in ruote[-amqp].
I have a few small remarks, please note that I completely understand that some of those remarks concern misunderstandings induced by lacks in documentation (and not lacking documentation) for which, as the project leader, I am responsible.
So :
- Storing the data into ruote_worker/ is a bit confusing for me, I was expecting to find some ruote worker code related in there. Maybe ruote_data/ or ruote_development_data/ ruote_production_data/ is a better folder name.
- The error_logger participant isn't really necessary, if a process gets into an error, the process is still queryable :
errs = engine.errors
if errs.size > 0
puts "there are processes with errors :"
errs.each do |err|
puts "process #{err.wfid}"
end
end
- It would be more DRY to reduce the ping and the pong components to one component that you instantiate two times (ping and pong)
- The process definition could be a bit simpler, there is one point with which I was not really following the original ruote-amqp author, but I'd prefer avoiding putting AMQP configuration details in a process definition. It's better to pass that configuration when registering the participants or via process variables. You are elegantly hiding that in two (ping and pong) subprocesses, but I'd really love people not to have to do that.
- It would be nice to have an orientation in the README.rdoc that indicates where is what.
.
Your example directly goes ruote + ruote-amqp + AMQP + RabbitMQ. For fun, I went back to ruote only and produced this ping/pong example :
( http://gist.github.com/596822 )
---8<---
require 'rubygems'
require 'ruote'
pdef = Ruote.process_definition do
repeat do
ping # mister ping, please shoot first
pong
end
end
class Opponent
include Ruote::LocalParticipant
def initialize (options)
@options = options
end
def consume (workitem)
puts @options['sound']
reply_to_engine(workitem)
end
end
engine = Ruote::Engine.new(Ruote::Worker.new(Ruote::HashStorage.new))
engine.register_participant :ping, Opponent, 'sound' => 'ping'
engine.register_participant :pong, Opponent, 'sound' => 'pong'
wfid = engine.launch(pdef)
sleep 5 # five seconds of ping pong fun
engine.cancel_process(wfid) # game over
--->8---
It orchestrates a tennis table exchange between ping and pong for 5 seconds.
Thanks again,
John Mettraux
On Sat, Sep 25, 2010 at 10:39:15PM +0900, John Mettraux wrote:
>
> I have had a look at your ping/pong example.
>
> http://github.com/coffeeaddict/ruote-amqp-ping-pong
>
> Congratulations for all the work ! I feel guilty because most of the work was induced by the lack of documentation in ruote[-amqp].
>
> I have a few small remarks, please note that I completely understand that some of those remarks concern misunderstandings induced by lacks in documentation (and not lacking documentation) for which, as the project leader, I am responsible.
>
> So :
>
> - Storing the data into ruote_worker/ is a bit confusing for me, I was expecting to find some ruote worker code related in there. Maybe ruote_data/ or ruote_development_data/ ruote_production_data/ is a better folder name.
Oh, I completely forgot this one :
- It's a bit confusing to have ping/ and pong/ described as workers. In ruote parlance, a worker is 'working' on executing processes, ping and pong are participants, more like "consumers". Is your choice of the "worker" word here induced by some of the ruote-amqp [lacking] documentation ?
Best regards,
David Greaves
> The ruote-amqp fog, err... project needs an active maintainer. I'm struggling
> with ruote, Torsten is the head of ruote-kit... Thanks for all those pointers
> !
Just to chime in - I'm (obviously) very interested in seeing ruote-amqp
maintained and developed as ruote develops further. I see it as a key mechanism
to allow ruote to present a consistent interface into multiple other systems.
So, whilst I'm not the maintainer, I will say that if people see issues with
ruote-amqp and write to the ml, then please feel free to cc me on them if you
want to ensure they grab my attention (or grab me on irc in #ruote). I'll do
what I can to help.
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
John Mettraux
On Sat, Sep 25, 2010 at 03:49:42PM +0100, David Greaves wrote:
>
> So, whilst I'm not the maintainer, I will say that if people see
> issues with ruote-amqp and write to the ml, then please feel free to
> cc me on them if you want to ensure they grab my attention (or grab
> me on irc in #ruote). I'll do what I can to help.
David is /^lbt_?$/ on #ruote.
Cheers,
Hartog C. de Mik
Good point! Fixed that.
> - The error_logger participant isn't really necessary, if a process gets into an error, the process is still queryable :
>
> errs = engine.errors
> if errs.size > 0
> puts "there are processes with errors :"
> errs.each do |err|
> puts "process #{err.wfid}"
> end
> end
Ah, that's usefull. Refactored.
> - It would be more DRY to reduce the ping and the pong components to
> one component that you instantiate two times (ping and pong)
Yes, it would be more dry, but I did this willingly and knowingly; The
intent of the example is not be DRY, but to be examplatory. And having
2 seperate daemon-kit participants is (imho) more informative then
having one which can do both.
> - The process definition could be a bit simpler, there is one point
> with which I was not really following the original ruote-amqp
> author, but I'd prefer avoiding putting AMQP configuration details
> in a process definition. It's better to pass that configuration when
> registering the participants or via process variables. You are
> elegantly hiding that in two (ping and pong) subprocesses, but I'd
> really love people not to have to do that.
I will fix this soon; I must first figure what happens when moving
around these options. I fully agree that all these options should not
be in the process definition; that should be kept as clean of
'configuration' as possible and easily be editable by the
BPM-consultant-three-doors-down.
> - It would be nice to have an orientation in the README.rdoc that
> indicates where is what.
Fixed that.
A lot cleaner than mine :-)
Will be pushing my updates to github shortly.
Grtz,
Hartog.
Asier
>
> On Sat, Sep 25, 2010 at 03:49:42PM +0100, David Greaves wrote:
>>
>> So, whilst I'm not the maintainer, I will say that if people see
>> issues with ruote-amqp and write to the ml, then please feel free to
>> cc me on them if you want to ensure they grab my attention (or grab
>> me on irc in #ruote). I'll do what I can to help.
>
> David is /^lbt_?$/ on #ruote.
Oh my... that name looks perl code! :-D
Regards
Asier
ruote-amqp plus ruote-kit is the key for people like me with an environment
different different from Ruby. In my case, Java (JRuby)
It's a bit tricky to have ruote-amqp running. I remember that the main problem
using JRuby was that only eventmachine 0.12.6 (ruote-amqp depends on amqp,
which depends on eventmachine) worked well with JRuby and believe me, I spent
some hours to discover it.
Regards
John Mettraux
On Sat, Sep 25, 2010 at 06:14:30PM +0000, Hartog C. de Mik wrote:
>
> Will be pushing my updates to github shortly.
Hello Hartog,
nice blog post !
http://simplic.it/blog/view/an_investigiation_into_ruote_and_amqp
There seems to be some confusion about :on_error, if you wire it to the subprocess "shout", the error will never appear in the error journal, the process will shout and happily terminate.
I've made sure to tighten the documentation about that aspect :
http://ruote.rubyforge.org/common_attributes.html#on_error
Many thanks,