Building Enterprise Services with Drools Rule Engine

by Birali Hakizumwami
01/17/2007

Using a rule engine provides a framework that allows a way to externalize business logic in a common place. This will in turn empower business users and subject matter experts of the business to easily change and manage the rules. Coding such rules directly into the application makes application maintenance difficult and expensive because the rules change so often. This article goes into detail on how to architect and build a service that uses Drools to provide business decisions. This service can be part of the overall enterprise SOA infrastructure. As such, it can either be a standalone service that is consumed in a one-to-many model by all contracted consumers, or part of a composite service that provides a complex business functionality. To illustrate this point, the article shows how a service using the Drools rule engine can hide the complexity of automating mortgage underwriting decisions that a mortgage company needs to make on a daily basis.

A rule engine such as Drools offers matching algorithms that can determine which rules need to be run and in which order, and provide a means of addressing conflict resolution. It allows facts to be reassessed by rules as they are being evaluated, causing the consequence of one rule to affect the fact base, or causing other rules to fire or retract as needed. By using a rule engine, rapidly changing business policies/rules can be externalized so that they can be maintained separately in one place. The rest of the enterprise applications can access the functionality through a service layer with well-defined contracts. The behavior of the service can then be modified without changing the interface contract or needing to recompile/redeploy. Rules are stored in human-readable form in a file so they can be changed with a text editor or rule editor. Many leading industry analysts have concluded that it is significantly more productive to build and change complex, decision-intensive applications with rules-based systems than with custom code.

Drools Rule Engine

Drools is a JSR-94-compliant rule engine that uses Rete, a matching algorithm developed by Charles Forgy. In the simplest terms, Rete builds a tree from all the rules to form a state machine. It begins with facts entering the tree at the top-level nodes as parameters to the rules, and working their way down the tree--if they match the conditions--until they reach the leaf nodes (rule consequences).

For this article, we use the JBoss Rules Workbench IDE as a tool to write and test the rules. The JBoss Rules workbench is delivered as an Eclipse plugin, which allows you to author and manage rules from within Eclipse. This is an optional tool; any other tool can be used to author and deploy the rules, provided the appropriate Drools libraries are included. Detailed instructions on how to obtain and install this plugin can be found at the Drools documentation site.

The following is a short description of the main libraries that constitute the Drools rule engine:

• drools-core.jar: Contains the core engine, the runtime component that implements both RETE and LEAPS algorithms. This is the only runtime dependency that's needed if you are precompiling rules and deploying them via Package or RuleBase objects.
• drools-compiler.jar: Contains the compiler/builder components that take a rule source file and build executable rule bases. Like we mentioned previously, this .jar file is not needed if rules are precompiled. This .jar has a dependency on drools-core.
• drools-jsr94.jar: Contains a JSR-94-compliant implementation.
• drools-decisiontables.jar: Contains the decision tables compiler component. It has a dependency on the drools-compiler component. This supports both Excel and CSV input formats.

There are other dependencies that the above components require; for an exhaustive list please refer to the Drools documentation.

Mortgage Underwriting Service Using Drools

The following section goes into detail on how the Drools rule engine can be used to architect an automated mortgage underwriting service as part of an overall enterprise SOA initiative. Even though we are talking about mortgage underwriting as a case study, this discussion can be easily applied to any other business sector other than financial services (healthcare, telecommunications, etc.) that needs to externalize a set of business rules as a enterprise service.

The example has been kept simple for the sake of clarity and emphasis has been put on highlighting Drools rule engine features. Figure 1 shows a simple example of an underwriting engine architecture.

Figure 1. Underwriting engine architecture

The architecture describes three components:

• Loan Application System: Captures and stores all the data submitted in the loan application. This acts as a consumer of the Underwriting Service: it submits underwriting queries and processes the underwriting decision.
• Underwriting Service: Implemented as a callable service that can be either a web service or an API. This component calls the Drools rule engine APIs to execute and evaluate the underwriting rules and produce feedback messages and an overall underwriting status. The service also provides the capability to modify the rules easily.
• Support Services: These are services needed to populate some of the fields in the loan application, borrower information, and property information: credit scoring service, property valuation service, and affordability model service.

Pages: 1, 2, 3, 4, 5

Next Page