Let’s have a look at four example scenarios that could benefit from a workflow, BPM or orchestration engine.

1.  

   Workflow: A simple web application that is responsible for managing tasks for people. Imagine an issue tracker where each type of starts a different type of workflow that involves several people. Or a DVD-store that manages the tasks done by people in the back-end after a sale has been submitted.

2.  

   Pageflow: A web application is made up of multiple pages. Most web frameworks have a mechanism of invoking a piece of user code, and then the user code returns the outcome. Based on the outcome, the web framework will show the next page. This maps very well on finite state machine diagrams. In some frameworks, this is called workflow, but I prefer the term pageflow. The added value of a pageflow engine in this context is that a pageflow process shows the overall picture of the web application. Without this overview, developers will have to scan through the pages, the invoked user code and the outcome to find out how the application is working.

3.  

   Legacy messaging: Legacy applications are often connected with newly developed applications by means of asynchronous messaging. Until recently, this kind of integration was often based on a proprietary protocol instead of the XML based technologies that are available now. In such an environment it can be a challenge for an application developer to keep track of what messages were sent and what messages are expected from other applications. That is another common situation where a state machine based workflow engine can be applied.

4.  

   Service orchestration: Suppose that you have already standardized your organisation on web services technology. All of the departments communicate over one backbone on which XML messages are exchanged asynchronously. (By the way, such a backbone is called a Enterprise Service Bus (ESB) and you should only use JBI-compliant implementations of such an ESB to make sure that you can by components from different vendors). Now suppose that you want to write a new web service as a function of existing web services. That’s a domain where the Business Process Execution Language (BPEL) is at its best. A BPEL engine is a component in an ESB-architecture. A BPEL processes is a service that is a combination of existing services.

The first point I want to make in this blog is that one process language is not enough. All attempts to find the ultimate process language have failed. Instead, each of the scenarios require their own process language. This is a very important statement because at this moment, some people still try to push BPEL as the ultimate process language. This perception is also fuelled by the fact that no consensus is being reached on other process languages as described in the other scenarios.

BPEL is the only standard that indeed gets consensus in one particular application domain. And BPEL is a necessary component of an ESB. But BPEL is not suitable in the other scenarios. The first 3 scenarios do not lend themselves to be handled by XML based technologies like web services. Many projects are realized with a simple .war web application that is deployed on Tomcat. Using BPEL in those environments just doesn’t make any sense.

The second point I want to make is that we should be searching for the ultimate foundation for all of these workflow and BPM engines, rather then searching for the ultimate process language. We started by identifying the two common functions that can be found in all workflow and BPM engines:

• Managing state: Processes are able to cope with wait states. This is something for which plain java just doesn’t have the proper support. See What’s wrong with the JVM
• Graphical representation: A graphical representation of processes can create a common language between business analysts and technical developers. As described before, this is another point that cannot be done with plain java.

After finding those two common functions of all workflow and BPM engines, we distilled a very simple approach to adding support for these functions on top of an Object Oriented Programming (OOP) language. You can find more information about it at the JBoss jBPM documentation.

These foundations are more then a theoretical exercise. In JBoss jBPM we already support 3 process languages today. Each of those languages are targeted at very different environments:

1. jBPM Process Definition Language (jPDL) : The core jBPM process language that focusses on task management and a clean integration with Java. All of this is packaged as a simple .jar Java library that can be used in simple web applications.
2. BPEL: Our BPEL product is an extension of the base jBPM library.
3. pageflow: In JBoss SEAM, jBPM is used for describing the pageflow of web applications.

The conclusion is that there are different types of workflow, BPM and orchestration. Each scenario requires its own process language. We have found Graph Oriented Programming to be a very solid basis for creating those process languages.