Towards ruote 2.0 (2009)

Slide 1

Slide 1 text

ruote 2.0 2009/10/07

Slide 2

Slide 2 text

warning : these slides pre-suppose you have some familiarity with ruote (0.9.x)

Slide 3

Slide 3 text

‣ recap : ruote ‣ is a ruby workﬂow engine ‣ ruby makes it easy to tinker and try ‣ workﬂows should be easy to tinker and try ‣ with some discipline, you might even end up doing BPM with it

Slide 4

Slide 4 text

agenda

Slide 5

Slide 5 text

agenda

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ruote 2.0 engine

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

‣ 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-ﬂight modiﬁcations to processes

Slide 10

Slide 10 text

‣ ruote 2.0 engine ‣ multi ruby process resilient :( ‣ complete rewrite with a cleaner interface

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

‣ our favourite env these days ‣ ruote-{kit|http} workﬂow as an http service ‣ ruote-amqp ‣ remote participants as amqp (daemons) http://github.com/kennethkalmer/daemon-kit ‣ load on ruote itself is low

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

‣ engine workqueue ‣ where each operation is performed ‣ only 1 op at a time ‣ by default, uses Thread/Queue ‣ uses EventMachine if present ‣ future work : ‣ ﬁbers ? ‣ it’s an implementation away ‣ anyway, engine is idle most of the time (usually waiting for those slow humans)

Slide 16

Slide 16 text

cleaner interface

Slide 17

Slide 17 text

cleaner interface

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

ruote 2.0 process deﬁnitions

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

AST is JSON friendly

Slide 22

Slide 22 text

XML is still here

Slide 23

Slide 23 text

‣ common attributes ‣ can be given to any expression

Slide 24

Slide 24 text

:if / :unless

Slide 25

Slide 25 text

:timeout

Slide 26

Slide 26 text

:on_timeout

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

:on_error

Slide 29

Slide 29 text

:on_error

Slide 30

Slide 30 text

‣ :on_cancel ‣ subprocess or participant triggered when expression gets cancelled ‣ unlike :on_error trigger happens when cancel is complete

Slide 31

Slide 31 text

:on_cancel

Slide 32

Slide 32 text

:forget

Slide 33

Slide 33 text

‣ 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

Slide 34

Slide 34 text

cursor / jump

Slide 35

Slide 35 text

‣ 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

Slide 36

Slide 36 text

rewind :ref => ‘tag’

Slide 37

Slide 37 text

skip :ref => ‘tag’

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

concurrent_iterator

Slide 40

Slide 40 text

concurrent_iterator

Slide 41

Slide 41 text

‣ ruote 0.9.x had the ‘eval’ expression ‣ evaluating segments of process ‣ ruote 2.0 has ‘apply’ ‣ same mission ‣ and more (yield)

Slide 42

Slide 42 text

vanilla apply

Slide 43

Slide 43 text

yield like apply

Slide 44

Slide 44 text

set ‘v:x’ => ‘y’

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

engine vars

Slide 47

Slide 47 text

engine vars

Slide 48

Slide 48 text

‣ more about process deﬁnitions and expressions http://ruote.rubyforge.org/expressions.html http://ruote.rubyforge.org/patterns.html

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

2.0 projects

Slide 51

Slide 51 text

‣ ruote-dm datamapper persistence http://github.com/jmettraux/ruote-dm ‣ ruote-ar activerecord persistence http://github.com/kennethkalmer/ruote-activerecord ‣ ruote-couch (coming soon) couchdb persistence http://github.com/kennethkalmer/ruote-couch

Slide 52

Slide 52 text

‣ ruote-kit full blown ruote-rest evolution http://github.com/kennethkalmer/ruote-kit ‣ ruote-http tiny sinatra ruote webservice http://github.com/jmettraux/ruote-http

Slide 53

Slide 53 text

‣ ruote-amqp amqp participants and listeners http://github.com/kennethkalmer/ruote-amqp ‣ ruote-ﬂuo still in the run http://github.com/jmettraux/ruote-ﬂuo

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

‣ ruote [2.0] website http://ruote.rubyforge.org ‣ ruote mailing list http://groups.google.com/group/openwferu-users ‣ freenode.net IRC #ruote

Slide 56

Slide 56 text

many thanks to everyone in the community especially to the “ruedas y cervezas” participants ;-)