The main activities of the Business Rule
Engine fall into one of two main user experience categories, the
design-time experience and the runtime experience. At design time,
business rule creators can use the business policy authoring tool,
namely the Business Rule Composer in BizTalk, to create and update the
business rules and policies. As mentioned previously, business rule
authors use the Business Rule Composer to first create the vocabulary
required to define the different business rules and then proceed to
define their business rules grouped in the form of policies. The
different artifacts created by the business rule creator are then
compiled and persisted in the Business Rule Store. A service, the Rule
Engine Update Service, periodically checks the Business Rule Store for
changes to update the rule engine runtime.
Applications and orchestrations calling the rule engine to execute
policies use the interfaces exposed by the Business Rules Framework to
do so. Figure 1
shows the separation between the two experiences and how the different
components interact together to allow for the auto-update of business
rules at runtime.
As we mentioned earlier, a highly efficient rule
inference engine serves as the core compo-nent of the Business Rules
Framework, and it provides the execution context for a policy. The rule
engine is primarily composed of three main components:
An inference engine, also called the rule set executor,
is responsible for the evaluation of rule conditions and action
execution. The default rule set executor, implemented as part of the
Business Rules Framework, is a "discrimination network-based
forward-chaining inference engine designed to optimize in-memory
operation". The
inference engine uses forward chaining
of rules and conditions to evaluate and action the rules in a rule set.
Weighted priorities assigned to the different rules will affect the
engine's processing and reorder the execution of their actions.
A rule set translator
takes as input a rule set definition—a RuleSet object—and "produces an
executable representation of the rule set. The default in-memory
translator creates a compiled discrimination network from the rule set
definition"). A
custom translator can be assigned to a particular policy version through
the policy translator property. To assign a custom translator, the
policy author needs to identify the .NET assembly containing the rule
translator as well as the class implementing the IRuleSetTranslator interface in that assembly.
A rule set tracking interceptor
receives output from the inference engine—rule set executor—and
forwards it to the rule set tracking and monitoring tools that
facilitate the tracking and debugging of business rules' execution.
The discrimination network-based forward-chaining
logic of the inference engine consists of a three-stage algorithm for
policy execution. The stages are as follows :
Match. In the match stage, facts are matched against the predicates that use the fact type
using the predicates defined in the rule conditions. To improve
efficiency, pattern matching occurs over all the rules in the policy,
and conditions that are shared across rules are matched only once.
Partial condition matches may be stored in working memory to accelerate
subsequent pattern-matching operations. The output of the
pattern-matching phase consists of updates to the rule engine agenda. An
agenda is completed when all facts that are simultaneously present in
working memory are matched to all active policy rules. The agenda is
used by the engine to queue rules and schedule them for execution.
Conflict resolution.
In the conflict resolution stage, the rules that are candidates for
execution are examined to determine the next set of rule actions to
execute based on a predetermined resolution scheme. All candidate rules
found during the matching stage are added to the rule engine's agenda.
The default conflict resolution scheme is based on rule priorities
within a policy. ... Therefore if multiple rules are triggered, the
higher-priority actions are executed first.
Action.
In the action stage, the actions in the resolved rule are executed.
Note that rule actions can assert new facts into the rule engine, which
causes the engine to cycle again and start at the matching stage. This
is also known as forward chaining. It is important to note that the
algorithm never preempts the currently executing rule. All actions for
the rule that is currently firing will be executed before the match
phase is repeated. However, other rules on the agenda will not be fired
before the match phase begins again. The match phase may cause those
rules on the agenda to be removed from the agenda before they ever fire.
An
agenda exists per engine instance, and acts on a single policy only. A
rule's actions are placed on the agenda and executed according to their
priority, when facts are asserted and the rule's conditions are
satisfied. A rule's actions are executed as a block and in order from
top to bottom, before the execution of the actions of the next rule on
the agenda.
Table 1. Rules Definition
| Declarative Representation | IF—THEN Representation Using Business Objects |
|---|
| Rule 1: Evaluate Income | |
| An applicant's credit rating should be ob-tained only if the applicant's income-to-loan ratio is less than 0.2. | IF Application.Income / Property.Price < 0.2 THEN Assert new CreditRating(Application) |
| Rule 2: Evaluate Credit Rating | |
| An applicant should be approved only if the applicant's credit rating is more than 725. | IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725 THEN SendApprovalLetter(Application) |
Table 2. Facts Definition
| Fact | Field |
|---|
| Application: An XML document representing a home loan application | Income = $65,000 SSN = XXX-XX-XXXX |
| Property: An XML document representing the property being purchased | Price = $225,000 |
| CreditRating: An XML document containing the loan applicant's credit rating | Value = 0 – 800 SSN = XXX-XX-XXXX |
Initially, the rule engine working memory and agenda
are empty. After the application asserts the Application and Property
facts with the values detailed in Table 8-2 to the rule engine, the engine's working memory and agenda are updated, as shown in Table 3.
Rule 1 is added to the agenda because its condition (Application.Income
/ Property.Price < 0.2) evaluated to true during the match phase.
There is no CreditRating fact in working memory, so the condition for
Rule 2 was not evaluated.
Table 3. Engine's Working Memory and Agenda Before Execution
| Working Memory | Agenda |
|---|
| Application | Rule 1 |
| Property | Assert new CreditRating(Application) |
Because the only rule in the agenda is Rule 1, the
rule is executed and then disappears from the agenda. The single action
defined for Rule 1 results in a new fact (CreditRating document for the
applicant) being added to working memory. After the execution of Rule 1
completes, control returns to the match phase. Because the only new
object to match is the CreditRating fact, the results of the match phase
are as shown in Table 4.
Table 4. Engine's Working Memory and Agenda After the Execution of Rule 1
| Working Memory | Agenda |
|---|
| Application | Rule 2 |
| Property | SendApprovalLetter(Application) |
| CreditRating | |
At this point Rule 2 is executed, resulting in the
invocation of a function that sends an approval letter to the applicant.
After Rule 2 has completed, execution of the forward-chaining algorithm
returns to the match phase. Because there are no longer new facts to
match and the agenda is empty, forward chaining terminates, and policy
execution is complete .
