A business rule is a statement or directive that defines, constrains, or controls some aspect of the business. It both asserts business structure and dictates business behavior.

The rules themselves are domain specific and range from the mundane to the exotic. Some examples include the following:

Let’s take a closer look at the structure of the common business rule.

Most business rules can be specified using a syntax that is familiar to all developers. The structure of the business rule is one of a condition, followed by an action to be acted upon if the condition is met. Thus, business rules can be defined in terms of an “if ... then ...” style of construct.

The previous examples can be rewritten using this syntax:

Though business rules have a simple structure, they are liable to change, making them dynamic in nature.

Companies today face relentless market competition, and consequently many organizations are finding that agility is an essential survival trait. An agile company is one that can respond quickly to changes in the marketplace by making changes to core policy, strategy, and operational procedures. As the business rules define all of these behaviors, the rules themselves cannot be static. Instead, such rules are dynamic by their very nature and must be maintained in a format whereby they can be readily changed.

Consider the example of the rule that specifies a discount is to be given to all customers paying their bills within 30 days. In this example, the company instigating the rule may wish to reward customers with air points with a nominated airline instead of a cash discount. Alternatively, the company may offer a 10% discount to all customers who pay their account using direct debit.

Business rules are a dynamic attribute of any enterprise system, yet traditional development methods hardcode business logic using general-purpose, third-generation languages, of which Java is an example.

This approach fails to meet the adaptive model businesses are demanding, because hard-coded rules are immutable, and changes can be effected only by rebuilding all or part of the system. Defining rules in this way does not reflect the dynamic nature of the rules themselves. Moreover, the use of a language like Java requires the services of a software engineer to apply all of the necessary changes. Potentially, the business expert could make such changes.

Although the if ... then ... structure of the business rule at first appears well suited to languages such as Java, this is unfortunately not the case. Java necessitates the services of skilled software engineers for implementing and changing business logic. Such changes are arguably best applied by those most skilled in the logic being defined: the domain experts. It can therefore be argued that business rules should be defined using a specialized natural-language syntax that enables business experts, as opposed to software experts, to build and maintain the rules.

Addressing the language issue from a different tangent, Java, as we know, is an object-oriented language. However, languages from a very different paradigm exist that are constructed specifically for the implementation of rule-based systems. These languages employ a declarative paradigm, as opposed to an imperative one, and originate from research projects into artificial intelligence (AI)–based systems. In upcoming sections, we look at the application of these specialized languages for the definition of business logic.

In traditional systems, the software that enables the application to operate and the software responsible for implementing the business logic become intertwined. This scenario further exacerbates the difficulties inherent in enabling domain experts to maintain the all-important business logic. The business expert must understand the operation of the entire application in order to accurately separate business functionality from application functionality.

The reverse is also true of the software engineer, who is required to be expert not only in the architecture of the system but also in the business domain itself. An architecture that supports the clean separation of the two concerns of business and system would enable the responsibilities for the development and maintenance of the system to be divided between the business and the software experts.

A company may find that as part of its wider IT portfolio, business rules are repeated several times in numerous different systems. This situation is not uncommon in large organizations and often occurs where systems overlap in terms of functionality. This situation can also arise during the transition phase as new systems are introduced to replace legacy systems.

Rule duplication significantly increases the total cost of ownership for an organization and adversely affects its propensity for agility. Changes to business processes must be effected across several different systems, thus incurring additional expense in terms of cost and time.

To address these issues with defining business rules, software vendors are turning to rule engines, a technology that was previously the preserve of academia and the computer scientist.

A rule-based system relies upon the services of rule engines as means of inferring which rules to apply when solving a particular problem. The architecture of a rule-based system generally comprises three main elements:

A rule-based system, such as an expert system, defines rules using the familiar construct of the if ... then ... clause, introduced earlier for business rules. Within an expert system, a rule represents a heuristic. The heuristic is an attempt to express the guidelines, or rules of thumb, a human expert applies when solving a particular problem.

Data is represented within the system as facts, which are typically maintained within a knowledge base.

The rule engine is responsible for matching facts to rules—matching facts against the if part of the rule. If a match is found, then the rule engine executes the actions defined for the rule’s then statement.

Execution of the rule engine ceases when all facts have been matched. Since rules are able to modify the knowledge base as part of their actions, the rule engine can go on to fire further rules as a result of the actions of each rule.

Rule-based systems have previously been the domain of computer science rather than business systems. Nevertheless, the areas of business rules and rule-based systems do overlap, and the research into the development of expert systems can be applied directly to the definition of business rules within enterprise systems. After all, a system designed to model complex human reasoning should have no trouble with the humble business rule.

You should consider using a rule engine if:

Rule engines, like databases, are enterprise resources. Where a database manages an organization’s data, correspondingly, a rule engine manages a company’s business knowledge. This makes rule engines complementary to the multitier architecture of the J2EE platform, which accesses the business knowledge managed by a rule engine in the same manner as corporate data assets held in a database are accessed.

In the next section, we examine how Java applications can employ the capabilities of a rule engine using Jess, a Java Expert System Shell.

Unlike its predecessor CLIPS, Jess is not public domain software. However, a trial version is available for evaluation purposes, and those in academia may apply for a free license.

Jess can be downloaded from http://herzberg.ca.sandia.gov/jess/index.shtml.

The documentation provided with the installation is comprehensive and includes a reference guide for the Jess language and the Java API along with example code.

To help understand how Jess defines rules, we look at a simple example of a Jess program and then examine each section of the code in turn. Listing 10-1 implements one of the business rules listed earlier, which states that jet aircraft are not allowed to land on grass runways.

; Fact templates
;
(deftemplate airplane (slot name))
(deftemplate jet extends airplane)
(deftemplate prop extends airplane)

; Rules
;
(defrule can-use-grass-runway
  "Planes that can use a grass runway"
  (prop (name ?n))
  =>
  (printout t "Aircraft can use grass - " ?n crlf))

(defrule can-use-asphalt-runway
  "Planes that can use asphalt"
  (airplane (name ?n))
  =>
  (printout t "Aircraft can use asphalt - " ?n crlf))

; Add some facts
;
(deffacts aircraft-facts "Aircraft type facts"
  (prop (name "Cessna 172"))
  (prop (name "Tiger Moth"))
  (jet (name "Boeing 737")))

; Start the rule engine
;
(reset)
(run)

The airplane.clp example is run directly from the command line:

java –cp jess.jar jess.Main airplane.clp

Running the code for the example displays the types of runway surface an aircraft can use.

Jess, the Java Expert System Shell
Copyright (C) 2001 E.J. Friedman Hill and the Sandia Corporation
Jess Version 6.1p6 11/21/2003

Aircraft can use asphalt - Boeing 737
Aircraft can use asphalt - Tiger Moth
Aircraft can use grass - Tiger Moth
Aircraft can use grass - Cessna 172
Aircraft can use asphalt - Cessna 172

So, what does this example do? Well, the code states a few rules about the landing capabilities of jet aircraft as opposed to those powered by a propeller. Within the example, jet aircraft are only allowed to land on sealed runways, in this case, runways with an asphalt surface. Propeller-driven aircraft aren’t quite so fussy and can land on all runway surfaces. Note this is a sweeping generalization about the capabilities of jet and prop-driven aircraft types.

The first part of the program defines a data structure for the different runway types using the deftemplate construct. These data structures hold the data for the facts declared later in the code.

(deftemplate airplane (slot name))
(deftemplate jet extends airplane)
(deftemplate prop extends airplane)

This declares an airplane structure with a single slot, name. The data structures jet and prop inherit from airplane.

It won’t be a rule-based program without any rules, so the next part of the code uses the defrule statement to declare a few rules about the different types of aircraft.

Jess rules are similar in form to the classic if ... then ... structure of business rules. In Jess, the if statement equates to the left-hand side (LHS) term of the rule. The LHS term details the pattern the rule engine matches against facts in the knowledge base. Where a match is found, the Jess rule engine fires the actions defined in the rule’s right-hand side (RHS) term. Thus, rules are expressed as

If LHS then RHS

The Jess notation is terser, so we get

LHS => RHS

Here is the rule that states only propeller-powered aircraft can land on grass runways.

(defrule can-use-grass-runway
  "Planes that can use a grass runway"
  (prop (name ?n))
  =>
  (printout t "Aircraft can use grass - " ?n crlf))

Adding, or asserting, facts of type prop causes the can-use-grass-runway rule to fire. The second rule in the example stipulates which aircraft can use a sealed runway. For the purposes of the example, all aircraft can use an asphalt runway, regardless of whether they are jet or propeller powered. This second rule is defined as

(defrule can-use-asphalt-runway
  "Planes that can use asphalt"
  (airplane (name ?n))
  =>
  (printout t "Aircraft can use asphalt - " ?n crlf))

Rules are no good without facts upon which to act. The example uses the deffacts statement as shorthand to assert a number of named facts into the rule engine’s knowledge base.

(deffacts aircraft-facts "Aircraft type facts"
  (prop (name "Cessna 172"))
  (prop (name "Tiger Moth"))
  (jet (name "Boeing 737")))

The deffacts construct sets up the program’s data, adding each aircraft to the knowledge base according to its type, either a prop or a jet.

The deffacts statement is not the only way to add facts to our knowledge base. We could have used a rule to achieve the same result and instead written

(defrule start-up
  "Rule to be executed first"
  =>
  (assert (prop (name "Cessna 172")))
  (assert (prop (name "Tiger Moth")))
  (assert (jet (name "Boeing 737"))))

Rules with no LHS terms are always executed first by the Jess rule engine. Thus, the start-up rule is fired when the program is reset and the facts asserted. This in turn fires the remaining rules, and the output of the program is generated. However, before this can happen, we need to reset the program and start the rule engine. The final two lines of code complete the example:

(reset)
(run)

The rule engine runs until all rules eligible for execution have been fired, after which the program exits.

Running Jess programs through the Jess interpreter is one thing, but how can Jess be put to work in a Java or J2EE application? Thankfully, Jess provides a Java API for this very purpose.

Mixing Jess with Java combines the object-oriented and rule-based paradigms. This allows the definition of business rules using the Jess language, while Java is used to assert facts into the rule engine and retrieve the results.

The next example demonstrates the hybrid approach. For convenience, the initial rules and data structures from the first example have been retained. Listing 10-2 shows the rules the example Java program will be loading.

; Fact templates
;
(deftemplate airplane (slot name))
(deftemplate jet extends airplane)
(deftemplate prop extends airplane)

; Rules
;
(defrule can-use-grass-runway
  "Planes that can use a grass runway"
  (prop (name ?n))
  =>
  (printout t "Aircraft can use grass - " ?n crlf))

(defrule can-use-asphalt-runway
  "Planes that can use asphalt"
  (airplane (name ?n))
  =>
  (printout t "Aircraft can use asphalt - " ?n crlf))

The rules and structures in airplane_rules.clp are loaded into working memory by the Airplane.java example, as shown in Listing 10-3.

import java.util.Iterator;

import jess.Fact;
import jess.RU;
import jess.Rete;
import jess.Value;

public class Airplane {

  public static void main(String[] args) {

    try {
      // Create an instance of the rule engine
      //
      Rete rete = new Rete();

      // Load in the rules
      //
      rete.executeCommand("(batch src/airplane_rules.clp)");

      rete.reset();

      // Add 4 facts
      // First 3 facts are added to rule engine using Java
      //
      Fact f1 = new Fact("jet", rete);
      f1.setSlotValue("name",
                      new Value("Boeing 737", RU.STRING));
      rete.assertFact(f1);

      Fact f2 = new Fact("prop", rete);
      f2.setSlotValue("name",
                      new Value("Cessna 172", RU.STRING));
      rete.assertFact(f2);

      Fact f3 = new Fact("prop", rete);
      f3.setSlotValue("name",
                      new Value("Tiger Moth", RU.STRING));
      rete.assertFact(f3);

      // Fourth fact is added by executing Jess statement
      //
      rete.executeCommand(
        "(assert (jet (name "Airbus 320")))");

      // Kick the rule engine into life
      //
      rete.run();

      // Facts can be listed programmatically
      //
      System.out.println("
Asserted facts");

      Iterator iter = rete.listFacts();
      while (iter.hasNext()) {
        System.out.println("Fact: " + iter.next());
      }

      // Alternatively Jess can do the job for us
      //
      System.out.println("
Facts as told by Jess");
      rete.executeCommand("(facts)");
   }
   catch (Exception e) {
     System.err.println(e);
   }
 }
}

Embedding Jess within a Java application first requires instantiating an instance of the Rete class. This is the Jess rule engine and provides an interface that allows the calling Java code to perform common Jess tasks such as asserting facts and defining rules. The Rete class also provides the method executeCommand() for parsing and running Jess statements.

The example uses the executeCommand() method to load the rules from airplane_rules.clp into the rule engine.

rete.executeCommand("(batch src/airplane_rules.clp)");

The ability to execute a Jess command provides a convenient shortcut. Running the batch command to load the rules avoids the need for construction of both a FileReader and a Jesp class to parse the input file. Executing the batch command saves a few lines of code.

Facts are asserted into the rule engine by instantiating a new Fact instance and adding it to the Rete object. Here is the declaration of a fact for the jet data structure.

Fact f1 = new Fact("jet", rete);
f1.setSlotValue("name",
                new Value("Boeing 737", RU.STRING));
rete.assertFact(f1);

Alternatively, facts can be asserted using a Jess command:

rete.executeCommand("(assert (jet (name "Airbus 320")))");

With the rules loaded and all facts asserted, the rule engine is ready to run:

rete.run();

Listing 10-4 shows the output from the complete program.

Aircraft can use asphalt - Airbus 320
Aircraft can use asphalt - Tiger Moth
Aircraft can use grass - Tiger Moth
Aircraft can use asphalt - Cessna 172
Aircraft can use grass - Cessna 172
Aircraft can use asphalt - Boeing 737

Asserted facts
Fact: (MAIN::initial-fact)
Fact: (MAIN::jet (name "Boeing 737"))
Fact: (MAIN::prop (name "Cessna 172"))
Fact: (MAIN::prop (name "Tiger Moth"))
Fact: (MAIN::jet (name "Airbus 320"))

Facts as told by Jess
f-0   (MAIN::initial-fact)
f-1   (MAIN::jet (name "Boeing 737"))
f-2   (MAIN::prop (name "Cessna 172"))
f-3   (MAIN::prop (name "Tiger Moth"))
f-4   (MAIN::jet (name "Airbus 320"))
For a total of 5 facts.

The Java API provided by Jess is proprietary to the Jess rule engine. Other rule-engine implementations, like JRules from ILOG, offer their own proprietary interfaces for accessing the services of the rule engine from a Java application.

To standardize on rule-engine access from the Java platform, a Java Specification Request (JSR) has been approved under the Java Community Process that defines a common API for rule engines.

The next sections focus on what rule-engine products can offer the enterprise system. As we shall see, rule engines such as Blaze Advisor and ILOG JRules not only provide the developer with the tools to build and deploy business rules, but also make it possible for business users to define their own rules.

Following are factors to be considered when evaluating rule-engine products:

To find out more about the capabilities of commercial rule engines, visit the sites of Fair Isaac Blaze Advisor and ILOG JRules to review their whitepapers and product documentation. Blaze Advisor resides at http://www.fairisaac.com, and ILOG JRules can be found at http://www.ilog.com.

The CLIPS software, along with examples and tutorials, is available from the site http://www.ghg.net/clips/CLIPS.html.

Jess is not public domain software. However, numerous Java implementations of rule engines exist that are. Table 10-1 lists some of them.

For more information on the intricacies of the Rete algorithm, refer to the paper in which it was first defined, Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem by Charles L. Forgy [Forgy, 1982].