Workflow engines are underused and underappreciated. Most companies configure or develop enterprise software so that it implicitly reflects their business processes and leave it at that -- big mistake.
To use a workflow engine, you create a state diagram via a graphical tool or configuration file. As the workflow engine executes the file, it enables you to map and store the state of the system and hook into state transitions that trigger events and functionality.
[ Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
Using a workflow engine forces you to rethink the way you write software. It forces you to decouple business process from business software, which can help your software become more robust and componentized. You retain the atomic components of your logic -- even if the overall process changes.
Further, using a workflow engine also provides solid documentation for your business process. A new developer, for instance, can understand the whole process at a glance, rather than only after they've read through thousands of lines of code or digested what a series of remote calls mean. Sure, you could document this anyhow, but I've rarely seen hand-generated documentation kept up to date after a few releases.
Unfortunately, I've seen few large projects actually organize the development of key business processes around a workflow engine. But I know of several embedded engines: In the Java world, for example, Alfresco contains the Activiti workflow engine, while JBoss ESB includes the jBPM workflow engine, an outgrowth of the Drools project. Activiti is a reimagining of the project that was previously known as JBPM (before version 5) by the same author, Tom Baeyens. On the .Net side, you have Windows Workflow Foundation.
