WS-BPEL language basics

Before we can design an orchestration layer, we need to acquire a good understanding of how the operational characteristics of the process can be formally expressed. This book uses the WS-BPEL language to demonstrate how process logic can be described as part of a concrete definition (Figure 16.1) that can be implemented and executed via a compliant orchestration engine.

Figure 16.1. A common WS-BPEL process definition structure.

Although you likely will be using a process modeling tool and will therefore not be required to author your process definition from scratch, a knowledge of WS-BPEL elements still is useful and often required. WS-BPEL modeling tools frequently make reference to these elements and constructs, and you may be required to dig into the source code they produce to make further refinements.

Note

If you are already comfortable with the WS-BPEL language, feel free to skip ahead to the Service-oriented business process design (a step-by-step process) section.

 

16.1.1. A brief history of BPEL4WS and WS-BPEL

Before we get into the details of the WS-BPEL language, let's briefly discuss how this specification came to be. The Business Process Execution Language for Web Services (BPEL4WS) was first conceived in July, 2002, with the release of the BPEL4WS 1.0 specification, a joint effort by IBM, Microsoft, and BEA. This document proposed an orchestration language inspired by previous variations, such as IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification.

Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS specification was released less than a year later, in May of 2003. This version received more attention and vendor support, leading to a number of commercially available BPEL4WS-compliant orchestration engines. Just prior to this release, the BPEL4WS specification was submitted to an OASIS technical committee so that the specification could be developed into an official, open standard.

The technical committee is in the process of finalizing the release of the next version of BPEL4WS. It has been announced that the language itself has been renamed to the Web Services Business Process Execution Language, or WS-BPEL (and assigned the 2.0 version number). The changes planned for WS-BPEL have been made publicly available on the OASIS Web site at www.oasis-open.org.

Notes have been added to the element descriptions in this section where appropriate to indicate changes in syntax between BPEL4WS and WS-BPEL. For simplicity's sake, we refer to the Business Process Execution Language as WS-BPEL in this book.

16.1.2. Prerequisites

It's time now to learn about the WS-BPEL language. If you haven't already done so, it is recommended that you read Chapter 6 prior to proceeding with this section. Concepts relating to orchestration, coordination, atomic transactions, and business activities are covered in Chapter 6, and are therefore not repeated here. This chapter also assumes you have read through the WSDL tutorial provided in Chapter 13.

16.1.3. The process element

Let's begin with the root element of a WS-BPEL process definition. It is assigned a name value using the name attribute and is used to establish the process definition-related namespaces.

Example 16.1. A skeleton process definition.

<process name="TimesheetSubmissionProcess"
 targetNamespace="http://www.xmltc.com/tls/process/"
 xmlns=
 "http://schemas.xmlsoap.org/ws/2003/03/
 business-process/"
 xmlns:bpl="http://www.xmltc.com/tls/process/"
 xmlns:emp="http://www.xmltc.com/tls/employee/"
 xmlns:inv="http://www.xmltc.com/tls/invoice/"
 xmlns:tst="http://www.xmltc.com/tls/timesheet/"
 xmlns:not="http://www.xmltc.com/tls/notification/">
 
 ...
 
 
 ...
 
 
 ...
 
 ...
process>

The process construct contains a series of common child elements explained in the following sections.

16.1.4. The partnerLinks and partnerLink elements

A partnerLink element establishes the port type of the service (partner) that will be participating during the execution of the business process. Partner services can act as a client to the process, responsible for invoking the process service. Alternatively, partner services can be invoked by the process service itself.

The contents of a partnerLink element represent the communication exchange between two partnersthe process service being one partner and another service being the other. Depending on the nature of the communication, the role of the process service will vary. For instance, a process service that is invoked by an external service may act in the role of "TimesheetSubmissionProcess." However, when this same process service invokes a different service to have an invoice verified, it acts within a different role, perhaps "InvoiceClient." The partnerLink element therefore contains the myRole and partnerRole attributes that establish the service provider role of the process service and the partner service respectively.

Put simply, the myRole attribute is used when the process service is invoked by a partner client service, because in this situation the process service acts as the service provider. The partnerRole attribute identifies the partner service that the process service will be invoking (making the partner service the service provider).

Note that both myRole and partnerRole attributes can be used by the same partnerLink element when it is expected that the process service will act as both service requestor and service provider with the same partner service. For example, during asynchronous communication between the process and partner services, the myRole setting indicates the process service's role during the callback of the partner service.

Example 16.2. The partnerLinks construct containing one partnerLink element in which the process service is invoked by an external client partner and four partnerLink elements that identify partner services invoked by the process service.

<partnerLinks>
 <partnerLink name="client"
 partnerLinkType="tns:TimesheetSubmissionType"
 myRole="TimesheetSubmissionServiceProvider"/>
 <partnerLink name="Invoice"
 partnerLinkType="inv:InvoiceType"
 partnerRole="InvoiceServiceProvider"/>
 <partnerLink name="Timesheet"
 partnerLinkType="tst:TimesheetType"
 partnerRole="TimesheetServiceProvider"/>
 <partnerLink name="Employee"
 partnerLinkType="emp:EmployeeType"
 partnerRole="EmployeeServiceProvider"/>
 <partnerLink name="Notification"
 partnerLinkType="not:NotificationType"
 partnerRole="NotificationServiceProvider"/>
partnerLinks>

You'll notice that in Example 16.2, each of the partnerLink elements also contains a partnerLinkType attribute. This refers to the partnerLinkType construct, as explained next.

16.1.5. The partnerLinkType element

For each partner service involved in a process, partnerLinkType elements identify the WSDL portType elements referenced by the partnerLink elements within the process definition. Therefore, these constructs typically are embedded directly within the WSDL documents of every partner service (including the process service).

The partnerLinkType construct contains one role element for each role the service can play, as defined by the partnerLink myRole and partnerRole attributes. As a result, a partnerLinkType will have either one or two child role elements.

Example 16.3. A WSDL definitions construct containing a partnerLinkType construct.

xmlns:plnk=
 "http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
 ...
>
 ...
 partnerLinkType name="EmployeeServiceType" xmlns=
 "http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
 
 
 
 partnerLinkType>
 ...
definitions>

Note that multiple partnerLink elements can reference the same partnerLinkType. This is useful for when a process service has the same relationship with multiple partner services. All of the partner services can therefore use the same process service portType elements.

Note

In version 2.0 of the WS-BPEL specification, it is being proposed that the portType element be changed so that it exists as an attribute of the role element.

 

16.1.6. The variables element

WS-BPEL process services commonly use the variables construct to store state information related to the immediate workflow logic. Entire messages and data sets formatted as XSD schema types can be placed into a variable and retrieved later during the course of the process. The type of data that can be assigned to a variable element needs to be predefined using one of the following three attributes: messageType, element, or type.

The messageType attribute allows for the variable to contain an entire WSDL-defined message, whereas the element attribute simply refers to an XSD element construct. The type attribute can be used to just represent an XSD simpleType, such as string or integer.

Example 16.4. The variables construct hosting only some of the child variable elements used later by the Timesheet Submission Process.

<variables>
 <variable name="ClientSubmission"
 messageType="bpl:receiveSubmitMessage"/>
 <variable name="EmployeeHoursRequest"
 messageType="emp:getWeeklyHoursRequestMessage"/>
 <variable name="EmployeeHoursResponse"
 messageType="emp:getWeeklyHoursResponseMessage"/>
 <variable name="EmployeeHistoryRequest"
 messageType="emp:updateHistoryRequestMessage"/>
 <variable name="EmployeeHistoryResponse"
 messageType="emp:updateHistoryResponseMessage"/>
 ...
variables>

Typically, a variable with the messageType attribute is defined for each input and output message processed by the process definition. The value of this attribute is the message name from the partner process definition.

16.1.7. The getVariableProperty and getVariableData functions

WS-BPEL provides built-in functions that allow information stored in or associated with variables to be processed during the execution of a business process.

getVariableProperty(variable name, property name)

This function allows global property values to be retrieved from variables. It simply accepts the variable and property names as input and returns the requested value.

getVariableData(variable name, part name, location path)

Because variables commonly are used to manage state information, this function is required to provide other parts of the process logic access to this data. The getVariableData function has a mandatory variable name parameter and two optional arguments that can be used to specify a part of the variable data.

In our examples we use the getVariableData function a number of times to retrieve message data from variables.

Example 16.5. Two getVariableData functions being used to retrieve specific pieces of data from different variables.

getVariableData ('InvoiceHoursResponse',
 'ResponseParameter')

getVariableData ('input','payload',
 '/tns:TimesheetType/Hours/...')

 

16.1.8. The sequence element

The sequence construct allows you to organize a series of activities so that they are executed in a predefined, sequential order. WS-BPEL provides numerous activities that can be used to express the workflow logic within the process definition. The remaining element descriptions in this section explain the fundamental set of activities used as part of our upcoming case study examples.

Example 16.6. A skeleton sequence construct containing only some of the many activity elements provided by WS-BPEL.

<sequence>
 
 ...
 
 
 ...
 
 
 ...
 
 
 ...
 
sequence>

Note that sequence elements can be nested, allowing you to define sequences within sequences.

16.1.9. The invoke element

This element identifies the operation of a partner service that the process definition intends to invoke during the course of its execution. The invoke element is equipped with five common attributes, which further specify the details of the invocation (Table 16.1).

Table 16.1. invoke element attributes

Attribute	Description
partnerLink	This element names the partner service via its corresponding partnerLink.
portType	The element used to identify the portType element of the partner service.
operation	The partner service operation to which the process service will need to send its request.
inputVariable	The input message that will be used to communicate with the partner service operation. Note that it is referred to as a variable because it is referencing a WS-BPEL variable element with a messageType attribute.
outputVariable	This element is used when communication is based on the request-response MEP. The return value is stored in a separate variable element.

 

Example 16.7. The invoke element identifying the target partner service details.

<invoke name="ValidateWeeklyHours"
 partnerLink="Employee"
 portType="emp:EmployeeInterface"
 operation="GetWeeklyHoursLimit"
 inputVariable="EmployeeHoursRequest"
 outputVariable="EmployeeHoursResponse"/>

 

16.1.10. The receive element

The receive element allows us to establish the information a process service expects upon receiving a request from an external client partner service. In this case, the process service is viewed as a service provider waiting to be invoked.

The receive element contains a set of attributes, each of which is assigned a value relating to the expected incoming communication (Table 16.2).

Table 16.2. receive element attributes

Attribute	Description
partnerLink	The client partner service identified in the corresponding partnerLink construct.
portType	The process service portType that will be waiting to receive the request message from the partner service.
operation	The process service operation that will be receiving the request.
variable	The process definition variable construct in which the incoming request message will be stored.
createInstance	When this attribute is set to "yes," the receipt of this particular request may be responsible for creating a new instance of the process.

Note that this element also can be used to receive callback messages during an asynchronous message exchange.

Example 16.8. The receive element used in the Timesheet Submission Process definition to indicate the client partner service responsible for launching the process with the submission of a timesheet document.

<receive name="receiveInput"
 partnerLink="client"
 portType="tns:TimesheetSubmissionInterface"
 operation="Submit"
 variable="ClientSubmission"
 createInstance="yes"/>

 

16.1.11. The reply element

Where there's a receive element, there's a reply element when a synchronous exchange is being mapped out. The reply element is responsible for establishing the details of returning a response message to the requesting client partner service. Because this element is associated with the same partnerLink element as its corresponding receive element, it repeats a number of the same attributes (Table 16.3).

Table 16.3. reply element attributes

Attribute	Description
partnerLink	The same partnerLink element established in the receive element.
portType	The same portType element displayed in the receive element.
operation	The same operation element from the receive element.
variable	The process service variable element that holds the message that is returned to the partner service.
messageExchange	It is being proposed that this optional attribute be added by the WS-BPEL 2.0 specification. It allows for the reply element to be explicitly associated with a message activity capable of receiving a message (such as the receive element).

 

Example 16.9. A potential companion reply element to the previously displayed receive element.

<reply partnerLink="client"
 portType="tns:TimesheetSubmissionInterface"
 operation="Submit"
 variable="TimesheetSubmissionResponse"/>

 

16.1.12. The switch, case, and otherwise elements

These three structured activity elements allow us to add conditional logic to our process definition, similar to the familiar select case/case else constructs used in traditional programming languages. The switch element establishes the scope of the conditional logic, wherein multiple case constructs can be nested to check for various conditions using a condition attribute. When a condition attribute resolves to "true," the activities defined within the corresponding case construct are executed.

The otherwise element can be added as a catch all at the end of the switch construct. Should all preceding case conditions fail, the activities within the otherwise construct are executed.

Example 16.10. A skeleton case element wherein the condition attribute uses the getVariableData function to compare the content of the EmployeeResponseMessage variable to a zero value.

<switch>
 <case condition=
 "getVariableData('EmployeeResponseMessage',
 'ResponseParameter')=0">
 ...
 case>
 <otherwise>
 ...
 otherwise>
switch>

Note

It has been proposed that the switch, case, and otherwise elements be replaced with if, elseif, and else elements in WS-BPEL 2.0.

 

16.1.13. The assign, copy, from, and to elements

This set of elements simply gives us the ability to copy values between process variables, which allows us to pass around data throughout a process as information is received and modified during the process execution.

Example 16.11. Within this assign construct, the contents of the TimesheetSubmissionFailedMessage variable are copied to two different message variables.

<assign>
 <copy>
 <from variable="TimesheetSubmissionFailedMessage"/>
 <to variable="EmployeeNotificationMessage"/>
 copy>
 <copy>
 <from variable="TimesheetSubmissionFailedMessage"/>
 <to variable="ManagerNotificationMessage"/>
 copy>
assign>

Note that the copy construct can process a variety of data transfer functions (for example, only a part of a message can be extracted and copied into a variable). from and to elements also can contain optional part and query attributes that allow for specific parts or values of the variable to be referenced.

16.1.14. faultHandlers, catch, and catchAll elements

This construct can contain multiple catch elements, each of which provides activities that perform exception handling for a specific type of error condition. Faults can be generated by the receipt of a WSDL-defined fault message, or they can be explicitly triggered through the use of the throw element. The faultHandlers construct can consist of (or end with) a catchAll element to house default error handling activities.

Example 16.12. The faultHandlers construct hosting catch and catchAll child constructs.

<faultHandlers>
 <catch faultName="SomethingBadHappened"
 faultVariable="TimesheetFault">
 ...
 catch>
 <catchAll>
 ...
 catchAll>
faultHandlers>

 

16.1.15. Other WS-BPEL elements

The following table provides brief descriptions of other relevant parts of the WS-BPEL language.

Table 16.4. Quick reference table providing short descriptions for additional WS-BPEL elements (listed in alphabetical order).

Element	Description
compensationHandler	A WS-BPEL process definition can define a compensation process that kicks in a series of activities when certain conditions occur to justify a compensation. These activities are kept in the compensationHandler construct. (For more information about compensations, see the Business activities section in Chapter 6.)
correlationSets	WS-BPEL uses this element to implement correlation, primarily to associate messages with process instances. A message can belong to multiple correlationSets. Further, message properties can be defined within WSDL documents.
empty	This simple element allows you to state that no activity should occur for a particular condition.
eventHandlers	The eventHandlers element enables a process to respond to events during the execution of process logic. This construct can contain onMessage and onAlarm child elements that trigger process activity upon the arrival of specific types of messages (after a predefined period of time, or at a specific date and time, respectively).
exit	See the terminate element description that follows.
flow	A flow construct allows you to define a series of activities that can occur concurrently and are required to complete after all have finished executing. Dependencies between activities within a flow construct are defined using the child link element.
pick	Similar to the eventHandlers element, this construct also can contain child onMessage and onAlarm elements but is used more to respond to external events for which process execution is suspended.
scope	Portions of logic within a process definition can be sub-divided into scopes using this construct. This allows you to define variables, faultHandlers, correlationSets, compensationHandler, and eventHandlers elements local to the scope.
terminate	This element effectively destroys the process instance. The WS-BPEL 2.0 specification proposes that this element be renamed exit.
throw	WS-BPEL supports numerous fault conditions. Using the tHRow element allows you to explicitly trigger a fault state in response to a specific condition.
wait	The wait element can be set to introduce an intentional delay within the process. Its value can be a set time or a predefined date.
while	This useful element allows you to define a loop. As with the case element, it contains a condition attribute that, as long as it continues resolving to "true," will continue to execute the activities within the while construct.

SUMMARY OF KEY POINTS

• A WS-BPEL process definition is represented at runtime by the process service.
• Services that participate in WS-BPEL defined processes are considered partner services and are established as part of the process definition.
• Numerous activity elements are provided by WS-BPEL to implement various types of process logic.