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 (
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.
This section documents the most important classes in bexee and their responsibilities.
Manager class is used to deploy new BPEL processes
to bexee. It uses the
DAOFactory to parse and create a new
BPELProcess and make it persistent respectively.
An inbound request triggering a process execution will always arrive
BexeeProvider, which processes the incoming
request and passes it on to the
Dispatcher uses the
DAOFactory to look
BPELProcess that has previously been stored by
Manager. After the
possibly also the
ProcessContext has been found, they
will be dispatched to the
DAOFactory is an abstract factory, which can
construct various types of concrete DAO factories
factory supporting a different type of persistent storage
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.
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.
Dispatcher is used to lookup or create a
ProcessInstance given an inbound
BexeeMessage and dispatch the message to the
ProcessController either synchronously or asynchronoulsy.
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.
ProcessContext contains state information about a
very specific process instance. This includes:
ProcessControllerto 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).
ProcessContext need to be made persistent for later
retrieval of asynchronous or long-running processes.
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.
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 contains no logic at all but merely
serves as a container for encapsulating a
object and the corresponding
Thus the fusion of the
ProcessContext and the
BPELProcess together form a
See Package bexee.model.
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.
bexee.model.impl contains classes
implementing the interfaces in package
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
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.