Proposal to remove jBPM from the PSM

[Jason Owen]

We are using jBPM, the Java Business Process Model, in the PSM. I suggest that our project would benefit from us removing it and replacing it with something simpler. (We should continue to use our rules engine, Drools.)

jBPM is a large, powerful, and flexible framework. It offers the ability to have many workflows, called business processes, which it manages on behalf of the application. These workflows are supposed to be easy to modify or replace, so as to custom-fit a particular deployment of the client application without a lot of custom code. jBPM also offers the capability of providing a user interface to handle steps in the business process that require user interaction.

The way the PSM uses jBPM makes it difficult for us to benefit from the good features of jBPM, while still imposing the overhead and complexity of a heavyweight framework. The PSM has a single business process, and the jump between native Java code and the jBPM-specific code makes it more difficult for developers to understand how the application works. Our experience of attempting to modify that single business process has been time-consuming and required both a higher level of expertise and more custom Java code than we’d hoped. The UI that jBPM offers does not look like the rest of the PSM, and so instead we have our own custom UI, written in Java and JSPs like the rest of the application. Finally, the way that the PSM integrates with jBPM makes it nearly impossible to upgrade jBPM to a more modern, supported version.

These problems have already had negative consequences in our development, in the form of seemingly simple changes requiring extensive work. We've twice tried to upgrade the version of jBPM we're using, and been unable to in the time we were willing to spend on it. Even small changes, like switching an input field from "EFT Vendor Number" to "Do you accept EFT? [ ] Yes [ ] No" radio buttons, ended up taking longer and being more difficult than it sounds like it should be, due largely to the design decisions imposed upon the project by the integration with jBPM.

We have work planned that will need to change or interact with jBPM, including:

- Adding external sources to our automated screenings

- Improving the UI around automated screenings

- Automatically re-running automated screenings on a regular basis

- Upgrading our external rules server

Each of those will be more difficult and time-consuming with jBPM, and less difficult without it.

I would like to remove jBPM from our project.

The most useful feature it provides (to us) is doing background work after an enrollment application has been submitted, in a way that does not block the web request. I think we should replace that functionality with an event-driven processing approach, such as that provided by Java EE message-driven beans (or Spring's equivalent).

Our single business process is pretty straightforward. There are essentially two parts: 1. new enrollment application submitted -> run automatic screenings, and 2. enrollment application approved -> do approval post-processing. Each of these map very simply to an event-driven approach.

The first step is to remove the unused or unimplemented steps from our current process. This overlaps with our goal of removing all the references to the old external sources, and is already in progress.

Once the process is cut down to the parts that are actually used, we can work backwards from the terminal nodes of the workflow, and switch those jBPM work item handlers into event-driven message handlers, one-by-one, so that jBPM and the event-driven architecture exist side-by-side during the transition.

After switching all the work item handlers over to be event-driven, we can remove jBPM.

An important aspect of this plan is that the PSM remains in a working state throughout the development process. If our priorities shift, we will be able to pause development on removing jBPM, with only the cost of context-switching. Our work can be merged as we go, using our usual review process, rather than having a giant, potentially problematic switchover all at once.

This investment would pay off in quicker development in the future, as well as easier onboarding of new developers, by simplifying the project and using more common architectural patterns.

This is a fairly technical proposal, but it will have a big enough impact on the PSM that I want to both let the PSM community know and solicit feedback. Do you have any questions? Do you have concerns about this? Do you have alternate approaches?

Thanks,

Jason