Java – Lightweight workflow engine for Java

activitijavajbpmworkflow

Is it better to write a new workflow engine or to use an existing BPM engine: jBPM 5, Activiti 5?

My application is a web based application and performance is important. My doubt is whether using jBPM/Activiti will be a performance overhead compared to writing a simple workflow engine.

If I go with self implementation, I will miss visualization of workflow. For performance it can be traded.

Best Answer

I agree with the guys that already posted responses here, or part of their responses anyway :P, but as here in the company where I am currently working we had a similar challenge I took the liberty of adding my opinion, based on our experience.

We needed to migrate an application that was using the jBPM workflow engine in a production related applications and as there were quite a few challenges in maintaining the application we decided to see if there are better options on the market. We came to the list already mentioned:

  • Activiti (planned to try it through a prototype)
  • Bonita (planned to try it through a prototype)
  • jBPM (disqualified due to past experience)

We decided not to use jBPM anymore as our initial experience with it was not the best, besides this the backwards compatibility was broken with every new version that was released.

Finally the solution that we used, was to develop a lightweight workflow engine, based on annotations having activities and processes as abstractions. It was more or less a state machine that did it's job.

Another point that is worth mentioning when discussing about workflow engine is the fact they are dependent on the backing DB - it was the case with the two workflow engines I have experience with (SAG webMethods and jPBM) - and from my experience that was a little bit of an overhead especially during migrations between versions.

So, I would say that using an workflow engine is entitled only for applications that would really benefit from it and where most of the workflow of the applications is spinning around the workflow itself otherwise there are better tools for the job:

Regarding state machines, I came across this response that contains a rather complete collection of state machine java frameworks.

Hope this helps.