I’m biased as well, as I am the main author of StonePath.
I have developed workflow applications for the U.S. State Department, the Geneva Centre for Humanitarian Demining, several fortune 500 clients, and most recently the Washington DC Public School System. Every time I have seen a ‘workflow engine’ that tried to be the one master reference for business processes, I have seen an organization fighting itself to work around the tool. This may be due to the fact that these solutions have always been vendor/product driven, and then end up with a tactical team of ‘consultants’ constantly feeding the app… but because of this, I tend to react negatively when I hear the benefits of process-based tools that promise to ‘centralize the workflow definitions in one place and make them repeatable’.
I very much like Ruote – I have been following that project for some time and should I need that kind of solution, it will be the next tool I’ll be willing to try. StonePath has a very different purpose than ruote
-
Ruote is useful to Ruby in general,
-
StonePath is aimed at Rails, the web framework written in Ruby.
-
Ruote is about long-lived business processes and their associated definitions (Note – active development on
ruoteceased). -
StonePath is about managing State-based workflow and tasking.
Frankly, I think the distinction from the outside looking in might be subtle – many times the same kinds of business processes can be represented either way – the state-and-task-based model tends to map to my mental model though.
Let me describe the highlights of a state-based workflow.
States
Imagine a workflow revolving around the processing of something like a mortgage loan or a passport renewal. As the document moves ‘around the office’, it travels from state to state.
If you are responsible for the document, and your boss asked you for a status update you’d say things like
- “It is in data entry”…
- “We are checking the applicant’s credentials now”…
- “we are awaiting quality review”…
- “We are done”… and so on.
These are the states in a state-based workflow. We move from state to state via transitions – like “approve”, “apply”, kickback”, “deny”, and so on. These tend to be action verbs. Things like this are modeled all the time in software as a state machine.
Tasks
The next part of a state/task-based workflow is the creation of tasks.
A Task is a unit of work, typically with a due date and handling instructions, that connects a work item (the loan application or passport renewal, for instance), to a users “in box”.
- Tasks can happen in parallel with each other or sequentially
- Tasks can be created automatically when we enter states,
- Create tasks manually as people realize work needs to get done
- Require tasks to be completed before we can move onto a new state.
This kind of behavior is optional, and part of the workflow definition.
The rabbit hole can go a lot deeper than this, and I wrote an article about it for Issue #4 of PragPub, the Pragmatic Programmer’s Magazine. Check out the repo link above for an updated PDF of that article.
In working with StonePath the last few months, I have found that the state-based model maps really well to restful web architectures – in particular, the tasks and state transitions map nicely as nested resources. Expect to see future writing from me on this subject.