This page explains the design objectives for the jBPM command based service facade.

Main design

A command exector service is a session facade (e.g. an SLSB) that takes commands as input and executes them.  The command executor service is responsible for setting up the JbpmContext and pass in that JbpmContext into the command when executing it.

A command listener is a listener that is registered on an asynchronous message queue (e.g. an MDB).  For each message that arrives over the queue, the command listener will receive it and pass it on to the command executor service for handling execution.

Main use cases

The first use case of the command messaging is asynchronous continuations.  A message is sent to a command executor to resume process execution after a node has entered and before a node has been executed.  By sending the command message further execution of the process

is interrupted and a message-send is added to that transaction.  Then the command executor will start a new transaction to resume the

execution where it left of.  This can be seen as transaction demarcation inside of the process definition.

Extensibility

The command pattern allows for users to write their own command implementations.  EJB/RMI makes this transparant, the user's classes will be send to the server in case the command class is not already available there.

Object graph resolution

In previous session facade approaches we tried to build for the jBPM object model, we encountered the problem that return values are object graphs.  These object graphs were directly fetched from the database with hibernate.  Because of the (desired!) lazy loading of hibernate only a part of the object graph was returned.  E.g. if you have a method TaskInstance getTaskInstance(long taskInstanceId).  You could navigate the whole runtime process data and static process definition data from the task instance.  Sometimes this is what you want, but if you only want to show the name of the task instance, that is a waiste to fetch all that data from the database, serialize it and stream it to the client.

The command pattern approach allows for a default set of getters to be implemented with a default resolution of the graph behind the returned objects.  If users want more or less objects resolved, they can inherit and customize the object graph resolution behaviour.