Process Modelling

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.

Tree representation of a BPEL process

This is a tree representation of the process. It represents the structure of the BPEL document.

Flow representation of a BPEL process


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:

  • a process and all its elements must be initiated in a uniform way
  • it must be possible to execute a process and all its elements in a uniform way
  • we need to persist data related to process instances and be able to reconstruct them for visualisation
  • process debugging must be possible
  • a straight forward way for not yet known process treatments has to be provided

Model Choice

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.


Process initiation

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.

Process execution

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.

Process data persistence

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.

Process debugging

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.

Yet Unknown Process Treatements

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.