Information Technology Reference
In-Depth Information
Defining your architecture
In order to define the architecture for a BPM system, we first need to understand the neces-
sities such systems will have. There are many considerations to take into account when de-
fining these requirements, and we will try to explain the main ones here.
First of all, the main purpose of the BPM systems is to provide an environment where pro-
cess definitions can quickly change to adapt to a changing complex situation of the com-
pany domain, and how it will change to drive the company to its goals. This means we
need a way to quickly define the change in our processes, in a manner that it can be noti-
fied and impacted quickly in the runtime. In order to provide a quick way to change the
representation of our knowledge, we will use a repository strategy to quickly change con-
tent as well as to keep track of the changes introduced to the knowledge definitions used.
Secondly, we need to understand that even if initially just one or a few applications will use
the BPM system, it will grow to be the centric point of access for all the company process
definitions and runtimes. In order to cover such growth, the BPM system needs to provide
a strategy to be distributed between multiple nodes. In order to provide such functionality,
we need to handle our process instances through a persistence that should be synchronized
with transactions. This can be done by using another repository strategy: in the KIE Work-
bench case, this is done with a JPA database.
One final concept we need to cover in a BPM system is the possibility of running as many
tasks as possible in an asynchronous fashion. This will result in a more manageable envir-
onment, where threads are not just spawned on demand, but rather managed according to
the environment capabilities. In the KIE Workbench (and any other jBPM6-based environ-
ment), there is a component called
ExecutorService
, which provides a
org.kie.internal.executor.api.Command
interface to give asynchronous exe-
cutions seamlessly, in a way that it can handle failure retrial and thread pool management.
Allocating how many threads can be used at the same time from processes will limit the
chances of a BPM server from crashing due to excessive calls.
The overall structure of our BPM system architecture will look like the following diagram,
considering the integration of all the mentioned components:
