Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Programming with the Microsoft Business Rules Framework : Page 3

Learn how to decouple the business rules within your application to yield high organizational visibility and accountability.


advertisement
Introducing Microsoft Business Rules Framework
The Microsoft Business Rules Framework is a fully functional rule framework originally intended for plugging in various rule executors and translators. The Microsoft Business Rules Engine (BRE) is Microsoft’s implementation of their rule language and corresponding translator components, as well as execution components based on the Rete algorithm (defined later). The BRE plugs into the Microsoft Business Rules Framework.

A rule-based engine isolates business rules from the application making the rules eminently reusable (and not to mention testable).

While the Microsoft Business Rules Framework and BRE are still relatively new (both were originally released with Microsoft BizTalk Server 2004), the Rete algorithm is not. The Artificial Intelligence Journal published a paper by Dr. Charles L. Forgy in 1982 entitled "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem." Dr. Forgy first published his research work on the Rete algorithm in 1974.



Rete is an efficient pattern-matching algorithm capable of evaluating rules at a very high rate of speed, with little regard for the number of rules being considered. The algorithm works by cross-checking a business fact with business policies to determine which rules should be considered for execution. If a rule does not need to be considered, it is skipped altogether. Also known as an inference-based rules engine, the Microsoft BRE also supports "forward chaining" of business rules, which causes the BRE to re-evaluate rules in a policy when the action of a rule that has fired causes a change to the state of a fact that has otherwise already been asserted.

Dr. Forgy first published his research work on the Rete algorithm in 1974 as an efficient pattern-matching algorithm capable of evaluating rules at a very high rate of speed.

Although the Microsoft Business Rules Framework (and MS BRE) ships with Microsoft BizTalk Server 2004, 2006, and 2006 R2, this is where any association to BizTalk Server ends. Microsoft defines the BRE as a stand-alone application consisting of a number of modules, support components, and tools. The primary modules include the Business Rules Composer for constructing policies, the Rules Engine Deployment Wizard for deploying policies created in the Business Rules Composer, and the Run-Time Rule Engine that executes policies on behalf of a host application. You'll see more detail later, using a practical example of how to create a business rule within a policy, and call it from a .NET application.

What It Isn't
Although MS BRE ships and installs with BizTalk Server, it's separate. You can take full advantage of MS BRE without BizTalk Server messaging or orchestration. This means that if you choose to install only MS BRE on a machine, you can do so with a very small footprint. However, keep in mind that because MS BRE is not a separate SKU, you can get it only with BizTalk Server, and therefore, you must meet licensing requirements for BizTalk Server even if you only use MS BRE. While this may sound intimidating, doing any amount of market research on competing rule-based engines will quickly prove that the price point for the Developer and Standard editions of BizTalk Server 2006 makes MS BRE a compelling choice for bringing a fully functional rules engine into the enterprise.

Author's Note: A gentle reminder: Please remember that although the Microsoft Business Rules Framework and BRE components are fully functional in a standalone configuration, any machine running BRE, or any other BizTalk Server components must be fully licensed for BizTalk Server 2006 or better.

In addition, MS BRE has nothing to do with Windows Workflow Foundation (WF) Rules. While there are similarities, it is important to understand that MS BRE is a product that is developed, maintained, and supported by a different product team inside Microsoft. WF is not a product. WF is a framework for building workflow enabled applications and services. WF supports the execution of business rules; however, the features provided in WF Rules in the current shipping version of .NET 3.5 pale in comparison to MS BRE. WF Rules lacks a rule editor that can be used outside of the developer role, and it lacks a rule repository. Like most of the features in WF, this makes WF Rules a solid starting point for building additional rule-based engine functionality, but at its core, WF merely provides an engine capable of executing rules. In fact, in early drops of WF, WF workflows were calling Microsoft BRE to demonstrate proof of concept scenarios before WF Rules were fully baked. While Microsoft has not taken a position on the future of each offering, I can only speculate that these competing offerings will converge, perhaps as part of the Oslo vision. Until then, I believe (and others agree, see the useful links at the end of this article) that MS BRE is a stronger choice for integrating rule-based engines into your applications and services.

Microsoft Business Rules Framework Architecture
The architecture for MS BRE is composed of both design-time and run-time components. As shown in Figure 1, the design-time components (such the Business Rules Composer) are provided via a separate user interface that runs outside of Visual Studio. These design-time components manipulate the Vocabulary, Rule Store, and Rule Set object model. While the BRE is a first-class citizen in BizTalk Orchestration, you'll see how to work exclusively with the Business Rules Composer and Visual Studio 2008 to develop, test, and execute the rule set in this article.

Figure 1. Business Rules Framework Diagram: The Microsoft Business Rules Framework consists of design-time and run-time components. Diagram courtesy of Microsoft Corporation.

The Vocabulary Object Model lets developers and business analysts use the Business Rules Composer to create domain-specific definitions for data or facts represented in various states.

The Rule Set object model lets developers and analysts build the rules, which consist of raw facts that can be either XML message-based, .NET objects, or a field in a database table or in-memory dataset. Rules are grouped according to business domain, and are logically organized as Policies. For example, the earlier rule "If the customer is a preferred member, always apply a 10 percent discount on the total checkout price" might be just one rule in a rule set logically represented as the discount policy for the company.

Vocabularies and policies/rule sets need to be persisted to the Rule Store. The Business Rules Composer uses the Rule Store object model for persistence. By default, the Rule Store is a SQL Server database; however, it is possible to use a file or other backing store (with some elbow grease, of course). Using SQL Server as the default repository for policies and vocabularies has some obvious performance and management benefits. Rules and vocabularies are serialized to BRL (Business Rules Language), which as you might imagine is an XML representation of the policy and rules.

From a run-time perspective, an application, such as a Smart Client, Console, WCF Service, WF application, or BizTalk Orchestration, works with a Policy class that provides the integration glue with the BRE. The Policy works with an instance of the Rule Engine class, thus shielding the developer and application from intimate details about the BRE itself.

Rules built with the Rule Set object consist of raw facts, which can be either XML message-based, .NET objects, or fields in a database.

The Rule Engine class is the workhorse behind the BRE and is responsible for the execution of the business rule policies. The Rule Engine class takes a policy (rule set) name as an argument, along with corresponding facts and determines which rules are applicable given the facts, translates the rules from BRL to in-memory object graphs, and executes the appropriate rules. I will cover this in more detail later, but it is important to understand that every rule has a condition, a predicate, and an action. This means that given our now canonical rule ("If the customer is a preferred member, always apply a 10 percent discount on the total checkout price"), if the rule executes, and the condition in the rule evaluates to true, the 10 percent discount will be performed.

Finally, a Windows Service, known as the Rule Engine Update Service, monitors the Rule Store for changes to rules or policies. When a change occurs, the Rule Engine Update Service updates the Rule Engine’s local cache to ensure that Rule Engine instances bound to a live Policy instance are updated in real time, and also ensure that any subsequent Policy invocations use an instance of the Rules Engine synchronized with the Rule Store.

The magic of the BRE is that it performs well because it is inference based—the BRE will consider only rules that apply to a given fact. Instead of looping through dozens, hundreds, or thousands of rules, the BRE creates an agenda of rules to execute that are associated with the fact. This could be a single rule or several. After adding the rules to the agenda, it executes them one by one until the execution cycle terminates. This means that you might have one or several corresponding actions resulting in a number of rules firing. I'll cover agenda and priority, and provide an example of forward chaining toward the end of this article.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap