BPEL is an XML based language and thus the BPEL documents are represented as trees by their very nature. At the same time BPEL also describes processes, i.e. flows (like flow-diagrams). Depending on the point of view, a BPEL process can therefore be seen and represented in different ways. Below you'll find the two possible representations of the same process.
This is a tree representation of the process. It
represents the structure of the BPEL document.
This is a flow representation of the process which shows the logic of a
BPEL process
Note that the <flow> element
in BPEL is used for executing branches simultaneously, it might be
as well called parallel. Referencing to the "flow" representation of a
BPEL process has to do with "flow" diagrams not the <flow> element.
For representing a BPEL process in the bexee core model, a solution covering both aspects of BPEL documents had to be found. In addition, the core bexee model implementation had to satisfy other technical requirements:
In order to fulfill those different requirements, a heterogeneous tree model has been chosen for the BPEL process representation. This implementation will suffice the requirements. At the same time, the BPEL specific elements will be defined as interfaces matching the BPEL model as closely as possible. It is considered important that the interfaces map closely to the actual BPEL model and that the latter does not exhibit any implementation specific details. The model should remain as abstract as possible leaving it open for a number of different implementations. As we've already mentioned, the default model implementation bexee uses, is a tree structure.
This is the BPEL process blueprint representation, but how are process instances represented? It is not necessary to copy the whole process blueprint for each instance. It suffices to keep process instance specific data and associate it with a BPEL process. The data representing a process instance will be represented in form of events and state data (variables, link states, etc.). Each event will encapsulate data and information about what happened during the course of processing BPEL process activities and will keep a reference to the related process activity. This makes it possible to keep data related to a specific process instance separated from the process itself. The entire information about a process can then be extracted from the process context object and its belonging BPEL process tree.
Below is an illustration of how the process model works. The
ProcessController can control and process the process tree
using a ProcessContext for each process instance. The tree
structure can be traversed in different ways, depending on the given
needs.
A newly created process instance needs to be initiated, i.e. the
process context. The ProcessController can traverse the
tree and process the elements that need to be processed, e.g.
variables, fault handlers, correlation sets, etc. Traversing the
process tree, events with initiation data are stored in the
process context. The ProcessController will traverse the
process tree using the double dipatch method. Like this, type checking
during the traversal will be made unnecessary.
During process execution, the ProcessController passes
a BexeeMessage containing the call information through the process
until it reaches the right Receive activity. After processing an
activity, it's the responsibility of the enclosing activity, e.g. a
sequence to process the next activity.
The tree representation of a BPEL process is very advantageous for persisting process data. Process instance data and state will not be saved directly in the process tree, which exists only once (the process tree is the BPEL process blueprint and can thus not be modified) but rather be stored as events and variables in the process context. In order to make the process persistent, it's only necessary to save the process context and the associated state and events. When a process has to be restored, it's only necessary to call the context back to memory and associate it with the process tree). To obtain a textual representation of the process for example, the process controller would need to traverse a process tree with the process context for the right process and serialize process specific (tree) with process instance specific (context) data in a textual form.
Every different BPEL activity of the process is treated uniformly as
an Activity. This uniform way of processing activities
allows the model to be used by other tools, such as process debuggers.
Although such a debugger will not be developed in the scope of this
project, it will not be necessary to change the bexee core model to
enable its use.
Similarly as for the debugging, the bexee core process model is prepared for the use of not yet known treatments. Thanks to the uniform way how activities are processed, it is possible to use the AOP paradigm for not yet known treatments. The illustration below shows where custom treatments can be called during processing.
