Rules Engines for Business Rules

Rules Engines brings agility into business systems by providing way to dynamically change business logic according to the dynamic nature of business. The power of Rules Engines lies in the declarative nature of defining business rules at fly, even without changing the source code of the application.

Introduction

Business applications often have to deal with changing business requirements that are often unpredictable and inevitable for business. Such changes cannot be even predicted during the system design. The conventional way to handle this situation is to go to the source code where the business logic exists, edit, compile, test and redeploy it; which requires a considerable amount of time and energy apart from the hassles of going through a complete release cycle.

Rules Engine eases out such situation by providing a way, that enables Business Analysts and developers to easily build decision logic based on business needs. Basically a Rules Engine externalizes the application logic from the source, thus enabling the business complex rules to be modified even on the fly, while the application is running.

Past, Present and Future

Rules Engines have existed from long time into the business software systems, but they have been gaining importance just recently, as business applications have started growing to be more complex. Rules Engines exist written in various languages including C/C++, C#(.NET), Java etc. But, of recent times, Rules Engines in Java have gained much importance with the Open Source wave.

Most of the earlier and legacy rules engines have proprietary API. making them difficult to integrate with applications. If a rule engine is no longer supported and the business decides to adopt another rule engine, most of the application code will need to be rewritten.

JSR 94 is an attempt to standardize rule engine implementations for Java technology. The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP) program, defines a Java runtime API for rule engines by providing a simple API to access a rule engine from a Java SE or Java EE platform.

Many Rules Engines exist in the Java World. Many follow the JSR-94 specifications, while some others do not.

Whats, Whys and Hows of Rules Engines

What is a Rules Engine?

The term Rule Engine is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes.

1. A simple system such as the form validation system can be a rules engine.

2. Action classes that we write, which execute business logic is also a rules engine.

However, the Rules Engines that we are discussing is a kind of Rules Engine, is also an 'Expert System' and are classically known as “Production Rule Systems”.

Please see http://en.wikipedia.org/wiki/Production_system for a good discussion on it. Production rule system is a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules (also termed as productions) about behavior.

Production Rule System is a term coined in the literature of Artificial Intelligence. This is the most common form of architecture used in expert and other types of knowledge based systems. This type of system uses knowledge in the form of production rules, i.e. if(/when) ... then rules.

if (condition-1 and condition-2 and condition-3)
then: take Action-1

If a production's precondition matches the current state of the world (the working memory), then the production is said to be triggered. If a production's action is executed, it is said to have fired. A production system also contains a working memory, which maintains data about current state or knowledge, and a rule interpreter.

Each rule represents a small chunk of knowledge relating to the given domain of expertise. When known facts of the system is supplied to such a system, a number of related rules may collectively chain to an inference and lead to some useful conclusions.

The brain of a Production Rules System is an Inference Engine that is able to scale to a large number of rules and facts; the engine is able to schedule many rules that are eligible for execution at the same time through the use of a "conflict resolution" strategy.

The Rules Engine can be viewed as a sophisticated interpreter of if-then statements. The if-then statements are the rules. A collection of such rules is what we call a RuleBase. Rules Engine is supplied with facts (data from our application) on which the Engine works, and lead to conclusions. These facts along with the rules together is called as the knowledge base. As rules execute, further knowledge may be added to this knowledge base. The outputs from the Rules Engine are determined by the inputs and may include the original input data objects with modifications, new data objects, and possible side effects (such as sending email to the customer). Sometimes, even some of the originally supplied data may be removed from the output.

The results may be used by the client to perform further processing. The rule engine determines when to evaluate each rule based on the input required for the rule as well as the results obtained from the evaluation of previous rules. Dependencies between the rules need not be specified, as they are resolved by the Rules Engine.

In addition to all of the industrial uses for rule systems, a handful of communities have begun springing up around rule engine technologies. Javarules.org and Business Rules Community are the most notable among them.

In further discussions, we will just deal with the Rules Engine as a Production Rule System.

When to use Rules Engine?

This is a very important question, when we are considering to use Rules Engine in our application. Is our effort to implement Rules Engine worth the application's need?

We may consider to use Rules Engine in the following situations:

1. Business logic is too dynamic (changes too often), and a change in a business policy needs to be immediately reflected in the application. Use Rules Engine to manage dynamic business logic and the task flow
2. Business logic is too complicated to be managed at the source code level (source code may have tons of if-else, and switch cases in various nested levels or you are using lots of look-up tables)
3. The application in hand may have business rules that needs to change often or needs to change in ways not anticipated in the original design.
4. Government regulated business, where a government regulation and norms need to be adhered to immediately. (Telecoms, Banking and Insurance sector for example)
5. At the presentation layer to customize the page flow and work flow, as well as to construct custom pages based on session state.

Typical scenarios where Rules Engine are/can be used:

1. Insurance (Rating, Underwriting)
2. Financial services (loans, fraud detection, claims routing and management)
3. Government (application process and tax calculations)
4. Telecoms customer care and billing (promotions for long distance calls that needs to be integrated into the billing system)
5. E-commerce (personalizing the user's experience)
6. Generic infrastructure for application platforms.

Why use Rules Engine?

We can answer to this question, if we could point out the pros and cons of using a Rules Engine in a project.

Advantages

1. Rules separate knowledge from its implementation logic.
2. Application logic is externalised from the System logic.
3. Business logic can be changed easily and fast (sometimes even while the application is running).
4. Rules can be changed without changing source code; thus, there is no need to recompile the application's code.
5. Declarative programming model to define business rules
• Like object (OOP) and aspect-oriented programming (AOP), declarative programming is a full-fledged style of software engineering, well suited to a specific branch of software engineering.
6. Rules that represent business policies are easily communicated and understood. Rules are felt more naturally than many lines of code. Even business peoples can understand these rules (sometimes, with some training).

7. Rule engines can also be used to build expert systems, which may be thought of as large rule banks that are tuned to a specific problem domain, such as workflow automation, resource exploration, or medical diagnosis.

1. The learning curve to get acquainted with Rules Engine, its semantics and possibly its syntax
2. Efforts in integrating Rules Engine with our system
3. Different Rules Engine implementation have different format and syntax for defining rules. Hence a decision to switch to another Rules Engine implementation would mean the effort to learn yet another tool.
4. More the facts and rules to process, the Rules Engine requires as much memory to store them as a knowledge base. As the application logic increases and goes complicated, the memory requirement for the application may also scale up.
5. Just like any other part of application, Rules Engine also need that the logic written be tested thoroughly before being moved to production. Using Rules Engine puts a greater emphasis on testing because, a small logic error can have dramatic impact on the business rules.

Which Rules Engine to use?

There are many Rules Engine available in the market today.Most of the rule engines available today loosely implement the JSR 94 specification, providing some commonality to integrating engines from different vendors. Thanks to JSR 94, integrating a rule engine into an application requires very few lines of code. Rules Engines on other platform also exist.

Some Open Source Rules Engine are discussed in http://java-source.net/open-source/rule-engines.

Below we discuss in brief about various Rules Engines available in market:

1. ILOG JRules and Fair Isaac Blaze

2. WebLogic Personalization Server

3. Rules4J and Java Expert System Shell (Jess)

4. Drools (JBoss Rules)

JSR 94 and Rules Engines

JSR 94 defines a simple API to access a rule engine from a Java SE or Java EE client. It provides APIs to

1. Register and unregister rules
2. Parse rules
3. Inspect rule metadata
4. Execute rules
5. Retrieve results
6. Filter results

Note that JSR 94 does not standardize the following:

1. The rule engine itself
2. The execution flow for rules
3. The language used to describe the rules
4. The deployment mechanism for Java EE technology

In other words, it doesn't standardize the semantics of rule execution.

JSR 94 provides guidelines for the rule administration and rule runtime APIs, but it defines no guidelines for what language to use to define the rules and actions. Efforts are under way to standardize a common rule language, including the Rule Markup Language (RuleML).

For our purpose, though the JSR-94 API are low level APIs and its better to just use some Rules Engine, which confirms to the JSR-94. Though we can use these low level APIs, however, this would make our applications, unnecessarily complicated, if we are concerned just in "using" the Rules Engine.

Conclusion

As we saw already, use of a Rules Engine has got its own advantages and disadvantages. The decision to use it should be taken meticulously. Even more important question is the choice of a rules engine. Weigh your needs and organization goals with what each rules engine has to offer. Nevertheless, considering the Rules Engine as an add-on to your application is always a good consideration to start using Rules Engine in your application so that if it grows complex for the need of rules engine, you may always rely on the intelligence of the Rules Engine.