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.

Workflow management systems. A liability or an asset?

Today more workflow systems appear to assist the business process management. The usual procedure is to draw a business process as a workflow diagram using a notation such as BPMN which will be converted to a code or more preferably to a process execution language script such as WS-BPEL (aka BPEL4WS).

This works fine until there is a requirement for a change in the process flow. The change can be a permanent one or it can be an ad-hoc one that caters for an exceptional situation. In the first case the process definition is changed which is known as an evolutionary change/adaptation. Where all the future instances of the process definition adhere to the new one. In the case of ad-hoc change only a particular process instance is changed which is known as momentary change thus would not affect the future instantiations.

One solution for this is to include all the possibilities into the process definition. For example BPEL switch statement. But some run time changes cannot be predicted during the design time. And even it could, the plethora of possibilities can make the design a very messy and complicated one.

Thus a running business implementation may have a business process but the frequent ad-hoc change might make it a liability than an asset. Making the stakeholders to by-pass the workflow definition rather than adhering to it. Thus it is required to find more flexible ways to design business processes that facilitate the frequent adaptation or change.

This will be my first post on this and will be followed by a series of discussion that will discuss the possible strategies to face the above challenge.