Chapter 4. Configuration and Services

Table of Contents

4.1. Services Container
4.1.1. Environment.xml file
4.2. Services
4.2.1. Publisher
4.2.2. Invoker
4.2.3. Repository
4.2.4. Persistence
4.2.5. Journal and History
4.2.6. Querier
4.2.7. Timers
4.2.8. Finished instance handler (FIH)

This chapter introduces the services configuration infrastructure provided by Nova Orchestra as well as main services included in this version.

4.1. Services Container

The Process Virtual Machine technology includes a services container allowing the injection of services and objets that will be leveraged during the process definition and execution. Objects and services used by the Orchestra engine are defined through a XML file. A dedicated parser and a wiring framework are in charge of creating those objects. Service invoker, publisher, persistence and timers are examples of pluggable services.

This services container (aka IoC container) can be configured through a configuration file. A default configuration file is included in the package under the /conf directory (environment.xml).

4.1.1. Environment.xml file

The default environment.xml file created during the installation of Nova Orchestra is set to use the database implementation of the persistence service. This file also sets the configuration of hibernate. Here is the environment.xml file generated :

<environment-definition>

  <application>
    <hibernate-session-factory table-prefix='NOVA_'>
      <properties resource='hibernate.properties' />
      <mapping resource='hibernate.definition.hbm.xml' />
      <mapping resource='hibernate.execution.hbm.xml' />
      <mapping resource='hibernate.job.hbm.xml' />
      <mapping resource='hibernate.queries.hbm.xml' />
      <mapping resource='hibernate.type.hbm.xml' />
      <mapping resource='hibernate.wire.hbm.xml' />
      <mapping resource='bpel.activities.hbm.xml' />
      <mapping resource='bpel.elements.hbm.xml' />
      <mapping resource='bpel.execution.hbm.xml' />
      <mapping resource='bpel.runtime.hbm.xml' />
      <mapping resource='bpel.services.hbm.xml' />
      <mapping resource='bpel.queries.hbm.xml' />
      <mapping resource='bpel.util.hbm.xml' />
      <mapping resource='bpel.wsdl.hbm.xml' />
      <mapping resource='bpel.lang.hbm.xml' />
      <cache-configuration resource='pvm.definition.cache.xml' usage='read-write' />
      <cache-configuration resource='bpel.cache.xml' usage='read-write' />
    </hibernate-session-factory>
    <standard-command-service>
      <retry-interceptor />
      <environment-interceptor />
      <transaction-interceptor />
    </standard-command-service>
    <job-executor threads='1' auto-start='false' />
    <repository class='org.ow2.orchestra.execution.services.db.DbRepository' />
    <publisher class='org.ow2.orchestra.axis.AxisPublisher' />
    <invoker class='org.ow2.orchestra.axis.AxisInvoker' />
  </application>

  <block>
    <timer-session />
    <standard-transaction />
    <job-session />
    <hibernate-session />
    <hibernate-bpel-persistence-service />
  </block>

</environment-definition>

Currently, following objects implementations can be injected in the environment:

  • publisher: object intended for publishing services of the given bpel proces .Default implementation is based on axis web services framewrok through the default implementation (class org.ow2.orchestra.axis.AxisPublisher).

  • invoker: object intended for external web services invocations. Default implementation is based on axis web services framewrok through the default implementation (class org.ow2.orchestra.axis.AxisInvoker).

  • repository: data repository storing processes and instances... Db persistence (class org.ow2.orchestra.execution.services.db.DbRepository) implementation is included in this RC.

  • recorder: object responsible of process execution logs. Default implementation handles process logs in the command line console (org.ow2.orchestra.persistence.log.LoggerRecorder). Recorder and Journal (see next) objects can be chained (new ones can be added as well on top of the recorder chainer). This give you a powerful mechanism to handle process execution data

  • journal: object responsible for storing or retrieving process execution data. Db persistence (class org.ow2.orchestra.persistence.db.DbJournal) implementation is provided by default.

  • archiver: object intended for process logs archiving. Default implementation handles logs on process data archiving through the default implementation (class org.ow2.orchestra.persistence.log.LoggerArchiver). Archiver and History (see next) objects can be chained (new ones can be added as well on top of the archiver chainer). This give you a powerful mechanism to handle process archived data

  • history: object intended for storing or retrieving process archieved data. Default implementation is provided and available in the following class: org.ow2.orchestra.persistence.db.DbHistory.

  • queryList: object intended to configure how the QueryRuntimeAPI will retrieve the process execution data. This retrieval could be configured to chain with the expected order into the journal and the history.

  • finished-instance-handler: action to perform when a process instance is finished. This object could chain two distinct actions: for a given process instance, deleting the runtime object including its activities from the repository and then store data in the archive and remove data from journal. Default implementations are proposed for both chained actions.

* Note 1: As explained before persistence objects are provided as default implementations in the environment. Notice that in a persistence configuration additional resources are required, i.e for hibernate persistence you can specify mapings, cache configuration...

* Note 2: The environment is divided in two different contexts: application and block. Objects declared inside the application context are created once and reused while objects declared inside the block context are created for each operation.