I played with jBPM and then dismissed it from consideration because it was too tied to HTTP and servlets. IMO It was a good idea but poorly implemented. I suggest looking at OSWorkflow instead.
Tied but not tightly
Posted byAnonymous Userat
2005-03-07 11:34 PM
jBPM's core workflow engine is independent of http. The web component for presenting forms to a user fairly primitive and dependent on http. It would be fairly easy to replace the presentation piece with one that is not based upon html and http. I spent a couple days looking at the code and created an improved version for working in portlets using velocity. With a little more work you could create a Swing or SWT version.
I found the documentation a lacking. Once you understand the way it works, it is pretty easy to use.
If you use jBPM your workflows will be versioned. Once a workflow is initiated, that version of the definition will be used until the process completes. In general this is a good thing. However, when you have long running processes it can make updates interesting.
I played with jBPM and then dismissed it from consideration because it was too tied to HTTP and servlets. IMO It was a good idea but poorly implemented. I suggest looking at OSWorkflow instead.
jBPM's core workflow engine is independent of http. The web component for presenting forms to a user fairly primitive and dependent on http. It would be fairly easy to replace the presentation piece with one that is not based upon html and http. I spent a couple days looking at the code and created an improved version for working in portlets using velocity. With a little more work you could create a Swing or SWT version.
I found the documentation a lacking. Once you understand the way it works, it is pretty easy to use.
If you use jBPM your workflows will be versioned. Once a workflow is initiated, that version of the definition will be used until the process completes. In general this is a good thing. However, when you have long running processes it can make updates interesting.