5

I'm looking for a straightforward Java workflow engine that:

  • can handle both automated and manual (GUI-based) steps within a workflow
  • supports long-running, asynchronous tasks
  • provides support for restarting workflows in the event of a server crash
  • stores a full audit history of previously executed workflows
  • provides easy access to this audit history data

Possible candidates include the new Drools Flow process engine in Drools 5, and OSWorkflow from OpenSymphony. From my current understanding, OSWorkflow seems to offer more of what I want (Drools Flow doesn't appear to store much in the way of an audit history); however, the most recent release of OSWorkflow was back in early 2006. Is it a mistake to now use OSWorkflow when it's no longer under active development?

Does anyone have much experience with either/both of these frameworks? Are there any other workflow engines I should be looking at? All recommendations welcome - thanks.

Roman C
  • 49,761
  • 33
  • 66
  • 176
A-G
  • 305
  • 4
  • 12

4 Answers4

7

Just to clarify how Drools Flow supports the requirements you are describing (refering to the Drools Flow documentation):

  • can handle both automated and manual (GUI-based) steps within a workflow

Drools Flow uses (domain-specific) work items (Chapter 8) to interact with external systems. These could be automated services, or a human task management component (Chapter 9) for manual tasks. This human task component is fully pluggable but Drools Flow supports a WS-HumanTask implementation out of the box. Drools 5.1 will include web-based task lists, including custom task forms.

  • supports long-running, asynchronous tasks

The engine allows you to start processes that can live for a long time. The process supports different kinds of wait states (work item nodes, event nodes, event wait nodes, sub-process, etc.) to model long-running processes. External tasks can be integrated synchronously or asynchronously.

  • provides support for restarting workflows in the event of a server crash

The runtime state of all process instances can easily be stored in a data source by turning on persistence (Chapter 5.1). Therefore, all processes can simply be restored in the state they were in after a server crash.

  • stores a full audit history of previously executed workflows

Drools Flow generates events about what is happening during the execution of your processes. By turning on audit logging (Chapter 5.3), these events can be stored in a database, providing a full audit history of whatever happened during execution.

  • provides easy access to this audit history data

The history data is stored using a few simple database tables. These tables can be queried directly, or you could use it for generating custom reports (Chapter 12.1) that show the key performance indicators that are relevant for your application.

Furthermore, we believe that a knowledge-oriented approach, allowing you to seamlessly combine processes with rules and event processing whenever necessary, will offer you more power and flexibility compared to aforementioned process-oriented engines.

Kris Verlaenen
Drools Flow Lead

  • Kris, Many thanks for the comprehensive answer. I'm now putting together a proof of concept workflow using Drools Flow - so far so good. It's likely I'll have a few questions as I go - hopefully see you on irc. Thanks again. – A-G Jun 10 '09 at 11:32
  • Just left jBPM after being horribly disappointed with their new API (4.3). Found Drools Flow and love it. – Richard Clayton Apr 15 '10 at 16:57
4

I've not had any experience with the candidates you've mentioned but judging from the projects that I've worked on it might be worth looking at jBPM. Quite a few developers I've worked with swear by it and I think it fits your criteria quite nicely.

digitalpardoe
  • 471
  • 3
  • 3
  • jBPM does not seem to be doing so well. With some of the core developers jumping ship, I suspect JBoss will end up migrating to Drools Flow as their standard Workflow implementation; thought this is from the perspective of an outsider. – Richard Clayton Apr 15 '10 at 17:04
4

Drools Flow is at lot more sophisticated and powerful than both jBPM and OSWorkflow and development is moving at a faster pace than either. We provide a lot of details and screenshots here: http://www.jboss.org/drools/drools-flow.html

But in summary. You get interactive debugging across rules, workflow and event processing. You have a larger set of built in nodes, improving the number of problems you can directly model declaratively. Correlated (across rules, processes and events) audit logging and reporting. We provide a very simple and yet powerful mechanism for building domain specific workflow, via our pluggable work items.

Drools 5.0 has just been released and 5.1 is going to follow in the next 4 to 6 weeks. We are adding simulation and testing for this, using an MVEL DSL, which we believe will be a huge hit. This will also include more extensive work for remote admin GUIs for processes, all integrated into Guvnor.

The Drools team also prides itself on being more accessible than any of those other mentioned projects. Feel free to pop onto irc for a chat.

Mark

Mark Proctor
  • 691
  • 4
  • 5
  • Mark, Thanks for your (and Kris's) answers. I'll be sure to use irc for any further questions I have. – A-G Jun 10 '09 at 13:27
1

I have experience with both.. also I was involved in a tool for migrating existing processes in OSWorkflow to Drools 5.0. You can read an article about that in: http://blog.athico.com/2009/01/drools-flow-and-osworkflow-migration.html. It is important to mention that this migration tool/translator was created to allow old projects that are using OSWorkflow to upgrade to Drools 5.0 and take advantages of all the Drools 5.0 Business Integration Platform.

Greetings