Author: buildbot
Date: Fri Nov 23 18:15:52 2012
New Revision: 839349
Log:
Staging update by buildbot for ode
Modified:
websites/staging/ode/trunk/content/ (props changed)
websites/staging/ode/trunk/content/architectural-overview.html
Propchange: websites/staging/ode/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Nov 23 18:15:52 2012
@@ -1 +1 @@
-1413005
+1413008
Modified: websites/staging/ode/trunk/content/architectural-overview.html
==============================================================================
--- websites/staging/ode/trunk/content/architectural-overview.html (original)
+++ websites/staging/ode/trunk/content/architectural-overview.html Fri Nov 23
18:15:52 2012
@@ -81,50 +81,38 @@
<div class="row">
<div class="span12">
- <p><a name="ArchitecturalOverview-ODE-ArchitecturalOverview"></a></p>
-<h2 id="ode-architectural-overview">ODE - Architectural Overview</h2>
-<p><a name="ArchitecturalOverview-Introduction"></a></p>
-<h3 id="introduction">Introduction</h3>
+ <p><a name="ArchitecturalOverview-Introduction"></a></p>
+<h2 id="introduction">Introduction</h2>
<p>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.</p>
<p><a name="ArchitecturalOverview-Objectives"></a></p>
-<h3 id="objectives">Objectives</h3>
+<h2 id="objectives">Objectives</h2>
<p>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.</p>
<p><a name="ArchitecturalOverview-Components"></a></p>
-<h3 id="components">Components</h3>
-<p>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 FIGREF. 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").</p>
-<p>!OdeArchitecture.png!</p>
+<h2 id="components">Components</h2>
+<p>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").</p>
+<p><img alt="ODE Architecture" src="/img/OdeArchitecture.png" /></p>
<p><a name="ArchitecturalOverview-ODEBPELCompiler"></a></p>
-<h4 id="ode-bpel-compiler">ODE BPEL Compiler</h4>
+<h3 id="ode-bpel-compiler">ODE BPEL Compiler</h3>
<p>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.</p>
<p>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.</p>
<p><a name="ArchitecturalOverview-ODEBPELEngineRuntime"></a></p>
-<h4 id="ode-bpel-engine-runtime">ODE BPEL Engine Runtime</h4>
+<h3 id="ode-bpel-engine-runtime">ODE BPEL Engine Runtime</h3>
<p>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.</p>
<p>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.</p>
-<p>The runtime implementation of BPEL constructs at the instance level is via
ODE's Java Concurrent Objects (<a href="jacob.html">Jacob</a>) framework. <a
href="jacob.html">Jacob</a> 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. <a href="jacob.html">Jacob</a> is in
very large part a Java implementation of the ACTORS [Agha] concurrency model
and shares many features with process algebras such as \pi -calculus.
Essentially, <a href="jacob.html">Jacob</a> provides a persistent virtual
machine for executing BPEL constructs.</p>
+<p>The runtime implementation of BPEL constructs at the instance level is via
ODE's Java Concurrent Objects (<a href="jacob.html">JaCOb</a>) framework. <a
href="jacob.html">JaCOb</a> 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. <a href="jacob.html">JaCOb</a> is in
very large part a Java implementation of the ACTORS [<a
href="agha.html">Agha</a>] concurrency model and shares many features with
process algebras such as π-calculus. Essentially, <a
href="jacob.html">JaCOb</a> provides a persistent virtual machine for executing
BPEL constructs.</p>
<p><a name="ArchitecturalOverview-ODEDataAccessObjects"></a></p>
-<h4 id="ode-data-access-objects">ODE Data Access Objects</h4>
+<h3 id="ode-data-access-objects">ODE Data Access Objects</h3>
<p>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:</p>
<ul>
-<li>
-<p>active instances -- keeping track of which instances have been created</p>
-</li>
-<li>
-<p>message routing -- which instance is waiting for which message</p>
-</li>
-<li>
-<p>variables -- the values of the BPEL variables for each instance</p>
-</li>
-<li>
-<p>partner links -- the values of the BPEL partner links for each instance</p>
-</li>
-<li>
-<p>process execution state -- the serialized state of the <a
href="jacob.html">Jacob</a> "persistent virtual machine"</p>
-</li>
+<li>active instances -- keeping track of which instances have been created</li>
+<li>message routing -- which instance is waiting for which message</li>
+<li>variables -- the values of the BPEL variables for each instance</li>
+<li>partner links -- the values of the BPEL partner links for each
instance</li>
+<li>process execution state -- the serialized state of the <a
href="jacob.html">JaCOb</a> "persistent virtual machine"</li>
</ul>
-<p>For the OpenJPA/JDBC DAO implementation, the relational structure used to
provide the above is shown in FIGREF.</p>
+<p>For the OpenJPA/JDBC DAO implementation, the relational structure used to
provide the above is shown in TODO.</p>
<p><a name="ArchitecturalOverview-ODEIntegrationLayers"></a></p>
-<h3 id="ode-integration-layers">ODE Integration Layers</h3>
+<h2 id="ode-integration-layers">ODE Integration Layers</h2>
<p>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.</p>
<p>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).</p>
</div>
