jBPM and Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 414

MySQL, PostgreSQL, and so forth. In this example, we're using Postgres 8.3, for which the driver's jar
dependency is expressed in Maven as:
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.3-603.jdbc3</version>
</dependency>
11-3. Integrating jBPM 4 with Spring
Problem
You want to use jBPM 4 (the newer, and current, release) but you've got a Spring-based architecture and
want to make use of jBPM from within a Spring application context.
Solution
jBPM ships with very good support for Spring, even providing a Spring-friendly configuration object
( org.jbpm.pvm.internal.cfg.SpringConfiguration ). This class makes it easy to set up the core pieces
of the integration in a Spring-friendly manner. The balance of the configuration is fairly boilerplate
transaction management and Hibernate integration, with some caveats. Andries Inzé started the project
to integrate Spring and jBPM, and so much of the great work here is because of his efforts, on top of the
great work behind jBPM itself, of course.
Approach
There are many ways to use jBPM. One approach is to use it as a stand-alone process server, perhaps
deployed using JBoss. This solution exposes a console into which you can deploy business processes and
even test the process out, and watch it move state forward. As it's written using Hibernate, it's not too
difficult to get it working on JBoss' EJB environment. So, you might use it as a service. Indeed, JBoss itself
supports deploying processes to a directory and loading those, with some configuration.
For our purposes, we want to flip that deployment on its head. We want to embed, rather than
deploy to, jBPM, in the same way that we can use Spring to invert control for other things such as remote
services, message driven POJOs, and the HibernateTemplate .
In this example, we'll host jBPM's services in the Spring context, just like we might any other
Hibernate services. jBPM is, fundamentally, a runtime that stores its state and jobs in a database. It
uses Hibernate as its persistence mechanism (though it may eventually move to a strict JPA-based
model). When jBPM, with Hibernate, interacts with the database, it uses transactions and avails itself of
many of the features that Hibernate provides to build a sophisticated object graph mapped to a database
schema. Naturally, this isn't so bad, except that in order to use jBPM with other services inside of Spring,
particularly ones that leverage transactions (other database resources, XA functionality including but
not limited to JMS, other Hibernate models,and so forth), you need to exert control over jBPM's
transactions. Otherwise, jBPM will commit and begin transactions independent of the Spring
container's transaction lifecycle.
jBPM 4 is built cleanly, in such a way that delegating the lifecycle of the system to another container
(such as JBoss's microcontainer or Spring) is feasible. The jBPM 4 and Spring integration builds on top of
this, providing a recipe for accessing key services that jBPM provides at runtime. This is the key to the
integration. With jBPM available to your beans as just another bean in the container, you can leverage it