Describe business process activities as Web services

Add WSBPEL to your enterprise toolbox

Web Services Business Process Execution Language, WSBPEL, is an XML-based process/workflow-definition execution language. WSBPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web services interfaces. WSBPEL also defines how multiple service interactions with these partners are coordinated to achieve a business goal as well as the state and the logic necessary for this coordination. WSBPEL, previously called Business Process Execution Language for Web Services (BPEL4WS), is often simply referred to as BPEL.

Business processes defined in WSBPEL can be modeled and re-engineered using numerous BPEL modeling tools to generate a BPEL file, which can then be deployed and executed in a runtime environment known as a native BPEL engine.

What relevant standards bodies pertain to WSBPEL?

WSBPEL evolved from the convergence of ideas and concepts such as Microsoft's XLang and IBM's WSFL (Web Services Flow Language). WSBPEL is now a part of the Organization for the Advancement of Structured Information Standards (OASIS) and has industry support from many vendors such as BEA Systems, Oracle, and IBM. The WSPEL specification mainly addresses service orchestration, where business processes are created using the services of the trading partners or stakeholders in the process.

What is the status and industry adoption of WSBPEL?

The current version of WSBPEL is 1.1; the 2.0 version, a committee draft dated September 1, 2005, is being defined by the OASIS WSBPEL Technical Committee. WSBPEL is backed by major IT players and software vendors such as Adobe Systems, Hewlett-Packard, IBM, Microsoft, Tibco Software, Sun Microsystems, and SAP, to name a few, and has also been adopted by the industry as the popular language for defining Web services-based business processes. Currently, numerous design-time and runtime products, such as WSBPEL-compliant modeling tools, editors, and process engines, are available from major software vendors.

What standards enable WSBPEL?

WSBPEL extends support to existing Web services standards to achieve universal interoperability between applications. As we know, Web services are built on a loosely-coupled integration model to allow the flexible integration of heterogeneous systems in a variety of domains including business-to-consumer, business-to-business, and enterprise application integration.

WSBPEL leverages several XML-based specifications pertaining to the Web services world such as:

  • WSDL (Web Services Description Language) 1.1
  • XML Schema 1.0
  • Web Services Addressing
  • XPath 1.0

WSDL messages and XML Schema type definitions provide the data model used by WSBPEL processes. XML Schema 1.0 is also used as the interface for validating all the process definitions generated using any of the available BPEL modeling tools and editors. WSBPEL's dependency on WS-Addressing avoids the invention of a private WSBPEL mechanism for Web services endpoint references—such references are obviously a general requirement in Web services usage. WSBPEL 1.1 provides extensibility to XPath 1.0, which supports data manipulation and can also accommodate future versions of these standards, specifically with regards to XPath and the related standards used in XML computation.

How Web services enable business process orchestration

Web services is a key component that enables services-based business process orchestration. WSDL has the most influence on WSBPEL, as its process model is layered on top of the service model defined by WSDL 1.1. At the core of the WSBPEL process model is the notion of peer-to-peer interaction between the services described in WSDL; both the process and its partners are modeled as WSDL services. A business process defines how to coordinate the interactions between a process instance and its partners. In this sense, a WSBPEL process definition provides and/or uses one or more WSDL services and also provides the description of the behavior and interactions of a process instance relative to its partners and resources through Web services interfaces.

In particular, a WSBPEL process represents all partners and interactions between these partners in terms of abstract WSDL interfaces (portTypes and operations); no references are made to the actual services used by a process instance.

Using WSBPEL

Now that we have a background on WSBPEL, let's try to understand its various constructs and how we can use them to define a meaningful business process. WSBPEL resembles conventional workflow management systems and follows a similar approach. WSBPEL activities have been designed to allow for most forms of process modeling and facilitate the mapping of graphical workflow modeling tools to BPEL. Presently, the activities in WSBPEL 1.1 can be divided into basic, or unstructured, activities and structured activities. In this article, we provide only a brief overview of each activity.

Table 1. Basic activities

<receive>Blocks until a message is received.
<reply>Sends a message in response to a received message. Therefore, the combination of a <receive> and a <reply> forms a request-response operation on the WSDL portType for the process.
<invoke>Invokes an operation on a portType provided by one of the collaboration partners.
<assign>Construct can be used to update the values of variables with new data.
<throw>Raises a fault for a fault handler to catch within the defined scope for an activity.
<terminate>Ends the business process explicitly.
<wait>Suspends execution for a given period of time or until certain time has passed.
<empty>No-operation used for synchronization purposes.

Table 2. Structured activities

<scope>Defines a block of activities.
<sequence>Executes a set of activities in an order; i.e., one after another.
<flow>Executes one or more activities concurrently; i.e., parallel processing.
<while>Repeats an activity depending on certain conditions.
<switch>Based on the condition, it chooses between a set of activities to execute.
<pick>Blocks and waits for a suitable message to arrive or for a time-out alarm to go off.
<compensate>Defines the set of activities that need to be compensated.

How XQuery is useful in the extension and implementation of WSBPEL

WSBPEL, being described in XML syntax, can thus be treated as an XML document. An implementation of the WSBPEL specification showcases several instances of running business processes, which, in turn, necessitate management of those instances and retrieval of meaningful information. XQuery, which is the de facto query language for XML, provides a rich way of querying a WSBPEL document and retrieving information from the document—for example, finding all trading partners involved in a process and querying across partner management applications to locate Collaboration Protocol Profile and Agreement (CPPA) agreements for a request validation. We propose using an XML database platform that includes an XQuery engine to provide the technology for this logical approach of storing and managing process instance documents.

Process lifecycle management with a native XML database

As one can imagine, in any real-world business process scenario, many process versions can be active at runtime. This means, for the purpose of maintenance and housekeeping, all production processes require persistence and querying on all copies of running processes. Also, some state management is needed to handle the interaction among activities. In addition, within a BPEL process, various versions of a Web service can be described.

A native XML database can provide persistence for all versions of processes and Web services, and also define the right processes for the right kind of applications at runtime using schema versioning and validation features of the database. The easiest way to achieve schema versioning using a native XML database is to tag the process document as the LATEST version at the time of deployment. So, whenever a new request is received for that process, the engine will create an instance from the LATEST tagged process.

To provide more flexibility, a request should carry versioning information about the process so the engine can create an instance of the process for that specific version. Also, a process can be marked as obsolete or dead when not in use anymore. If one prefers to achieve this functionality by updating an XML document at the node level, an XQuery engine that enables node-level updates may provide a better alternative.

WSBPEL process analysis

As described earlier, an XML persistence mechanism is important for process lifecycle management when combined with XQuery. Another advantage of having XML persistence for business processes is the use of an XML data management system for business process analysis, which can be important in real-world business scenarios. WSBPEL specs do not provide a clear way for any optimization mechanism based on past execution. It is thus advantageous to have historical or persisted data for the processes, either running or completed, to enable process optimization. Furthermore, various reports and key process indicators can be generated from the persisted data and metadata used during process execution, such as:

  • Number of running/completed instances of processes per week
  • Number of errors for specific endpoints or partner links for a process
  • Execution time for a specific process over a period of time
  • Size of data exchanged per endpoint
  • Availability or uptime of partner links (uptime)
  • Average wait time for asynchronous endpoints

BPEL engine architecture

A typical BPEL engine from our viewpoint can be depicted as shown in the figure below:

A typical BPEL engine architecture. Click on thumbnail to view full-sized image.

In summary, a typical BPEL engine services requests pertaining to processes compliant to WSBPEL 1.1. The engine implementation could extend any Web services engine/SOAP engine. The architecture's key components are the gateway, process engine, message transformers, queues, handlers, and managers for various functions within the engine and a native XML database. The BPEL engine creates process instances and executes activities as per their language definitions to achieve a business result for every request. The execution contains the business process definition, WSDL(s), and engine-specific deployment descriptor files.

Salient features of WSBPEL

WSBPEL 1.1 clearly speaks about its capability of defining the business process, which, simply put, is the orchestration of Web services in a sequential or a structured way. WSBPEL addresses some key concepts such as:

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more