This section contains information about major architectural decision that have been taken.
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.
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:
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.
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.
See 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.
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.