BizTalk Server 2009 : Use The Business Rule Engine (part 1)

1. What Is a Business Rule Engine?

An organization's most strategic assets are the products/services it provides to its customers as well as the business model and internal processes it uses to differentiate itself from its competition. An organization's IT department's most valuable assets are the data on products/services and customers of the organization as well as the workflows and business rules that drive the internal processes and business model. It is the IT department's main responsibility to ensure the agility of those assets.

Although data management and portability is being addressed by database management systems such as SQL Server and although workflow management and portability is usually addressed by business process management services such as the BizTalk orchestration engine, business rules are usually neglected. Most business rules today are implemented in procedural languages and code that is maintained by application developers and programmers. This ties up one of the most critical organizational assets and limits its agility. The cost and time required to update the business rules and underlying IT services within an organization that implements its business rules in procedural languages is too high for such an organization to react quickly to its business units' needs. Moreover, the business rules might be improperly translated from the design documents (written in a human language) to the procedural code, which contributes to problems and leads to inconsistency.

The BRE addresses these pains. It allows IT departments to properly isolate, consolidate, and manage their business rules and policies in a simple manner so that they can react to their organization's business process changes swiftly at low cost points. The Business Rule Engine allows business analysts to describe business policies and rules in a simple graphical or textual form without the need to use a typical procedural programming language. Those rules are then stored away from the rest of the enterprise applications in a separate business rule store managed by the Business Rule Engine. Isolating business rules from the invoking applications in such a manner allows business analysts and business rule authors to update the business rules dynamically to meet the changes required by their business units. Updating those business rules does not require any changes to enterprise applications or business orchestrations that invoke them, unless changes to those rules require new data input or alter the output in a way that requires updates to the calling application. Running applications will seamlessly fire the latest version of the updated business rules the next time they invoke them. Applications leveraging the BRE invoke business rules through the Business Rules Framework.

The Business Rules Framework is a Microsoft .NET-compliant class library. It provides an efficient inference engine that can link highly readable, declarative, semantically rich rules to any business objects (.NET components), XML documents, or database tables. Application developers can build business rules by constructing rules from small building blocks of business logic (small rule sets) that operate on information (facts) contained in .NET objects, database tables, and XML documents. This design pattern promotes code reuse, design simplicity, and modularity of business logic. In addition, the rule engine does not impose on the architecture or design of business applications. In fact, you can add rule technology to a business application by directly invoking the rule engine, or you can have external logic that invokes your business objects without modifying them. In short, the technology enables developers to create and maintain applications with minimal effort.

Rule engines optimize rule resolution performance. They can evaluate rules within the same policy in parallel and cache their results until the facts involved in their evaluation change. Business policies, or rule sets, are composed of multiple business rules. Figure 1 illustrates this composition. The order of the evaluation of the different rules within a policy may be controlled by setting priorities to these different rules. Rules are composed of a condition followed by a set of actions that are executed if the condition in question is evaluated to be true. Conditions are composed of operations—predicates—that can be performed on facts to result in a Boolean value. Facts may be part of an XML document, an entry in a relational database, a basic .NET type, or a .NET component. To retrieve the values of complex facts, fact retrievers, which are .NET components that implement a particular interface, may be used.

Figure 1. The composition of a business policy

The Business Rule Engine is composed of multiple components:

• The Business Rule Composer allows business rule authors to identify the sources for the different facts used within their business rules as well as define and version their business policies and business rules.

• The Business Rule Store holds the definition of those business policies and facts.

• The in-memory cache holds the results of the evaluation of the different business rule conditions.

• The Business Rules Framework is used by application developers or orchestration developers to call business policies and execute different business rules from within their applications or orchestrations.

• The Business Rules Update Service monitors the Business Rule Store for published updates of policies and rules to deprecate older versions from the cache and reevaluate conditions as needed.

2. What Are Business Rules?

As explained in "Implementation Guide of BizTalk's Business Rules" (Xi, 2005),

Business rules (or business policies) define and control the structure, operation, and strategy of an organization. Business rules may be formally defined in procedure manuals, contracts, or agreements, or may exist as knowledge or expertise embodied in employees. Business rules are dynamic and subject to change over time, and can be found in all types of applications. Finance and insurance, e-business, transportation, telecommunications, Web-based services, and personalization are just a few of the many business domains that are governed by business rules. Each of these business domains shares the need to convey business strategies, policies, and regulations to information technology (IT) personnel for inclusion into software applications.

As mentioned previously, a rule consists of a condition and a set of actions. If the condition is evaluated to true by the BRE, the actions defined in the rule are executed.

Traditional procedural and object-oriented programming languages, such as C, C++, and Microsoft Visual Basic, are oriented toward programmers, thus limiting the ability of nonprogrammers to participate in the maintenance of automated business policies. Even advanced object-oriented languages, such as Java and C#, are still primarily programmers' languages. The Business Rule Engine and the Business Rules Framework address this problem by providing a development environment that enables rapid application creation without the lengthy cycle of traditional application programming. For example, business policies constructed by using this framework can be updated without recompiling and redeploying the associated orchestrations (Xi, 2005).

3. When to Use the BRE?

Traditionally, rule engines have been used for such things as credit scoring and underwriting in financial organizations because of the volume and complexity of business rules that these applications require. Using a procedural programming language to code such rules directly into an application makes application maintenance difficult and expensive, as these rules change often. The difficulty in maintaining these rules is encountered even in the initial release of the application, since such rules often change between the time the code is written and the time it's deployed. Hence, rule engines were devised to separate business rules from application logic (Moran).

Although simple runtime rule customization can be implemented by using database tables or configuration files to store values for facts used in business rules, a rule engine offers much greater flexibility than simple database tables or configuration files. A rule engine allows you to isolate the condition as well as the action from the application flow. You can simply update a rule's condition, change values associated with facts, or change actions in a rule altogether without the need to recompile and redeploy the application.

So when do you use the BRE and when do you keep your rules outside the BRE? A rule engine is suitable when your application involves significant decision making; the rules are complex or change frequently; the rules need to be shared across multiple applications and organizations; or you are in a volatile industry sector where change is the norm or regulation is extensive and complex. Maintaining your rules in custom code that may be configured through database value lookups or configuration files is suitable when the rules are mostly static and computational, or are simple, even if numerous; speed and throughput are more important than flexibility and maintenance cost; or your business rules are never expected to change in the future (eFORCE).