This is at the moment intended to be a discussion 'playground' for concepts of using JMS in the context of jBPM in extension to the threads in the jBPM Developer forum. (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77591)

I've attached a PDF that gives a rough impression of what I have implemented for a client.

More coming up, especially on the reasons for dividing the execution in so many transactions.

Any comments welcome.

Rainer

-

(I'll just document what I've done. Not everything will be relevant to everyone. I/We will refine later on. Otherwise this would never get written. Most of the mechs should be of interest to any asynch features.) I would just show the code - for all those who read code better than docs - but the company that paid for all this isn't up to that. No ill will there, just corporate inertia.

• Reasons for using JMS

• Loadbalancing over Time and Machines

• Securing Non-Transactional Resources

• Concurrency

• Use of Transactions

• Separating Workflow State from Workflow Execution

• Implementation

Reasons for using JMS

Loadbalancing over Time and Machines

The scenario, for which the implementation described in the PDF was created, is an automated 'EAI' application that, basically, coordinates resources that may not support transactions. There is no user interaction.

The application must be able to handle high volume peaks that occur on a daily as well as a yearly basis (end-of-year processing routines). The queue mechs of JMS are ideal to spread out the load over time as well as in a cluster.

todo .... more coming

Securing Non-Transactional Resources

Both resources currently connected by this 'EAI' application are basically database applications (one is a well-known document management/archive system while the other is a well-known workflow application). Still, both do not support any transaction. This is a major problem - 'losing' a document in both (i.e. not starting a process in the legacy workflow system, as well as starting a process twice) is potentially embarrassing and very expensive.

Starting a process in the legacy workflow system is one of the actions done by a jBPM process. Directly implementing a legacy process start in an ActionHandler would have made any rollback of this action impossible. As the legacy workflow system does not support transactions the process is started. Period.

Using JMS we are able to package all information needed to start a legacy workflow process, send the message in a transaction and be sure that the message only gets sent if the and when the transaction commits. A MDB then does the actual work.

The 'EAI' application allows ActionHandlers or rather the Tokens to wait for a callback from the MDB.

todo .... more coming

Concurrency

jBPM does not support truly concurrent execution of more than one Token of the same ProcessInstance. (This should/could be expanded into an own topic "jBPM Concurrency and Transactions" as it pops up in the Forums all the time.) As long as the workload is executed inside of ActionHandlers the execution is singlethreaded per processInstance. This is usually ok (concurrent sounds good, but I haven't really seen a use case where there was any real benefit.)

In the rare situation where true concurrency is needed (long running tasks like finding the meaning of life) this can be achieved by packaging the workload and sending everything to a MDB by JMS. (This does not yet take into account the asynch functionality of jBPM 3.1)

todo .... more coming

Use of Transactions

Separating Workflow State from Workflow Execution

todo

Short version: this allows us to rollback whatever happended during workflow execution - because of some error condition - and still let the workflow state change, e.g. five retry attempts implemented by timers. Failure after the fifth attempt. This cannot be implemented if workflow state and workflow execution are in the same transaction.

Implementation

todo

(I will try to come up with a cleanroom implementation - is that possible? splitting your mind? - that I can share. For now a detailed description of the concepts will have to do.)