Unifying Processes And Rules

In "A Vision for Unified Rules and Processes", Mark Proctor, lead of the Drools rules engine describes how he sees the further integration between rules and processes.

I believe that any company that isn't able to truly unify rules and processes into a single modelling system, how PegaSystems have done, will not be in a suitable position for the future. ... rules and processes must exist as first class citizens within the modelling and execution environment ... we need to make sure that we unify these models and allow it to go to much greater depths. Once rules and processes are fully integrated that modelling environment will benefit from any other declarative systems added, such as our plans to add Complex Event Processing (CEP) to the engine and language - this means we can have rules monitoring streams of data and triggering process milestones.

From a product point of view, I totally agree with Mark. In fact, I met him last week and I was impressed with the productization ideas they had for creating in integrated processes and rules environment.

For instance the Business Rules Management System (BRMS) manages the full lifecycle of rules from sources, over packaging to runtime deployment. The model and tooling that they have layed out would fit perfectly with jPDL processes. Futhermore, it supports both the developer use cases as well as the business user use cases. The drools vision in that respect is fully applicable to jPDL processes.

Similar for the business user test scenarios. Drools has a web UI for creating test scenarios on a business level. While this will not replace software testing based on something like JUnit, it does allow for business users to express basic scenarios. For non complex processes, this vision is also applicable to jPDL processes.

So if you look at it from a product point of view, we agree. The way I see this unification is a drools-jPDL integration is a single download that just can be unzipped to be installed. Integrated BRMS, console and designer. Drools has this approach and jPDL has the same appraoch with the suite distribution package.

But I see the componentization underneath the product quite differently. First of all I think that ruleflow should be merged with jPDL. They fit together and complement each other perfectly. I don't think that ruleflow should be a separate language from jPDL. Ruleflow could be build as a set of nodes build on top of the PVM. These nodes could be added to jPDL. Whenever you use them, you get a dependency on the drools.jar. This is just like with e.g. the beanshell based script node that we have now in jPDL.

Secondly, I don't think we need to integrate jar packages. IMO, "truly unify rules and processes" as Mark Proctor refers to, should be in the productized package that integrates jPDL (incl ruleflow) and drools. There is no need for the jars to merge in order to realize the vision as Mark Proctor describes it.