Understanding Rule-based Systems

Rule-based systems vary greatly in complexity. Rules are usually stored in some repository, such as a database. The total collection of rules is known as the rule base or knowledge base. Simple rule-based systems typically utilize an IF. . .THEN format to store rules. Each rule lists a condition (the if part) that must be met for the rule to be true. The rule also specifies what action or result (the then part) must take place.

There is no set standard for forming rules, but they should be based on meaningful and clear ideas. Since the rules need to be formalized in written language that dictates programmatic action, it may take some time to create a useful rule base.

The sample application in this chapter will parse human language and then use rules to determine how data should be stored in a database.

Note

The sample application in this chapter will parse a sentence and use rules to determine how the data should be stored in a database. The portion of code that examines the sentence is not the same as natural language processing (NLP). NLP is a complex process that attempts to understand human language. It is discussed further in Chapter 9.

The Phases of Rule-based Systems

Applications that use rules may apply them in a four-phase process. The phases are as follows:

1.	The Condition Matching phase involves looping through all the rules and determining which ones have true conditions. Depending on the input data, several rules may be true. In some cases the actions associated with these rules may conflict.
2.	A Priority Evaluation phase is necessary in order to determine which rules should be applied. A priority value is assigned to each rule. This phase may indicate the order in which the rules should be applied or may eliminate conflicting rules.
3.	The third phase, the Application of Results phase, involves the execution of the rules identified in the second phase.
4.	Since the application may execute an inappropriate action, there is usually an Adjustment phase. This final phase requires that a human expert review the decisions made by the application. If a wrong decision was made, the expert will either add, delete, or change some of the rules.

The final phase is the most critical one. It is not realistic to expect that rules will never have to be changed once they are defined. Just as a human employee must be trained and then retrained, so too does a successful rule-based system.

BizTalk Server 2004

BizTalk Server 2004 is a development tool that can be used by developers and non-developers to automate certain business processes. The main purpose of the tool is to facilitate communication between applications. The applications can exist on a single network or across networks for different companies.

The 2004 version of BizTalk Server is built around the .NET framework, and solutions can be created inside Visual Studio.NET. It utilizes XML files and Web Services to connect different applications. You can connect applications of many kinds, ranging from those running on a mainframe to those running on a Windows-based network.

The Business Rule Composer, new with this version of BizTalk Server, is a tool that allows users to create new rules and modify existing ones. The rules are then processed by the Business Rule Engine.

Users can start by creating a vocabulary that maps friendly, nontechnical names to the variables used to build rules. Terms can be associated with fields in a database table or an XML document. They can also be associated with the results of complex database queries. A vocabulary is useful for situations in which people who are not developers use the composer to build rules. Terms in the vocabulary are more meaningful than the items they are associated with. A vocabulary is not required to build rules, but it can be helpful.

Rules are defined in an If. . .Then format. If certain conditions evaluate to true, a corresponding action is initiated. The conditions operate on facts that apply to terms defined in the vocabulary. Multiple facts can be combined with operators like "AND," "OR," or "NOT." The actions are invoked by calling methods, setting properties, or manipulating documents or database tables.

Once the rules are defined, they are grouped together to form policies. In most cases, every application will have its own policy. Once tested, all the rules can be published together through the policy as a policy version. A policy can be deployed independently of the associated application so that the code does not have to be recompiled when the policy is changed.

The Business Rule Engine is encapsulated within a .NET namespace, and its functions can be invoked by other .NET applications. You can write custom .NET applications that utilize the Rules Engine without using BizTalk Server 2004.

The main benefit of using the Business Rule Engine in BizTalk Server is that rules can be created by the people who are most familiar with the actual business policies even if they are not developers. In addition, rules can be changed without any need for a code recompile.

BizTalk Server is not a magic bullet and is by no means the optimal development solution for all business applications. But it can be a great time saver for applications that need to easily automate business processes and facilitate communication between applications. It can also be the best way to tap into a company's expertise through the knowledge of its employees.