Initial presentation of Ruote 2.0. The slides were presented by Nando Sola for the first "Ruedas y Cervezas" in Madrid 2009-10-08.
The first part enumerates technical issues ruote 2.0 wanted to solve while the second part is about enhancement to the process definition language itself.
3. ‣ recap : ruote
‣ is a ruby workflow engine
‣ ruby makes it easy to tinker and try
‣ workflows should be easy to tinker
and try
‣ with some discipline, you might
even end up doing BPM with it
8. ‣ ruote engine : historically
‣ middleware/backend-ish
‣ not for your big front web 2.0 app
‣ cheap workflow engine
‣ 1 engine per business unit
9. ‣ ruote engine : core requirements
‣ has to run multiple processes
‣ with multiple branches
‣ and/or subprocesses
‣ can be stopped / restarted
(if running with persistent storage)
‣ can run multiple versions of any
process
‣ has to allow in-flight modifications
to processes
10. ‣ ruote 2.0 engine
‣ multi ruby process resilient :(
‣ complete rewrite
with a cleaner interface
11. ‣ multi-process
‣ the average user wants to put ruote
in his rails app
‣ the rails app is
in a ‘multi-process’ ruby web server
‣ ruote 0.9 is
in trouble...
12. ‣ multi-process resilience
‣ ruote 2.0 knows it could run in a
multi-process env
‣ it has defense mechanisms
things like ‘tickets’ and ‘locks’
‣ they have a cost :-(
‣ suggestions
‣ avoid mp envs for ruote
(the engine is idle most of the time)
‣ run ruote as a webservice
in a 1p env
‣ (ruote in 1p can use “caching”
and be faster)
13. ‣ our favourite env these days
‣ ruote-{kit|http}
workflow as an http service
‣ ruote-amqp
‣ remote participants
as amqp (daemons)
http://github.com/kennethkalmer/daemon-kit
‣ load on ruote itself is low
14. ‣ anyway...
‣ 1 engine that scale
for everything ?
‣ why not 1 engine
per domain / unit ?
‣ why not a separation between
tactical and technical engines ?
‣ why not engines that talk to each
other ?
‣ scale the business
or scale the tools ?
15. ‣ engine workqueue
‣ where each operation is performed
‣ only 1 op at a time
‣ by default, uses Thread/Queue
‣ uses EventMachine if present
‣ future work :
‣ fibers ?
‣ it’s an implementation away
‣ anyway, engine is idle most of the
time (usually waiting for those slow
humans)
33. ‣ cursor / jump
‣ can now jump to
a tag,
a participant name or
a subprocess name
‣ almost that
‘cursors as state machines’
feeling
‣ works with repeat (loop)
as well
35. ‣ directed commands
‣ cursor/repeat has
jump/rewind/break/... commands
‣ until now these commands were
only meant for the enclosing cursor/
repeat
‣ now with :tag and :ref,
more precision is possible
‣ works with the iterator expression
as well
45. ‣ engine variables
‣ can be read from processes
‣ cannot be set from processes
‣ are thus on the same foot as
participants
(which are registered at the engine
level)
53. ‣ ruote-amqp
amqp participants and listeners
http://github.com/kennethkalmer/ruote-amqp
‣ ruote-fluo
still in the run
http://github.com/jmettraux/ruote-fluo