Overview

Participants and Responsibilities

ProcessController

The ProcessController is the core of the engine and contains the execution logic for every BPEL activity. The ProcessController needs to be thread-safe as several threads may use it simultaneously.

DispatcherThread

The DispatcherThread's sole responsibility is to call the dispatchMessage() method on the ProcessController in a new thread.

ProcessInstanceFactory

The ProcessInstanceFactory is responsible for creating a new ProcessInstance. This happens by looking up the BPELProcess and the ProcessContext that is associated with the incoming message.

BPELProcessLocator

Given an incoming message, the BPELProcessLocator is responsible for looking up the appropriate deployed BPELProcess.

ProcessContextLocator

Analogous to the BPELProcessLocator, the ProcessContextLocator is responsible for looking up the a ProcessContext object that matches the incoming message. This might include comparing CorrelationSets.

ProcessInstance

The ProcessInstance contains no logic at all but merely serves as a container for encapsulating a ProcessContext instance and its corresponding BPELProcess reference.

Thus the fusion of the ProcessContext and the BPELProcess together form a ProcessInstance.

ProcessContext

A new ProcessContext will be created for every new process instance. The ProcessContext contains state information about a very specific process instance. This includes:

• Link states
• Global and local variable values
• Detailed event information about each processed activity. This information is vital for the ProcessController to be able to resume asynchronous process execution. Another optional use of this information might be a later process execution tracing (e.g. for graphical representations of an executing or finished process).

The ProcessContext should be made persistent.

BPELProcess

A BPELProcess is basically the blueprint of a business process. There exists exactly one BPELProcess object per deployed BPEL document.

The BPELProcess interface needs to foresee methods such as how to obtain the next Activity in a process. How this will be achieved exactly, depends on the underlying implementation.

The BPELProcess is tightly coupled with the Process object representing the <process> element in a BPEL document.

Upon deployment a BPELProcess needs to be made persistent.

BPELProcessFactory

A BPELProcessFactory follows the GoF Abstract Factory Pattern to create different BPELProcess implementations.

BPELProcessTreeFactory

A BPELProcessTreeFactory is a concrete factory implementing the BPELProcessFactory interface to create a BPELProcessTree instance.

BPELProcessTree

A BPELProcessTree implements the BPELProcess interface given a tree structure.

Package bexee.model

The package bexee.model contains a number of classes that map directly to the elements in a BPEL document and thus enable a object representation of the BPEL document. The classes don't provide any logic and the objects are used as pure value objects.

Package bexee.model.impl

The package bexee.model.impl contains classes implementing the interfaces in package bexee.model. The default bexee implementation uses a tree structure to represent a BPELProcess and thus the implementing classes will also implement the Vertex interface, because they will be the nodes of the process tree.

Some elements such as Sequence are special vertices, because they have the ability to expand their children. Note that this functionality is specific to a given BPEL activity, but not incorporated into the Vertex public interface. Thus the Vertex interface doesn't provide functions to expand an element, but the tree containing the vertices must provide this functionality given a Vertex.