Back

TechnologyFeb 27, 2014

Using Drools Expert with Apache Camel: Part 1- Get Ready to Drool

Justin Wilson

This is part one of a three-part series on using Drools Expert with Apache Camel. Today’s topic provides a basic overview of Drools Expert. Part two will cover Apache Camel, and part three will contain a working example.

What is Drools Expert?

Drools Expert is a “rules engine” that excels at abstracting complex decision logic away from hardcoded Java into external Drools Rule Language (DRL) files. These files are written in a Domain Specific Language (DSL) that can be more readily read and modified by non-technical domain experts than Java code. These files can serve as a source of executable documentation with visual editor support.

A sample DRL file with a single rule has been provided below. Note that its syntax is a combination of custom notation designed to simplify conditional statements and Java code.

Code sample from can-drink-rule.drl

Sets of DRL files are more resilient to constant change than modifying code directly. Thus, code that is meant to satisfy constantly changing requirements, which would normally be implemented with an abundance of if statements or switch cases, is a prime candidate for abstraction into a rules engine.

Basic Components

Drools Expert functions by passing a group of “facts” through a series of “rules” which modify the incoming facts. Rules are grouped into entities called “knowledge sessions” that serve as fact processing units. Knowledge sessions, facts, and rules are the basic building blocks of Drools Expert.

  • A forward-chaining “knowledge session” consists of a series of rules read from one or more DRL files. Utility POJOs called “global variables” can be passed into the session for rules to utilize.

  • A fact is a POJO that will be inspected and possibly modified by each of the rules in the knowledge session. In the example DRL file above, a “Person” POJO passed into the knowledge session would be a fact.

  • A rule is a conditional statement that is applied to all incoming facts, along with a resulting Java snippet that is executed when the condition is met. The DRL file above details the rule’s condition using intuitive Drools-specific syntax, with Java code between the “then” and “end” labels for result calculations.

Knowledge sessions can also be configured to retain or discard information about previously processed sets of facts.

  • Stateful knowledge sessions can modify variables that are maintained within the session that can affect future decisions.

  • Stateless knowledge sessions are cleaned after each use, ensuring that any given set of facts will always be evaluated in the same way each time they’re inserted.

The rules are the business logic that’s been abstracted away from Java code (e.g., if statements), and the facts are the data that the conditions are being applied to. The result of a knowledge session firing all of its rules a given set of facts is a set of objects that results from the aggregation of each triggered rule (which is usually a modification of the incoming facts). In the DRL example above, all “Person” facts that satisfy the rule’s condition will be modified to have their “can drink” property set to true.

Drools’ Niche

Abstracting constantly changing complex conditional logic can be potentially useful within any Java application, but it is especially applicable to serving as the implementation behind complex decision nodes on ESBs or BPM solutions. Specifically, Drools Expert can serve as the implementation for a stateless Content Based Router Enterprise Integration Pattern (EIP) or a stateful Dynamic Router EIP.  Since Drools can be executed from arbitrary Java, any BPM or ESB solution can integrate it to fill this niche. Due to Drools’ popularity, some ESB and BPM solutions have Drools Expert compatibility built in. The next entries in this series will cover using Drools as a Content Based Router in an Apache Camel route with working code samples.

If you have any questions over this introduction to Drools Expert, please to use the comments section below or contact us at info@credera.com. Be sure to stay tuned for the next part of this series by following us on Twitter at @CrederaOpen or connecting with us on LinkedIn.