Appeared in Object Magazine, June 1998
Rules and Web-Object Systems
The subject of hybrid Web-Object systems has been a recurring theme in my column for the past two years. In an effective hybrid system, objects become resources on the Web, and Web resources become objects. The distinction is invisible to users, and developers can easily integrate the two perspectives. This month I will bring a new contributor into this hybrid design by integrating rule-based systems. The resulting triad allows rules to be specified about both Web and object resources, and these components can be distributed across client and server subsystems in the architecture.
In the past year, there has been significant interest, and product announcements, related to "capturing business policy rules," or "separating business rules from application and database logic." However, I’ve been disappointed by the vague statements about how these principles can be operationalized in a system design. I’ll take the first steps toward making these concepts more concrete within this column. As an initial definition, rules can be generally understood as the specification of patterns, and the actions that should be executed when those patterns are satisfied. Also, the absolute ordering of rule selection and execution is not determined by the programmer, but by a rule engine that iterates over the rule base to match and fire applicable rules.
Consider three fundamental ways in which rules can be integrated into a hybrid Web-Object system. In general, I will use the term "resource" to refer to either Web resources (i.e., anything that can be returned by a URL) or objects, underscoring my intent that the distinction should be transparent in hybrid systems.
The first type of rule integration is the most obvious, where rules are written about the properties of individual objects and Web resources. Although, what may be less obvious, is how the attributes of Web resources can be determined by a rule-based application. One approach is to make use of standard HTTP metadata returned by Web servers. For example, all Web servers return values for the properties: server name, content type, content length, authorization scheme, any many others. Other application specific properties can be exchanged in "cookies" that are passed between the Web server and client.
In the next, near-term, generation of the Web, the Extensible Markup Language (XML) will provide many possibilities for encoding unlimited metadata properties about Web resources. In particular, the Resource Description Framework (RDF) enables a standards-based way to define and exchange metadata (see http://www.w3.org/RDF/Overview.html ). Also, for more information, I wrote about the XML revolution in my previous two Object Magazine columns (Nov 1997 and Feb 1998).
Many rules are not limited to individual resources, but apply to particular combinations of resources or the presence of relationships between resources. Most current rule engines have adopted a relational join approach to specifying object relationships, similar to writing a SQL query. For example, consider the following rule:
This rule would select all customer orders whose amount exceeds $1000, and print the customer name and amount ordered. The emerging generation of rule engines is adopting a more object-oriented approach to specifying rule patterns. Consider the following rewrite of the last rule:
This rule also matches all orders exceeding $1000, but it traverses the relationship between Order and Customer objects, and invokes methods on objects in both the rule pattern and action. The getCustomer() method is invoked on the current Order instance being tested, and its return value is assigned to the variable named ?cust. The getName() method is invoked on the assigned customer instance in the rule action. The rewritten rule is more intuitive to object-oriented programmers and opens up interesting possibilities for integrating rules into existing object-oriented systems.
However, it’s again less obvious how similar rules can be written about Web-based resources. I believe that another member of the XML family of standards will provide a possible solution. The Extensible Linking Language (XLL) specifies a rich language for linking XML documents to other XML, and non-XML, documents. See http://www.w3.org/XML/ for the current draft of the XLL standard. As this linking standard matures over the next few months, I’m certain that you will discover accompanying programming libraries that allow Web resource links to be tested in rules similar to the above example.
Finally, I’ll briefly address the third approach for integrating rules into hybrid systems: Task-oriented control structure. It’s often useful to define a set of application tasks and to group rules into those tasks. For example, I’m currently building a rule-based system to evaluate whether a family is eligible for state-supported medical benefits for their children. This system is decomposed into the following tasks: Determine Residency, Classify Family, Accumulate Financials, Compute Net Financials, and Evaluate Eligibility. Each application rule is then associated with one or more tasks where it is applicable. There is a set of control rules that analyze the state of application objects to determine when it is appropriate to progress from one task to another. However, within each task, the rule engine is free to choose which rule to fire next. It’s important for the developer to break out of the procedural mindset where if/then statements are strictly ordered.
In my medical benefits eligibility system, the rule engine is embedded in a Java servlet and all rules run within the Web server. The servlet uses JDBC to query a relational database for application data, which is then mapped into Java objects in the servlet. The rule engine is executed on the Java objects to determine eligibility, and the results are both written back into the database and displayed to the user in a dynamic HTML Web page. In other systems, the rules could be run within a Java applet in a Web browser, or the rules could be partitioned between both the client applet and the server-based servlet. A few possible options are summarized in the following table.
There are several current options for embedding rule engines in Java-based systems. I’ve been working with two rule engines that are written entirely in Java. Ernest Friedman-Hill developed the Java Expert System Shell, or Jess, at Sandia National Laboratories (see http://herzberg.ca.sandia.gov/jess/). Jess rules are, for the most part, syntax compatible with the widely used CLIPS rule engine written in C. The new version 4.0 release of Jess adds several very interesting features for integrating rules with Java objects. Jess uses the standard JavaBean design patterns for allowing rules to access any JavaBean’s get/set methods as simple property values. Standard JavaBean property change events notify the rule engine automatically when the object’s properties have been modified.
I have also been working with Ilog’s Java-based rule engine (see http://www.ilog.com/html/products/infrastructure/rules.htm). In particular, I’ve been evaluating a prerelease of Ilog’s next generation rules engine, which should be available shortly after this column is published. Ilog’s engine provides rule syntax similar (but, not identical) to the object-oriented rule example given above. Ilog also provides a very complete Java programmer’s API for embedding the rule engine in another application, or for building customized rule editing and maintenance tools.
The scope of this column does not permit me to assess the specific approaches that these rule engines use for integrating rules and Java objects. I’m planning another article that will consider these details. However, I hope that I’ve enticed you to think about ways in which rules might contribute to your own application design. I believe that it’s essential to design for a Web-Object-Rules hybrid system if we are to achieve the Intelligent User Agents that have been widely discussed, but rarely delivered.