Considering that a high-end BRMS (Business Rule Management System) costs about US$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.
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 (US$100 with source code) and easily affordable for most businesses, costing as much as US$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 US$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.