towards ruote 2.0

Post on 01-Nov-2014

9.127 Views

Category:

Technology

3 Downloads

Preview:

Click to see full reader

DESCRIPTION

Initial presentation of Ruote 2.0. Those slides were presented by Nando Sola during the first "Ruedas y Cerverzas" meeting in Abstra.cc Madrid office on 2009-10-08. The first part enumerates reasons for the move to 2.0 while the second details the enhancement made to the ruote process definition language.

TRANSCRIPT

ruote 2.0

2009/10/07

warning :

these slides pre-suppose you have some familiarity

with ruote (0.9.x)

‣ 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

agenda

agenda

ruote 2.0 engine

‣ ruote engine : historically‣ middleware/backend-ish‣ not for your big front web 2.0 app‣ cheap workflow engine‣ 1 engine per business unit

‣ 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

‣ ruote 2.0 engine‣ multi ruby process resilient :(‣ complete rewrite

with a cleaner interface

‣ 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...

‣ 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)

‣ 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

‣ 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 ?

‣ 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)

cleaner interface

cleaner interface

ruote 2.0 process definitions

‣ AST is JSON friendly‣ attributes common to all expressions‣ :if / :unless‣ :timeout, :on_timeout‣ :on_cancel / :on_error‣ :forget

‣ directed commands‣ break :ref => ‘tag’

‣ jump :to => ‘tag’‣ concurrent_iterator enhancements‣ subprocesses and apply‣ ...

AST is JSON friendly

XML is still here

‣ common attributes‣ can be given to any expression

:if / :unless

:timeout

:on_timeout

‣ :on_error‣ much like begin / rescue...‣ occurs when error is triggered‣ error is thus not logged in

error_journal

:on_error

:on_error

‣ :on_cancel‣ subprocess or participant

triggered when expression gets cancelled

‣ unlike :on_errortrigger happens when cancel is complete

:on_cancel

:forget

‣ cursor / jump‣ can now jump to

a tag, a participant name ora subprocess name

‣ almost that‘cursors as state machines’feeling

‣ works with repeat (loop)as well

cursor / jump

‣ 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

rewind :ref => ‘tag’

skip :ref => ‘tag’

‣ concurrent_iterator‣ :times / :branches‣ add_branches partner expression

concurrent_iterator

concurrent_iterator

‣ ruote 0.9.x had the ‘eval’ expression‣ evaluating segments of process

‣ ruote 2.0 has ‘apply’‣ same mission‣ and more (yield)

vanilla apply

yield like apply

set ‘v:x’ => ‘y’

‣ 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)

engine vars

engine vars

‣ more aboutprocess definitions and expressions

http://ruote.rubyforge.org/expressions.html

http://ruote.rubyforge.org/patterns.html

2.0 projects

‣ ruote-dmdatamapper persistence

http://github.com/jmettraux/ruote-dm

‣ ruote-aractiverecord persistence

http://github.com/kennethkalmer/ruote-activerecord

‣ ruote-couch (coming soon)couchdb persistence

http://github.com/kennethkalmer/ruote-couch

‣ ruote-kitfull blown ruote-rest evolution

http://github.com/kennethkalmer/ruote-kit

‣ ruote-httptiny sinatra ruote webservice

http://github.com/jmettraux/ruote-http

‣ ruote-amqpamqp participants and listeners

http://github.com/kennethkalmer/ruote-amqp

‣ ruote-fluostill in the run

http://github.com/jmettraux/ruote-fluo

‣ ruote [2.0] website

http://ruote.rubyforge.org

‣ ruote mailing list

http://groups.google.com/group/openwferu-users

‣ freenode.net IRC

#ruote

many thanksto everyone in the communityespecially to the “ruedas y cervezas” participants ;-)

top related