Workflow management with BPEL
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 . 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.
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.
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.
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.
Founder of ownCloud launches the Nextcloud project.
Will The Machine change the way future programmers think about memory?