What does JBoss mean by BPM

Written By: Peter Abrahams
Content Copyright © 2005 Bloor. All Rights Reserved.

The primary role of an IT Analyst is to understand what we are being told. Therefore, it is imperative never to go to a briefing with any preconceptions of what words or phrases mean, but always ask the speaker for their definition.

This is probably no more true than with the acronym BPM. The first task is to agree what the letters stand for – it is normally Business Process Management (but even that is not certain). This does not help a lot because I have discovered that anyone who uses the term, including myself, has a specific slant on its meaning; so it means ‘whatever one intends it to mean at the time it is said’.

I was reminded of this need for an open mind by the title of a briefing by JBoss: “JBoss jBPM: Workflow, BPM & Orchestration made easy”.

I understand from this that their Business Process Management product (jBPM) provides functions for:

  • Workflow: the ability to hand off a process to a human workflow process system and wait for the decision/result to come back.
  • Orchestration: the ability to integrate several external services into a process flow using a language like Business Process Execution Language (BPEL).
  • BPM: the ability to integrate programme logic together, especially integrating Java objects together to implement a business process.

This second use of BPM I find odd as it is limiting it to a specific technology, and I am sure that my colleague, Terry Schurter, would find it even odder as he understands the term to include the managing of business processes totally independently of technology. It is also odd that, by implication, the definition means that orchestration is not part of BPM; I believe most of the rest of the industry would disagree with this definition. The separation of workflow from BPM is less contentious as this distinguishes the human workflow from the automated processes – but even this is somewhat contrived.

I think that the product could be better described as: “JBoss jBPM: human workflow, service orchestration and logic integration made easy”, implying that all three functions are needed in a BPM solution.

However, for the rest of this article I will stick to JBoss’s limited definition of BPM.

The developers of jBPM realised that there were two things that a Java programmer needed in order to support the implementation of business processes:

  • A way for business analysts and process developers to communicate clearly.
  • An ability to support long wait states (for example two stages in a business process can easily be separated by several days, or even longer).

Business processes will always have a process flow and this can be described with a diagramming technique called Graphic Oriented Programming (GOP). GOP consists of nodes, where processing occurs, and transitions between the nodes. One node may have several transitions out; which transitions are taken depend on the outcome of the processing in the node. There are special nodes for the start and completion of a process. There is also the ability to fork, so that several nodes can run in parallel and then the flows can join back together later. GOP has been verified as being able to describe any process flow by comparing it to the academic analysis documented at workflowpatterns.com.

Once a process flow has been agreed between the analyst and the developer, then the developer can fill in the detailed implementation by adding ‘actions’ to the nodes and transitions. These ‘actions’ are invisible to the analyst and therefore do not change the GOP diagram. The diagram and the ‘actions’ are stored as XML documents using a special language: Java Process Definition Language (JPDL).

JPDL and BPEL are both process definition languages. The difference is that JPDL is much better integrated with Java logic, as its name implies, and JBoss claims that it is much simpler than BPEL.

Once a process has been stored in JPDL it can be executed by interpreting the JPDL and by keeping the status of a particular invocation in a set of tokens. This solves the long wait state problem because when a process is waiting, the tokens can be persisted to a database and jBPM can reinstate the process when it becomes active again by reinstating the tokens.

Because jBPM is Open Source it is an interesting way to start looking at how to define and implement business process management technologies. JBoss aims to build a platform using its Professional Open Source model that enables various BPM, integration and workflow experts to leverage a common, mass market foundation to solve customer problems in their business focus areas. The low entry cost provided by jBPM will no doubt greatly increase the interest in the whole area of business process automation and should be good news for the industry as a whole.

I will write further about jBPM and its ability to support workflow and orchestration when I have had the chance to investigate them more deeply.