Engine Architecture

This section contains information about major architectural decision that have been taken.

  1. Structure Overview
  2. Participants and Responsibilities

Structure Overview

The class diagram below gives a rough graphical representation of the most important classes involved in bexee. There are only three activities shown (Invoke, Receive and Sequence) for the sake of simplicity. For the same reason other classes that might not be indispensable for understanding how the classes work together have been omitted in the diagram.

For more information on the control flow of incoming messages, please refer to Process Executionin the Engine Architecture section.

Participants and Responsibilities

This section documents the most important classes in bexee and their responsibilities.


The Manager class is used to deploy new BPEL processes to bexee. It uses the BPELProcessFactory and DAOFactory to parse and create a new BPELProcess and make it persistent respectively.


An inbound request triggering a process execution will always arrive at the BexeeProvider, which processes the incoming request and passes it on to the Dispatcher.


The Dispatcher uses the DAOFactory to look for the BPELProcess that has previously been stored by the Manager. After the BPELProcess and possibly also the ProcessContext has been found, they will be dispatched to the ProcessController.


The DAOFactory is an abstract factory, which can construct various types of concrete DAO factories (BPELProcessDAO, ProcessContextDAO), each factory supporting a different type of persistent storage implementation.


This class is used and responsible for the creation of an object representations of a BPEL processes, which is defined by a specified BPEL document.


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.


The Dispatcher is used to lookup or create a ProcessInstance given an inbound BexeeMessage and dispatch the message to the ProcessController either synchronously or asynchronoulsy.

When the Dispatcher kicks off the ProcessController it will know, whether a synchronous or asynchronous BPEL process is to be started. Depending on that it will either return right away after starting the process for an asynchronous BPEL process or it will wait until the result is available for a synchronous BPEL process.


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 need to be made persistent for later retrieval of asynchronous or long-running processes.


A BPELProcess contains all the necessary data to execute a BPEL process. It holds a reference to the Process as well as references to the WSDL files describing the BPEL process and its partners.

In addition to this, the BPELProcess class also provides a few convenience methods, such as determining whether a BPEL process is synchronous or not.

The BPELProcess is tightly coupled with the Process object representing the <process> element in a BPEL document. So what's the difference between a BPELProcess and a Process? We took great care to map the BPEL XML Schema into Java objects without modifying or polluting the BPEL model. The BPELProcess class allows us to implement new methods that might be used by bexee but are not part of the BPEL model.

Upon deployment a BPELProcess needs to be made persistent for later retrieval.

ProcessInstance (not shown in diagram)

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

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

Process, Activity, Invoke, Receive, Sequence

See Package bexee.model.

BPELProcessImpl, ProcessImpl, InvokeImpl, ReceiveImpl, SequenceImpl

See Package bexee.model.impl.

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. This allows for a decoupling of the concrete implementation choice from the BPEL model. It is imaginable that another implementation could be provided that uses an entirely different approach. Possibly this would also mean that a matching ProcessController implementation needs to be made avaiable.

In the current version of bexee the tree-structure given by BPEL is used in combination with the Visitor pattern to execute and process BPEL processes.