Un-Rule Engines for Business Rules
Revised Oct 20 2008: This is a new "hybrid rule engine" category for the development site, more nut-and-bolts-oriented than most rule engine discussions.
What I call "un-rule engines" are rule engines without true inferencing capabilities. How can they be called rule engines ?
They are engines in that they apply the appropriate rules to a given set of data according to some fixed criteria, such as geographic location or transaction type. The key distinction is that they apply rules in a pre-determined order and are incapable of working outside of a restricted set of situations. Most workflow and validation engines fall into this category. Typically, there is some sort of fixed binding strategy or scheduling algorithm at the core of the engine.
These systems are often large, complex and cranky in the extreme. Many rank among the legacy COBOL applications of yesteryear. Why would IT managers and developers implement these things and keep them going years after year ?
Reasons for Implementing Un-Rule Engines
First of all, they can be very fast: the per-transaction performance is typically 4-8 times that of real inference engine. And remember that these horrible old COBOL behemoths originally ran on machines the equivalent of a modern pocket calculator.
Second, the kinds of "knowledge domain" that the applications address do not really require the power of an inferencing engine. It can be pre-determined which rules to fire when. The knowledge domain, while large, is effectively closed rather than open - ideally, the problem space is completely understood and there is no new knowledge to be discovered.
Lastly. the companies that run these systems have often launched giant re-engineering projects to bring them into the 21st century and gotten very mediocre results ... that is, when the projects managed to complete at all which they often did not. A knowledge domain may be closed but it may still be very big, too big for a technological quick-fix.
Often, the combination of knowledge engineering techniques and new technology can achieve better results than either alone. At a minimum, a preliminary knowledge engineering phase can help avoid the common fallacy that "we can code our way out of this" when confronted with inherently complex domains.
Many of the necessary components are open source and open license. A very promising technology for un-rule engine solutions is plain old relational database engines, using the very trick of treating rule structures as relational entities in the database. In particular, recent versions of mySQL support triggers and procedures. Great stuff for building un-rule engines.
Using Relational Database Navigation as a "Rule Engine"
One approach to developing at least a partial solution for a business rules engine without getting into the arcane mechanics of inferencing is using a relational database to drive the engine.
The fundamental problem with this approach is 'reachability', where parts of the deductive "tree" can not be reached by a relational database. In practice, however, many of the benefits of a business rules engine such as flexibility and easy reconfiguration can be realized without an actual rule engine, as outlined in the articles below.
The primary link is to an O'Reily article titled Put Your Business Rules In Your Database. Note the comment by the author "Paul: I understand your concern, but many business rules should be relatively invariant ...". This is a critical point. If a business rule never changes, then it might as well be in the database. Even better, hard-code it !
For a software configuration approach to un-rule engines, see Automatic Generation of Rule-based Software Configurations ( PPT ). The 'rule engine' in the architecture is not necessarily an inferencing rule engine - it could also be a complex database with a navigation engine or even a code generator for a workflow 'scheduling engine' application.