Tools for rules

The dust was thick on my copy of the 1985 Clocksin and Mellish classic, Programming Prolog. But Ted Neward, author of the forthcoming book Effective Enterprise Java, brought it all rushing back: expert systems, declarative rules engines, predicate calculus, backward- vs. forward-chaining evaluation.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

Neward gives an example on his Weblog why this obscure discipline is back in vogue. "If the guy filing the expense report files a 334-B form, then the upper limit on the total is twice his Personal Expense Liability total (which you get from the HR database, of course), unless his boss is an Assistant Vice President, in which case we have to get departmental approval from two managers and the AVP himself."

Today we program this stuff in procedural languages, and we make a hell of a mess doing so. Wouldn't it be great if we could declare a bunch of rules and have a rules engine work out the consequences? As Ted points out, this is the moral equivalent of using SQL to say what you want done with data not how.

Don't go hunting in the attic for your 5-1/4-inch Turbo Prolog floppy, though. Although Jess, a Java-based engine developed at Sandia Labs, has roots in both Lisp and Prolog, the emerging business-rules engines work with languages such as Java and C#, read XML-rule declarations, and are packaged for J2EE and/or .Net deployment.

I spent some time with two of these products: YASU Technologies' QuickRules (a commercial toolkit) and drools (the open source Java project that inspired Ted Neward'sblog posting). They differ in interesting ways. QuickRules provides a GUI rules editor that writes the XML rule definitions for you. But those definitions can only refer to Java or .Net classes; they don't use Java or C# directly to express tests and actions. With drools, you hand-edit the XML rule definitions. The tests and actions can not only refer to Java, they can also be written in Java or, happily, in Python.

These differences are only superficial, though. In fact, these products feel remarkably similar. And they will seem alien to most programmers, just as XSLT (eXtensibleStylesheet Language Transformation) and SQL did until we got used to them. In the declarative realm, the engine that runs your code has a mind of its own. You can try, for example, to pretend that XSLT is a procedural language, but a transformation that does not embrace the match-and-apply paradigm is running the engine on one cylinder. At the end of the day, you have to learn how the engine thinks.

Rules debuggers, such as the one provided by Ilog'sJRules will be essential (see "Working by the rules"). In my experiments with QuickRules and drools, even the simplest rulesets produced complex behavior. A test is evaluated, it triggers an action, the fact database is updated, and a new round of test evaluation begins. All this proceeds automatically and can take an unpredictable number of rounds to settle.

Tools will help us visualize that otherwise-hidden activity. But it's going to take a long while for programmers -- never mind business analysts -- to internalize the model. Now's the time to start. In Prolog's heyday, rules engines spent a lot of time solving old chestnuts such as the Tower of Hanoi puzzle. Business objects and processes weren't represented in ways that made them accessible to automatic reasoning. Thanks to the Web services movement, that's changing big time.

Will rules-based programming just create a different kind of mess? I doubt anyone really knows, but I'm glad we're gearing up to do the experiment. Sooner or later, something like this has to work.