Assert like a boss

Red Hat JBoss BRMS & BPM Suite: Best practices

EricSchabell
like-a-boss

Get the most out of Red Hat’s BRMS & BPM Suite, with the help of Eric Schabell & Edson Tirelli.

Introduction

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). [1]

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.[2]

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.

Processes

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:

Initialization Layer

Implementation Layer

Interaction Layer

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.


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

Customers

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.

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.

Implementation layer

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.

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

Rules

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.

Goals

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.

BRE-enabled applications

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.

Architectural

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.

Rules Authoring

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.

References

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.

Author
EricSchabell
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
comments powered by Disqus