jBPM migration strategies - Introduction

For some time now I have been looking to put together my views and experience on how to position your current jBPM v3.2.x implementations for migration to a newer version. This article will outline some of the best practices within the four layers identified in general jBPM projects.

These ideas will be put forth based on the simple diagram provided here which outlines a typical enterprise business process implementation. It is not necessary to have all the various components in an implementation to be able to make use of the guidelines detailed in this article. The extensive list of components is provided to allow for discussion on the typical interactions I have encountered in my jBPM travels. In this introduction these layers will be outlined and future articles will cover them in more detail.

The idea behind each layer will be to identify best practices and ways to keep your implementations as jBPM version agnostic as possible. I believe this can be achieved, to a point, with proper knowledge and design time application of this knowledge. Each section will dive deeper into that specific area and try to provide you with the knowledge to design and implement your jBPM projects in such a way as to future proof them. You will be as ready as you can be to migrate to the next version.

The choice to focus on jBPM v3.2.x is due to the fact that this is currently the supported enterprise version provided in the JBoss SOA-P product. This is what many enterprises are currently using, throughout the world.

Process initialization layer
The first layer covers the details of providing flexible initialization of your processes within enterprises where you might have serious performance wishes, many different processes that can be initiated and allow for prioritising which process will be started when.

Process definition layer
This layer contains the process definition itself, a narrow layer that simply needs to be migrated to some future version of jBPM. Will this layer be jPDL, XPDL or some form of BPMN?

Process implementation layer
Here we dive into the underlying code layer that is best known as Handlers. The actual Java implementation that you may extended with abstraction layers, business logic and helper utilities. There is much to be cautious of here when looking to migrate your processes to a future version of jBPM, but there are some simple practices that will make migration less work than you think!

Process interaction layer
There is much to be won with a good strategy for accessing business logic, back-end systems, back-office systems, user interfaces, other applications or whatever your business processes need to use to get their jobs done. Here you will find a series of components passing review with suggestions for each one on the best way to position your projects for easy migration. A bit of prevention will go a long way in your IT budget!

General best practices
For as far as they have not been covered, I will provide some best practices with regards to any jBPM project. These will zoom in to a lower level than the above layers and can be applied across them all. If you get nothing out of these articles, I hope you will be able to make use of these gems of knowledge learned through harsh lessons in the trenches of jBPM projects.

Please feel free to provide feedback and suggestions for areas that might be missing. I am not trying to cover all possible use cases for jBPM projects, but to provide a reference architecture that is recognisable for the majority of enterprise jBPM users.

The next article in this series examines the process definition layer...