ruote stockholm 2008

1,971 views

Published on

Published in: Technology
  • Be the first to comment

ruote stockholm 2008

  1. 1. Stockholm University - 2008/10/08
  2. 2. ruote
  3. 3. ruote • open source project • “ruote” is a nickname • formal name is “openwferu” http://openwferu.rubyforge.org
  4. 4. ja to ru • OpenWFE project started in late 2001 • became OpenWFEru late 2006 • java to python ruby • nicknamed Ruote (keep the ru)
  5. 5. sub-projects • ruote • ruote-fluo • ruote-web & ruote-rest
  6. 6. sub-projects • ruote : as a ruby project • ruote-fluo : how ruote sees processes • ruote-web & ruote-rest : ruote + web
  7. 7. ruote
  8. 8. ruote • open source • ruby • workflow engine
  9. 9. ruby • ruby is slow • yes, but development time is shorter • yes, but hardware gets faster • yes, but interpreters get stronger and faster
  10. 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. 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. 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. 13. ruby and workflow my endeavour : • bring a workflow engine to ruby or • leverage ruby to write a better workflow engine ?
  14. 14. ruby • ruby is one of the fastest language (shortest development time) • less code to write • less code to maintain
  15. 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. 16. workflow engine • process definition interpreter • process definition language ? • many grails
  17. 17. many grails • visual grail • “no code” / no programming grail • standard grail • (formal grail)
  18. 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. 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. 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. 21. programming business processes • building abstractions / raising the abstraction level • provide a language • a process definition language
  22. 22. language • a language and its interpreter • 4 main constructs • process-definition • participant • sequence • concurrence
  23. 23. 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
  24. 24. requirements • the workflow control patterns • directly and indirectly • community • feedback and requests
  25. 25. participants • workflow resource patterns • orchestrating : • BPEL and web services • ruote and ‘participants’ • participants usually change less often than processes • users, roles, systems, services, ...
  26. 26. workitems • issuing workitems to participants • serializable as JSON / XML / YAML • payload : reference is better than raw content • apply / reply workitems as well
  27. 27. ruote-fluo
  28. 28. ruote-fluo • is a javascript library • fluo-can : renders process definitions graphically • fluo-tred : online process definition edition
  29. 29. fluo-can
  30. 30. fluo-tred
  31. 31. formats • so you have XML, Ruby and this online tool • it’s manipulating ASTs • exp := [ exp_name, { attribute* },[ child_exp* ]]
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. ruote • simplistic / naive • that’s a strength when things go wrong (it should not play tricks on you) • ...
  36. 36. ruote & web
  37. 37. ruote & web • a process definition is a document • a document, a URI
  38. 38. ruote & web • workflow things as web resources • processes / errors / workitems • launch : POST /processes • cancel : DELETE /processes/3425ba2
  39. 39. ruote-rest • trying to be RESTful • trying to stick to web standards • trying hard for connectedness
  40. 40. web standards • HTTP • XML, JSON • Atom, RSS • AtomPub (content oriented maybe) • iCal, ...
  41. 41. ruote-rest • process server • embedded vs external • state machine vs process server
  42. 42. next spins
  43. 43. next • better ruote-web2 (2008/11) • more in-flight edition • better migrations / batch migrations • more documentation • more...

×