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

11-4. Building a Service With Spring

Problem
In the previous recipe, we configured Spring and jBPM, such that Spring's is successfully “hosting”
jBPM. Y ou set about writing a business process and want to work with jBPM inside of your service code,
and to be able to delegate actions to Spring beans from within a business process.

Solution
Use Spring normally, injecting the services as you need them. For access within your business process,
you can simply reference the services as you would any other process or environment variable in a
business process. jBPM will expose beans using the jBPM expression language, and you can then just
reference them by name.

Approach
In this recipe, we'll work through a simple example so you can see the pieces of a typical integration with
Spring and jBPM. We've already laid the ground work in the previous example. Here, we'll actually build
a simple Java service that works with Spring to move the process state forward.
The use case is a user registration, like the one described in Figure 11-1.
There are four steps:
1. A prospective customer (modeled here as a Hibernate entity, Customer ) signs

up via a form. (We'll leave the web page interactions to your imagination for
this example; suffice it to say that the form, when submitted, invokes a service
method, which we'll define.)

2. A verification e-mail is sent.

3. The user (ideally) will confirm the receipt of the e-mail by clicking on a link,

which authorizes the user. This could happen in a minute, or in a decade, so
the system can't afford to waste resources waiting.

4. Upon confirmation, the user will receive a “Welcome!” e-mail.

This is a simple use of a business process. It abstracts away the process of incorporating and
processing a new Customer . Conceivably, the Customer object could have come from any number of
channels: somebody sitting taking phone calls inputs them manually, the user self-subscribes to the
system, in a batch process, and so on. All of these different channels can create and reuse this business
process, though. When the processing for a new customer is standardized, the challenge becomes about
surfacing the functionality for as many end users as possible.
Because the user could conceivably wait a few days (or weeks; it's arbitrary) before checking the
e-mail and clicking the confirm link, state needs to be maintained but not burden the system. jBPM, and
indeed most workflow engines, passivate state for you - allowing a process to “wait” on external events
(“signals”). Indeed, because you've decomposed your process into a series of isolated steps, each of
which contribute to the larger goal while remaining independently useful, you get the best of both
worlds: stateful processes and stateless scalability. The state of the global business process is
maintained, and throughout the state of customer's sign-up is persistent, but you get the benefits of not
keeping things in memory when there's no progress in the business process, thus freeing it up to handle
other requests.