Workflow management with BPEL
All Together
BPEL helps you build tools for managing workflows.
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).
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.
Integrating Workflows with Structures
To integrate a workflow component with an existing infrastructure, architects often deploy a worklist management system as well as the central engine (see Figure 2).
When a BPEL process assigns a task to a specific employee, it calls a web service. The web service sends the task to the worklist manager, which accepts the query and adds it to the employee's to-do list. Once the employee has completed the task, the worklist manager sends a completion message to the BPEL engine. Systems of this kind are often linked to groupware or a web front end; other systems use email.
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.
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs