You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ode.apache.org by bu...@apache.org on 2012/11/23 19:16:40 UTC

svn commit: r839350 - in /websites/staging/ode/trunk/content: ./ architectural-overview.html

Author: buildbot
Date: Fri Nov 23 18:16:40 2012
New Revision: 839350

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:16:40 2012
@@ -1 +1 @@
-1413008
+1413009

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:16:40 2012
@@ -94,7 +94,7 @@
 <p><a name="ArchitecturalOverview-ODEBPELCompiler"></a></p>
 <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>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>
 <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>
@@ -112,7 +112,7 @@
 </ul>
 <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>
-<h2 id="ode-integration-layers">ODE Integration Layers</h2>
+<h3 id="ode-integration-layers">ODE Integration Layers</h3>
 <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>