Eric D. Schabell: jBPM process rework in progress

Friday, October 17, 2008

jBPM process rework in progress

My current project has provide me with the chance to rework a rather a monolithic jBPM process implementation. It is my third time working through this same process flow and I want to do something about it before it gets any worse. It consists over over 59 nodes (decisions, task-nodes, nodes, but not a single state) and has all business logic intertwined within the individual nodes. Even some of the transitions have handlers that are providing business logic functionality which mystifies me to no end.

When the applications business logic is not placed in a service layer then I would expect that it would be kept as visible and above water as you could make it. The idea being to facilitate maintenance and future development within/upon the process flow. I was wrong. I won't get into the long story about how we got to the point that we can rework this process flow, it is not very interesting and I imagine it is par for the course in most large software development organizations.

All in all, it has provided a very interesting first step in my current project to start working on this problem. I am currently migrating as much logic possible from the transitions back into the process steps or even creating new process steps to bring this functionality into the light. Visibility is the key here. My plans:
  • Business logic is being encapsulated into services and pushed down into the SOA layer.
  • Transitional actions are being brought up into process steps
  • Core process steps are being black-boxed so that you can fill them with any eventual project specific sub-flow definitions as needed.
  • Migrating almost all process nodes to state nodes to facilitate a proxy between the process instance node and the service layer (calls)
  • Looking to add a custom jBPM class loader with maven like functionality to facilitate multiple projects running with different service versions (why we need this is an infrastructural problem)
This should keep me busy for the rest of the year as it is not a small task. More on this migration should any interesting experiences arise and feel free to provide input should you have some thoughts on these points.

1 comment:

  1. Some remarks/questions for your 'plans' (in order)
    # good choice, see http://www.redhat.com/v/webcast/SOAdemo2/SOADemo2.html
    # Is GPD visibility (or lack there of of actions on transitions) the reason for this?
    # jBPM 3.2.3 has the option to decide a subflow runtime (by name e.g. refering to a processvariable) not a specific version though, would that be of interest?)
    # Can you elaborate on this? I miss something, but that is probably me
    # jBPM 3.3 has some classloader changes, see the jira for this. Versioning in general is a challenge. Think e.g. of the relation between a process, webapp, rules etc... al with specific versioning things. Process and rules already support this, in combination with specific classes, but how should a versioned webbapp be implemented?

    Looking forward to your future steps/problems/...

    ReplyDelete

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