A basic rule of technology is that you only get smart results from smart tools. One such “smart tool” is a BRMS (business
rule management system) that takes business logic out of procedural code and puts it where it belongs: in the hands of business
analysts. A BRMS can extract and isolate business rules from all of the other control code in an application, allowing business
analysts to configure the rules (for discount pricing, loan interest rates, insurance premiums, and so on) using simple if-then-else
statements and ordinary business language.

ILOG Jrules 4.5
ILOG, ilog.com
|
Very Good 8.0 |
 |
| criteria |
score |
weight |
| Ease-of-use |
9 |
20% |
 |
| Support |
7 |
20% |
 |
| Developer tools |
8 |
15% |
 |
| Implementation |
8 |
15% |
 |
| Scalability |
8 |
10% |
 |
| Rule repository |
8 |
10% |
 |
| Value |
8 |
10% |
 |
|
 |
Cost: $12,000 per developer seat, $20,000 per CPU; volume discounts available
Platforms: Almost any platform that supports Java including Windows, Solaris, AIX, Linux, and Mac OS X (not supported by ILOG)
Bottom Line: Jrules 4.5 is a shining example of a rich set of tools. Analysts can build rules in ordinary language using an easy GUI or
familiar spreadsheet. Programmers benefit from rapid deployment, automatic code generation, UML modeling, and excellent debugging
tools.
|
 |
About our Reviews and Scoring Methodology
|
|
|
|
Exposing business logic in this way can yield amazing cost benefits. Rules-management systems are especially useful in industries
such as banking, mortgage lending, insurance, and telecommunications, where the logic is complex, changes are frequent, and
the rules are best left under the control of the business experts.
Of course, putting business rules in the hands of nonprogrammers doesn’t take programmers off the hook. Indeed, the main benefit
of a BRMS is that, by allowing them to share a rules language they both understand, it facilitates closer communication between
the programmer and the analyst, making the job of each much easier. A good BRMS serves two masters, giving the programmer
effective tools for creating the rule base and deploying applications, and giving analysts easy-to-use tools for building
and changing rules.
For Java applications, ILOG’s JRules 4.5 offers all of the bells and whistles that enterprise developers and business analysts
require. Improvements from Version 4.0, which was introduced in March of last year, include automatic code generation and
point-and-click deployment for programmers, and friendlier rule-building tools for business analysts. Version 4.5 also performs
better than 4.0, and provides the useful ability to configure role-based access privileges to rule sets and individual rules.
JRules provides the richest set of tools I’ve seen in a BRMS. Only Blaze Advisor from Fair Isaac rivals JRules’ ability to
“expose business logic to daylight.” OPSJ from Production Systems Technologies and Jess from Sandia National Laboratories
deserve honorable mention, but JRules and Blaze are the only rules engines for the Java platform truly geared to enterprise
use.
Rules and Coding
The importance of developer tools for both programmers and business analysts cannot be overestimated. Nontechnical users must
be able to determine that business rules have been written correctly. Over the lifetime of a rule-based application, these
same business users must be able to modify rules to accommodate changing business processes. JRules has always provided a
GUI that allows analysts to build rules and programmers to view the underlying code, but until Version 4.0 the GUI wasn’t
very stable.
In Version 4.5 the GUI is not only stable, but the BAL (Business Action Language), which the programmer uses to describe an
application’s objects, attributes, and methods in the lingua franca of the business user, now has all of the features of JRules’
underlying rule language. With Version 4.5, analysts can do anything in BAL that can be done in the less-accessible JRules
syntax. Further, BAL can be extended to include words and phrases common to the industry and company.
Once the programmer configures the BAL, JRules’ GUI allows business users to build rules simply by selecting canned phrases
and logical operators from menus. When the rules are in place and the logic is fixed, variables -- such as the percentage
for a discount -- can be changed with a click. In the end, instead of having to explain a business rule to a programmer in
order to translate it into Java -- “if (order.numItems >= 2 and order.numItems <= 4)” -- the business analyst can express
it in a form anyone can understand: “If the shopping cart contains between two and four items ….”
At the same time, the GUI gives programmers access to the underlying Java objects, and allows either programmers or business
users to debug rules. As with any standard debugger, it allows you to set and unset breakpoints or step through the rule.
The only hurdle the GUI and BAL present is the time and effort it will take programmers and analysts to define how they want
the plain English version of the rule base to appear.
Another helpful addition in JRules 4.5 is the expanded capabilities for rule flow analysis. Even though rules are incrementally
independent, there is typically a certain “natural flow” of rules from one event to the other. Using the Rule Flow Editor
allows the business user to graphically view this sequence of events. And if there is a correction to be made, then the user
may simply drag and drop a rule into a new location.
Decision Tables, another new feature, allow business analysts to write a set of rules in a familiar spreadsheet format. The
rules are generated from the spreadsheet and can be modified anytime and regenerated. Decision Tables should prove invaluable
in some financial settings.
Programmers also get a number of handy new features. One is the ability to view Java objects in UML (Unified Modeling Language)
format and to generate Java code from that model. JRules 4.5 also provides automatic code generation for J2EE, J2SE, and Web
services, as well as point-and-click deployment for various scenarios, including the BEA WebLogic and IBM WebSphere J2EE servers.
While many programmers hate code generators (Reason? Pride.) this is still a very good start toward building a system. You
can always change the generated code.
Performance Matters
When evaluating a rule-base engine, one of the first measures is performance. The most common benchmark is the Miss Manners
test. In this test, 128 guests are invited for supper, and each may have one, two, or three hobbies. The idea is to seat boy-girl-boy-girl
so that there is someone with a similar hobby on either side. When run properly, the guests and hobbies have already been
determined, so the system can’t cheat nor can the system rearrange the data for better performance (see “Benchmarking the rules engine”). The data are arranged totally at random and may not be changed.
In firing all of the 8,513 rules in just over 100 seconds, JRules 4.5 proved to be about 7 percent faster than JRules 4.0
when I tested using JDK 1.3.1_07. I also ran the tests using JRules 4.5 and JDK 1.4.2 and got another 5 percent improvement.
JRules 4.0 is not compatible with JDK 1.4.2, so I could not compare performance on that JVM.
I also compared JRules 4.5 and JRules 4.0 performance using the Waltz test, a far more complicated benchmark that involves
determining shapes, edges, and points of juncture. Again, JRules 4.5 ran slightly faster than JRules 4.0 when run using JDK
1.3.1_07.
After implementing a rules engine, companies are often amazed to find that either their rules, as implemented in code, are
wrong or that a great deal of their business logic is missing entirely. The typical mismatch between the goals of the business
and the actual computer code in business applications is due to programmers not understanding the business logic and business
analysts not understanding what is happening with the code. JRules 4.5 can help programmers and business people bridge the
gap.