Tutorial: JBoss Enterprise BRMS Best Practices
Red Hat’s Eric Schabell and Edson Tirelli offer some handy hints as how to get the most out of Red Hats JBoss Enterprise BRMS
Red Hat’s Eric Schabell and Edson Tirelli offer some handy hints as how to get the most out of Red Hat’s JBoss Enterprise BRMS.
DISCLAIMER – The article represents the personal views of Schabell and Tirelli, not of Red Hat.
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 Enterprise BRMS makes it possible with fully integrated business rules management, business process management (BPM), and complex event processing (CEP).
This article will provide you with an overview of our insights into creating process and rule based applications with JBoss Business Rules Management System (BRMS) 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 some basic insights to allow you to develop large scale applications.
In this article it is assumed you have a working knowledge of the JBoss BRMS product and will not cover the basics. A solid software architectural background is useful as this article discusses the design decisions being made and what you need to do so thatyour 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. Figure 1 below shows that there are several component layers where we will want to focus our attention:
- Initialization Layer
- Implementation Layer
- Interaction Layer
The process initialization layer will be covered first, where we present best practices around you, your customer and how processes can be started. The process implementation layer is where processes are 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 your processes will connect to all manner of legacy systems, back office systems, service layers, rules systems even third party systems and services.
Fig 1 – JBoss BRMS process architecture
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 injecting it by the call. This can be embedded in your application via the BRMS jBPM API call, make 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, system or user that provides the initial process starting data. In Figure 2 we provide a high level look at how our customers provide process data that we then package 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 EJBs, MDBs and clouds that represent any manner of scheduling that might be used to empty the process queues.
Fig 2: Queues and more
These queues can be as simple as database tables or as refined as message queues. They can be set up 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 twofold. First, you have made sure that by not directly starting the process instance from the customer interface, you have persisted the customer request. It will never be lost en 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 Figure 2 are representing any JEE mechanism you might want to use to deal with the process queues. It can be EJBs, MDBs, 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 jBPM API within a single service to ensure 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, 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 you can do during the designing of your processes.
There is within the JBoss BRMS BPM component one thing of interest for building highly scalable process architectures. This is the concept of a Stateful Knowledge Session (SKS). 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 KS (note, not stateful!) with all your rules and data leveraging this single KS. With a SKS and processes, we want to leverage a single SKS per process instance. We can bundle this functionality into a single service to allow for concurrency and to facilitate our process instance lifecycle management. Within this service you can also embed eventual synchronous or asynchronous Business Activity Monitoring (BAM) event producers as desired.
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 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 BRMS BPM architecture includes a separate Human Task (HT) server that runs as a service and implements the WS-HT specification. Being pluggable, there is nothing to keep you from avoiding hosting another server in your enterprise by exposing the WS-HT task lifecycle in a service. This should then use a synchronous invocation model which vastly simplifies the standard product implementation that leverages a HornetQ messaging system by default.
A second service that you can implement to provide great reporting scalability we call a BAM service. This service you would use to centralize the BAM events, use it to push these events to JMS queues which are both reliable and fast. A separate machine can then be used to host these JMS BAM queues, processing the messages without putting load on the BPM engine itself, write to a separate BAM database, optimize with batch writing and any clients that consume the BAM information will again not be putting any load on the BPM engine itself.
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.