Eric D. Schabell: jBPM from the trenches - a state proxy for your state nodes

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.

7 comments:

  1. Due to decisions outside the control of man

    That must be the financial crisis ;-)

    ReplyDelete
  2. Not the financial crisis, the organizational crisis!!

    The first paragraph needs more clarification. There is too little detail in these posts. Not really interesting what is posted here.

    Too much fuzz too little examples and code snippets and not really exiting material etc.

    ReplyDelete
  3. Dear Anonymous,

    You are most certainly right... I am often stuck between being open and exposing too much of the companies software. They have been really great to me so I try to find a pragmatic balance.

    I'll tell you what, give me a bit of time on this topic and I will try to generate a more detailed posting of the solution applied and what it is meant to solve. This solution is in the works right now.

    I will really try to provide some code snippets in the post, promise! ;-)

    ReplyDelete
  4. As you might have read, I am leaving SNS Bank:

    http://www.schabell.org/2009/03/job-change-off-to-join-redhat.html

    I will not be able to post the code as I had hoped. I imagine you will understand why.

    ReplyDelete
  5. Ah, you are leaving...

    Too bad. Now your blog has even less value for me as your solution might be very interesting, not only for me but for the OS community and other readers as well.

    But, does your solution work, I bet you already used it in a test/acceptance environment by now?

    ReplyDelete
  6. The solution works, it is just a matter of finding time to put it into a project here. Other issues pushed this on the sidelines for now.

    I do understand the interest in the solution, so feel free to contact me (email) for details if you are so inclined. That I can do. ;-)

    ReplyDelete
  7. As promised, a bit more information and the final solution can be found here:

    http://www.schabell.org/2009/04/jbpm-from-trenches-state-proxy-solution.html

    ReplyDelete

Note: Only a member of this blog may post a comment.