jBPM migration strategies (part II) - process definition layer

It has been awhile since this series of articles on jBPM migration strategies was launced with an Introduction. The reason for this was that there was a flurry of activity that included the jBPM5 Request For Comments, jBPM5 Roadmap, and finally the initial jBPM5 Alpha code release. It did not feel right to base these thoughts and ideas on assumptions or trying to guess what would be the final output of these activities. Now that jBPM5 has a real target, real direction and some code to base a migration strategy on, it is time to complete the rest of the articles on jBPM migration strategies.

Background
While the Introduction article laid out several areas of interest that require attention when we position and existing jBPM project for future migration, the process initialization layer, the process definition layer, the process implementation layer, the process interaction layer, and general best practices.

This article will cover some suggestions to help you position jBPM 3.2.x projects for migration to the coming next generation of jBPM, one that moves you to BPMN. It will also detail the status of jBPM and what will be the focus of a migration project will be explained, validating why we will be focusing on only jBPM 3.2.x initially.

Status of jBPM
When we are looking at the products produced by Red Hat that support enterprises we are talking about jBPM 3.2.x. This will be the initial focus of our migration efforts. It is what is supported for the coming years and where most implementations are based on that I have encountered.
The newest member of the jBPM family is jBPM 5 which will provide tooling to model processes in BPMN. The current jBPM 3.2.x models the process definition layer in jPDL 3 which we will need to map to BPMN. This tooling we will provide for you in the jBPM Migration Tool project. In this project you will find the outline of our plans which eventually will include more than just the process definition layer.

Processes designed for migration
When we are looking to migrate a process definition from jPDL 3 to BPMN it would be a good idea to think about how you are defining your processes. The tooling to be provided will map nodes, states, and sub-process node types, but you need to be aware that custom node extensions will not be taken into account. A good strategy would be to ensure that your process steps are designed to do one thing only. A single handler to be pointed to from your nodes and states for example. The more exotic you get with your process designs, the larger the chance that a straight forward conversion will not be possible. Try to keep your process work in the actual nodes and not in the transitions. The more visible it all is in your process definitions (images), the better.

Keep in mind, these are just guidelines and suggestions. All test cases you can provide to the jBPM migration tool project will be welcome and applied to the tooling to meet your needs.

jBPM migration tool project
Maurice de Chateau and myself have started working on the migration tooling we think is needed to take us into the jBPM future. We see a need for two separate parts to achieve our goals:

• process definition migration
• mapping API functionality (matrix)

The first item will be our initial development goal. We are currently evaluating a few possible solutions, but we plan to provide tooling to migrate jPDL 3 to BPMN through the following steps:

1. take input jPDL 3 file, validate against jPDL XSD
2. transform jPDL 3 to BPMN
3. take BPMN file, validate against BPMN XSD
4. test it against jBPM5 process engine (can is parse this?)

This tooling will be command line interface (CLI) only, to easily allow for integration into the JBossTools project. We envision developers being able to right click in their IDE and 'convert.' The tooling to migrate jPDL 4 to BPMN will be looked at later or left to the jBPM community as an exercise based on our initial solution.

We would also like to provide mapping of jBPM 3.2.x API methods to jBPM 5 API methods, but this is something that will need to stabilize in the coming releases. Think along the lines of scanning a code base or project, provide suggested mappings and provide a list of non-mappable calls or calls needing human intervention. More on this in the process implementation layer article to be covered in the near future.

The tooling will be implemented based on use cases, so you should be able to follow along as the tool evolves. We hope to have you out there supply use cases that won't work for you so we can improve the tooling for all. Let us know if you want to help!