Thursday, January 15, 2009

jBPM from the trenches - a state proxy for your state nodes

The first post from the trenches in 2009 and the political winds have shifted on our jBPM process rework. Due to decisions outside the control of man, we have been forced to abandon all of our work on migrating the business logic down into the services layer (SOA). Instead, wise men have decided to implement a brand new process in jBPM which could contain the various elements already discussed for the process upgrade. Unfortunately it most likely won't.

There is always a bright side to these events. I have been given plenty of time to work on a state proxy solution. To review a bit, it is a wish to make use of state nodes within our process definitions. This would provide a more secure situation for our processes by persisting data in each process step where business logic is executed. Up to now it has not been possible due to service calls not being able to signal a wait state that the response is ready. Now it will be.

A Java Dynamic Proxy together with a Factory is used to provide access to web services interfaces. Each state node will make a single service call through that services proxy in the state nodes onPerformCall method. Results are serialized with jboss serialization, as the web service interfaces and implementations are not serializable we could not just use Java serialization. Reacting to the results is done in either the onHandleResults or onHandleException methods depending on succes or failure.

The architectural complications that keep us from using some of the nicer solutions available have been covered previously in the above linked posts, but a quick summary might help explain the situation:
  • no upgrades allowed yet from jbpm-3.1.4
  • deployment is on a single jbpm engine
  • no ESB
There are some interesting things in the works to improve the above situation, so stay tuned for more soon.