Drools Flow has been renamed to jBPM 5. Click here to go the jBPM website.

Rich Modelling Support
Rule Integration
Unified API and Tooling
Pluggable Work Items
Human Tasks
Guvnor Integration
Debugging
Correlated Auditing
Business Activity Monitoring
BPMN
Drools Flow and jBPM

Drools Flow provides workflow or (business) process capabilities to the Drools platform. A business process or workflow describes the order in which a series of steps need to be executed, using a flow chart. This makes it much easier to describe a complex composition of various tasks. Processes are especially useful in describing state-based, long-running processes. Drools Flow allows end users to specify, execute and monitor (a part of) their business logic using these processes. The Drools Flow process framework is easily embeddable into any Java application (as a simple Java component) or can run standalone in a server environment.

In the following sections, we will highlight the most important features of the Drools Flow framework.

Rich Modelling Support

Drools Flow provides the necessary building blocks that end users can simply drag and drop onto their canvas when constructing their business processes. This includes not only standard node types like start/end nodes or split/join nodes (for branching/synchronization), but more advanced node for incorporating wait states, timers, events, composite nodes, etc. Each of the different node types as shown below are explained in detail in the Drools Flow manual.

The underlying implementation is based on a generic process framework that support the execution of different process models on the same execution engine. This process model is based on a simple nodes, connections and context, that make it easy to include new node types into an existing process language, or support even completely different languages as a whole. The underlying framework provides generic solutions for non-functional concerns like persistence, transactions, events, etc. For example, we have already extended Drools Flow to support specific OSWorkflow nodes, to allow a simple migration path for existing OSWorkflow users to the Drools Flow process engine.

Rule Integration

Processes and rules are usually considered as two different paradigms when it comes to defining business logic. End users who are defining the business logic of their application usually don't want to be forced into one paradigm, but want to chose the most appropriate paradigm for each part of their logic. Loosely coupling a business process and a business rules engine (also known as “decision services”) might improve this situation in some cases (and are an excellent solution in certain use cases), but that approach does not allow advanced interaction between your processes and your rules, and puts the burden on integrating these products on the end user.

We believe that end users should be allowed to seamlessly combine processes and rules. This means for example that:

• rules can define which processes to invoke,

• (high-level, domain-specific) rules can specify decisions in that process

• rules can augment (or even override) the behaviour specified in the process (for example to handle exceptional cases)

• assignment rules can be used to assign actors to (human) tasks

• rules can be used to dynamically alter the behaviour of your process

• non-functional concerns can be removed from the process and modularized using rules

• etc.

As a result, your business processes become much more resilient to change.

Unified API and Tooling

Being able to integrate processes and rules in the runtime engine is however not enough. The learning curve of end users must be as low as possible. If processes and rules are treated as completely di?erent assets, then the user is responsible for learning, integrating and managing two di?erent products. We however believe in a knowledge-oriented approach, where the application is not process-oriented or rules-oriented, but the end users can simply select between di?erent paradigms to represent their business logic. All tools and interfaces the user is confronted with support this idea of a uni?ed environment throughout the entire knowledge life cycle.

For example, the following code snippet shows how adding a process or a rule to a knowledge base is completely the same:

Similarly, we provide a similar API to interact with the runtime engine, to listen to events generated by the engine, etc. Tools support all different types of knowledge (like processes, rules, decision tables, etc.) in a similar way.

Pluggable Work Items

While Drools Flow provides the necessary building blocks to combine tasks in various ways into a process, the tasks that need to be executed are usually domain-specific. Domain-specific languages are targeted to one particular application domain and therefore can offer constructs that are closely related to the problem the user is trying to solve. This makes the processes and easier to understand and self-documenting. Drools Flow allows end users to easily extend the palette of nodes with custom, domain-specific work items, like for example the figure shown below, that is using specialized nodes in a healthcare context to model nursing task, medication, notifications, etc.

And this example shows some file handling automation, that finds some files, logs and validates them before archiving, copying and emailing them.

These pluggable work items are:

• domain-specific

• declarative (what, not how)

• high-level (no code)

• customizable to the context (e.g. testing)

These work items make it very easy to integrate external services into your business processes in a very user-friendly manner. We currently provide default implementations for tasks like:

• sending email

• finding files

• FTP

• google calendar

• instant messaging

• REST services

• RSS feeds

• creating archives

• executing system commands

• transforming data

With the help of the community, we are hoping to extend this set of default supported services even further.

Human Task

An important aspect of business processes is human task management. While some of the work performed in a process can be executed automatically, some tasks need to be executed with the collaboration of human actors. Drools Flow supports the use of human tasks inside processes using a special human task node that will represent this interaction. This node allows process designers to define the type of task, the actor(s), the data associated with the task, etc.

Since this human task node is implemented as a pluggable work item (see above), users are able to integrate any human task management solution (back-end and/or user interface) they prefer. We do however provide a default implementation based on the WS-HumanTask specification. This specification describes the life cycle of the tasks and how to interact with the task management service (query tasks, change status, etc.).

Guvnor Integration

Drools Guvnor provides a (logically centralized) repository to store you business knowledge, and a web-based environment that allows business users to view and (within certain constraints) possibly update the business logic directly.

Processes can be uploaded to Guvnor and added to a knowledge package (in combination with other knowledge assets like rules, decision tables, etc.) either manually, or by using our Eclipse Guvnor tooling. This makes managing the business logic of your company (including history, versioning, dynamically updating the logic, etc.) much easier and accessible for business users as well.

Debugging

The Drools Eclipse IDE extends your normal Eclipse debugging experience with specialized views that show the currently running process instances and the state they are in. For example, the following screen shot shown a process where highlighted nodes are currently executing and waiting to be completed.

This makes it easy to find out what the state of your application is at any point during execution and to debug your processes in case you are seeing unexpected results. Note that the Drools IDE supports integrated debugging, meaning that you will always be able to see the state of both your processes and your rules simulateously.

Correlated Auditing

Drools Flow generates events during the execution of processes, which allows us to create an audit log containing the necessary information to figure out what is going on at runtime. This audit log can be a simple XML file (which can then be visualized in a tree-based manner in the Drools IDE as shown below), or stored in a database (for further processing).

More importantly, this auditing feature does not only provide information about the execution of your processes, but also about the rules in your application. End users do not have to try and manually correlate two different log files (one from the process engine and one from the rules engine) but can see one integrated audit log showing the events that happened during execution.

Business Activity Monitoring

You need to actively monitor your processes to make sure you can detect any anomalies and react to unexpected events as soon as possible. Business Activity Monitoring (BAM) is related to the real-time monitoring your processes and the possibility to intervene directly (possibly even automatically), based on the analysis of these events. Drools Flow allows users to define reports based on the events generated by the process engine, and possibly direct intervention in specific situations using event processing rules (Drools Fusion).

Based on the Eclipse BIRT plugin (Business Intelligence Reporting Tool), users can create reports that show the key performance indicators of their business. It's easy to define your own reports yourself, using the predefined data sets containing all process history information (based on a history logger that logs all runtime events in a database), and any other data sources you might want to add yourself. The Eclipse BIRT framework allows you to define data sets, create reports, include charts, preview your reports, export them on web pages, etc. The following screen shot shows a sample of such a chart.

BPMN

BPMN (Business Process Modeling Notation) is a popular workflow notation language used by business users for modeling business processes. BPMN defines terminology, different types of nodes, how these should be visualized, etc. People who are familiar with BPMN might find it easier to implement an executable process (possibly based on a BPMN process diagram) using a similar visualization. We have therefore created a BPMN skin that maps the Drools Flow concepts to the equivalent BPMN visualization.

Drools Flow and jBPM

Drools Flow is a community project. jBPM is still the only offical workflow product at JBoss. Drools Flow and jBPM are two separate projects. This is as a result of the need for process integration within the Drools knowledge-oriented platform (and advanced integration between processes and rules), which could not be provided by the jBPM project at that point. Both jBPM4 and Drools Flow are based on a (similar but independent) process framework with pluggable execution behaviour, what jBPM refers to as the PVM (Process Virtual Machine). However, until now, neither the jBPM or Drools team have been able to agree on a common way to move forward. We however do believe Drools Flow offers a set of features at least comparable with the jBPM project.

Drools 5 is a complete rethink (not reimplementation) from the bottum up, with a new public api and everything designed with rules, processes and events as first class citizens - no feature is added without making sure that is is seamless, unified and orthogonal. Because processes, rules and events are integrated into the same engine, all three paradigms can easily take advantage of the common features (when you add a feature to one paradigm it is accessible to the others as well). There is simply no reason for multiple apis and deployment approaches that at best only burden the user with more complexity and at worst introduce impedence mismatches when two differing projects are used together.

The traditional way of using two different offerings forces the user to work with a process-oriented or rules-oriented approach, which just gets in the way, often with great confusion over which tool they should be using to model which bits. Drools is a move away from a rule-centric or process-centric attitude to a more behaviour modelling approach with a lot more flexibability for users to model their problems how they want, creating a more holistic approach to software development (where the term holistic is used for emphasizing the importance of the whole and the interdependence of its parts).

We do not believe in the process-centric approach only, where rule integration or event processing integration are not being considered or will be added as an after-thought rather then a basic principle from the beginning. This usually means that rule integration is limited to a stateless rule session being invoked in a process node (with all the mapping, marshalling and unmarshalling and consistency problems as a result). Being process-oriented also forces the user to learn duplicate, but different, apis and deployments approaches, will not provide one tool chain for supporting the life cycle of the business knowledge (like for example a unified knowledge repository and mangement tool as Drools Guvnor, or provide important features such as correlated audit logging and reporting.

Based on these and other distinguishing features and with enough community adoption and demand, we however hope to have Drools Flow adopted as a JBoss product.