Drools 5.0 and business process modeling flexibility

The rules and workflows are considered to be two different paradigms for business process modeling[1]. Although there are some approaches[2, 3] that attempted combine the advantages of both rule driven and workflow driven business process modeling, the Drools 5.0 combined the advantage of both paradigms as a commercial product.

Earlier the drools modeling considered rules (conditions and actions) as first class citizens. The drools engine allows rules to be specified using the drools language or in xml to be interpreted by the rule processor. This is now provided as the Drools Expert. The java program that integrates the rules engine can pass java objects as facts in to the engine to be evaluated against a rule, or a group of rules. But now with the Drools Flow[4], the processes (better say workflows) are too considered as first class citizens (entities). Also earlier there is no notion of events. The events, such as exceptions, alerts should be handled by the (Java) program. Upon an event the program fires rules. But now with the Drools Fusion [5]the events too are considered first class entities that can be modeled along with processes and the rules. (Here I use the same terminology in the drools documentation. However it should be noted that their use of processes are very similar to the meaning of workflow in other literature. Also when they refer rules it seems they refer to a combination of event and actions). Apart from the above Drools-Govnor allow the users (especially the non-technical lot) to manage the rules using a web interface.

I see following main advantages of this development in drools with Drools Flow and Drools Fusion.

Now it is possible to implement the business logic without being restricted to rule-centric or process-centric modeling approach. Therefore from the design point of view the users can practice the best applicable approach to design different parts of the business logic. Because a flexible process modeling approach will be ended up somewhere in between these two paradigms.

Form the implementation point of view, now the developers have a common API to work with. Earlier the business processes have to be implemented using a different API while rules are specified using Drools (Now Drools Expert). That brought many limitations. For example it wasn’t possible to take decisions in a business process based on an outcome of a rule evaluation. There has to have an intermediary layer to bridge the gap. But now the rules can be used to take decisions on business processes and even assigning the actors to human tasks.

Also, the ability to model complex events using Drools Fusion is a great advancement compared to the earlier versions. In earlier the event handling is done by the java program and which eventually fires a set of rules. However now it is possible to do temporal reasoning of different events (e.g. E1 before E2), use sliding windows both time (e.g. items of last 10 minutes) and length based (e.g. last 10 items) etc.

Moreover the processes, events and rules (Condition, Actions) are all now part of one knowledge base. Thus it is easy to manage the state, share context of a particular process instance. Consequently the process instances can deviate from the pre-defined execution path, for example to handle an exception.
link

1.R. Lu and S. Sadiq, “A Survey of Comparative Business Process Modeling Approaches,” Business Information Systems, 2007, pp. 82-94.
2.A. Charfi and M. Mezini, “Hybrid web service composition: business processes meet business rules,” Proc. Proceedings of the 2nd international conference on Service oriented computing, ACM, 2004.
3.T. Graml, R. Bracht and M. Spies, “Patterns of business rules to enable agile business processes,” Enterprise Distributed Object Computing Conference, vol. 2, no. 4, 2008, pp. 385-402; DOI http://dx.doi.org/10.1080/17517570802245441.
4. “Drools Flow,” http://jboss.org/drools/drools-flow.html.
5. “Drools Fusion,” http://jboss.org/drools/drools-fusion.html.