Chapter 10. Working to Rule

A recurring theme of this book is that rapid development is achievable by being able to quickly and effectively accommodate change. One area of most applications that is subject to continual change throughout the life of the system is the business rule.

This chapter examines the benefits of applying rule-based languages and rule-engine technology to the problem of constantly mutating business logic. Specifically, this chapter covers how rule engines can assist in rapid application development by:

  • Enabling the description of rules in a language appropriate for expressing complex business knowledge.

  • Improving system maintainability by cleanly separating business logic from application logic.

  • Allowing the definition of business-rule sets as an enterprise resource, thereby enabling business rule changes to be swiftly effected across all corporate systems.

  • Providing sophisticated end-user tools for visually specifying business logic.

We cover some of the main concepts behind rule-based programming by introducing the expert system shell language Jess, a rule engine specifically designed for writing rule-based systems for the Java platform.

Business Rules

Business rules are the core of any enterprise system. Collectively, they define how an organization functions. A correctly modeled set of business rules captures the various aspects of the organization in terms of policy, strategy, and procedure. By implementing these business rules, an IT system ensures a company’s strategic initiatives are fully realized.

What Is a Business Rule?

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:

  1. Stock items must be replenished when levels drop below 5 percent.

  2. All creditors paying invoices within 30 days of billing will receive a 10 percent discount.

  3. Jet aircraft are not permitted to land on grass runways.

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

Structure of a 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:

  1. If stock levels fall below 5 percent, then replenish the stock.

  2. If an invoice is paid within 30 days of billing, then the price is discounted by 10 percent.

  3. If you are flying a jet aircraft and the airport runway has a grass surface, then divert to another airport.

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

Dynamic Nature of Business Rules

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 in Software

As business rules direct how an organization engages with the market, the ability to change focus as market forces dictate is of paramount importance to any company wishing to remain successful. Organizations are therefore seeking architectures for their enterprise systems capable of supporting an adaptive business model in which business rules are truly dynamic.

Unfortunately, traditional systems suffer a number of limitations when it comes to supporting dynamic business rules:

  • Business rules are commonly hardcoded in enterprise systems.

  • Traditional languages like Java do not offer the most appropriate semantics for expressing dynamic business logic.

  • Business and system concerns, although orthogonal, are interleaved within the code.

  • Rules are often duplicated across a company’s IT systems.

It is worth considering each of these points in further detail.

Hardcoded Rules

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.

Rule Definition Languages

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.

Tight Coupling of System and 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.

Rule Duplication

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.

Rule Engines

The rule engine originates from an area of computer science that has long battled with the issues surrounding the embedding of human logic and expertise into computer software. Research into AI, and the offshoot from that research in the form of expert systems, led to the development of rule engines as a means of organizing and managing large and complex rule sets.

An expert system, also known as a production system, is an AI-derived application that employs a knowledge base of human expertise for the purposes of problem solving in a well-defined problem domain, such as medical diagnosis or hardware fault-finding. Achieving this aim requires defining potentially thousands of complex, interrelated rules, which capture the knowledge of a human expert.

Developers of expert systems use rule engines within their products because they offer several benefits over conventional software engineering approaches: Specifically, they:

  • Allow the dynamic addition of rules and data.

  • Enable the definition of rules using specialized rule-based languages.

  • Make rules easier to manage by centralizing them in one location.

  • Reduce the complexity involved in modeling extremely complex sets of rules.

Rule engines enable developers to employ declarative programming techniques on software systems using rule-based languages. Conventional approaches to software development rely on programming languages that use the imperative computational model. Imperative languages like Java provide the computer with a list of commands to execute in a specific order. Declarative programming languages instead state a set of conditions and then leave it to the computer to determine how the conditions should be satisfied.

Declarative programming techniques help facilitate the development of rule-based systems and have proven extremely effective in the field of expert systems.

Rule-Based Systems

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:

  • Rules in the form of if ... then ... statements

  • A knowledge base of facts, or data

  • A rule engine

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.

note

Rule engines are sometimes referred to as inference engines.

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.

note

Not all rule-based systems use this approach. Systems built using the logic programming language Prolog define both facts and rules as predicates and so do not differentiate between the two.

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.

Rules Engines in Enterprise Systems

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:

  • Your business rules are subject to frequent change.

  • Other systems implement the same rules.

  • The business rules are highly complex and difficult to represent using conventional programming languages.

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.

Introducing Jess

The Java Expert System Shell, or Jess, is a Java implementation of the popular CLIPS expert system shell. CLIPS, the C Language Integrated Production System, is a public domain software tool for developing and delivering rule-based systems.

NASA initially developed the CLIPS environment in the mid-1980s to provide NASA software engineers with a portable, high-performance implementation of an expert system shell. The CLIPS language was modeled on OPS5, one of the leading expert system languages. The OPS5 language was originally developed by Charles Forgy at Carnegie-Mellon University, and the language continues to be synonymous with expert system projects.

Jess is a Java implementation of CLIPS and is to CLIPS what Jython is to Python. Although CLIPS can integrate with Java through a well-defined API, Jess provides the same level of seamless integration with Java as was witnessed with Jython. Jess is compliant with CLIPS to the extent that software written for Jess will run largely unaltered under CLIPS.

Note

Jython is covered in Chapter 9

Dr. Ernest J. Friedman-Hill at Sandia National Laboratory created Jess to support the development of expert systems in Java. Since its inception, many have realized the potential of Jess for adding the power of the rule engine to any Java application. This interest has gone well beyond the scope of expert system development, and Jess is being used effectively in enterprise systems.

In addition to being rule-based, Jess is a general-purpose programming language and provides the developer with a dynamic scripting language with which to access Java class libraries.

Installing Jess

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.

note

If you have obtained a trial version of Jess, it will expire after 30 days, so don’t leave it too long before you start your research.

Jess Example

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.

Example 10-1. airplane.clp

; 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.

The Rete Algorithm

Like CLIPS, Jess uses an optimized algorithm for determining which rules are eligible for firing in the form of the Rete algorithm. The efficiency of this algorithm enables rule-based systems to offer superior performance to that of their procedural counterparts that must rely on a multitude of conditional statements for defining rules.

Forward and Backward Chaining

Rule engines like Jess that start by matching the LHS terms of a rule are called forward chaining systems. These systems are data-driven: they start from the facts. Once running, the execution cycle of one rule can update the facts in the knowledge base, causing the condition of another rule to be met, thus firing the rule.

Alternatively, rule engines that operate by commencing with a stated goal that is matched to the RHS terms are known as backward chaining systems. Jess uses predominantly forward chaining but has the flexibility to use the backward chaining approach. The logic programming language Prolog is a classic example of a backward chaining system.

Jess and Java

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.

Example 10-2. airplane_rules.clp

; 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.

Example 10-3. Airplane.java

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.

Example 10-4. Output from Airplane.java

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 Java Rule-Engine API

Considering that rule-based programming offers such benefits for enterprise systems development, it should be no surprise that the Java Community Process instigated a JSR on the subject. JSR-94 covers the integration of rule-engine technology into the J2SE platform, and its existence highlights that rule-engine technology is more than just an academic exercise where commercial systems are concerned.

The need for JSR-94 arose from the proprietary nature of rule-engine vendor APIs. Currently, rule-engine vendors each offer their own proprietary interfaces for integrating their particular rule engines into Java applications. Due to the lack of a suitable standard, a diverse range of rule-engine interfaces has resulted. Software engineers must learn each vendor’s API and rewrite application code should they wish to migrate between different rule-engine products.

In order to address this problem, JSR-94 defines javax.rules, a lightweight API that looks to standardize access to rule engines from Java. Although the JSR specifies the J2SE platform, it is relevant for use in the J2EE environment.

The javax.rules API detailed in the JSR employs an approach similar to that of the JDBC API, whereby the client communicates via a standard interface with a vendor-supplied rule-service provider. The following code snippet is taken from JSR-94 and illustrates this approach:

Class.forName("org.jcp.jsr94.ri.RuleServiceProvider");
RuleServiceProvider serviceProvider =
  RuleServiceProviderManager.getRuleServiceProvider(
    "org.jcp.jsr94.ri.RuleServiceProvider");

The use of the javax.rules API is intended to provide compile-time compatibility between rule engines. Runtime compatibility, however, is not accommodated because the JSR does not encompass the definition of the rule language’s semantics. Consequently, while code written with javax.rules compiles against any rule-engine provider compliant with the JSR, the implementation of the rules themselves likely will need to be migrated according to each rule engine’s language.

JSR-94 has been approved and is available for download from

http://www.jcp.org/en/jsr/detail?id=094

The reference implementation bundled with the JSR is implemented as a wrapper over Jess, which operates as the driver for the rule-service provider. An example application comes with the JSR but requires the installation of a current jess.jar. The full details for building and running the example are provided with the JSR.

Enterprise-Level Rule Engines

The benefits of applying rule-engine technology to the problem of defining and managing business rules within enterprise-level systems have not gone unnoticed by solution vendors. With organizations demanding highly dynamic systems capable of supporting an agile business model, the rule engine has come to the fore as one solution for delivering on these demands.

Consequently, software vendors are developing and marketing enterprise-centric versions of the rule engine that specifically target the enterprise-level computing market.

Such products offer the developer the benefits of a rule-based programming language for defining business logic, combined with powerful development tools for building, compiling, and orchestrating rules. Two notable examples of these types of product include Fair Isaac Blaze Advisor from Fair Isaac Corporation and ILOG’s Business Rule Management System (BRMS).

Enterprise Rule-Engine Features

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.

Externalized Business Rules

Rule engines make the clean decoupling of business logic from application code possible. Using such an approach, business rules can be maintained and managed independently of the application.

Extracting the business logic from the application and placing business rules in a central rules repository where they can be accessed remotely offers a number of architectural advantages that are worth reiterating.

First, the business logic is not owned by any one application but is instead accessible by any system across the enterprise. This eliminates the problem of business logic being replicated between systems and thus removes the associated support overheads incurred when maintaining duplicate business logic across systems.

Second, rules can be defined independently of the technology of the systems that use them. Therefore, productive rule-based languages can be used for the definition of rules and rule sets as opposed to the general-purpose languages used to implement the systems themselves.

Rule-Based Language Support

Rule-engine vendors enable a variety of languages to be used in the development of working rule sets. Languages range from the fully declarative, including OPS5-style syntax, to languages more suited to the business end user. Moreover, with all the hype surrounding XML, it should come as no surprise that vendors are also turning to XML for representing rules. This approach has advantages in that standard XML tools can be used for managing rules in this format.

For its part, Jess offers a very powerful language for defining rules but is inarguably a developer’s language and is not intended for use by the business user. Indeed, the creator of Jess describes the Jess language as being for real programmers.

Unlike Jess, which is specifically aimed at the software engineer, other commercial rule engines cater to business users wishing to maintain their own rule sets by providing a natural-language-type business-rule syntax. Although potentially not as expressive as a true programming language, these business rule languages enable business domain experts to control their own business logic, thereby enabling business-rule changes to be applied without the need for involvement from software developers.

Many software engineers will find the concept of end users managing complex business logic in this manner unrealistic, even threatening, especially as the need to undertake extensive testing on any changes that impact a production system cannot be overlooked. The thought of business users releasing new business functionality on an unsuspecting organization will have many software engineers shaking their heads in dismay. Nevertheless, end-user programming languages are a major selling point for rule-engine vendors, albeit the use of such languages must be carefully controlled and managed. The majority of business users are technically competent, and products like Blaze Advisor and ILOG JRules have been developed to meet the expectations of an increasingly sophisticated end user.

Rule Management Tools

Enterprise-level rule engines offer more than just the rule engine and rule definition language. In order for rules to be easily defined, managed, and tested, products provide visual development tools that can be readily employed by both the software developer and the skilled business user.

As software engineers, we should expect sophisticated development and debugging tools for any languages we use. The same holds true for rule-based languages, and indeed the best examples of these products provide the developer with powerful visual development environments for building, compiling, and optimizing business rules.

note

Version 7 of Jess, codenamed Charlemagne, will include a development environment in the form of a plug-in for the Eclipse platform. Charlemagne is in alpha release at the time of writing.

Rule-Engine Evaluation Criteria

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

  • Performance.

    Most organizations rely on thousands of business rules to operate. The ability of a rule engine to accommodate rule sets of this size and return an acceptable level of performance is of paramount importance. Most forward-chaining rule engines employ the Rete algorithm, which is ideally suited to this task. Some vendor products also enable rules to be precompiled for additional performance gains.

  • Cost.

    All development projects work to a budget. Rule-engine price is typically based on feature set, so an application whose rules will only be defined by developers may not justify the additional costs of a rule engine that supports business-user development tools.

  • Scalability.

    This factor is critical where enterprise-level systems are concerned. A rule engine that cannot work effectively in a scaleable J2EE environment is likely to preclude its selection.

  • Rule management tools.

    Business-user-oriented languages might not be an important criteria for your particular project. Nevertheless, even if end-user interface tools are not required, rapid application development still demands the use of productive development and debugging tools for any language, rule-based or otherwise.

  • Integration.

    For a J2EE system, it must be possible to invoke the rule engine from J2EE components. Some rule engines are available as EJB components and are easily integrated into a J2EE solution. In addition to supporting the J2EE platform, the rule engine may also need to be accessible from other systems across the enterprise. The ability of the rule engine to support calls from heterogeneous systems is therefore an important factor if systems other than J2EE are required to make use of the services of the rule engine.

  • Rule language(s).

    Most rule engines support the if ... then ... rule construct. Some rule engines offer a choice of languages, ranging from developer-level rule-based languages to natural-language syntax for the business user.

  • API.

    In addition to the features offered by the rule language, the API provided by the rule engine is of particular interest to developers. Compliance of the rule engine with JSR-94 is also a consideration.

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.

Summary

As with scripting languages, knowledge of a rule-based language is a valuable skill that software engineers should have at their disposal. Rule-based programming is no longer considered purely the domain of the computer scientist but is finding an application in the development of business systems.

Business rules represent one of the greatest areas of complexity within enterprise systems, and the rule engine offers an effective mechanism for managing their sophisticated and dynamic nature. Rule engines are therefore well suited to rapid application development, offering the following benefits:

  • Rules can be externalized from all applications to a centralized repository where they can be managed using specialized rule management tools.

  • Rule-based programming languages are more suited to defining business rules than are languages such as Java.

  • Business rules can be defined and managed by domain experts rather than by skilled IT professionals.

  • The rules themselves are dynamic, enabling business-rule changes to be effected across the enterprise without the need to rebuild system components.

The next and final chapter on rapid development languages covers aspect-oriented programming, one of the software industry’s most exciting new paradigms.

Additional Information

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].

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.104.160