Open source rule management

JBoss Rules and Jess deliver solid rule tools and respectable performance at a nice price

Considering that a high-end BRMS (Business Rule Management System) costs about $50,000 just to get started, and that annual maintenance, runtime fees, and professional services can drive the total toward a hefty half-million or more, organizations on a tight budget have incentive to seek alternatives. Thankfully, good options exist. Two of the better low-or-no-cost tools are Jess from Sandia National Laboratories, and JBoss Rules from JBoss, a division of Red Hat.

As do enterprise systems such as Fair Isaac’s Blaze Advisor and ILOG’s JRules, Jess and JBoss Rules expose the business logic of complex Java applications as sets of rules that can be changed quickly and easily without changes to the underlying Java. However, unlike the enterprise systems, neither Jess nor JBoss Rules provides friendly user interfaces (visual editor, flow diagrams, spreadsheet GUI) that allow ordinary business users, as well as programmers, to enter, change, and delete rules.

Unlike Blaze Advisor and JRules, Jess and JBoss Rules also lack a full-blown rule repository. Jess and JBoss Rules can integrate with a CVS for version control, but this falls far short of the lifecycle management, granular access controls, and extensive reporting provided by the repositories in the enterprise products. A full-featured repository can be key to a collaborative effort among many developers and business analysts, and rich reporting capabilities can be indispensable aids to debugging and optimization (see “Enterprise rule managers bring important extras”).

Of course, the open source approach that Jess and JBoss take does have advantages. Both Jess and JBoss Rules have developers around the world who are constantly finding and fixing bugs, suggesting new features, writing new code, and in effect serving as the unpaid engineering group for these products. Your IT staff could, with guidance from the Jess or JBoss Rules user community or third-party consultants, develop a friendly spreadsheet GUI, a visual flow editor, and other goodies you might want, but such efforts take a lot of staff, training, and investment spread out over several months or years, when the problem exists today.

In a nutshell, Jess and JBoss Rules are best suited to smaller projects, where a rule repository and extensive reporting and debugging capabilities aren’t critical needs, and where rule development and maintenance can be entrusted to one or a few devoted programmers.

Sandia Labs’ Jess 7.0

Jess, from Sandia Labs and Dr. Ernest Friedman-Hill, was, to my knowledge, the first implementation of a rule-based system into Java. It was pretty much a direct port of the more popular parts of CLIPS (C-Language Interface to Production Systems), a NASA venture. After that, a number of high-end systems, such as JRules from ILOG and Blaze Advisor from Fair Isaac, began to pop up. In the ensuing years, Friedman-Hill has always maintained that Jess is a programmer’s tool, not something for the ordinary, run-of-the-mill business analyst. That description is still spot-on.

Jess has been upgraded with a number of bells and whistles in the past five or six years: fuzzy logic capability for really nasty logic problems, backward-chaining for configuration and resource management problems, an Eclipse IDE that provides a pretty decent GUI development and debugging facility, and the ability to interface more directly with Java Beans, using either a static or a dynamic method. In the static method, the Java Beans are referenced as objects to be used in the rules and updated in response to internal changes (inside the Jess engine) as the rules are running. The dynamic method updates the external Java Beans in response to external changes, so it supports real-time applications.

From the beginning Jess has remained a free system for personal use ($100 with source code) and easily affordable for most businesses, costing as much as $15,000 for a full-blown, commercial license including source code and no runtime fees.

The new Eclipse interface is quite good. The GUI even includes something that most high-end BRMS tools don’t provide: a graphical representation of the Rete network, something only a real geek could love. For debugging, it allows break points within the rules but only on right-hand-side method calls. This means that you cannot break just anywhere in a rule. For example, you cannot stop the running of the rules at certain points on the left-hand side and examine the Agenda Table, or the value of any of the object attributes, and so on -- information that would greatly help in debugging. And, for the novice, the output is cryptic; he or she must go back to the documentation to understand the results.

Further, the debugger gives you just the bare bones -- basically, an explanation of the exceptions that Jess throws. It could be dramatically improved with reporting on which rule was called the most number of times, which rule took the most time to execute, potential rule conflicts, potential rule subsumption, and so on. But then, Jess is not the $50,000 package that includes the kitchen sink. To implement Jess, you must depend on someone who knows how to debug Java and someone who knows how to debug declarative rules. 

The code syntax is difficult for most C/C++ or Java or C# programmers to understand. For one thing, the rule syntax must follow that of the current CLIPS incarnation, which is archaic at best. Although Eclipse helps with everything else, it does not put a pretty face on CLIPS syntax. On the plus side, Jess code is much more concise than the equivalent code in JBoss Rules (see a comparison here) or some other BRMS engines. Some users (including E-Loan) have written an interface that brings a more industry-specific look to the underlying Jess code.

In addition to adding features, Jess has continually improved performance on the standard benchmark tests. It usually runs somewhere between the fastest commercial products and the current freebies. For this review, I tested Jess in two ways, one using internal objects and the other using external Java Beans, which runs a bit slower. On the Manners 128 benchmark (on Windows XP) Jess completed the run in 27 and 38 seconds; JBoss Rules took 21 seconds. On Waltz 50 (on Mac OS X), Jess ran the benchmark in 22 and 32 seconds; JBoss Rules took 25 seconds. Compared with the industry leaders, Jess runs faster or even with standard JRules and several steps behind OPSJ, Blaze Advisor, and optimized JRules. Their times for Manners 128 and Waltz 50 clock in the single digits, even less than a second for OPSJ on Waltz. Navigate here for the most recent marks for Jess, JBoss Rules, and others.

Documentation for an open source or shareware product is typically sparse, but not so for Jess. In 2003, Friedman-Hill published a book, Jess In Action: Java Rule-Based Systems that, although based on an earlier version of Jess, is still largely applicable to the current product. Friedman-Hill also maintains an up-to-date online manual, and the Java Docs are quite good. The only thing I found missing was an index for the online material.

Finally, the Jess User Group is probably one of the finest in the world. Friedman-Hill, Jason Morris, and Bob Orchard constantly monitor this group and give answers within 24 hours if not within the hour. Although rapid response is not a guarantee (because this is, after all, a support group, not a contract), I’ve discovered that these three will usually beat the response times of the Fair Isaac and ILOG technical support groups.

JBoss Rules 3.2

It wasn’t until late last year, when JBoss bought Drools (Dynamic Rule Object-Oriented Language System) and hired Drools’ project lead, Mark Proctor, that Jess had a real competitor in the open source arena. No longer Drools but JBoss Rules, the software is now in Version 3.2. I must emphasize the exact version number for JBoss Rules because it seems to be changing so quickly and gets so many improvements on a month-to-month basis. For the users, this is a good thing.

Before JBoss came along, the syntax in Drools was almost unreadable in its former XML incarnation, and many of the rulebase essentials were missing: features such as query support, dynamic rules, a truth maintenance system, and even operators such as “and,” “or,” “not,” “nested nots,” “exists,” “exists with nesting,” “for all,” “accumulate,” “from,” and on and on. For JBoss Rules 3.0, chief guru Mark Proctor brought that unreadable XML into an easy-to-use IDE, the exact, same Eclipse 3.2 interface that Jess uses. JBoss even implemented the graphical version of the Rete network -- just like Jess. Compared with Jess code, the JBoss code is easy to read and understand. Most business analysts could learn it in a day’s time with a bit of help from their favorite Java programmer.

The XML is still there, of course, and you can use ANTLR (ANother Tool For Language Recognition) to write your own parsing language, similar (but not quite as easy) to what ILOG and Blaze do with their GUIs. On the other hand, the JBoss approach is much more powerful in that you could create a Jess, JRules, Blaze Advisor, or Haley BRMS language, whatever syntax you might need, and donate the code to the JBoss Rules community.

As is Jess, JBoss Rules is being worked on around the world, and so is the documentation. JBoss Rules’ worldwide group is mostly programmers who are helping to write the latest version. Jess’s worldwide group includes programmers, newbies, students, professors, research scientists … almost anyone who might need help. Jess doesn’t encourage highly technical discussion on its list, whereas you find quite a bit of that on the JBoss Rules wiki.

About the only things that JBoss Rules doesn’t have that Jess has are fuzzy logic, backward chaining, internal objects, shadow objects, and Dr. Ernest Friedman-Hill -- but they have a good Friedman-Hill look-alike in Mark Proctor. JBoss Rules is also a close match to Jess in performance. Price/performance is pretty darn good too, because JBoss Rules is free.

What does JBoss Rules have that Jess doesn’t? It has something like the decision tables in Blaze and JRules. But instead of first creating a spreadsheet-looking GUI and then creating rules in the background, you create a rules template that generates the spreadsheet-looking GUI, and then you fill in the values for the cells. It’s a bit clumsy, but it does allow the business user to work in tandem with the programmer.

JBoss Rules 3.2 is a solid, true-blue, Rete-based inference engine with a fairly decent, Eclipse 3.2 developer GUI and debugger. The debugger isn’t working exactly right at the moment, but Mark Proctor is working really hard at changing that very soon. Proctor and company are also developing a Rule Server, the details of which can be found here.

Open source rules

JBoss Rules and Jess are similar in both design and functionality. Neither would be a good choice for a fast-track enterprise project, or for a large application requiring input from many business users or analysts. But both are suitable for business applications that use fewer than, say, 1,000 rules and 100 objects, which means most applications.

How to choose between them? If you are especially price-sensitive, then JBoss Rules is the answer; it’s free. If you seek a formal network of service partners, or if you like the “true” open source approach that focuses on development, versus user support, again JBoss would be the better choice.

On the other hand, if you want more stability, in terms of a longer track record for the product and a longer-established user community, you can’t go wrong with Jess. Likewise, if your project requires fuzzy logic or simple backward chaining, Jess offers these capabilities, JBoss doesn’t.

InfoWorld Scorecard
Setup (10.0%)
Value (10.0%)
Documentation (20.0%)
Performance (20.0%)
Developer tools (30.0%)
Support (10.0%)
Overall Score (100%)
Jess 7.0 9.0 8.0 8.0 7.0 6.0 8.0 7.3
JBoss Rules 3.2 9.0 9.0 7.0 7.0 7.0 7.0 7.4
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies