just like you might a Hibernate session or a JMS queue connection. Similarly, you can hide its use behind
service methods that you expose to your applications clients.
Imagine exposing a service method for creating customer entities. It might use Hibernate to save the
new record to the database, use JMS to trigger integration with an external financial system the company
uses, and use jBPM to start a business process for fulfillment. This is a very robust, well-rounded service.
You can use the services like you might any other transactional service—confident that the containing
transaction will envelope the transactions of the jBPM process.
We will build a simple application context that contains the common elements you'll need to start
using jBPM in your application, and then see where you may want to customize the solution to your
In the example for jBPM 4, we will build a solution that models a simple customer registration
workflow. In so doing, you will get a feeling for how you would set up the example, as well as get a
chance to see a (very simple) jBPM solution. The namespaces of the work we'll do will sit below
The Application Context
The first thing to do is to set up basic database and Hibernate configuration. We will use the tx , p , aop ,
and context namespaces to build this solution. The skeletal frame for our Spring XML configuration is
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=" http://www.springframework.org/schema/beans"
In this example, we'll use two Spring application contexts. One application context will configure
jBPM ( jbpm4-context.xml ), and the other will configure our sample application (simply, context.xml ).
The first application context is geared around configuring jBPM. You should be able to reuse this file
later with no changes to the file itself. Mainly, you'd have to update the property file (naturally) and
you'd have to tell the session factory about any annotated classes that you want it to know about from
your own domain model. In this example, doing so is simple, as it involves overriding an existing List
bean named annotatedHibernateClasses in a separate context. It's been done this way because it's not
possible to have two sets of Hibernate classes that are registered with the Hibernate SessionFactory .
To have an annotated class be registered as a Hibernate entity, it needs to be registered with the
AnnotationSessionFactoryBean. The annotatedClasses property expects a list of Class names. Because