The functionality of jBPM is split into modules. Each module has a definition and an execution (or runtime) part. The central module is the graph module, made up of the ProcessDefinition and the ProcessInstance. The process definition contains a graph and the process instance represents one execution of the graph. All other functionalities of jBPM are grouped into optional modules. Optional modules can extend the graph module with extra features like context (process variables), task management, timers, ...

Figure 20.1. The pluggable architecture

The pluggable architecture in jBPM is also a unique mechanism to add custom capabilities to the jBPM engine. Custom process definition information can be added by adding a ModuleDefinition implementation to the process definition. When the ProcessInstance is created, it will create an instance for every ModuleDefinition in the ProcessDefinition. The ModuleDefinition is used as a factory for ModuleInstances.

The most integrated way to extend the process definition information is by adding the information to the process archive and implementing a ProcessArchiveParser. The ProcessArchiveParser can parse the information added to the process archive, create your custom ModuleDefinition and add it to the ProcessDefinition.

public interface ProcessArchiveParser {

  void writeToArchive(ProcessDefinition processDefinition, ProcessArchive archive);
  ProcessDefinition readFromArchive(ProcessArchive archive, ProcessDefinition processDefinition);

}

To do its work, the custom ModuleInstance must be notified of relevant events during process execution. The custom ModuleDefinition might add ActionHandler implementations upon events in the process that serve as callback handlers for these process events.

Alternatively, a custom module might use AOP to bind the custom instance into the process execution. JBoss AOP is very well suited for this job since it is mature, easy to learn and also part of the JBoss stack.