12 June 2008
Most systems have context that lasts longer than the typical request/ response of the clients and servers involved in the system, but shorter than the lifetime of the business entities that define the domain model. This is called "conversational" state. The naïve way to handle conversational state is to clutter the domain model with "state" flags that mark benchmarks against some sort of process.
Typically, these state flags aren't useful data to the enterprise. Sometimes they do correspond with business events, in which case they perhaps deserve a flag. When they don't however, it is a grave mistake to enshrine these passing values in the data tier. Take for example the simple process of signing up a user.
The only real business data here is that the customer has signed up and is in a consistent state, or that she hasn't, in which case perhaps the inconsistent data should be expunged from the system. To model this, however, you would have to have some way to note whether or not the user is in the process of signing up, whether she's gotten a confirmation email, whether she's clicked on the confirmation link in the email and whether she's completed the sign up process. And that's for a very SIMPLE process with two "actors" (modeled as swimlanes – the user and the services)! Imagine what something even mildly complex with concurrent processes would look like!
What you need is some way to divorce process state from the domain model entirely and keep it in a structure designed to measure state. In the case of something like Spring Web Flow or JBoss Seam's jPDL page flow language for the wizard interaction, that state is stored in the session and measures progress against mile-markers in a "flow". In the case of a true workflow / Business Process Management system like jBPM that state is typically stored in the database. Each milestone is called an activity. Because the structure keeps track of where any given process is relative to the whole process, you can derive metrics from these systems that are useful to the business.
So now you know how to model a conversation. Generally. What you need is some way to "code" an activity diagram. That's where a BPM system comes in play.
Next, we'll discuss actually using a BPM system, jBPM.