Introduction¶
The purpose of this document is to outline the high-level architecture of Apache ODE. First, we describe the architectural objectives, then the various ODE components and how they interact. It is assumed that the reader is familiar with BPEL and the BPEL specification.
Objectives¶
The principal objective in the development of ODE was to create a reliable, compact, and embedable component capable of managing the execution of long-running business processes defined using the BPEL process description language. The focus has been on developing small modules with minimal dependencies that could be assembled (and easily reassembled) to construct a full featured BPMS.
Components¶
The key components of the ODE architecture include the ODE BPEL Compiler, ODE BPEL Engine Runtime, ODE Data Access Objects (DAOs), ODE Integration Layers (ILs), and user tooling. A high-level depiction of the relationships between these components is shown in the Figure below. It can be summarized as: "The compiler converts BPEL documents into a form executable by the run-time, which executes them in a reliable fashion by relying on a persistent store accessible via the DAOs; the run-time executes in the context of an Integration Layer which connects the engine to the broader execution environment ( i.e. the "world").
ODE BPEL Compiler¶
The BPEL compiler is responsible for the conversion of the source BPEL artifacts (i.e. BPEL process documents, WSDLs, and schemas) into a compiled representation suitable for execution. The output of the compiler is either a "good" compiled representation, or a list of error messages indicating problems with the source artefacts.
The compiled BPEL representation generated by the compiler is an object model similar in structure to the underlying BPEL process document. However, the compiled representation has resolved the various named references present in the BPEL (such as variable names), internalized the required WSDL and type information, and generated various constructs (e.g. default compensation handlers). The compiled representation (typically a file with the .cbp extension) is the sole artifact required by the BPEL runtime.
ODE BPEL Engine Runtime¶
The ODE BPEL Engine Runtime ("runtime") is found in the bpel-runtime module and provides for the execution of compiled BPEL processes. The runtime handles the dirty work of process execution by providing implementations of the various BPEL constructs. The runtime also implements the logic necessary to determine when a new instance should be created, and to which instance an incoming message should be delivered. Finally, the runtime implements the Process Management API that is used by user tooling to interact with the engine.
To achieve reliable execution of processes in unreliable environments, the runtime relies on Data Access Objects (DAOs) to provide persistence facilities. The implementation of these DAOs can be customized, but is typically provided by a transactional relational database. The DAOs are described in more detail in the next section.
The runtime implementation of BPEL constructs at the instance level is via ODE's Java Concurrent Objects (JaCOb) framework. JaCOb provides an application-level concurrency mechanism (i.e. it does not rely on threads) and a transparent mechanism for interrupting execution and persisting execution state. JaCOb is in very large part a Java implementation of the Actors [Agha] concurrency model and shares many features with process algebras such as π-calculus. Essentially, JaCOb provides a persistent virtual machine for executing BPEL constructs.
ODE Data Access Objects¶
ODE Data Access Objects mediate the interaction between the BPEL Engine Runtime and an underlying data store. Typically the data store is a JDBC relational database: in this case, the DAOs is implemented via the OpenJPA data access library. It is possible to create custom DAO implementations that employ a mechanism other than JDBC to achieve persistence, although no such implementation is provided. The BPEL Engine Runtime requires DAO objects to deal with the following persistence issues:
- active instances -- keeping track of which instances have been created
- message routing -- which instance is waiting for which message
- variables -- the values of the BPEL variables for each instance
- partner links -- the values of the BPEL partner links for each instance
- process execution state -- the serialized state of the JaCOb "persistent virtual machine"
For the OpenJPA/JDBC DAO implementation, the relational structure used to provide the above is shown in TODO.
ODE Integration Layers¶
The ODE BPEL Engine Runtime cannot exist in a vacuum: by itself it is incapable of affecting any interaction with the outside world. For this it relies on an the ODE Integration Layers (ILs). Integration Layers embed the runtime in an execution environment. For example, there are integration layers for AXIS2 and JBI. The fundamental function of an IL is to provide communication channels for the runtime. The AXIS2 IL achieves this by using the AXIS2 libraries to allow the runtime to communicate via Web Service interactions. The JBI IL achieves this same goal by tying the runtime into the JBI message bus.
In addition to communication, an IL provides the runtime with a thread scheduling mechanisms, and manages the life-cycle of the runtime (i.e. configuring and starting the runtime).