Java Pro - A Design Pattern for a Rule Engine 01/20/2006 02:21 PM

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.

Convert to XML Data

The first step in our approach is to convert the data to an XML format. All data that will be managed
by a rule engine should have some kind of converter to transform the data from and to XML. I will not
consider this part because I assume you can write, download, or buy many utilities for such
conversions. In short, the data utilized by the XSLT rule engine should be formatted as XML data.

Let's consider an example with two sets of account data from a bank. You can download all XML and
XSL files, Java source code, and Ant build scripts discussed here. The first set (data1.xml file) of data

http://www.ftponline.com/javapro/2003_08/online/xml_yboglaev_08_01_03/default_pf.aspx 第 1 頁（共 3 頁）
Java Pro - A Design Pattern for a Rule Engine 01/20/2006 02:21 PM

looks like this:

<data1>
<account number=
"1111111" type="0">
<open_date>20021009
</open_date>
<amount>990</amount>
</account>
<account number=
"1111112" type="0">
<open_date>20030309
</open_date>
<amount>30000</amount>
</account>
</data1>

The second set of data (data2.xml file) looks like this:

<data2>
<account number=
"2222222" type="0">
<last_name>Tester
</last_name>
<first_name>John
</first_name>
<birthdate>19400212
</birthdate>
</account>
<account number=
"2222223" type="1">
<last_name>Explorer
</last_name>
<first_name>Joe</first_name>
<birthdate>19721223
</birthdate>
</account>
</data2>

Suppose that the bank decides on these business rules, which should be applied to the data shown
previously for the first data set:

Rule 1 – if cash amount < 1000 then action: warning

Rule 2 – if cash amount > 20000 then action: invite to investment
Rule 3 – if account is opened in 2003 then action: promotion message

And for the second data set:

Rule 1 – if customer age is 60+ then action: promotion message

Our goal is to specify these rules outside of our application code. You will never find conditions (<, >,
=, and so on), values (1000, 20000, 2003), and messages in your code. They will be placed within
XSL templates, which allows us to refactor these rules from the application code. It means that the
specification, maintenance, and modification for business rules can be done outside of the code. This
maintenance can be completed by people with business skills and remove developers from having to
deal with daily business-rule change requests. If the business rules change, the application code will
not be affected based on this solution.

The main idea under our rule engine design is that XSLT in itself is a rule-based engine. XSLT
contains pattern matching and branching, recursion, and by supplying this powerful engine with an
event-driven process and an XML data source we are ready to start processing business rules.

http://www.ftponline.com/javapro/2003_08/online/xml_yboglaev_08_01_03/default_pf.aspx 第 2 頁（共 3 頁）
Java Pro - A Design Pattern for a Rule Engine 01/20/2006 02:21 PM

As a short example, let's consider data set two and its corresponding business rule 1. Our example for
XSLT-rule specification consists of two files: ruleset.xsl and ruleset_1.xsl. The first template plays the
role of the main driver containing calls to particular rule templates, and the second template contains
the rules in Ruleset.xsl (see Listing 1). The second template contains the callback to the action class
SendMessage from the XSL template in Ruleset_1.xsl (see Listing 2).

If you analyze these templates, you will find that the business rule is specified with a condition and an
external call to the sendMsg2Stdout() method in XSL. This transformation could be run on data
without an event part so that you can debug business-rule specifications independently during
development. The template parameter "index" is introduced to make a hook from action to the template
caller when it is in place. In the concluding installment, we'll take a closer look at event triggers and
other components in the rule engine implementation to achieve separation of business rules and
application code.

I would like to thank Craig Maheu for his valuable comments, suggestions, and code testing, and Jerry
Bartlett and Meryl Sonon for their strong encouragement.

About the Author

Yuri Boglaev is a senior software developer at Ameritrade, ThinkTech division, who specializes in
building large-scale, real-time distributed applications, software design, Java, XML technologies, and
declarative languages. He has more than 15 years of software development experience, including
scientific and engineering applications. He is author of Computer Mathematics and Programming (Univ.
Press, Moscow, 1990) and dozens of publications in scientific journals. Contact Yuri at
yboglaev@ameritrade.com.

© Copyright 2001-2005 Fawcette Technical Publications | Privacy Policy | Contact Us

http://www.ftponline.com/javapro/2003_08/online/xml_yboglaev_08_01_03/default_pf.aspx 第 3 頁（共 3 頁）