A Business Rule Perspective on a Standard Rule Language
Gary Hallmark
Gary.Hallmark@Oracle.com
This paper presents the position of the Oracle Business Rules development team toward a standard for rules. Our team is biased toward rules that execute in a Java enterprise application server and that provide infrastructure that allows business analysts to specify and modify their business processes and applications.
Benefits of Business Rules
Business rules capture important and time-changing business policies and store them in a repository separate from the application code. Business analysts can modify rules to respond to changing regulations, economic pressure, or customer demand. Rules make applications, and therefore the businesses they support, more agile.
Benefits of Business Rule Standardization
The benefit of technology standardization in general is that the cost and investment risk for consumers decrease because consumers are not tied to a single producer. Technology producers must become more competitive and innovative and in return, they produce better cheaper products that increase the size of the market for the technology. Producers may also specialize on a portion of the standard. For example, one producer could develop a rule engine while another develops a design tool.
A major consumer of business rule technology is enterprise business applications. Today, a large business typically integrates applications from many vendors. For example, a Siebel CRM system might recruit new customers, an Oracle invoicing system might bill them, and an SAP logistics system might ship to them. Though many of these businesses would like to move to a suite of applications from a single vendor, this is not easy. Each application has been extensively modified to support the business policies for its part of the business. If all applications used standard business rules to capture business policies, it would be much easier to switch application vendors and migrate the policies to the new application.
Other businesses may prefer a best of breed approach and continue to integrate applications from several vendors. Standard business rules would let all the rule-enabled applications share a common rule repository so that all rules can be viewed and modified in one place. Inference rules that span applications like "if a customer spent $500 last month then set his status to GOLD; if a customer's status is GOLD then discount his shipping by 50%" become easier to implement.
Requirements for Business Rule Standardization
Enough should be standardized to support real business applications. Otherwise, consumers won't enjoy the benefit of choice among several rule vendors. Following are characteristics that seem to be common among commercial business rule products.
The action part of a rule should be able to interact with the world. For example, it should be able to append to a log of rule firings, invoke a web service to retrieve new facts, remove facts from consideration, or update a database.
Rules should have XML syntax for interoperability and syntax familiar to business analysts. For example,
age of driver is less than 30
is better than
driver[@age < 30]
and
op:lt(age(?driver), 30).
It is okay for the business syntax to be supported by a tool or XSLT transformation.
A group of rules with a regular structure can be specified using spreadsheet-like decision table syntax. This syntax makes it easy to visually or automatically check for gaps or overlaps in rule coverage.
Some rules in a group may conflict. There must be one or more standard strategies to resolve conflicts. (A conflict occurs when the conditions of more than one rule are satisfied at the same time. A resolution strategy is the order in which those rules are fired.)
Support inferencing within a group of rules. Inferencing occurs when a rule action that adds, deletes, or modifies facts triggers another rule to fire whose action adds, deletes, or modifies facts, and so on.
The above characteristics suggest an implementation that relies on forward chaining production systems. Some support for backward chaining is also useful for fetching expensive facts on demand. For example, a rule might deny a loan if the applicant is jobless or has a poor credit history. Because job status is present on the loan application but credit history must be fetched (at some cost) from a credit bureau, it makes sense for the rule to fetch the credit history only if the applicant has a job.
Rules reason on facts. Facts may originate from XML, or they may originate in application objects such as Java beans or in database tables. A standard rule language must have a standard way to define facts that is independent of where those facts originate. A separate binding mechanism must be provided to handle the details of mapping to and from various data sources.
A fact definition encapsulates the binding information and stores additional metadata such as business-friendly names to use in rules. Commonly, facts are flat, not tree structured. A fact is a set of named fields and typed values. This allows simple rule syntax to reference fields of facts in rules. A highly structured document such as a purchase order would be mapped to several facts, possibly using the Java API for XML Binding (JAXB) or using an Xpath expression for each field.
When facts are bound to programming language objects, it must be possible to invoke methods on those objects, including the ability to invoke methods in rule conditions. Note that heavy use of a particular programming language binding in rules can limit the portability of those rules. This fact suggests that a standard rule language should provide a rich set of built-in functions and the ability to define and invoke new functions in order to minimize dependence on any particular programming language.
Rules should balance declarative and procedural semantics. Rules are seldom 100% declarative. Often, some kind of "rule flow" is required. For example, a number of rules might examine a shopping cart and propose a number of discounts, based on customer history and inventory levels. A "best discount" rule selects the maximum proposed discount. The "best discount" rule should not allowed to fire until all of the proposals have been generated.
Finally, a rule-enabled application needs to control the execution of rules on facts. Rules typically apply only to certain facts that have been "asserted", or inserted into "working memory".
One solution is to provide a web service for invoking rules. The service should provide methods to pass facts and rules to the rule engine, allow the rule engine to demand additional facts (backward chaining) and to return results and tracing/debugging information.