This project has retired. For details please refer to its Attic page.
Apache ODE – Frequently Asked Questions

Frequently Asked Questions


This section collections frequently asked questions about ODE, BPEL, and related topics.


Q. What is ODE? A. ODE is a system for executing reliable long-running process described using the WS-BPEL 2.0 standard and the BPEL4WS 1.1 vendor specification.

Q. What is the architecture of ODE? A. The architecture of ODE is described in the ODE Architectural Overview

Q. In what language is ODE written? A. ODE is written in Java and relies on JDK v5.0 features.

Q. How does ODE ensure reliable process execution? A. ODE relies on a relational database to provide persistent storage.

This section covers frequently-asked questions about ODE's support for the OASIS WS-BPEL language.

Q. Which version or versions of BPEL does ODE currently support? A. ODE aims to provide full compliance to the OASIS WS-BPEL 2.0 standard as well as backward compatibility for BPEL4WS 1.1 processes. At present, ODE (mostly) supports the syntax of the final WS-BPEL 2.0 draft; limitations are described in the WS-BPEL 2.0 Specification Compliance page.

Q. Is the entire WS-BPEL 2.0 specification supported? A. Most WS-BPEL 2.0 language features (and all important features) are supported. For specifics see the WS-BPEL 2.0 Specification Compliance page.

Q. Does ODE use native Java language constructs to execute BPEL, e.g., multiple threads for a <bpel:flow> or a while (...) {...} for a <bpel:while>? A. No. ODE's BPEL implementation does not map the BPEL process into Java. Instead, it relies on a transactional concurrency framework JaCOb similar to the theoretical concurrency model known as Actors Agha86.

Q. Does ODE support BPEL processes developed in third-party tools? A. Yes. Well-formed BPEL from any source should work.

Q. Can ODE support extensions or alternatives to standard BPEL syntax and semantics? A. Yes. ODE's BPEL compiler can be customized to support non-standard BPEL syntax and semantics.

Q. Does ODE support custom XPath extension functions in a BPEL process? What are the limitations? A. Yes. XPath extension functions are supported; however, to ensure correct process execution in the presence of system failures, extension functions must be side-effect free.

Q. Does ODE support custom expression / query languages? A. Yes. The expression / query language is fully pluggable.

Q. Does ODE support BPELJ or JSR-207? A. No.

Q. Can multiple BPEL activities be grouped into a single transaction? A. No.

Q. My process fails with a selectionFailure; What can I do?_ A. BPEL expects a single element to be selected when evaluating <to> and <from> expressions, and a selectionFailure fault is thrown if zero or more than one element are selected.

If you get zero element, double-check your namespace prefix and bindings. Also, remember that you must initialize your variables (most often with <literal>'s) before assigning into them, unless your are reassigning the whole variable (e.g. directly into $variable, or $variable.part). To debug assignments, you can set the "org.apache.ode" logging category to DEBUG in order to see the content of variables as the process executes.

BPEL Process Management

This section covers frequently-asked questions about the runtime management of the engine and process instances.

Q. Does ODE support process versioning? A. Yes, our versioning approach is described here in detail. The ability to modify the definition of an existing process instance may be available in future versions.

Q. Does ODE provide debugging facilities? A. Yes, BPEL processes can be debugged "in-container" using the Management API.

Q. What kind of eventing or audit information is available from ODE's BPEL engine? A. ODE includes a rich eventing API that exposes information about the start and completion time of activities and scopes, variable manipulations, and other information. Event listeners can extract as much or as little of this information as desired.

Runtime Environments and Requirements

This section covers frequently-asked questions about the runtime requirements for ODE and supported thirdparty products.

Q. Which Java virtual machines and runtime environments does ODE support? A. Building ODE and executing ODE requires JDK 5.0.

Q. Which operating systems does ODE support? A. ODE is written entirely in Java and can run on any operating system supporting the required Java environment. ODE has been tested and is known to run on Windows 2000, Windows XP, Linux, MacOS X, Solaris, and AIX.

Q. Does ODE require a database? Which databases and versions does ODE support? A. ODE does not depend directly on any specific database or persistence mechanism. Instead, ODE relies on a set of data access object ("DAO") interfaces that encapsulate the behaviors of a persistence layer. The ODE distribution includes a DAO implementation for JDBC databases built using OpenJPA. This DAO implementation can support most common relational databases. Schemas suitable for MySQL and Derby are provided. Relational databases lacking transaction or binary large object ("BLOB") capabilities are not supported. The DAO interfaces can readily be implemented to support alternative persistence mechanisms (e.g. JDO), XML datastores, or direct filesystem-based persistence.

Q. Does ODE require a J2EE application server? A. The core ODE components do not require a J2EE application server. ODE relies on a Integration API that allows ODE to be embedded in most any environment that can supply the required facilities. An AXIS2 Integration is provided that permits ODE to be installed on a J2EE application server, or in a "dumb" Servlet container via a WAR file. A JBI Integration integration is also provided that permits ODE to be installed in a JBI container.

Q. Is there a stand-alone ODE integration? A. No, the standard ODE distributions require either an application server, Servlet container, or JBI container.

Q. Can ODE be deployed within an application server or web container? A. Yes, ODE can be deployed into most common application servers. However, it is important to note that ODE is not an enterprise application in the J2EE sense: ODE manages its own transactions and threads.

Q. Does ODE require JMS? A. No, however future versions of ODE will require a transactional transport to support clustering.

Q. Is ODE internationalized? If so, which languages are supported? A. ODE messages intended for user consumption are internationalized using the Java resource bundle mechanism. American english messages are provided.

Q. I'm getting data truncation errors, what does that mean? A. We try to use sensible sizes for the database columns that contain messages and variables in ODE. However if you're manipulating large quantities of data that may not e enough. The solution in that case is to alter the column that's too short to reserve enough database space for your needs.

Integration with Third-Party Products

This section covers frequently asked questions related to integrating ODE into third-party products or integrating third-party products into ODE.

Q. Can ODE interact directly (i.e., not over the network) with native Java services? A. This is currently supported in the JBI Integration via standard JBI mechanisms. It is currently not supported in the AXIS2 Integration but will be in the future.

Q. Can ODE integrate with Middleware X? Can ODE integrate with Legacy system Y? Can ODE integrate with Enterprise Application Z? How is this accomplished? A. The generic answer is "Yes," although it requires some work on the part of the integrator. The primary extension point for integrating with external systems is the Integration API, which can be used to embed ODE in most any environment.

Q. Does ODE rely on any third-party or open source libraries? A. ODE uses a number of liberally-licensed (i.e., non-GPL) open source libraries, some integral and some not. These are enumerated in the reference.

ODE and Web Services

This section covers frequently asked questions about how ODE related to various web services specifications and initiatives.

Q. Does ODE supply a SOAP stack? A. Not directly. ODE relies on the Integration Layer to supply the "physical" communication mechanisms. The AXIS2 Integration Layer that is part of the ODE distribution uses the AXIS2 SOAP stack. The JBI Integration Layer relies on external HTTP/SOAP components (e.g. ServiceMix's servicemix-http component).

Q. Can ODE be integrated with third-party web services products such as Apache AXIS, Systinet WASP, or JAXRPC? A. Yes, ODE can be integrated into most any stack via the Integration API

Q. Does ODE support web services transaction specifications, e.g., WS-Transaction, WS-Coordination, WS-Business Activity, OASIS BTP, or Composite Application Framework (WS-CAF)? A. No, not at present.

Q. Does ODE support WS-Addressing? A. ODE does not directly support WS-Addressing. However, the BPEL implementation and the core ODE infrastructure provides support for opaque end-point references. This allows ODE to be integrated with arbitrary addressing standards. The AXIS2 Integration Layer for ODE employs this mechanism to support WS-Addressing.


This section covers frequently asked questions about the reliability of ODE.

Q. Can ODE recover in the event of system failure? A. Yes, ODE uses transaction management and relies on transactional data stores to ensure data consistency in the event of failure.

Q. How does ODE's BPEL Engine recover in the event of system failure? A. todo: describe recovery mechanism

Q. What happens to outbound invocations bound to transaction protocols (such as SOAP-over-JMS) in the event of system failure? A. todo: describe

Q. What happens to outbound invocations bound to non-transactional protocols (such as HTTP) in the event of system failure? A. todo: describe


This section covers frequently asked questions about ODE's clustering support.

Q. Can ODE be deployed in clustered or other configurations intended to provide fault tolerance and increased performance? A. Clustering support is currently under development. Clustering support will require a transaction inter-node transport (such as JMS) as well as a transactional data store that can be accessed concurrently by all nodes in the cluster (i.e. a modern RDBMS).