Let's get down to business process management

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 Hat’s 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


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

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


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

Fig 1 – JBoss BRMS process

Initialization Layer

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
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.

Implementation layer

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
(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. 

Interaction layer

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

A second service that you can implement to provide great
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



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

BRE-enabled applications

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

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

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.

Rules Authoring

Don’t try to

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

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



rule “2 – Elders can
buy tickets in area A”


Person age is greater
or equal to 65


Allow sales of area A



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


Assert: the person is
an Elder


rule “1 – Teenagers
and Elders get discount”


Teenager or


Assign 25% ticket


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

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

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 :

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.

Author Bio

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.

Eric D. Schabell has been working within software development since 1998 for many different organizations such as IBM, Radboud University Nijmegen, SNS Bank and smaller software companies. He has been involved with Open Source projects such as Sourcemage Linux, eGroupWare, DocConversion, cmlFramework & still helping out in the JBoss jBPM project. Currently lead on jBPM Migration Project.
comments powered by Disqus