9. ruby
• ruby is slow
• yes, but development time is shorter
• yes, but hardware gets faster
• yes, but interpreters get stronger and
faster
10. workflow
• ruote is a workflow engine
• incidentally BPM, BPM the discipline
• do you have the discipline to integrate
such a tool ? (usage cost)
• do you have the discipline to avoid
such a tool ? (non-usage cost)
11. ruby and workflow
• ruby is well-known,
because of Ruby on Rails
• rails people are able to build web
application very quickly
• “workflow” for them is spelled
“act_as_state_machine”
12. act_as_a_state_machine
• ruby on rails plugin
• attach states (and transitions) to rails
entities
• virtual entities representing
business processes
• still 1 web application
• ruote : target is ruby, not just rails
13. ruby and workflow
my endeavour :
• bring a workflow engine to ruby
or
• leverage ruby to write a
better workflow engine
?
14. ruby
• ruby is one of the fastest language
(shortest development time)
• less code to write
• less code to maintain
15. ruby people
• lots of ex-{PHP|Perl|Java} people
• different perspective
(enterprise wide vs web wide)
• true community (not big guns driven)
• ruby people seem to be
going in the right direction (trust)
16. workflow engine
• process definition interpreter
• process definition language ?
• many grails
17. many grails
• visual grail
• “no code” / no programming grail
• standard grail
• (formal grail)
18. visual and standard
• in 2001-2002,
there were XPDL and BPML
• visual is hard, lots of noise info
• trying to come up with a language
19. “no code” grail
• defining a process is not
programming
• redacting a mission statement is not
programming
• specifying a series of task to be
executed by a machine is not
programming
20. programming
• I firmly believe that defining a process is
programming (modeling)
• I firmly believe that issues raised by
process execution are better solved by
people with an understanding of
programming and systems (managing)
• no coder and no admin ?
21. programming
business processes
• building abstractions / raising the
abstraction level
• provide a language
• a process definition language
22. language
• a language and its interpreter
• 4 main constructs
• process-definition
• participant
• sequence
• concurrence
23.
24. language
• conciseness
(process def vs context)
• no “box and arrow position” noise
• graphical representation can be
derived from such a language
• XML parsers were/are available
25. requirements
• the workflow control patterns
• directly and indirectly
• community
• feedback and requests
26.
27. participants
• workflow resource patterns
• orchestrating :
• BPEL and web services
• ruote and ‘participants’
• participants usually change less often
than processes
• users, roles, systems, services, ...
28. workitems
• issuing workitems to participants
• serializable as JSON / XML / YAML
• payload : reference is better than raw
content
• apply / reply workitems as well
33. formats
• so you have XML, Ruby and this online
tool
• it’s manipulating ASTs
• exp :=
[ exp_name, { attribute* },[ child_exp* ]]
34.
35.
36. languages, trees
• a tree at the heart
• direct interpretation, no compilation
(not so low level interpretation)
• (-) slower
• (+) graspable,
directly modifiable (in-flight)
• (+) easy to add new expressions
37. expressions
• ruote is a very patient (long running)
interpreter
• interprets trees of expressions
• expressions come in two flavour :
raw / applied
• they reply to 3 messages :
apply / reply / cancel
38. a
process-
definition b
0
c
sequence
g participant
0.0
d 0.0.0
quot;alphaquot;
alpha
e
f
apply
participant
0.0.1 quot;bravoquot;
reply
bravo
39. ruote
• simplistic / naive
• that’s a strength when things go wrong
(it should not play tricks on you)
• ...
