Tthe dusk that 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.
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.25-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’s blog 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.
Will rules-based programming just create a different kind of mess? I doubt anyone really knows.