Notes from this Post on the Serverside
I recently wrote an O’Reilly article on one of the related JBoss projects the Drools / JBoss rules engine.
Just to get the difference between jBPM and Drools / JBoss Rules straight in my head:
– Workflow tends to be ‘wide’ where Rule Engines tend to be ‘deep’.
– Workflow is wide as the flow is spread over different people / actors and over time.
– Rule Engines are ‘deep’ as they apply simple rules to solve complex problems, but in general the rules are applied ‘all at once’.
Some of the confusion (in my head at least) comes from the fact:
– It is possible to implement workflow using a rules engine, much as it is possible to write your own workflow using Java. Of course , you don’t get the graphical designer that JBpm has.
– Both JBoss Rules (Drools) and JBoss Workflow (jBPM) see to
‘externalize’ part of the solution outside of Java. By stepping outside
of Java to use an XML / Graphical based approach, it makes the solution
easier to configure and understand.
imho, it is not really a matter of wide versus deep (although i understand with the methaphor).
a workflow engine (or Graph Oriented Programming in general) is about specifying a graph that represents an execution. The nodes can represent wait states.
a rules engine is about specifying a set of rules and then applying an inference algorithm for a given set of facts. So given a set of rules and a set of facts and an inference algorithm, there is one calculation that results from it. It’s a one shot calculation that possibly creates new facts or modifies the input facts. The rules are a form of if-then-else statements and the inference algorithm specifies how these rules will be applied at runtime.
One crucial difference between the workflow/BPM and rules is the fact that rules engines do not support wait states. And that is not necessary either because rules don’t specify any form of execution.
The overlap is to be found in state transitions in workflow/BPM engines. Processes in workflow or BPM can be considered as state machines. Then one state transition can related to one application of facts to a set of rules by a rules engine. For each state transition in a workflow/BPM process, you could think of a set of rules that will calculate the next state from a given state.
So in theory you could model all state transitions of a workflow/BPM process in terms of rules, but the wait states will remain the gaps. Those wait states are not representable in rules or facts.
Thanks for the comment. I’m still working my way through the JBoss jBPM documentation – so far the Eclipse editor for the graphical representation of workflow is very impressive.
I’m interested in the workflow for two reasons
1) I have a client who I think could benefit from a formal workflow framework (as opposed to a ‘build your own’ that turns into a homegrown framework). It’s just a case of convincing the business of the benefits, and deciding on the best workflow implementation for their needs.
2) I’m interested in easier / better ways of modelling business logic (hence the Drools / JBoss Rules . While I don’t think many Business clients will ‘dive in’ and start workflow modelling , it is much better to print the workflow picture and discuss at at meeting (that to take in Java Code!)
I also have a thesis coming up as part of this Masters in Software Engineering in UCD Dublin. I’m looking around for subjects, basically stuff that I can reuse again for O’Reilly articles / books etc (we keep copyright to anything we write for UCD), so any thoughts in this area would be good.