Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This page outlines all possible integration points from Activiti with the Spring Framework. On the kick-off meeting the team agreed that there MUST NOT be a needed runtime dependency to Spring, but a decent and optional integration will help Spring users to add Actviti into their existing and new Spring application.

Configuration support

It should be easy to configure Activiti with the Spring Framework inside an application context. Activiti should provide a namespace configuration support to simplify the configuration of the Activiti engine inside Spring. A possible namespace based configuration could look like this

The namespace could also be implemented with default references for the most commons extensions points like the bean "transactionManager" for the transaction manager bean definition. The bean name "transactionManager" is a common name used in Spring for the transaction manager in particular if used with the built-in jta namespace support. With the defaults, the configuration could look like this in its simplest form (assuming that we are using a JTA transaction manager)

Starting with a minimal and simple default configuration there could be lots of extension points that can be configured with Spring to plugin the Spring-based implementation like transaction managers or their own SPI-based implementation.

The next chapters will outline possible configurable extension points for Activiti along with the affected classes/modules in Activiti

DataSource Configuration

Because of the fact that Spring users will integrate Activiti into their Spring application and vice-versa they will built a new Spring application based on Activiti it is crucial to offer a extension point for injected datasources through Spring. Based on the unified datasource inside the application context it is possible to use Activiti with its own persistence implementation (ibatis) and the application persistence (probably JPA) inside one transaction without JTA.

The extension point would be a javax.sql.DataSource class that can be configured in Spring and referenced through the Activit namespace.
A sample for a standalone data source that utilizes the Apache Commons DataBase Connection Pool could look like this

likewise the user could use a JNDI based data source for its application and Activiti

Implementation Notes

The support to add an external data source is already supported in the code based through the method org.activiti.test.cfg.spring.ProcessEngineFactoryBean#setDataSource although there is no namespace support right now.

Transaction Manager Configuration

Spring provides a rich set of transaction manager implementations to be used in a standalone environment (like plain JDBC, Hibernate and JPA) and also different implementations to be used inside a JEE application server (like plain JTA, Websphere and Weblogic specific and optimized ones). With both strategies supported, it is possible to have one transaction for the application and the engine even in a standalone environment!

A namespace based configuration could look like this for the standalone environment with plain JDBC

whereas the setup in combination with a JEE application server could look like this

Where the tag <tx:jta-transaction-manager/> automatically detects the best available transaction manager (Websphere/Weblogic specific ones before the JTATransactionManager as a fallback)

Implementation Notes

There is already support to use the Spring Framework transaction abstraction inside Activiti. The method org.activiti.test.cfg.spring.ProcessEngineFactoryBean#setTransactionManager already support Spring based org.springframework.transaction.PlatformTransactionManager implementations.

MyBatis Configuration

Although Spring doesn't have any support for (My)iBatis yet is should be possible to configure the org.apache.ibatis.session.SqlSessionFactory with Spring to customize the iBatis configuration used in Activiti in the following areas
*Interceptors
*Caching

NOTE This decision can be deferred until Spring 3.1 ships with the iBatis 3.x configuration support. The iBatis 3.x support will be tackled in this issue

Spring Infrastructure

Spring provides a fully fledged infrastructure to run JAVA based application in a standalone and JEE server environment with special support for the most common application servers like Websphere, Weblogic. The most important infrastructure implementation and their benefits for Activiti will be outlines below.

Task Abstraction

Some JEE Application servers disallow the creation of native Threads while running a application inside the server. It is mandatory to use the vendor specific APIs to create "managed" threads. Spring has an built-in abstraction Task abstraction that allows to run tasks (which are essentially Runnables) with different implementations like a java.util.concurrent.Executor for standalone environments and a CommonJ based implementation for Websphere and Weblogic.

Implementation Note

Activiti uses native Threads like org.activiti.impl.jobexecutor.JobAcquisitionThread which must be converted to a Runnable instance. There is also a new abstraction needed to run Runnable instances with different implementations (for the beginning a java.util.concurrent.Executor one and a Spring based one).

  • No labels