Workflow Business Process Management systems and rules engines go hand in hand. A process definition language (such as XPDL, Colored Petri Nets, Pi-Workflow or jPDL) is used to describe a process at a relatively coarse level of abstraction. Rules are then used to implement decisions based upon the context of the workflow, for example to determine who should work on an item, who should be notified when an activity completes, or what to do when an activity has stalled.
The current "modus operandi" for the rule industry is a focus on stateless decision services, where the separate workflow engine at some point calls out to the separate stateless rule engine to assist in some decision making - after 30 years of research and development is that the best we have to offer, multi-million pound license deals that effectively boil down to glorified spreadsheets called via a stateless web services from some workflow engine. Not to mock this model, as it is actually quite useful, but this level of integration is superficial at most and we need to make sure that we unify these models and allow it to go to much greater depths.
The article builds on a previous paper published by the jBPM team on what was dubbed the "Process Virtual Machine" (PVM). In a nutshell, PVM is to workflow what bytecode is to Java - a process execution engine that is independent of the process definition language. Kris explains that PVM+ integrates rules engine constructs with the process execution environment offering several advantages:
- Rules can be modeled in the process definition.
- Data (including structure definitions) can be shared between rules and processes.
- Unified auditing.
- Simplified administrative functions.
- The ability for rules and process instances operating in parallel to react to changes via shared contexts.
PVM+ serves as a substrate for process centric DSLs. Kris lists the existing jBPM language jPDL, as well as the recently introduced PageFlow (workflow language for specifying the control flow in web pages) and RuleFlow (a workflow language for specifying the order in which large rule sets should be evaluated), as example implementation languages.
Drools 4.0 ruleflow diagram
Kris discusses the role of "work items handlers", which are responsible for execution of process instances. Of particular interest is the idea of having different handlers depending on the context. This could be used to overcome one of the longer standing criticisms of rules and workflow based development - testing:
A workflow can behave differently depending on its stage in the life cycle. For example, for testing, handlers that do not actually do anything but simply test the execution of the workflow could be registered. For simulation, some visualization of the work items that should be executed, and the possibility for the person doing the simulation to complete/abort these work items is possible.
