Specifying a Business Process by Means of BPEL

As mentioned above, the Business Process Execution Language (BPEL) has become the most dominant language for specifying workflows in the area of web services.

Thus, we concentrate on BPEL for specifying workflows in a service-oriented envi-ronment and do not further detail any of the other orchestration and choreography languages. In this subsection we introduce the main concepts of BPEL. Furthermore, we demonstrate how the examples of Section 4.2 are represented in BPEL.

BPEL specifies a business process among web services. To be more precise, it is a flow among web services operations that are provided by one or more business

partners. These operations are defined as part of port types in one or more WSDL files. In order to keep our example simple, we assume that all port types are defined in a single WSDL file shown in lines 001–078. In reality, the port types of different business partners are more likely to be defined in different WSDL files.

In our order management process as depicted in Figure 4.1 five organizations are involved. Accordingly, we define five port types for the following organizations:

buyer (B) in lines 003–012, carrier (C) in lines 013–017, seller sales department (Ss) in lines 018–034, seller accounting department (Sa) in lines 035–043, and seller pro-duction department (Sp) in lines 044–061. Each of the nodes in Figure 4.1 represent an operation. These nodes are already marked with organization (B, C, Ss, Sa, Sp) or the port type, respectively, which provides the operation. Consequently, we assign these operations to the respective port type in the WSDL file. Most of these oper-ations are asynchronous message exchanges. It follows that most of these services only have an input message. The exceptions are the operationscheck against offer andcalculate delivery datewhich are synchronous message exchanges comprising an input and an output message. All the input and output messages refer to mes-sages declared in the same WSDL file. Due to space limitations we have skipped the message definitions and only highlight the need for message declarations in line 002.

031 <wsdl:operation name="readyToShip">

In a BPEL process, partners always interact in a bilateral manner, i.e., one part-ner invokes an operation and the other partpart-ner receives a call of this operation. In order to reflect the bilateral collaborations, the WSDL file is extended by the con-cept of partner link types. Owing to its bilateral nature, a partner link type always includes two roles representing the two collaborating partners. Each role references the port type that has to be provided by the corresponding role. In our order man-agement example, the seller sales department acts as a hub which has bilateral col-laborations with the four other organizations, whereas the other organizations do not

directly interact with each other. Accordingly, the WSDL file includes four partner link types representing the interactions of the sellers sales department (i) with the buyer (B2SsLT) in lines 062–065, (ii) with the carrier (Ss2CLT) in lines 066–069, (iii) with the seller accounting department (Ss2SaLT) in lines 070–073, and (iv) with the seller production department (Ss2SpLT) in lines 074–077.

A BPEL process is built by nested scopes, where the outermost scope is the pro-cess definition itself. It contains partner links that define the relationships to other business partners, declaration of process data, handlers for various purposes and the activities that are orchestrated/choreographed. We distinguish between basic activ-ities and structured activactiv-ities. Basic activactiv-ities are incoming and outgoing operation calls as well as activities for data manipulation. Structured activities cover other activities and define the process logic amongst them.

The most important basic activities are the following:Invokeis used to call an operation.Receiveis an activity that receives an operation call.Replyis used to re-turn the response of an operation which was previously called by areceiveactivity.

Pickwaits for the first event of a set of alternative events to happen and executes the activity associated with this event. Eachpickmust include at least oneonMessage event. TheonMessageevent is semantically equivalent to areceiveactivity. Other basic activities areemptyrendering of a no-operation,waitinterrupting the execu-tion of a process for some time,exit immediately stopping the process, andthrow generating a fault. The following structured activities are considered as the most im-portant ones.Sequencespecifies a sequential execution of activities.Switchprovides a multi-branch decision construct.Whileallows the definition of loops.Flowis in general used for specifying parallel execution. However, conditional control links may be used to define a partial acyclic order of the activities within aflow. Most of these activities will be further illustrated in the example below.

In the lines 079–128 we present the BPEL process of the seller sales department as illustrated in Figure 4.1. This BPEL process imports in line 080 the WSDL file as illustrated in the lines 001–078. The partner links in the lines 081–086 define the bilateral collaborations of the seller sales department with the other organiza-tions. At first sight, one may think that this was already done in the partner link types of the WSDL file. However, the partner link types are defined from a some-what neutral position defining two roles. The BPEL process is always described from the perspective of a specific role—in our case from the perspective of the seller sales department. Consequently, a partner link references a partner link type and defines which role is played by the process owner and which by the rating organization. For example, the partner link in line 082 reflects the collabo-ration between the buyer and the seller sales department (B2Ss). The partnerLink-Type attribute references the corresponding partner link type (B2SsLT) as defined in lines 062–065. The myRole attribute is set toseller, and the partnerRole attribute tobuyer—which correspond to the roles defined in the partner link type in lines 063 and 064.

A business process defined in BPEL describes the exchange of messages by means of operations. These messages, or at least some of them are relevant for the correct execution of the business process. Thus, these messages have to be included

in the business context of the business process. This is realized by variables that serve as data manipulation containers for incoming and outgoing messages. The declaration of variables is highlighted in lines 087–089. However, we omit to show the declaration of all variables that relate to message exchanges. We just demon-strate the declaration by means of the variable for the purchase order in line 088.

079 <bpws:process name="sellersOrderManagement"

portType="ns:B" />

The definition of the control flow of the seller’s order management process is de-fined in a block structure in lines 090–127. Its outermost scope defines a sequence of basic and structured activities. Before going into the details of the process struc-ture, we describe the basic notation toinvoke/receiveservice calls by examples. In line 092 the seller sales department calls the operationcheck against offer from the seller accounting department. This is realized by aninvokeactivity. Its attributes pro-vide the necessary details: Theoperationbeing called ischeck against offerwhich belongs to thepartner linkbetween the seller sales department and its accounting department (Ss2Sa) and is part of theport typeof the seller accounting department (Sa). According to the WSDL file this operation defines a synchronous message exchange (lines 036–039), theinputvariable for the call ispurchase order and the output variable ischeck result. In the case of an asynchronous message call that does not get a return, there will be no output variable—such as the invocation of reserve stock in line 094.

In line 091 the buyer calls the operationorder productfrom the seller sales de-partment. From the seller’s perspective it is areceiveactivity. Again the the attributes provide the details: Theoperationcalled isorder productwhich belongs to the part-ner linkbetween the buyer and the seller sales department (B2Ss) and is part of the port typeof the seller sales department (Sa). The incoming message is stored in the variablepurchaseOrder. A variable in areceiveactivity is always an input, because

areceiveactivity does not output anything. If thereceiveactivity refers to an incom-ing synchronous operation call, the return of the output message must be defined by a followingreplyactivity which uses the same values foroperation,partner linkand port typeas thereceiveactivity, but specifies the output to be sent in the attribute variable. In our example, there is no reply activity at the seller sales department.

The receiveactivity order product in 091 is special in the case that it marks the beginning of a new process instance. Therefore, the Boolean value of the attribute create instanceis set toyes.

The second kind of activity that refers to an incoming operation call is the on message activity. It is always used in conjunction with apickactivity in order to specify that this incoming operation call is one of more alternative events that ap-pear next within apick. The attributes of anon messageactivity are exactly the same as the ones for thereceiveactivity. As an example, line 104 shows theon message activity that receives a call of the get status operationon the seller sales depart-ment (Ss)port typeas part of thepartner linkwith the buyer (B2Ss). The incoming message is captured in thestatus requestvariable.

The block structure in the lines 090–128 describes the orchestration among the incoming and outgoing operation calls of the seller sales department as depicted in the middle lane of Figure 4.1. The outermost scope of this block structure is a se-quence. After the first two activities of this sequence namelyorder product (091) andcheck against offer(092), aflowactivity follows. Theflowactivity (093–096) is used for parallel execution of the activitiesreserve stock(094) andreserve produc-tion line(095). After completion of the two activities within the flow, the sequence continues withcalculate delivery date(097),reserve transport(098),confirm trans-port (099), andresponse to order(100).

Looking at the remaining activities in Figure 4.1, it follows that a block of getting status information is optional, but may be repeated until either a block marking the shipment of the goods or a block for canceling of the order starts. This business fact is represented within awhileloop (101–126), which is the last activity in the overall sequence. The condition of thewhileloop is permanently set totrue in line 102—

it is stopped by anexit either in line 115 or in 122, which terminates the overall process. The only activity within thewhile loop is apickactivity (103–125). The pickactivity reacts on one of three possible incoming calls of operations:get status (104),cancel order(109), orready to ship(118). In case of a call ofget status, the process continues with asequence(105–107) that consists of aninform on status (106) only. Having executed the specified action after picking theget statusevent, thewhileloop restarts again.

If thecancel orderoperation is picked, it results in asequence(110–116) of two activities. The first one is aflow(111–114) for the parallel execution ofdeallocate product line(112) and clear resources (113). The second activity of thesequenceis anexit in line 115 which terminates the whole process. Finally, if aready to ship operation is picked, it results in asequence (119–123) ofnotify shipment (120), transfer to accounting (121) and again in anexit(122) stopping the process.