ILog JRules Business Rules Management System – Point of View

Who is this blog for?

This blog is for teams that are looking to use JRules or any BRMS for providing solutions to the business needs of their customers. It is not a tutorial. It has my experience with JRules in a set of brief but important points. It will give you a feel of what it takes to leverage a BRMS for your needs. This blog is written with ILog JRules 6.1.5 in mind. The latest version however is 6.7.  Most of points mentioned here would still apply to 6.7.

ILog JRules

ILOG JRules is a popular Business Rules Management System for ILog, a French software company established in 1987. It will be acquired by IBM soon as the negotiations have been finalized. ILog JRules is a platform for defining, testing, integrating, and managing the business logic of an application in the form of business rules. It allows both business and IT users to manage the business rules. ILog has a suite of BRMS products for various platforms.

• ILOG JRules
• ILOG Rules for .NET
• ILOG Rules for COBOL
• ILOG Rules for C++

ILog JRules is the BRMS for the Java platform and is the most widely used among the products.

What are business Rules

Business rules describe the definitions, constraints/business policies and operations that apply to an organization in achieving its goals. For example, a business rule may state that

If

    The driver of the vehicle is under 18 years of age

Then

    The driver is a young driver;

    The driver has an additional surcharge of 20 dollars

Given a change of business strategy, the organization might have to change this rule by either increasing the surcharge, or having a different surcharge for a particular state, or might increase the age for the young driver.

• A business rule must be declarative. It describes the operations of an organization and must not prescribe how an organization must operate. That is why rules are discovered and not created.
• A business rule must be atomic. It can either be completely true or completely false. It must describe one and only one well defined business rule. The business rules must distinct and independent.
• It must be expressed in a natural language so that a wider audience can be reached.

In JRules business rules may also be specified as decision trees and decision tables.

What is BRMS?

As companies rely more and more on information technology (IT) to manage their business, IT departments need to develop more complex applications and simultaneously accommodate an increasing rate of change in the applications they support. Traditional software architectures have been short in addressing the volume, complexity, volatility and fast changing nature of the business rules. BRMS addresses this issue by providing a structure to define, author, deploy, execute, monitor and maintain the variety and complexity of business rules. It can be loosely equated to the role played by Database Management Systems to manage data. Similarly, BRMS manages business rules. Business Rule Management System provides tools that allow you to manage business rules independently from the application logic. The atomic reusable business rules can then be mixed and matched to create rule applications that are hosted on a rule engine. Also, both IT and business users can participate in rule development at the same time.

ILog JRules

JRules BRMS enables business users and IT development teams to manage these business rules simultaneously. The following is the basic architecture of JRules BRMS.

There are three perspectives of importance during development of business rules in JRules.

Business Rule Application Development

Developers and architects first design a data model, often working with business analysts as a source for models and requirements. They develop a rule project, write business rules, and integrate rule execution into a production application. JRules Studio, which is integrated as a plug-in with eclipse enables the developers and architects to design the business rule application, author, review, and debug business rules. They can keep the rules in sync with the business users using the Rule Team Server.

Business Rule Management for Business Users

Rule Team Server has a web based tool used by Business users and policy analysts to author, publish and maintain the business rules. Similarly, developers publish rules to Rule Team Server through the Eclipse based Rule Studio. Rule Team Server is a database to store and manage these independent rules.

Integration into an Enterprise Application

Integrating a business rule application into your enterprise environment consists of writing the integration code that calls the execution of business rules from your application, and deploying the rules to the execution environment. Once the business rule application is deployed, an administrator can monitor execution using the Rule Execution Server console. The following components are necessary.

Rule Engine

The rule engine is a component in which you assemble, isolate and apply the business logic (the rules) of an application.

Rules Execution Server

Rule Execution Server is a managed, monitored execution environment for deployed business rules. Rule Execution Server handles the creation, pooling and management of ruleset instances in order to assist invocation of a decision from application code. Rule Execution Server provides a management console, from which you can deploy, manage, and monitor Rule Applications.

Rule Scenario Manager

Rule Scenario Manager is a framework that enables developers to provide business rule testing and simulation solutions to other developers or policy managers. Business users and developers can create and manage tests that invoke the rule engine and manage reference data used for testing and simulation in different formats including spreadsheets.

Point of View

I was involved in the development of a rule based system for a major Railroad client.

Setting the context

I worked on a rule based application for a major railway in the US. We created a prototype using ILog JRules version 6.1.5 and determined the feasibility of using this BRMS. During my involvement in the development of this business rules engine, I learned quite a bit about JRules and wish to share my observations with the IT community.

My experience

• As part of the initial feasibility study or the pre-initiation stage of the project, one must make the end users understand the impact and the commitment required for using a BRMS. Since the users would be modifying the rules and testing them, responsibility of maintenance of the rules indirectly falls on the end users. Several times, the users understand the extent of their involvement only after the project is in final stages. It is the responsibility of the IT team to make sure that the business users realize that “With great power comes greater responsibility”
• Based on my experience, I believe that it is essential to study the necessity and the technical feasibility of using the business rules management system.
  1. Sometimes, a traditional J2EE approach might be more suitable for the business problem than a full fledged BRMS. Imagine creating a system that just parses and stores messages from several sources. This system would be better off as a J2EE EJB application than a BRMS
  2. The following attributes may loosely indicate that your application rules can be better maintained using a BRMS i) Constantly changing rules , ii) Large number of rules, iii) Rules for a single service scattered across multiple applications, iv) Facilities in the application that configure the way the business rules in the application are executed. JRules provides that facility using Rules Team Server
  3. Some example services are 1) Service to validate if a person is eligible for an insurance product, 2) Service that looks at a set of readings of a train from a way side detector and decides whether the train has a defective component,
  • I recommend creating a simple prototype by picking a few use cases from the business domain. The demonstration of the prototype would help the users understand the features, advantages and drawbacks of a BRMS. The IT team will also understand where the BRMS fits in to the big picture.
  • The prototype can be used as a base for iterative development of the application.
• It is essential that the business users are trained sufficiently to use the BRMS.
  1. JRules has its own English like language to build business rules. It is called Business action language. Even though the vocabulary is built by the IT team in association with business users, there are still basics that need to be learnt.
  2. The end users also need to learn to use tools like Rules Team Server Web application for authoring rules and sometimes Rules Execution Server Web console for deploying rules.
  3. The IT team must learn IRL (ILog Rule Language) on top of Business Action Language in order to write rules
• Shift in programming methodologies.
  1. Most of us are used to procedural, modular or object oriented programming. Writing business rules using JRules requires a paradigm shift in our thought process. The rules engine does not evaluate the rules in sequence. Instead, it uses RETE algorithm to process rules. The Rete algorithm is used by the rule engine to minimize the number of rules and conditions that need to be evaluated, compute which rules should be executed, and identify in which order these rules should be fired. It is a pattern matching algorithm. For a discussion of RETE algorithm, please use the following link.

1.  http://en.wikipedia.org/wiki/Rete_algorithm

• The first step in creating the Business Rules engine is to have a clear understanding of the business domain.
  1. The domain models are first created using UML by understanding the business requirements.
  2. The domain models are converted to Java classes. This set of models is called Execution Object Models or XOM.
  3. The XOM is imported into the JRules Rule Project in JRules Rules Studio (Eclipse based). The XOM now becomes the business object model or BOM.
  4. The IT team works with the users to provide proper business names to these business object models. For example
  • String studentAge will become “Student Age”
  • addSurcharge(Car car) will become “Add surcharge on this car” etc.
• Once we have a stable BOM, the IT team generates Rule Flows. Rule flows are similar to UML activity diagrams. It creates a business flow that will evaluate the rules with the passed data and return output. Every UML activity is composed of a set of rules written in Business Action Language, ILog Rule Language, Decision Tree or Decision Table. The rules in an activity can execute either sequentially or using RETE algorithm. An example of a rule flow is as follows

• The business user and/or the IT team can now start adding rules to these rule tasks (UML activities) using BAL or IRL.
  1. Example of a typical rule in BAL (Business Action Language)

if
    the age of the 'current driver' is less than 18

then
    make it true that the 'current driver' is under age ;

1. The rules may also be written as decision tables

1. The rules may be written as decision trees

1. The IT team can also write rules and functions for calculations, flow control etc using ILog Rule Language. These rules are called technical rules.

1. After sufficient testing of the rules written by IT and business users, the application can be deployed. Testing can be automated by using Rules Scenario Manager, a testing suite for ILog JRules. It follows a concept similar to JUnit. The test cases can be grouped as suites and suites as scenarios. The highlight here is the ability of the tool to accept data in spreadsheets. The business users can feed data using spreadsheets and test. Apart from the test results, several key performance indicators (KPI) like number of rules fired, the set of the rules that did not fire etc can be inspected to perfect the rules.

1. The deployment of rules can be done using Rules Execution Console. The Rules Execution Unit can be made available as a resource on an application server. The calling program can use various methods to invoke the rule application.

1. JRules provides a rules extraction, querying and rule reporting mechanism. Rule reporting internally uses Eclipse BIRT (Business Intelligence Reporting Tool) to generate static reports on the rules.

1. It is possible to perform hot deployment on rules. However, this powerful feature must be controlled by having an efficient rule governance policy that aligns with the IT policy of an organization. A rule governance policy determines how rules are developed and deployed in an organization for business use.

1. The power of JRules lies in quick creation and deployment of rules by both business and IT users. The ability to leverage these features requires a higher learning curve as compared to traditional J2EE applications for both IT and business users.

1. Since rule applications are by nature designed to take an input and provide the result as output and also perform a well defined decision making activity, they are good candidates for Services. When architecting systems, BRMS rulesets can easily fit in as services in our Business Process Models.

1. It essential that a NFR document and performance plan is prepared upfront. Continuous performance management is best way to achieve the most optimal performance in BRMS based development methodologies

1. ILog’s Agile Business Rules Development methodology (ABRD) is the business rule management industry's vendor-neutral methodology, delivered as an Eclipse Process Framework plug-in that provides a step-by-step process for developing business rule applications. Starting from rule discovery to rule set deployment and maintenance, this method helps to develop rule set using an iterative approach.

 http://www.ilog.com/brms/media/ABRD/

Copyright © 2001-2007 ILOG S.A. and its subsidiaries

Resources for ILog JRules

http://www.ilog.com/products/jrules/documentation/jrules67/

http://www.ilog.com/products/jrules/index.cfm

http://blogs.ilog.com/brms/

http://www.ilog.com/dev/brms/

http://www.ilog.com/brms/media/ABRD/

Conclusion

JRules is one of the best BRMS in the industry. If implemented right, it can improve the agility and responsiveness of a business organization. With this blog, I hope the teams looking to use JRules can make informed decisions on using JRules by understanding the processes, pitfalls and risks in implementing a JRules based development strategy.