This paper identifies differences between two classes of computer platforms^[1] that implement business rules.  One platform directly supports business rule semantics; the other is an inferencing platform that is supported by commercial inference engines.  The author graciously acknowledges Ron Ross' introduction to this paper.^[2]

The Semantics of Rules

According to Ross^[4], from the viewpoint of the first and second perspectives above:

"The general case is that there are always two or more events (more accurately, change-of-knowledge-state events) relevant to every rule where the rule might be violated and therefore needs to be evaluated." ^[5]

The business rules system must be able to analyze any given rule to identify the specific events (Ross calls these 'update events'^[6] that could violate the rule.  This analysis gives rise to the notion of a runtime event-to-rule mapping that can be used by a rules engine.  The rules engine uses this mapping to access the relevant rules given an event of interest.  When any update event occurs, the engine needs to be able to determine whether any rule associated with that event is violated.

For example, consider the following rule:

A customer must be assigned to a service representative if the customer has placed an order.

This rule could be violated when the following update events occur:

• A customer places an order
• A service representative is de-assigned (for any reason) from a customer

When a customer places a new order, the rules engine must be able to test all the business rules, including the one above, that could be violated given this event.  The power of business rules semantics is that this same rule can also be accessed by the engine as a member of an entirely different set of rules when a service representative leaves the company (and is, therefore, de-assigned from a customer).

It is important that the system be responsible for the analysis of the rule and for identifying the relevant events.  Ross states:

"The problem with procedural approaches to rule enforcement is that there is no guarantee of consistent or comprehensive enforcement across all the procedures and actions that might produce those events."^[7]

A Rules Platform

Figure 1 shows the architecture of a platform for implementing business rules using a rules engine that is directly based on the semantics of business rules.  The rules engine is especially designed for implementing rejectors and inference rules, although it can handle other types of rules, such as triggers for processes or procedures.  In his introduction to this discussion, Ross refers to this type of rules engine as a 'violation-time' or 'event-time' engine.

• The Rule Repository Management System (RRMS) offers such functionality as rules editing (typically by business users), validation and querying.  In addition, it offers management functionality such as rule check-out/check-in, rule approval and rule productionalization.

• The Rule Repository, which is frequently referred to as the rulebase, contains business rules and related meta-data, including rule maintenance history and rule management controls.

• The Business Systems are thin clients offering business functionality to employees, customers, and anyone who signs onto the organization's website.  All the functional points at which the world interacts with the business systems of the organization can be called 'Business System Touch Points.'

• The Database^[8] represents any instantiation of the business fact model that can record events originating in the business systems.  The rules engine essentially acts as a filter through which all events must pass.  Permitted events result in a change in the state of knowledge of the business.

• The Rule Engine monitors all events occurring in the Business Systems.  When the engine detects a change-of-knowledge-state event that needs to be recorded, it uses a suitable runtime mapping of events-to-rules to determine which rules might be violated by that event.  (In general, every rule can be violated by at least two events.)

The rules engine maps from events to rules in a highly efficient manner.^[9]  The engine evaluates the rules against the new state 'desired' by the event.  If the rule is a rejector and would be violated, the rules engine rejects the event and displays the rule to the user who tried to initiate the event (assuming the user is authorized to see the rule and can understand it).  If the rule is an inference rule (which itself is a constraint), the engine makes sure that the inference is not violated by making true whatever has to be made true as specified by the rule.^[10]  (This produces a new desired state or update event, and then the process repeats.)  If the rule is a trigger, the specified process is initiated by the engine.

Production Rules and Inference Engines

The preceding section referred to the idea of inference rules as a constraint.  A constraint is a (Boolean-valued) statement that must be maintained to be true throughout all transactions.  The view that inference rules are constraints is fundamental to the Business Rules Approach.^[11]  However, the perspective on inference rules within the inference engine platform is different.

Inference engine technology provides a platform for implementing business rules that is optimal for addressing applications in which complex logical decisions must be made automatically.  Inference rules, as treated by commercial inference engines, use the following format:

IF condition
THEN do action

This format does not yield a constraint because this is not a Boolean-valued statement, at least not directly.^[12]  To distinguish this type of inference rule from an inference rule in the Business Rules Approach, this type of rule will be identified by its more traditional name: production rule.  Production rules are bits of programming logic (implementation code) that are executed by an inference engine.

It is possible to map different types of business rules into production rules.  These mappable rule types include what Ross calls 'producers' (computation and derivation rules) and several types of 'projectors' (inference rules, 'copiers,' and perhaps certain types of toggles and triggers).  The transformation of a business rule into a production rule usually occurs against the background of specific system requirements for the use of inferencing.^[13]

Inference engines implement a 'chaining' algorithm that links together production rules at runtime.  Classic chaining algorithms are backward chaining (sometimes called 'goal-driven reasoning') and forward chaining (sometimes called 'data-driven reasoning').  Commercial inference engines offer either one or a combination of these algorithms.^[14]

Two Platforms: A Comparison

The following table compares the operation of event-driven rules engines with that of commercial inference engines.

Event-Driven Rules Engine Platform	Inference Engine Platform
Rules are statements that must be true at all times.	Rules are condition/action expressions (not Boolean statements).
Invariants (often called 'rejectors') and inference rules are considered under the same general category of constraints.	Invariants are distinct from production rules. Invariants cannot be expressed with production rules.
The rules engine determines the proper action (rejection or projection) in the light of the rule.	The inference engine is explicitly given action statements by the rule.
Rules are invoked in relation to update events no matter where or when these events occur.	Rules are invoked by explicit request to inference with an explicitly specified set of rules.
Rules are considered by the rules engine when they are relevant as determined by the occurrence of update events.	Rules are considered by the inference engine when the inferencing algorithm deems them to be appropriate for the specific line of inferencing being pursued.
All rules that are relevant to a given event are invoked; that is, rules are applied across applications for any business transaction.	Only the rules within the set presented to the inference engine are executable; rules are available only to the application that invokes them.[15]

Summary: The Diversity of Business Rules Approaches

The influence of the Business Rules Approach on commercial inference engines as products has been profound over the past seven or eight years.  These products have embraced business language as a means to express production rules and externalized their rules in rulebases.

Inference engines provide a foundation for developing advanced decision-making systems when those decisions rest on a known but complex body of rules or regulations. Insurance underwriting, fraud detection, claim adjudication and adjustments, shop floor scheduling, solutions to various design and configuration problems, and a myriad of other critical business systems using inferencing attest to the power of inferencing as a platform for implementing such business systems.

Despite the wide disparity between event-driven rules engines and commercial inference engines, both are valid platforms for implementing business rules.  The business rules community should embrace both platforms in a rule implementation 'suite.'

Cited References and Notes

[1]  In this paper, platform is used wherever it is not ambiguous. 

[2]  The author would also like to thank Ron Ross for his comments on the pre-publication drafts of this paper.  Ron's contributions, which are too numerous to be individually acknowledged, extend well beyond the passages explicitly credited to him. 

[3]  Ronald G. Ross, Principles of the Business Rules Approach (Addison-Wesley, 2003).  (Hereinafter, Principles.)  Available via BRSolutions.com. 

[4]  Ronald G. Ross, personal correspondence.  See also Ross, Principles, p. 72. 

[5]  Ronald G. Ross, personal correspondence.  See also Ross, Principles, p. 72. 

[6]  Ross notes, "It is very important to remember that these events are always change-of-knowledge-state events -- not application events produced for other reasons or resulting from other causes.  These change-of-knowledge-state events can be called update events.  Although that designation more or less suggests a database platform for implementation, it should be noted that, strictly speaking, such an assumption is not required." 

[7]  Ronald G. Ross, "Actions Are Not Rules (and Vice Versa)," Business Rules Journal, Vol. 4, No. 5 (May 2003), www.BRCommunity.com/a2003/b141.html 

[8]  The Database component is sometimes referred to as the 'Factbase.'  When combined, the 'Factbase' and 'Rulebase' are referred to as the 'Logicbase.'  See Ross, Principles, p. 228. 

[9]  Ronald G. Ross, personal correspondence. 

[10]  Ronald G. Ross, Principles, pp. 247–248.  See also Ross, "Actions Are Not Rules (and Vice Versa)":  "In a rules engine environment, rule statements in declarative form are evaluated (not executed) by the system (rules engine) so the system can take responsibility for ensuring correctness of state, infer new facts and so on." 

[11]  Ronald G. Ross, Principles, pp. 247–250.  This position also appears to be implicit in Tony Morgan's Basic Constraint rule pattern.  See Tony Morgan, Business Rule and Information Systems:  Aligning IT with Business Goals (Addison-Wesley, 2002), p. 69. 

[12]  Ross notes, "If an action has an execution state that the rules engine can be aware of, then this execution state is itself knowledge that can be tested in Boolean expressions.  However, this interpretation is not the usual one in the commercial inference engine community." 

[13]  Further discussion of the transformation process and the system requirements that indicate the use of inferencing is beyond the scope of this paper. 

[14]  Ross allows that the rules engine could use standard inferencing algorithms (backward and forward chaining) when executing inference rules (Principles, p. 250).  However, the underlying mechanics of inferencing (its invocation and semantics) are different on these two platforms -- see the following section for further discussion regarding how inference rules are evaluated by a rules engine vs. executed by an inference engine.

[15]  Inference engines today often provide the ability to 'externalize' rules by moving them to an external medium, a rulebase.  However, externalization of rules does not alter this point because the application must still 'load' the rules from the external medium and submit them to the inference engine for evaluation and execution. 

© Copyright Computer Associates International, Inc., 2003.

# # #