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.

Process Aware Information Systems

During my summer vacation, I started reading the Book "Process Aware Information Systems". The book caught my eye as I was passing a shelf in the library. After reading the preface I decided to have a better look.



The first section gives an overview of PAIS(Process Aware Information Systems) which includes a nice classification of PAIS and the rationale behind it, adding a little bit of history along with techniques and tools too.
Then the book discusses concepts of Workflow Management and modelling, person to person interactions, business to business integration etc.
The section two of the book is more like a reference. That includes UML modelling, petri nets, and event driven process chains. But hard to read continuously though.
The last section discusses more practical methodologies and standards such as XPDL and BPEL. For those who are interested in web services business processes like my self, this is again a good reference. But before reading this section its better to have look at those specifications first and may be started with "Introduction to XYZ..." kind of an article.

BPEL from CDL

WS-CDL and WS-BPEL both provide a way to describe how web services should collaborate. But the difference is that WS-CDL gives a global perspective the message exchange whilst the WS-BPEL provides a single participant's perspective.
As some are arguing I do not see a competition between these two specifications. Rather they must co-exist to describe services interactions properly.
Though, WS_CDL is designed to be used in conjunction with the WS-BPEL, one limitation of the WS-CDL specification is that a clear mapping with BPEL is missing. I agree that the intention of WS-CDL is not to be depend on WS=BPEL but there are advantages of having such a clear mapping.

1. Choreographies can be defined in WS-CDL first by business partners and then generate BPEL process stubs for each party
   
2. A party who’s having an internal business processes may need to publish the interface to its processes to attract business partners by generating the choreography. This could be done using a BPEL to CDL mapping.
   

From the engineering perspective such a mapping could be automated. Also such a defined approach would minimize the inconsistent mappings by different parties coming in to collaboration.
This paper presents how BPEL process definitions are derived from the global WS-CDL model. Authors have done this by defining a set of transformation rules.
For example

1. Each party participated in CDL choreography a separate BPEL stub is generated
   
2. One cdl:relationshipType maps to one bpel:partnerLinkType and the bpel:role with its bpel:portType is generated from the referenced cdl:roleType declaration
   
3. Generate separate property files for each cdl:roleType including only those bpel:properties that are relevant for a party.
   
4. BPEL basic activities are directly mapped to CDL basic activities
   
5. Work units in CDL are related to scopes in BPEL
   

The complete mapping is available in the section 5.
The paper addresses a much required issue by not altering the existing standards or without introducing new standard, which is a plus point. The approach seems straightforward and not requiring intermediated mapping like in the approach here[4] where the mapping is into Communicating Sequential Processes. Also authors have implemented a prototype of the mapping as a proof of concepts.
Saying that, one limitation of the paper is that there is no reference on how to verify the generated BPEL stubs over the original CDL. Generated stubs may be correct for the given example or could be verified manually for simple scenarios. But it is required to have a formal mechanism to verify more complex scenarios. That is not in future work section too. And the verification need to be integrated to the BPEL stub generation or it should be done after generating BPEL stubs but before the populating them with application logic.
Also it is not clear how the mapping from BPEL processes to CDL is done. Which also an interesting issue (as far as ROAD is concerned ). May be we might be able to complete that part. We can map several processes to a common choreography by projecting them over a ROAD Self Managed Composite. In other words by overlapping several processes we might be able to define the choreography. Syntactical transformations might use the same discussed in the paper. Sure need to think and discuss more about that.

Adaptive web processes in a pervasive services oriented environment

Services Oriented Architecture provides different applications to interact in a distributed environment to perform a particular task. The concept of services orientation in software design aimed to achieve the loose coupling of applications from its underlying operating environment. Being a progression of component based software development, Services oriented computing provide interfaces to users (human or software) to utilize a particular resource in a distributed environment.
On the other hand the image of traditional computer is fading away. Mobile /embedded devices claim for a good portion of computing efforts today, with the advancement of electronic technologies. Our car, phone, watch or what ever a device that we can’t picture today, has started to or will become a computing device. This resulted in many researches on Pervasive Computing or Ubiquitous Computing.
The operating conditions in such a pervasive services oriented computing environment are always subjected to change. For example while you are travelling, you mobile phone in your pocket and the car you drive might be doing some message exchanges/queries with applications hosted in nearby restaurants, shops and motels. The operating conditions like the mobile coverage, network bandwidth, types of technologies and even the availability of services can be subjected to frequent changes. The life time of applications is determined by these varying factors of the environment. The survival is always critical. And this calls for self-adaptive software systems.
Studies about adaptable and adaptive software systems have emerged as a major research topic in the past few years. Survival in highly fluctuating environments is a critical requirement for future software systems. Concepts of self-healing, self-configuration, self-optimization and all other self-* buzzwords are popping up in pervasive services oriented software systems. Many frameworks, solutions, techniques are being introduced in the reason past.
It is interesting to study about how business processes adapts to these highly fluctuating environments. Current approaches like BPEL and WS-CDL does not address the adaptation. Although it is possible to identify sort of programmable adaptation, in above approaches, where pre-defined processes are carrying out according to limited "expected" changes, it is not the sort of adaptation that we would be looking for. It is required to define, change choreographies among different business partners at run time in order to ensure smooth continues business processes. Runtime negotiation and establishment/termination of contracts among participating entities are essential part of the adaptation.
My research would be concentrated finding techniques and designs for process adaptation in such a pervasive, services oriented computing environment. Yeah... A diverted lil bit from security:-). Though this is not a really hot topic, I belive that there are more yet to be investigated. Therefore in coming months I'd be concentrating on this.