Workflow Continuations

Programmers are looking for simpler ways to define workflows. The simplest form is using what Fowler calls a transaction script. Interactions between the client and server are scripted out in simple method calls-- pretty simple, it's kind of like stating the sky is blue.

With the web, things aren't as simple. During client and server interactions, the client can basically hold the 'transaction' for an infinite length of time (20 or 30 minutes in most cases for the life of their sessions). A couple of solutions to this "wait" period are:

• Put the workflow in a thread, present the view and put a wait lock on the thread until the next response comes in.


• Break up the steps of the transaction into seperate methods that allow the transaction to simply be a series of action calls-- such as Struts, etc.


• Implement continuations to allow the process to mark "pauses" in the execution without the need for threads.

Recently, there has been some talk of having the JVM include continuations-- allowing the JVM state to be paused or persisted and continued at a later time. I've looked at what James Strachan has been doing with CodeHaus and what Rife is suggesting as a solution to scripting transactions on the web. I'm finding a couple issues with continuations as a solution to web applications, such as:

• I have concerns with memory usage, if the stack/heap is popped from the current thread, how will that be managed? When will the memory be reclaimed?


• If your thread exits the current process via continuations to serve up the view, nothing says that the state can't change in ways unexpected. Traditional transaction processing involves calling the same processes over and over until it's successful. Continuations say that I can be half way though the process and pick up exactly where I left off-- half way done already. But if we can't restrict changes to the state, then we really can't just pick up half way through the transaction again.


• Continuations, like AOP can *allow* for poorly written code. By forcing programmers to break operations up into steps, it leads to reusable code. Continuations could lead some programmers to scripting 'special cases' everytime without exposing processes for reuse.

The solution then to modeling workflows? I don't have one yet. I am currently investigating using the visitor pattern with actions, but this may only add unecessary complexity for the common case. Hopefully I will write more this idea later.