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.