email article printer friendly get the code more resources

A Design Pattern for a Rule Engine
Use XML data, events, and XSLT for a simple rule engine that helps you separate business rules from application code
by Yuri Boglaev

The main goal in this two-part discussion is to show a simple approach for separating business rules from application code. Without a rules-based approach, rule code could be potentially hard coded and possibly replicated throughout your application within if/then blocks. Doing so could cause the code to not be reused or maintained easily.

There are many commercial rule-based engines out there such as Advisor, Haley's, Jess, and JRules as well as open source software: CLIPS, Drools, Mandarax, and so forth (see Resources). These products could be used in refactoring business rules from application code. However, they came from the artificial intelligence (AI) arena with different problems in mind. They often exceed e-business task requirements; moreover, small companies might have a hard time purchasing their licenses.

The simple rule engine discussed here is based on an event-condition-action paradigm, which covers a vast majority of e-business applications. Rules are XSL templates imposed on the XML representation of data. They are triggered by events from XML data. XSLT can invoke external actions on an event source, therefore creating rule-engine functionality. To some extent, this technique exposes the logic programming flavor of XSL.

Extra language for rules specifications isn't necessary and is seen as a main drawback in commercial and open source rule engines. All a developer would need in the toolbox is Java, XML, and XSL. It is worth noting that the design pattern discussed here is language neutral. Java could be replaced with any language that can communicate with XSLT (call and callback) such as C++, which would require a developer to make only minor code modifications. Be aware that we will use XSLT in a way for which it was not designed. XSLT is a language for transforming XML source into something else called result. In our approach, this result is a by-product that could be used or discarded depending on your application. In general, transformation results are out of the scope of this discussion.

Most companies rely on business rules at the core of their operation procedures. For example, a bank may have a business rule condition such as: if account value <$1000.00, then send a warning message to the client that a maintenance charge will be imposed this month. Since banking subsystems allow withdrawals, it would not be uncommon for the bank's system to have code within an if/then block with the condition (<) and value ($1000.00), and to contain a resulting message string based on the condition. You can imagine the level of development maintenance required if the business decides to change the condition, value, and resulting message on a daily basis. There are many ways to refactor business rules starting from trivial configuration files or database tables with values ($1000.00, message string, and so on) and finishing with AI rule-based engines, which can solve this refactoring problem as well as prove some mathematical theorems if you need to.