An employee who is going on a business trip mails the dates and target location to a service center; somebody in the back office copies these details to various online booking portals and issues a confirmation memo. The employee then returns from the trip and enters the same data again for an expenses claim. Some clever employee might use scripting to automate this process, thereby removing the need for entering redundant information, but what happens if the company modifies the process? Will anyone take the time to rewrite all the custom scripts?

Developers often need a way to modify business processes without reinventing the underlying infrastructure. The processes are thus the interface between the productive departments and IT. At the same time, developers and administrators need to keep track of the whole system and its internal processes – a challenge for both modelers and architects.

The purpose of workflow management systems (WFMS) is to model operations independently of their implementation. The idea is to give users basic tools that map procedures to business functions, such as mail, credit card transactions, or inventory systems, without the need for legacy programming.

XML lends itself to this kind of task, but because an XML description is difficult to manage with just an editor, a range of graphical tools are available to handle the job. The WFMS reads the process definition encoded in the XML and refers to it to coordinate and check the tangible instance of the modeled process.

Workflow engines provide a means for addressing the chain of activities and its sequence. To integrate individual services, most engines use Service-Oriented Architecture (SOA), an XML-based function description. SOA lets a company glue together components from different frameworks. For instance, you can deploy SAP systems in Accounting and still use an in-house component based on JEE or Dotnet in Engineering.

If all the applications have direct SOA interfaces, WFMS can link their functions across applications and control workflows between the components. The individual web services are like the instruments in an orchestra: The workflow directs and integrates the individual parts to create a harmonious whole. Experts in the field refer to this as "programming in the large."

Business Process Execution Language (BPEL) is a standard for SOA workflow management. IBM, BEA, Microsoft, SAP, and others drafted the BPEL OASIS standard, which has now reached version 2.0 [1]. BPEL uses XML to describe processes and relies on the web service standards WSDL and SOAP.

Designing Sample Processes

The process designer starts by drafting planned workflows in a mainly non-technical form, such as event-driven process chains or sketches. Then the designer uses one of the various editing tools to create a BPEL environment – that is, to formulate a plan in the formal description language. The Eclipse environment, for instance, offers BPEL programmers action pallets that support point-and-click-based process building (see Figure 1).

Figure 1: Instead of manually editing the XML code, the BPEL Designer lets users model processes by drag and drop.

BPEL models a process as a sequence of atomic processing steps, or activities. These activities are typically provided directly by web services as invoke elements, or they are available as manipulable variables. Developers organize individual activities as nodes in a graph. Each node contains exactly one control element – for example, conditions that trigger other activities or flows that execute other activities in parallel. Elements such as sequences or loops also manage the control flow.

When stored in an XML document, these structures represent a BPEL process definition. The definition additionally contains meta information and interface descriptions. The modeler formulates the definition in WSDL and as PartnerLinks elements. These elements create a further abstraction layer – between invoke activities below a process on the one hand and tangible web services on the other.

BPEL uses the default XML schema to pass in values; the variables can thus accept complex structures. Fault handlers catch process execution errors and respond by, say, shutting down the database connection. In contrast to this, event handlers provide additional services besides the normal process logic.

Controlling Sequences

The pattern the planner uses to organize sequences is, in effect, the process. Not until a run-time environment, the BPEL engine, parses this description are process instances created from it. Each instance has its own states. The instance links the individual IT systems with the stakeholding employees (see the "Integrating Workflow with Structures" box). Stakeholders are given their own web service connections: To allow this to happen, the engine delivers an email message to the stakeholder or adds a task to the enterprise groupware.

Business processes can take multiple days or even longer depending on the application. Legacy methods such as rolling back an SQL database cannot fully guarantee data integrity in this kind of environment: for example, it is impossible for the sender to recall a letter they have sent. Instead, workflow systems rely on compensation, such as a second letter that cancels a hotel reservation. A compensation is defined like a separate process in a BPEL context; developers can use all of BPEL's design options within the compensation.

Figure 2: The BPEL engine executes individual activities in a sequence provided by users as specified through data created in a browser-based worklist manager.

Long-Winded

Another problem occurs with lengthy processes: The typical HTTP request/response approach is insufficient if the response takes too long to arrive. A request to a synchronous service like this would time out before the web service could respond. For this reason, BPEL defines techniques for asynchronous web service communications between the client and server. The client interrupts the connection when a confirmation of receipt reaches it. The request uses a replyTo header field to define a URL for the response. Once the task is complete, the two partners swap roles, and the former server sends the response to the specified address so that the BPEL engine at this address can continue the process. If it is impossible for the process engine to accept responses, the task falls to a middleware component, such as an enterprise service bus.