Java Pro - A Design Pattern for a Rule Engine

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

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

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

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

There are many commercial rule-based engines out there such as Advisor, Haley's, Jess, and JRulesas well as open source software: CLIPS, Drools, Mandarax, and so forth (see Resources). Theseproducts could be used in refactoring business rules from application code. However, they came fromthe artificial intelligence (AI) arena with different problems in mind. They often exceed e-business taskrequirements; 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 coversa vast majority of e-business applications. Rules are XSL templates imposed on the XMLrepresentation of data. They are triggered by events from XML data. XSLT can invoke external actionson an event source, therefore creating rule-engine functionality. To some extent, this techniqueexposes the logic programming flavor of XSL.

Extra language for rules specifications isn't necessary and is seen as a main drawback in commercialand open source rule engines. All a developer would need in the toolbox is Java, XML, and XSL. It isworth noting that the design pattern discussed here is language neutral. Java could be replaced withany language that can communicate with XSLT (call and callback) such as C++, which would require adeveloper to make only minor code modifications. Be aware that we will use XSLT in a way for whichit was not designed. XSLT is a language for transforming XML source into something else calledresult. In our approach, this result is a by-product that could be used or discarded depending on yourapplication. 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 bankmay have a business rule condition such as: if account value <$1000.00, then send a warningmessage to the client that a maintenance charge will be imposed this month. Since bankingsubsystems allow withdrawals, it would not be uncommon for the bank's system to have code withinan if/then block with the condition (<) and value ($1000.00), and to contain a resulting message stringbased on the condition. You can imagine the level of development maintenance required if thebusiness decides to change the condition, value, and resulting message on a daily basis. There aremany ways to refactor business rules starting from trivial configuration files or database tables withvalues ($1000.00, message string, and so on) and finishing with AI rule-based engines, which cansolve this refactoring problem as well as prove some mathematical theorems if you need to.

Convert to XML DataThe first step in our approach is to convert the data to an XML format. All data that will be managedby a rule engine should have some kind of converter to transform the data from and to XML. I will notconsider this part because I assume you can write, download, or buy many utilities for suchconversions. 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 andXSL files, Java source code, and Ant build scripts discussed here. The first set (data1.xml file) of data



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 shownpreviously for the first data set:

Rule 1 – if cash amount < 1000 then action: warningRule 2 – if cash amount > 20000 then action: invite to investmentRule 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 withinXSL templates, which allows us to refactor these rules from the application code. It means that thespecification, maintenance, and modification for business rules can be done outside of the code. Thismaintenance can be completed by people with business skills and remove developers from having todeal with daily business-rule change requests. If the business rules change, the application code willnot be affected based on this solution.

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



As a short example, let's consider data set two and its corresponding business rule 1. Our example forXSLT-rule specification consists of two files: ruleset.xsl and ruleset_1.xsl. The first template plays therole of the main driver containing calls to particular rule templates, and the second template containsthe rules in Ruleset.xsl (see Listing 1). The second template contains the callback to the action classSendMessage 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 anexternal call to the sendMsg2Stdout() method in XSL. This transformation could be run on datawithout an event part so that you can debug business-rule specifications independently duringdevelopment. The template parameter "index" is introduced to make a hook from action to the templatecaller when it is in place. In the concluding installment, we'll take a closer look at event triggers andother components in the rule engine implementation to achieve separation of business rules andapplication code.

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

About the AuthorYuri Boglaev is a senior software developer at Ameritrade, ThinkTech division, who specializes inbuilding large-scale, real-time distributed applications, software design, Java, XML technologies, anddeclarative languages. He has more than 15 years of software development experience, includingscientific and engineering applications. He is author of Computer Mathematics and Programming (Univ.Press, Moscow, 1990) and dozens of publications in scientific journals. Contact Yuri [email protected].

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

Documents

Java Pro - A Design Pattern for a Rule Engine