Published in TDAN.com October 2001
In order to maximize the benefit of a rules-based approach to systems development (as discussed in the April 2001 column), you need to follow the separation of rules through to the implementation
phase. The easiest way to do this is to utilize a tool that handles the implementation of rules in their own layer, apart from the backend system/data processing layer and the front-end UI layer.
You can program this layer yourself, but so could you program a database management system yourself. Just as we hand over the responsibility for database management to a DBMS, we can hand rule
management responsibility over to rules technology, allowing analysts and developers to focus on the rules themselves.
Products in this space fall into two main categories – data change-oriented and service-oriented. In a data change-oriented product, the rules are very closely tied to a data or object model,
and the rule management system determines when each rule must fire based upon changes made to (or intended to be made to) a data element. The rule layer intercepts all data changes before they are
applied to the database and ensures that all appropriate rules fire as a result. For example, a rule is created to maintain the value of an order total: the order total is the sum of the amounts of
all line items plus the tax plus the shipping charge minus any discounts. Once this rule is established, any change to a line item amount (e.g. adding or deleting a line item, changing a quantity),
the tax (e.g. ripple effect from any change in the line item amounts), the shipping charge or the discounts results in a change to the order total, automatically. The service-oriented products take
a different approach. The rules are packaged around events rather than around data objects. A data/object model is still a basic requirement, but the rules are combined into sets according to when
decisions need to be made with which the rule engine can assist. Based upon a given decision, you list all the appropriate rules and link any related rules that will also need to fire in order to
evaluate the desired set. You have more control (but also more responsibility) over when and in what order the rules will fire. When a set of rules is called, the rule engine manages the order in
which the rules are fired, including activating and de-activating rules as the conditions change as a result of the firing of other rules. For example, a set of rules is established to decide the
risk rating for an applicant and then to provide a policy quote after the required data is entered about the applicant. Whenever a risk rating and policy quote are needed, the application calls a
service to invoke the rule engine.
Among the products on the market today, USoft and Versata fall into the data change-oriented group, while Blaze Advisor and ILOG JRules are service-oriented. All products are geared mainly to Java,
particularly the J2EE environment. They generally work in other environments as well, but the development focus is solidly on J2EE.
USoft considers the true business model to be comprised of the data model and the business rules, and nothing else. Workflow analysis is done in the later stages of system development, after the
true business model is detailed. The workflow aids in determining how the user will interact with the system, but should not interfere with the analysis of what the system should do and why. USoft
uses ANSI-standard SQL as its rule specification language, which is relatively user-friendly, but not exactly in business terminology. A reasonably savvy business user or business analyst should
not have too much trouble with this. Upon implementation, the rules are called into action whenever the data is ‘touched,’ whether by direct data change or by another rule that prompts
a data change and thus another rule to fire. The interdependency of rules is a complexity handled by the rule engine (in USoft as well as in the other products mentioned – this is a key
benefit to incorporating a commercial rules engine rather than building one yourself).
Versata behaves similarly to USoft. A data/object model provides the basis for both rules and for UI development. Versata also uses a SQL-based (although closer to natural language) rules syntax,
with the addition of Java methods which may be referenced within a rule clause (a condition or statement determining whether the rule should be ‘fired’) or called as the result of a
rule. Versata compiles the rules into Enterprise Java Beans that execute at run-time to enforce the rule logic. The Versata Logic Server (VLS) executes the rules on a middle tier, providing both
data-source independence and front-end application independence – multiple applications may be running against the same logic server accessing multiple, even heterogeneous data sources. The
VLS may be integrated with IBM’s Websphere or BEA’s Weblogic in order to take advantage of full application server functionality. Both Versata and USoft are complete application
development environments, although you may use your own UI in conjunction with their rule layer implementation if you prefer.
One of the benefits of any of these products is that fewer lines of code need to be written, since the rules are expressed in a concise, declarative manner, and the rule product controls the
execution, rather than programming logic controlling the execution. Of course, programming expertise is required, and often the requirements are specialized, working around the edges of these
products. Versata estimates that 80% of the programmers on a project need have only limited Java experience and will work mainly within the Versata tool itself, while the remaining 20% will need
extensive Java experience to handle the architectural and more complex application issues.
In Blaze Advisor, you must have a set of objects on which the rules will operate, but the rules are defined within rulesets based upon decisions or tasks that require the rules to be applied, often
within a ruleflow that determines the order in which each ruleset is needed. Outside of ruleflows, the invocation of a ruleset is managed by the calling application. Blaze Advisor allows you to
express rules in a very English-like syntax or in a Java-like syntax. With either, you can access properties and methods of any referenced objects within the rules. At deployment, Advisor creates a
set of files that configure the Advisor rule server and include the rulebases (sets of rulesets) needed for the given application. The remainder of the application (UI, database access) is handled
outside of Advisor.
ILOG JRules also uses a Java-like rule language, which enables developers to reference any application object and invoke their methods as needed. Since this is a bit overwhelming for business users
and perhaps for analysts, ILOG JRules also provides a more readable business rules language that facilitates business users modifying the rules themselves. ILOG JRules behaves a little differently
from Blaze Advisor; the rule engine is always running, and you cause rules to fire by placing objects into the engine’s working memory. When objects become known to working memory, the rule
engine determines if any rules should fire, and as long as the objects remain there, the rule engine will be alert for any object changes that would cause a rule to fire. You can have multiple
engines active at the same time, each with its own set of rules, for different purposes.
Based upon their divergent philosophies, data-change oriented products and service-oriented products are best used for different types of problems. If you are most concerned about maintaining the
integrity of the data, you will want to work with a data-change oriented product. The types of rules most applicable are unconditional constraints and computations, although derivations and
conditional actions may also be used. If you will leave data integrity up to other aspects of the application (enforcing in the database or in application code) and are mainly concerned with
applying a consistent set of rules to important decisions in your application, a service-oriented product will suit your needs better. Unconditional rules are not commonly used. Conditional rules,
either for deriving new data values or for initiating actions are the majority of rules used in these products. For example, a retail e-commerce application in which the validity of each
transaction is paramount and in which you need to accurately maintain inventory values at all times lends itself to a data-change oriented approach. However, if the products you are selling are
complex and tailored to each client, such as insurance policies, you are more concerned about the decisions made in tailoring the product to each client and to ensuring that the product is priced
according to a complex set of rules. The integrity of the transaction itself may seem minor in comparison. In this case, a service-oriented product that allows for more complex logic and rules that
reference data from a wider set of objects more easily, fulfills the requirements better.
Either type of product may be used in a way that mimics the other type, at least to a degree. In order to make a data change-oriented product act like a service-oriented product, you need to force
a change to data. From that point, you can cause the appropriate rules to fire. Depending on the manner in which the tool implements the rules, you may need to twist and turn a bit to get the
behavior you need, but in principle you can. Similarly, in a service-oriented product, you can induce calls to the rule engine in reaction to database changes, but this is not as automatic as in a
data change-oriented product. Currently, it appears that a fair amount of work is involved in getting any of these rule products to behave in the guise of the other type, but it can be done. As
these tools are on the expensive side, you need to weigh the development effort against the purchase of two rule products to satisfy each type of requirement. It is important to determine the types
of problems central to your operations overall as well as which types of problems are prevalent in which applications. Although it may seem to go against the movement towards standardizing on one
tool in a given space, the types of rules engines available today are divergent enough in philosophy to warrant using one type for certain applications or components and another type for other
applications or components, rather than making all applications fit one mold (or worse, solving one type of problem with a rules-focus while ignoring the rules-based opportunities for others).
