apache ode 2.0

This package contains interfaces for representing BPEL "break-points". BPEL break-points are similar to conventional programming break-points in that they permit the interruption and suspension of execution based on various criteria.

BPEL compiler (bpelc) classes and interfaces. Taking as input the de-referenced BPEL object model (see {@link org.apache.ode.bom.impl.nodes}), the BPEL compiler applies static analysis rules to ensure compliance of the BPEL model. Upon successful analysis, the compiler generates a "compiled" process description suitable for consumption by the BPEL Service Provider?s (see {@link com.fs.jlo.bpel.provider.BpelServiceProvider}) processing engine (also known as the virtual processing unit or VPU).

Failures in the static analysis phase are reported in the same manner as parser errors and contain detailed error descriptions and line number references to the location of the errors in the original BPEL XML process definition.

The API for the BPEL Object Model (BOM), a domain-specific document object model (DOM) that can represent BPEL v1.1 and BPEL v2.0 (OASIS) processes. While the BOM enforced strcutural constraints --for example that a process contain one root activity-- it does not perform any static analysis, and may be used to produce processes that are invalid. It is also possible to use the BOM to build processes that do not conform to the BPEL XML Schema. This allows the BOM to be used in applications such a process design, where an incomplete or invalid process may need to be modeled.

Data-Access Object (DAO) interfaces used by the BPEL Service Provider to communicate with the data store; can be used to customize the BPEL persistence layer. The BPEL DAO layer is used to maintain persistent state of each active BPEL process instance. This includes the values of scope variables, as well as instance "state snapshots" that may need to be persisted due to the activation of receive, pick, or invoke activity that cannot be immediately satisfied. Like the DAO of the framework (see {@link com.fs.jlo.sfwk.bapi.dao}), the BPEL DAO is a "dumb" object-relational model supporting transactional access.

Supporting classes for the Hibernate/DAO implementation used by both the BPEL and SFWK DAO implementations.

An implementation of the BPEL data access objects (DAO) api using hibernate.

Hibernate POJOs for bpel.

This package contains classes related to EPR handling that are of a general enough nature as to be useful to any Integration Layer implementation.

The client connection interface ("CCI") provides a uniform mechanism for accessing services hosted inside the ODE container from objects outside the container. For example, through the CCI a client can connect to a running BPEL service to inspect the state of a process instance; similarly, a Servlet may use the CCI to notify a ODE SOAP service that a new message has arrived.

The CCI supports marshalling of invocations for arbitrary interfaces that are defined by each particular service provider. Both blocking and non-blocking operations are supported.

Contains implementations of commandline tools and Ant Tasks.

Each subpackage, e.g., com.fs.jlo.tools.foo contains:

• One or more implementations of the {@link com.fs.jlo.tools.Command} interface that perform a given function.
• In the com.fs.jlo.tools.foo.cline subpackage, a class with a main() method that uses the above {@link com.fs.jlo.tools.Command} implementation to perform some function, e.g., deploying a ODE system.
• In the com.fs.jlo.tools.foo.ant subpackage, a class that extends {@link com.fs.jlo.tools.CommandTask} (which, in turn, extends {@link org.apache.ant.Task}) that uses the above {@link com.fs.jlo.tools.Command} implementation to perform roughly the same function.

The ultimate goal of the package is collect a set of reusable "command" representations that can be invoked under different contexts like the commandline, an Ant build, or from a wizard or tool in a GUI application.

Miscellanous utility classes.

Contains libraries for handling commandline arguments (i.e., the String[] passed-in by a main method).

This package provies "refactorable" internationalized message bundles. The goal is to provide a consistent framework for obtaining internationalized error and informational messaeges, with the additional requirement that it should be easy to "refactor" the names of the message keys. Instead of relying on clients to pass string message keys (e.g. bundle.getMessage("filenotfound")) this package requires the programmer to create a method decleration for each message. The programmer does not however need to provide an implementation of the method, which is generated automatically by the package.

To use the package the programmer defines an interface that extends org.apache.ode.utils.msg.MsgBundle with methods for each required message. Each method name must start with the strings "msg" or "str", and have a @jlo.msg JavaDoc tag containing the default message text (internationalized versions can be placed in corresponding property files). For example:

interface MyMsgs extends org.apache.ode.utils.msg.MsgBundle {

  /**
   * @jlo.msg File '{0}' not found.
   */
  String msgFileNotFound(String fname);
}

MyMsgs msgs = (MyMsgs) BundleManager.getBundle(MyMsgs.class);
msgs.msgFileNotFound("foo.zip");