Peter Holditch

Services accessed by standard APIs, such as transaction services provided through JTA and the services of the EJB container, take a lot of the technical grunt work out of transforming business requirements into deployable applications and allow developers to devote more attention to the business logic, and less to the technical niceties of how this logic should be realized in a physical implementation.

There is more to business applications than application servers, however. The J2EE APIs (with the exception of JMS) tend to be focused around a synchronous programming model where a request for information (often from a Web browser) arrives, some code runs to execute whatever business logic there might be, and a response is sent back to the client. This model is fine for simple applications, but in real life, the front end that a user wishes to interact with is likely to be an aggregation of display elements for many back-end systems, and many business processes may involve interaction with partners, or offline systems, or they may simply run for a long time - where long is defined as longer than a user would wish to wait at his desk for a response to come back from the system.

To take care of these more complex - and more realistic - scenarios, BEA provides the WebLogic Platform - a higher-level set of platform services layered over the application server to deliver support for long-running business processes and back-end integration in the WebLogic Integration component, and to aggregate and display content at the front end in the WebLogic Portal. Completing the picture, WebLogic Workshop provides a runtime framework to abstract the complexity of using the synchronous J2EE programming model for asynchronous Web service implementations.

That's all well and good, but what does it have to do with transactions? In this column I'll look at the WebLogic Integration Business Process Manager (BPM) and how it uses the JTA subsystem provided by the underlying application server to bring ACID transaction properties to bear on potentially long-running business processes. This will not only serve as an introduction to one feature of the BPM tool itself, but give you some indication as to how the raw J2EE programming model in general, and JTA in particular, could be applied in a real design to a real business process.

So, What's the Problem?
As I've discussed here several times before, JTA transactions should be kept as short as possible to avoid locking a large quantity of distributed data for long periods of time, thereby increasing the susceptibility of an application to performance and scalability problems at best, and at worst to deadlock situations routinely impeding users' ability to interact with the finished system. The Business Process Management tool, on the other hand, is all about representing business processes that will, by definition, last for a long period of time - maybe, running into multiple years. Given the need to track process instances over these long periods of time, a database is clearly going to be necessary to store the state of all active workflow instances - try keeping in-memory state information reliably for a period of years.... Also, given that this database will be transactional, combining this representation of the process's state transactionally with the execution of the individual steps that make up the overall process will enable JTA to deliver once and once-only execution of each step in the process and minimize or avoid the need for compensating workflows and other such techniques to back out changes in the case of a failure. This, after all, is exactly what JTA does best. However, a trivial mapping of one workflow instance to one JTA transaction is clearly not what we want. We have already said that a workflow instance could be active for years, and also that a JTA transaction should be active for as short a time as possible, two obviously conflicting goals.

Workflow: Marriage While You Sleep
So how do you design a marriage between the close-coupled JTA transaction on the one hand, and the long-running workflow on the other? To find the answer, we need to discover why workflows can run for such a long time. They clearly aren't just hanging around for the sake of it. The reason always turns out to be that they're waiting for something, usually an event occurring in an external system (maybe even a system in someone else's organization). While an instance of a workflow is waiting for something to happen in this way, it no longer needs to be in the app server's memory executing. It can be swapped out to the database and the workflow engine can commence processing other useful work that can execute. The instance is said to be quiesced. You will have spotted that swapping the instance state to the database required a database update, which in turn will require the transaction to be committed. Yes, you've guessed it - the workflow engine will run tasks up to the point where an instance has to quiesce within the context of a single JTA transaction, and before it quiesces, it will commit the transaction. In fact, that's not strictly accurate. If a workflow instance was invoked programmatically within the context of an existing JTA transaction, then the workflow engine won't try to commit the transaction; it will merely perform the database update and return control to the caller.

In general, the workflow engine will start a transaction when an instance is activated (unless one is already in force, started externally) and execute actions as instructed by the workflow (including actions in and called sub workflows) up until the point when a quiescent state is reached. Then the state will be written away to the database and the transaction will be considered complete from the workflow engine's point of view. Workflow actions themselves (for example, call a business operation implemented in an EJB, call an application through an adapter) will also be invoked in the context of the transaction (subject to the usual rules enforced by the containers as defined in deployment descriptors). Provided they can support XA transactions, any updates that they cause to happen will commit or abort atomically with the progress of the workflow instance itself giving the desired once and once-only semantics that can so simplify coding of business logic.

Two final points: first, what happens when things go wrong? The workflow engine provides an exception-handling capability, and it is the responsibility of the active exception handler to decide if the exception is recoverable and commit, abort, or mark abort-only the transaction as appropriate. Second, what if I want to explicitly break up one workflow that just consists of a set of synchronous calls into multiple transactions? To achieve this, you must force the workflow instance into a quiescent state. This can be done by inserting an event node that triggers itself, assigning a task to a user or various other tricks documented in the manual. Thus, if you want transaction granularity smaller than the default, you can achieve it. That's it for this month, I'll flow off now and quiesce for a while. ZZzzzz...

References
A short article necessarily can't cover every detail of such a wide-ranging topic as workflow and transactions. For the complete description of the transactional behavior of the WebLogic Integration Business Process Management engine, refer to chapter 7, "Understanding the BPM Transaction Model," in the "Programming BPM Client Applications" manual.