Event Triggering XSLT Magic
Conduct e-business the contemporary way—reuse XSLT rules in components without code replication
by Yuri Boglaev
Posted August 13, 2003
Editor's Note: This is the second of a two-part discussion of using a simple XSLT-based rule engine to separate business rules from application code. The first installment, "A Design Pattern for a Rule Engine" by Yuri Boglaev (FTPOnline, August 6, 2003), mentioned several commercial rule-based engines and open source solutions that often exceed e-business task requirements, thus posing difficulties for small companies in purchasing licenses. The rule engine discussed here as an alternative is based on an event-condition-action paradigm that covers many e-business applications. In this concluding installment, Boglaev discusses event triggers and other components in the rule engine implementation. You can also download the code for the examples he describes in both installments.
The event part of the event-condition-action paradigm is the front line for the rule engine implementation. In our approach, after an event is triggered, the application code will invoke the XSLT engine to make magic with if/then conditions. For the examples I will use code snippets that utilize the Xalan processor from Apache Software Foundation (see Resources).
As mentioned previously, data exposed to the rule validation should be XML data. The first step would be to convert data from other formats (database, file, RAM data source, and so on) to XML while making any modification to the data source only through XML data. This XML data modification is the event that triggers XSLT. Event triggers are implemented in the package simple.rules.data with two classes and one interface (see Figure 1) and detailed output from javap (see Listing 3).
The xmlData class contains the field doc, which is an instance of the org.w3c.dom.Document class. The Document object doc is the XML form of your data. In my example, doc is defined by the data.xml file. In general, you will need converters (from/to) for all data formats involved in rule data processing. There are two methods in the XmlData class, insertAttributeValueIntoNodeList() and insertElementValueIntoNodeList(), that trigger event creation (XmlEvent) and notification of their listeners that implement the XmlListener interface. The XmlData objects maintain the listeners vector (add/remove) based on the standard Java event model.
The XML event triggers an invocation of the method xmlModified(event) on the listeners-implemented XmlListener interface. In fact, this method contains an XSLT process based on the Document doc object and an XSL transformer created from ruleset.xsl (templates with the business rules).
The RulesValidator class implements the XmlListener interface with the xmlModified(event) method:
public class simple.rules.engine.
RulesValidator extends java.
lang.Object implements
simple.rules.data.XmlListener
{
private static java.util.
Vector allXmlData;
private static java.util.
Vector allTemplates;
private static java.util.
Vector allTransformers;
public simple.rules.engine.
RulesValidator(simple.
rules.data.XmlData,java.
lang.String);
public void xmlModified(
simple.rules.data.
XmlEvent);
private static void
handleException(java.lang.
Exception);
}
The constructor has two parameters: XmlData object and XSL template (see Listing 4). The main purpose of this class is to respond to the events from the XmlData object by running the XSLT engine with appropriate XSL templates. The xmlModified method is an example of the XmlListener interface implementation (see Listing 5).
Drawing Conclusions
All components outlined previously could be presented as a simple rule engine based on XSLT. The core of the rule engine is the class RulesValidator, which is composed from two vectors of objects (see Figure 2): XmlData (event source) and XSL transformers (templates or rules). In rule engine terminology, XML data is often referred to as facts representing the state of the application. Output objects (for example, modified XML data) are referred to as inferences or conclusions.
The rule engine functionality is created according to the sequence shown in Figure 3. Messages from XmlData to XmlData are an indicator where possible cascading of initiated rules occurred, which is the main feature of the rule engines. Action from one rule is triggering the XML event for another rule, and so on.
There are a couple of missing components in our simple rule engine, which could be added if you would like to work in a production environment. The first one is a rule editor that could convert some restricted English sentences with if/then blocks to XSL rule templates. The second one is a rule modifier class that could insert or update at run time an XSL rule set and communicate with the rule editor.
As always, it would be not a bad idea to keep an eye on some standards like the Java Rule Engine API (JSR-94) and RuleML (see Resources) if you are developing a product based on rules processing. With a J2EE application server, you could also implement a rule engine as an EJB embedding into its internal behavior data converters from or to XML.
XML data, events, and XSLT form a design pattern to create a simple rule engine that will allow you to achieve a true separation of business rules and application code. You will reuse the XSLT rules in various application components without code replication with if/then blocks. This reuse allows business rules to be modified outside of an application, which is a contemporary way of doing e-business. I hope that you find your own derivatives from the concept presented here.
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 .
Back to top
|