4.2. Services Container
| Chapter 4. Configuration and Services |

## 4.2. 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).

This configuration is only used on the server side.

### 4.2.1. Environment.xml file

The default environment.xml file created during the installation of 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>
      <environment-factory>
        <job-executor auto-start="false" threads="10"/>
        <properties name="orchestra-properties" resource="orchestra.properties"/>
        <hibernate-session-factory configuration="hibernate-configuration:core" init="eager" name="hibernate-session-factory:core"/>
        <dead-job-handler class="org.ow2.orchestra.services.handlers.impl.ExitInstanceDeadJobHandler"/>
        <hibernate-configuration name="hibernate-configuration:core">
          <properties resource="hibernate.properties"/>
          <mappings resource="hibernate/bpel.core.mappings.xml"/>
          <mappings resource="hibernate/bpel.monitoring.mappings.xml"/>
          <cache-configuration resource="hibernate/bpel.cache.xml" usage="read-write"/>
        </hibernate-configuration>
        <command-service>
          <orchestra-retry-interceptor retries="10"/>
          <environment-interceptor/>
          <standard-transaction-interceptor/>
        </command-service>
        <hibernate-configuration name="hibernate-configuration:history">
          <properties resource="hibernate-history.properties"/>
          <mappings resource="hibernate/bpel.monitoring.mappings.xml"/>
          <mapping resource="hibernate/bpel.util.hbm.xml"/>
        </hibernate-configuration>
        <hibernate-session-factory configuration="hibernate-configuration:history" init="eager" name="hibernate-session-factory:history"/>
        <repository class="org.ow2.orchestra.services.impl.DbRepository"/>
        <publisher class="org.ow2.orchestra.cxf.CxfPublisher"/>
        <invoker class="org.ow2.orchestra.cxf.CxfInvoker" name="serviceInvoker"/>
      </environment-factory>
      <environment>
        <hibernate-session factory="hibernate-session-factory:core" name="hibernate-session:core"/>
        <message-session retries="3"/>
        <transaction/>
        <chainer name="archiver">
          <archiver class="org.ow2.orchestra.persistence.log.LoggerArchiver"/>
          <ref object="history"/>
        </chainer>
        <journal class="org.ow2.orchestra.persistence.db.DbJournal" name="journal">
          <arg>
            <ref object="querier-session:core"/>
          </arg>
        </journal>
        <history class="org.ow2.orchestra.persistence.db.DbHistory" name="history">
          <arg>
            <ref object="querier-session:history"/>
          </arg>
        </history>
        <timer-session/>
        <chainer name="finished-instance-handler">
          <finished-instance-handler class="org.ow2.orchestra.services.handlers.impl.DeleteFinishedInstanceHandler"/>
          <finished-instance-handler class="org.ow2.orchestra.services.handlers.impl.ArchiveFinishedInstanceHandler"/>
        </chainer>
        <queryApi name="queryList">
          <ref object="journal"/>
          <ref object="history"/>
        </queryApi>
        <chainer name="recorder">
          <recorder class="org.ow2.orchestra.persistence.log.LoggerRecorder"/>
          <ref object="journal"/>
        </chainer>
        <chainer name="undeployed-process-handler">
          <undeployed-process-handler class="org.ow2.orchestra.services.handlers.impl.ArchiveUndeployedProcessHandler"/>
        </chainer>
        <querier-db-session name="querier-session:history" session="hibernate-session:history"/>
        <runtime-db-session name="runtime-session:core" session="hibernate-session:core"/>
        <job-db-session session="hibernate-session:core"/>
        <querier-db-session name="querier-session:core" session="hibernate-session:core"/>
        <hibernate-session factory="hibernate-session-factory:history" name="hibernate-session:history"/>
      </environment>
    </environment-definition>

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

- publisher: object intended for publishing services of the given bpel process. For web services based on axis framework, degfault class is org.ow2.orchestra.axis.AxisPublisher. For web services based on cxf framework, the default class is org.ow2.orchestra.cxf.CxfPublisher.

- invoker: object intended for external web services invocations. Default implementation is based on SAAJ through the default implementation (class org.ow2.orchestra.services.impl.SOAPInvoker). For web services based on cxf framework, the default class is org.ow2.orchestra.cxf.CxfInvoker

- 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 or more 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.

- undeployed-process-handler: action to perform when a process is un-deployed. This object could chain distinct actions. Default implementation stores data in the archive and removes data from journal.

- dead-job-handler: action to perform when a asynchronous execution has failed all the retries. This object could chain distinct actions. Default implementation exits the process instance that failed to execute asynchronously.

* 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 mappings, cache configuration...

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

Chapter 4. Configuration and Services |  | 4.3. Services