Red Hat JBoss BRMS & BPM Suite: Best practices
Get the most out of Red Hat’s BRMS & BPM Suite, with the help of Eric Schabell & Edson Tirelli.
Business experts and application developers in organizations of any size need to be able to model, automate, measure, and improve their critical processes and policies. Red Hat’s JBoss Business Rules Management System (BRMS) makes it possible with fully integrated business rules management, and complex event processing (CEP). 
Red Hat JBoss Business Process Management (BPM) Suite is a comprehensive platform for business process management that can be deployed across physical, virtual, mobile, and cloud environments. It includes all the business rules and CEP capabilities of JBoss BRMS , along with advanced tools and runtime support for Business Process Model and Notation v2.0 (BPMN2)-compliant business processes.
For the rest of this article we will refer to only the JBoss BPM Suite, as it contains all of the capabilities of JBoss BRMS, making it a super-set containing all of the functionality that will be covered in this article (rules, events, and processes).
This article will provide you with and overview of our insights into creating process and rule based applications with JBoss BPM Suite that can be scaled to handle your current and future enterprise project needs. We will cover both process based and rule based applications, providing you with the basic insights to ensure you can develop large scale applications.
In this article it is assumed you have a working knowledge of the JBoss BPM Suite product and will not be covering the basics. A solid software architectural background is useful as this article discusses the design decisions being made and how to ensure your project(s) will scale in your enterprise architecture moving forward.
Finally, we will not be examining the CEP component in this article.
To start with we need to take a closer look at a typical enterprise landscape and then peel back the layers like an onion for a closer look at how we can provide BPM projects that scale well. Illustration 1 shows that there are several component layers where we will want to focus our attention:
The process initialization layer will be covered first where we present some best practices around you, your customer and how processes can be started. The process implementation layer is where the processes are being maintained, with help from the process repository, tooling, business users and developers that design them. Here you will also find the various implementation details, such as domain specific extensions to cover specific node types within our projects. Finally, the process interaction layer is where you processes will connect to all manner of legacy systems, back office systems, service layers, rules systems even third party systems and services.
Taking a look at how to initialize your processes, we want to provide you with some of the best practices we have seen used by large enterprises over the years. There seems to be a main theme of gathering the customer, user or system data that is needed to start your process, then just injecting it by the startProcess call. This can be embedded in your application via a JBoss BPM Suite API call by making use of the RESTful service or via a standard java web service call. No matter how you gather the data to initialize your process instances, you might want to think about how you would want to scale out your initialization setup from the beginning. Often the initial projects are setup without much thought as to the future, so certain issues have not been taken into consideration.
The customer defined here can be a person, a system or some user that provides for the initial process starting data. In illustration 2 we provide a high level look at how our customers provide process data that we then package up into a request to be dropped into one of the process queues. From the queues we can then prioritize and let different mechanisms fetch these process requests and start a process instance with the provided request data. We show here EJB’s, MDB’s and clouds that represent any manner of scheduling that might be used to empty the process queues.
These queues can be as simple as database tables or as refined as message queues. They can be setup any way your project desires, such as Last-In-First-Out (LIFO) or First-In-First-Out (FIFO). The benefits of using message queues is that you can prioritize these from your polling mechanism.
The reason for this setup is two fold. First, you have ensured that by not directly starting the process instance from the customer interface that you have persisted the customer request. It will never be lost in route to the process engine. Second, you have the ability to prioritize future processes that might not be able to meet project requirements like a new process request that has to start in 10 seconds after submission by the customer. If it gets put at the bottom of a queue that takes an hour to get to processing it, you have a problem. By prioritizing your queues you can adjust your polling mechanism to check the proper queues in the proper order each time.
Java / Cloud
The java icons shown in illustration 2 are representing any JEE mechanism you might want to use to deal with the process queues. It can be EJB’s, MDB’s, a scheduler you write yourself or whatever you want to come up with to pick up process requests.
The cloud icons are meant to represent services that can be used by your software to actually call the final startProcess method to initialize the process instance being requested and pass it initial data. It is important to centralize this interaction with the JBoss BPM Suite core API into a single service thereby ensuring minimal work if the API should change, for possible version migrations in the future and should you wish to expand it in future projects to extend the service interaction with jBPM.
This layer focuses on your business process designs, your implementations of custom actions in your processes and extensions to your ways of working with your processes. The adoption of the standard BPMN2 for process design and execution has taken a lot of the troubles out of this layer of your BPM architecture. Process engines are forced to adhere and support the BPMN2 standard which means you are limited in what can do during the designing of your processes.
There is within the JBoss BPM Suite one thing of interest for building highly scalable process architectures. This is the concept of a Session, specifically a Stateful Session (SS). This is created to hold your process information, both data and an instance of your process specification. When running rules-based applications it is normal procedure to run a single session (note, not stateful!) with all your rules and data leveraging this single session. With a SS and processes, we want to leverage a single SS per process instance. We can adjust our deployments to leverage this SS per instance allowing for concurrency and to facilitate our process instance lifecycle management.
There is much to be gained by a good strategy for accessing business logic, back-end systems, back-office systems, user interfaces, other applications, third-party services or whatever your business processes need to use to get their jobs done. Many enterprises are isolating these interactions with a service layer within a Service Oriented Architecture (SOA) which provides for flexibility and scales nicely across all the various workloads that may be encountered. Taking a look at the BPM layer here we want to mention just a few of these backend systems as an example of how to optimize your process projects in your enterprise.
The JBoss BPM Suite architecture includes a separate Human Task (HT) server that runs as a service that implements the WS-HT specification. Being pluggable there is nothing to prevent you from hosting another server in your enterprise by exposing the WS-HT task lifecycle in a service.
The Business Activity Monitor (BAM) component is now a setup to be self-sufficient and access datasources drirectly as per user configuration. You can design and create all manner of useful reporting and no longer need to work about any setup of event producers or queues.
While BPM is focused on modeling a sequences of actions with well defined flows, Business Rules Management (BRM) technologies are better suited to model actions that are loosely coupled and 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 and most obvious 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 it 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. A BRMS can efficiently execute and scale to hundreds of thousands of rules.
Centralization of knowledge: by externalizing and consolidating rules, businesses can ensure 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 than developing traditional applications, but there are some best practices that can be followed in order to maximize the benefits that BRMS tools provide. The next section is a list in no particular order of some of these best practices grouped under architectural and authoring practices.
KIE Base Partitioning
A Knowledge Is Everything (KIE) Base, or KieBase for short, 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 KieBases 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. The first best practice is then to partition the KieBases by deploying only the related rules into a single KieBase. Avoid monolithic KieBases as well as too fine grained KieBases.
KIE Session Partitioning
The creation of KieSessions is designed to be very inexpensive with regards 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 KieSessions 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 possible way. 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 optimize further 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 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” when Person age is between 16 and 18 or Person age is greater or equal to 65 then Assign 25% ticket discount end
rule “2 – Elders can buy tickets in area A” when Person age is greater or equal to 65 then Allow sales of area A tickets end
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” when Person age is between 16 and 18 then Assert: the person is a Teenager end
rule “0.b – Elders are older than 65” when Person is older than 65 then Assert: the person is an Elder end
rule “1 – Teenagers and Elders get discount” when Teenager or Elder then Assign 25% ticket discount end
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 inefficient
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 expressive and powerful conflict resolution strategies that JBoss BPM Suite 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 inefficient 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 BPM Suite has many advanced features that help users and rule authors to 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 BPM Suite provides is the declarative models, i.e., fact types declared and defined as part of the knowledge base. For example:
declare Person name : String age : int end
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 BPM Suite 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.
1. Red Hat JBoss Business Rules Management System (BRMS), http://www.redhat.com/products/jbossenterprisemiddleware/business-rules.
2. Red Hat JBoss Business Process Management (BPM) Suite, http://www.redhat.com/products/jbossenterprisemiddleware/business-process.