Let's get down to business process management
Tutorial: JBoss Enterprise BRMS Best Practices - Part 2
While BPM is focused on modeling a sequence of actions with well-defined flows, Business Rules Management (BRM) technologies are for modeling actions that are loosely coupled and are triggered by scenarios. An easier way of thinking about this concept is to remember the most common use case for rules implementation: Decision Management.
Generally speaking, Decision Management is the externalization and consolidation of all the rules and variables (data) involved in decision making for a given domain as well as their management. These consolidated rules are then made available to applications through decision services and can be centrally managed, audited and maintained. They will have an independent life-cycle from user applications as well as providing other benefits.
What are some of the goals of adoption of Business Rules Management to applications in general?
Decision automation: The first benefit is the automation of decisions in the business application. Here we are talking about day-to-day, operational decisions that take the bulk of the time in any business environment. We are not referring to the long term, strategic decisions that require human intervention. The reality is that the vast majority of operational decisions in a business can be automated, thereby lowering response times and improving business performance. It also allows more quality, consistency and the ability to audit decision processes over time.
Expressiveness and visibility: Business Rules Engines (BRE) usually provide higher level metaphors and higher level languages for the authoring of rules. By using these higher level representations, rules become more concise making them easier for business users to understand and verify. It also empowers business users to author the rules themselves.
Performance and scalability: BRE have specialized algorithms for the compilation and execution of rules that outperform hand coded rules by automatically optimizing them. JBoss BRMS can efficiently execute and scale to hundreds of thousands of rules.
Centralization of knowledge: By externalizing and consolidating rules, businesses can confirm that the rules are correctly implemented and are consistent among all applications that use them. This architecture also promotes a clear separation between logic, data and tasks, allowing the enterprise to improve agility and time to market. Finally, by centralizing business knowledge, it can be audited for compliance and optimizations.
Developing BRE-enabled applications is not so different from developing traditional applications, but there are some best practices that can be followed in order to maximize the benefits provided byBRMS tools. The next section is a list, in no particular order, of some of these best practices grouped under architectural and authoring practices.
Knowledge Base Partitioning
A Knowledge Base usually will contain assets such as rules, processes and domain models that are related to one subject, business entity or unit of work. Understanding how to partition these assets in knowledge bases can have a huge impact on the overall solution. BRMS tools are better at optimizing sets of rules than they are at optimizing individual rules. The larger the rule set, the better the results will be when compared to the same set of rules split among multiple rule sets. On the other hand, increasing the rule set by including non-related rules has the opposite effect as the engine will be unable to optimize unrelated rules. The application will still pay for the overhead of the additional logic. As a best practice, users should partition the knowledge bases by deploying only the related rules into a single knowledge base. Users should also avoid monolithic knowledge bases as well as those that are too fine grained.
Knowledge Session Partitioning
The creation of Knowledge Sessions is designed to be inexpensive with regard to performance. BRMS systems typically scale better when increasing the number of rules and scale worse when increasing the volume of data (facts). We can therefore infer that the smaller the knowledge sessions are, the better the overall performance of the system will be. Individual sessions are also simple to parallelize, so a system with many sessions will scale better on hardware with multiple processors. At the same time we should minimize the fragmentation of data or facts, so we want to include only the related facts in the same session with the related rules. This typically comprises the facts relative to a transaction, service or unit of work. When creating a session, it is more desirable to add all the facts to the session in a batch and then fire the rules than it is to add individual facts and fire the rules for each of them.
Domain Model Design
A BRE is in many ways similar to a database, from the underlying relational algorithms to the optimizations like data indexing. It is not a surprise then that many of the best practices that are documented for the use of databases also apply to BRE. One of the most important is to carefully design the domain model. The quality of the domain model is directly proportional to the performance and maintainability of the rules. A badly designed domain model not only affects the runtime of the engine, but also increases time and cost as rules will be more complex to author and harder to maintain over time. A good domain model is one that represents the relationships between the multiple entities in the simplest way possible. Flatter models usually help making constraints easier to write while small entities (entities with few attributes) help prevent loops.
Don't try to micro-control
Rules should execute actions based on scenarios, these are the conditions of the rules. By following this simple principle rules remain loosely coupled, allowing rule authors to manage them individually. Rule engines further optimize the rules that are decoupled. Use conflict resolution strategies like salience, agenda-groups or rule-flows only to orchestrate sets of rules, never for individual rules.
Don't overload rules
Each rule should describe a mapping between one scenario and one list of actions. Don't try to overload the rules with multiple scenarios as it will make long term maintenance harder. It also increases the complexity of testing and unnecessarily ties the scenarios to each other. Leverage the engine's inference and chaining capabilities to model complex scenarios by decomposing it into multiple rules. The engine will share any common conditions between scenarios, so there is no performance penalty for doing so. For example:
rule “1 – Teenagers and Elders get Discount”
Person age is between 16 and 18 or Person age is greater or equal to 65
Assign 25% ticket discount
rule “2 – Elders can buy tickets in area A”
Person age is greater or equal to 65
Allow sales of area A tickets
The above rules are overloaded. They define in the same rules policies for what a teenager or elder is, as well as the actual actions that should be taken for those classes of people. Pretend that the company had 1000 rules that apply to elders and in each rule, it would repeat the condition “Person age is greater or equal to 65” to check for Elders. Imagine that the company policy for Elders, or the government law about it, changes and a Person with age 60+ is now considered an Elder. This simple policy change would for a change in all of the 1000 existing rules, not to mention test scenarios, reports, etc. A much better way of authoring the same rules would be to have one rule defining what an Elder is, another defining what a Teenager is, and then all the 1000 rules just using the inferred data. For example:
rule “0.a – Teenagers are 16-18” rule “0.b – Elders are older than 65”
Person age is between 16 and 18
Assert: the person is a Teenager
rule “0.b – Elders are older than 65”
Person is older than 65
Assert: the person is an Elder
rule “1 – Teenagers and Elders get discount”
Teenager or Elder
Assign 25% ticket discount
When authored like this the user is leveraging the inference capabilities of the engine while making the rules simpler to understand and maintain. Also the same change of policy for elders would only affect one single rule among the 1000 rules in our example, reducing costs and complexity.
Control facts are a code smell
Control facts are facts introduced in the domain and used in the rules for the sole purpose of explicitly controlling the execution of rules. They are arbitrary and don't represent any entity in the domain and usually are used as the first condition in a rule. Control facts are heavily used in engines that don't have the expressive and powerful conflict resolution strategies that JBoss BRMS has and have many drawbacks: they lead to micro-control of rule executions, they cause massive bursts of work with unnecessary rule activations and cancellations. They degrade visibility and expressiveness of rules, making it harder for other users to understand as well as create dependencies between rules. Control facts are a code smell that should be avoided as a general best practice. Having said that, there is only one use case where control facts are acceptable, and that is to prevent an expensive join operation that should not happen until a given condition is met.
Right tool for the right job
JBoss BRMS has many advanced features that help users and rule authors model their business. For instance, if one needs to query the session for data in order to make a decision, or to return data to the application, then a user should use queries instead of rules. Queries are like rules but they are always invoked by name, never execute actions and always return data. Rules on the other hand are always executed by the engine (can't be invoked), should always execute actions when they match and never return data. Another feature that JBoss BRMS provides is the declarative models, i.e., fact types declared and defined as part of the knowledge base. For example:
name : String
age : int
Declarative models are a great way to develop quick prototypes and to model auxiliary fact types that are used only by rules, not by an application. JBoss BRMS integrates natively with domain models developed in POJOs and the use of POJOs simplifies application integration, testing and should be preferred whenever rules and application use the same domain entities.
Eric D. Schabell is the JBoss technology evangelist for Integration and BPM products at Red Hat. He is responsible for various outbound technical aspects of promoting JBoss Enterprise Middleware integration products and services (BRMS/BPM, SOA, and data integration). He has been working within software development since 1998 for many different enterprises. Follow this blog at http://www.schabell.org.
Edson Tirelli is a principal software engineer at Red
Hat and has more than 10 years of experience in middleware and
telecom solutions. He has been working on the Drools project and
the JBoss Enterprise BRMS product design and development since 2006
and is the lead engineer of the Drools Fusion CEP module. His
interests are AI in general, specially inference engines, language
design, and development and compilers.
- Introduction and Layers
- Rules and Goals of BRM