a case study of workflow reconfiguration: design and ...etd.dtu.dk/thesis/275152/ep11_10.pdf ·...

A Case Study of WorkflowReconfiguration: Design and

Implementation

Mu Zhous080786

Kongens Lyngby 2011IMM–M.Sc.2011-10

Technical University of DenmarkInformatics and Mathematical ModellingBuilding 321, DK-2800 Kongens Lyngby, DenmarkPhone +45 45253351, Fax +45 [email protected]

Summary

Dependable systems are more and more expected to operate in dynamic en-vironments to deal with the new problems and tasks. One way of achievingthe flexibility of the system is to use dynamic reconfiguration. A system canbe implemented as a collection of configurations, where each configuration canbe optimized for each service. Therefore, dynamic reconfiguration can providemaximum flexibility of the system by replacing one configuration by anotherat runtime. Furthermore, it makes the system more dependable because theoverall architecture of the system has not been changed by adding or removingconfigurations. However the problem of interferences between the old and thenew configurations needs to be addressed. The purpose of our research is to de-sign, model, verify and implement a case study involving the reconfiguration ofan office workflow for order processing, based on the requirements on a systemimplementing the workflow and its reconfiguration.

In this thesis, we design a system for an example of an office workflow using theBusiness Process Modeling Notation (BPMN), which is a widely used graphicaltool for designing business processes. Applications that provide specific busi-ness functions are being exposed as Web services. These services are reusablecomponents that can build business processes. In order to facilitate the designof business processes, Business Process Execution Language (BPEL) is used.BPEL is an XML-based workflow language that uses basic and structured ac-tivities to describe the logic of a business process. We present and discuss amapping from BPMN model to BPEL process based on the identification ofpatterns of BPMN fragments which can be directly mapped onto BPEL code.We also use an automatic tool to do the same translation and try to find thedifferences between these two mapping ways. In this work, we investigate also

ii

whether or not the design will meet the reconfiguration requirements and discussthe strengths and weaknesses of BPEL in modeling dynamic reconfiguration. Weinclude with a discussion of an alternative design and motivate why we find thealternative less suitable for this project.

This thesis has been developed in the context of an international research collab-oration on ”Evaluation of Formalisms for Dynamic Reconfiguration of an OfficeWorkflow: Design, Modeling, Analysis and Implementation” among

• Embedded Systems Engineering Section, DTU Informatics, Technical Uni-versity of Denmark (DTU)

• Reconfiguration Interest Group at Newcastle University, Newcastle uponTyne, UK

• CRAC Laboratory at Ecole Polytechnique de Montreal, Montreal, Canada

• Department of Computer Science and System Engineering, Faculty of En-gineering (CPS) , University of Zaragoza.

The joint project focuses on design, modeling, analysis and implementation ofan office workflow case study, in particular, on evaluating several well-knownformalisms for their suitability for reconfigurable dependable systems. Thisthesis has mainly accomplished the design and implementation of the case studyand its reconfiguration.

Preliminary results of the project have been submitted to the 13th InternationalConference on Coordinating Models and Languages (COORDINATION’2011).The submitted paper is included in Appendix A.

Preface

This thesis was prepared at Informatics Mathematical Modelling, the TechnicalUniversity of Denmark in partial fulfillment of the requirements for acquiringthe M.Sc. degree in engineering.

The thesis deals with using Business Process Modeling Notation (BPMN) designsystem and implementing the system in Business Process Execution Language(BPEL). The main focus is present a case study involving interference betweenapplication activities and reconfiguration activities in a office workflow in termsof BPMN design and implement it in BPEL.

This thesis has been developed in the context of an international research collab-oration on ”Evaluation of Formalisms for Dynamic Reconfiguration of an OfficeWorkflow: Design, Modeling, Analysis and Implementation”.

Lyngby, February 2011

Mu Zhou

Structure of this Thesis

The thesis is structured as shown in Figure 1. Chapter 1 introduces basicconcepts of dynamic reconfiguration, workflow, and presents our particular casestudy. The following chapters start from two points of view addressing theproblem: describing the design of a system implementing the workflow in BPMNand implementing the system in BPEL. Chapter 2 explains BPMN in moredetails and includes a BPMN design for our case study. At the implementationside, Chapter 3 introduces some underlying concepts and technologies aboutWeb services, which is a fundamental background supports for understandingthe BPEL language will be introduced in chapter 4 ; all the Chapter 2, 3, 4 arebackground concepts used to reach two implementation approaches in Chapter5 and chapter 6. At the end, an alternative BPMN design and its correspondingBPEL implementation is introduced in chapter 7.

vi

Figure 1: Structure of this thesis

Acknowledgements

I am thankful to everyone who all supported me to complete my thesis effectivelyand on time. I am grateful to my supervisor Nicola Dragoni. He gave mesupport and guided me in different matters regarding the topic. I am deeplygrateful for all the comments provided by Henning Christiansen, KristianGlejboel and Manuel Mazzara. I would also like to thank my family whohelped me a lot in everything. Although they are far away in China, they alwaysencouraged me over the phone.

Contents

Summary i

Preface iii

Structure of this Thesis v

Acknowledgements vii

1 Dynamic Reconfiguration of an Office Workflow 1

1.1 Office Workflow: Requirements . . . . . . . . . . . . . . . . . . . 3

1.2 Office Workflow: Dynamic Reconfiguration . . . . . . . . . . . . 5

2 Business Process Modeling and Notation (BPMN) 11

2.1 What is BPMN? . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 BPMN Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 An Example of a Simple BPMN Model . . . . . . . . . . . . . . . 16

2.4 BPMN Implementation - Case Study . . . . . . . . . . . . . . . . 18

3 Web Services 23

3.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Web Services Definition Language (WSDL) . . . . . . . . . . . . 24

3.3 XML Schema Data Typing . . . . . . . . . . . . . . . . . . . . . 27

3.4 Build a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Business Process Execution Language (BPEL) 29

4.1 Composite Services into Business Processes . . . . . . . . . . . . 30

4.2 BPEL for Business Process . . . . . . . . . . . . . . . . . . . . . 30

4.3 BPEL Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . 32

x CONTENTS

5 Mapping BPMN Models to BPEL 455.1 Basic Activities Translation . . . . . . . . . . . . . . . . . . . . . 465.2 Structured Activities Translation . . . . . . . . . . . . . . . . . . 495.3 Overall Mapping Approach Illustration: an Office Workflow . . . 54

6 Tool-based Mapping BPMN Models to BPEL 736.1 Designing and Implementing Process . . . . . . . . . . . . . . . . 736.2 Comparison Between the two Mapping Ways . . . . . . . . . . . 78

7 Discussion of an Alternative BPMN Design 837.1 New BPMN Design . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2 Discussion Between Two BPMN Designs . . . . . . . . . . . . . . 847.3 BPEL Implementation of the New BPMN . . . . . . . . . . . . . 85

8 Conclusion 91

A Paper Submitted to COORDINATION 2011 93

B Source Codes for the Office Workflow Case Study - generatedby manually mapping 111B.1 WSDLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.2 BEPL Process for the Old Configuration . . . . . . . . . . . . . . 112B.3 BEPL Process for the New Configuration . . . . . . . . . . . . . 112B.4 BEPL Process for the Reconfiguration Transition . . . . . . . . . 113

C Source Codes for the Office Workflow Case Study - generatedby tool-based mapping 115C.1 WSDLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115C.2 WSDL for Partner Links . . . . . . . . . . . . . . . . . . . . . . . 116C.3 BEPL Process for the Old Configuration . . . . . . . . . . . . . . 117C.4 BEPL Process for the New Configuration . . . . . . . . . . . . . 117C.5 BEPL Process for the Reconfiguration Transition . . . . . . . . . 117

D Source Codes for the Office Workflow Case Study (alternativedesign)- generated by tool-based mapping 119D.1 WSDLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119D.2 WSDL for Partner Links . . . . . . . . . . . . . . . . . . . . . . . 120D.3 BEPL Processes for the Old Configuration . . . . . . . . . . . . . 121D.4 BEPL Processes for the New Configuration . . . . . . . . . . . . 121D.5 BEPL Processes for the Reconfiguration Transition . . . . . . . . 121

Chapter 1

Dynamic Reconfiguration ofan Office Workflow

Dependable systems are more and more expected to operate in dynamic en-vironments, to deal with arbitrary changes such as technology changes, theapplication environment changes, the human need changes and so on. In or-der to cope with these new demands, system have to evolve continuously, anda reconfiguration process may be applied to rearrange the components of thesystem. Reconfiguration supports a set of actions such as adding or deletingcomponents, changing links between systems, and modifying component config-uration. If the reconfiguration occurs while the system is running, we can saythe architecture is dynamically reconfigurable [24]. In this way, the system donot have to be taken off-line or rebooted to adapt the changes that applied toa system through reconfiguration.

Traditionally, there are a wide variety of studies based on the software archi-tecture, where the software architecture specifications have been exploited torepresent the configuration and connection of system components [23]. Thereare also many studies focus on runtime dynamic reconfigurations which replacesone configuration by another at runtime. It allows a system to evolve from itscurrent configuration into another at run-time without affecting the system’sexecution. The paper [20] indicates that hardware reconfiguration is an exten-sively researched area (e.g., [10] [16]), but little has been done so far for servicesreconfiguration. Here the service is a well defined interface offer to the clients,

2 Dynamic Reconfiguration of an Office Workflow

through which some entity can be accessed and be asked to perform a task forthe clients. Services are quite dynamic than typical components because theyare located, bound, and executed at runtime over the Internet using some stan-dard protocols. Different configurations can be optimized by different services.Since it is relatively easy to create configurations that provide new services andremove configurations that no longer required the providing services, service re-configuration makes the system more flexible. Dynamic reconfiguration researchutilizing web services has primarily focused on two area, the dynamic exchangeof one service for another in workflow and the dynamic composition of servicesusing semantics [17].

However such systems have to face problems caused by continually develop-ing new web services and modifying or terminating existing web services. Thesechanges directly affect the system dependability. Dependability is an integrativeconcept that encompasses availability, reliability, safety, security and maintain-ability attributes. Dependability of a computing system has been characterizedby [11] as is the ability to deliver service that can justifiable be trusted. Whenwe say a computing system is dependable, it means we place reliance on theservice that the system delivers, which characterized in terms of system’s func-tionality, availability, safety, security and maintainability and so on. In paper[23] is proposed a framework that can automatically reconfigure participatingservices at runtime and certify each service to see whether it satisfies the de-pendability attributes before it can participate in the application.

Although some research performed on service reconfiguration do exist today,there are still more work required on the formal foundation, modeling and ver-ification of dynamic reconfiguration of dependable services. The problem ofinterface between old configuration activities, new configuration activities andreconfiguration activities that occurs due to overlapping modes needs to be ad-dressed. Thus this thesis has been developed in the context of an internationalresearch collaboration on ”Evaluation of Formalisms for Dynamic Reconfigura-tion of an Office Workflow: Design, Modeling, Analysis and Implementation”.The main contributions of this thesis are:

• Describing the system’s design in Business Process Modeling Notation;

• Giving an implementation of the system in Business Process ExecutionLanguage.

1.1 Office Workflow: Requirements 3

1.1 Office Workflow: Requirements

This case study is about a medium-sized organization that handles productorders from existing customers using a series of activities according to the fol-lowing procedure: when an order is received from a customer, a form includingcustomer identity information and inventory identity information is filled out.Then this form is sent to credit check to evaluate customer identity, and thenpass on to inventory check to evaluate product identity. After this evaluation,either the order is rejected and a notification is sent to the user, or it is pro-cessed and passed on to billing and shipping. The billing procedure will causethe customer be billed for the total cost of all ordered items plus their shippingcosts; the shipping procedure will cause the items send to the customer. Afterthat, the order is archived for further reference and a confirmation notificationwill be sent to the customer. The requirements of the case study given by thepaper [9] are listed below. The reason for choosing to use this case study isthat it describes a simple but abundant order processing commonly found in amedium-sized organization.

1. Order Receipt : an order for a product is received from a customer. Theorder includes customer identity and product identity information.

2. Evaluation: the product identity is used to perform an inventory check onthe availability of the product. The customer identity is used to perform acredit check on the customer using an external service. If both the checksare positive, the order is processed; otherwise the order is rejected.

3. Rejection: if the order is rejected, a notification of rejection is sent to thecustomer and the workflow terminates.

4. If the order is processed, the following two activities are performed con-currently:

(a) Billing : the customer is billed for the total cost of the productsordered plus shipping costs.

(b) Shipping : the goods are shipped to the customer.

5. Archiving : the order is archived for future reference.

6. Confirmation: a notification of successful completion of the order is sentto the customer.

This is a wholly automated process, which consists of tasks and information inorder to proceed an order. We use a simple figure to represent this procedure.(See figure 1.1).


Figure 1.1: The Case Study - an Office Workflow

1.2 Office Workflow: Dynamic Reconfiguration 5

As you can see, Figure 1.1 depicts a workflow, which automates a businessprocess during which tasks are communicated among participants accordingto the procedural rules. We can also represent this workflow specific to webservices, where exposing and accessing the functionality of applications as webservices (see Figure 1.2).

1.2 Office Workflow: Dynamic Reconfiguration

Workflow can be subjected to change because of many reasons, such as new de-velopment, administrative decisions (e.g., modification of existing product lines,incorporation of new resources) and so on. These reasons can cause workflowchanges by adding a new task, deleting an existing task, making a modificationto the order of execution of tasks. Here we suppose that the organization de-cides to change its order processing procedure by moving the billing step to takeplace before the shipping step (see Figure 1.3 and Figure 1.4).

This change modifies the workflow definition and is introduced to improve anold workflow process. However the problem of interferences between old con-figuration and new configuration needs to be addressed. The state of an orderin the old configuration may not correspond to any state of the order in thenew configuration. The safe way to do this change is to stop or abort the workon the ongoing process, and ensure that no work case is in progress when thechange is made. It can be done by delaying and not processing any new cus-tomer request until after the change and at same time wait until all acceptedorders are completed before making the change. Then make adjustments to theworkflow and initiate work again. However it is unpractical to delay or abortlarge numbers of orders because the workflow is being reconfigured. We have toallow overlapping modes for the workflow during its reconfiguration, that is tosay that keeping both the old procedure and the new procedure simultaneouslyavailable. It must be ensured that the following requirements are met duringthe transition interval from one procedure to the other [9]:

1. The result of the Evaluation activity for any given order should not beaffected by the change in procedure.

2. All accepted orders must be billed and shipped, then archived.

3. All orders accepted after the change in procedure must be processed accord-ing to the new procedure.


Figure 1.2: The Case Study - a Service-based Office Workflow


Figure 1.3: The Case Study - a New Office Workflow


Figure 1.4: The Case Study - a New Service-based Office Workflow


In Chapter 2 below we will introduce some basic concepts background on Busi-ness Process Modeling Notation (BPMN) and then present a system design ofthis office workflow case study using BPMN. In order to understand the im-plementation of the system part, we will give a general introduction to thebackground of web services in Chapter 3 and explain how to establish a busi-ness process using Business Process Execution Language (BPEL) in Chapter 4.In the following Chapter 5 we present a BPEL implementation based on theBPMN design model by using theories of mapping BPMN to BPEL. A tool-based transition will also be provided in Chapter 6. Finally we provide thereader with an alternative BPMN design model for this case study and its cor-responding BPEL implementation. The main goal of this thesis is to model andimplement this office workflow case study, including the old configuration, thenew configuration and the reconfiguration process between two configurations.From this case study, we have found that although BPEL itself has not beendesigned to cope with dynamic reconfiguration, it presents some features whichcan be used to this purpose.

Chapter 2

Business Process Modelingand Notation (BPMN)

This chapter intends to provide a high-level overview and introduction to Busi-ness Process Modeling and Notation (BPMN). A small set of notation cate-gories has been described here so that the reader of a BPMN diagram can easilyrecognize the basic types of elements and understand the diagram. We alsopresent a design of the workflow case study using BPMN. The choice of usingBPMN as a design tool is motivated by its wide adoption as a standard nota-tion for designing and managing business processes. We choose to use YaoqiangBPMN Editor 2.0 [3] to draw all the figures in this chapter.

2.1 What is BPMN?

A standard Business Process Model and Notation (BPMN) has been devel-oped by the Object Management Group (OMG) [2]. It aims to provide agraphical representation for specifying business processes that is readable andunderstandable by business users. BPMN also provides a mapping to the exe-cution language of BPM Systems (WS-BPEL) that will execute these BusinessProcesses. Business Process Management (BPM) [21] focuses on improvinghow things are done for the benefit of shareholders, stakeholders and produce

12 Business Process Modeling and Notation (BPMN)

greatest profits. It requires understanding business processes in order to improvethem. The current Wikipedia gives a definition to a Business Process, ”is acollection of related, structured activities or tasks that produce a specific serviceor product for a particular customer or customers.” So for some companies, ifthey kick off to address a new challenge, they will start building business pro-cess model to illustrate a flow of works and related activities. When it comes tomodeling a multifaceted world of work, business process model needs a certaindegree of rigors - graphic notations such as box and arrow have to stand forsomething. That is what the BPMN is about - a modeling notation specifi-cation representing business processes for descriptive purposes at a high-level.Once the business analysts create the initial draft of a process, the technicaldevelopers will implement the technology to perform this process; and at theend the business users can manage and monitor the process [21]. So we can saythat BPMN creates a bridge for the gap between Business Processes designand business processes implementation as well.

2.2 BPMN Basics

BPMN defines a Business Process Diagram (BPD) , which is a flowchart madeup of a set of specialized graphical elements to depict a process [21]. The basiccategories of elements of BPD are Flow Objects, Data, Connecting Objects,Swimlanes and Artifacts.

Flow Objects They are main graphical elements used to define the BusinessProcess, which including three types of Flow Objects:

• Activities represent the work performed within a Business Process.They are depicted as round-cornered rectangles as shown in Figures 2.1and 2.2. An activity can be either a Task (atomic type) (see Figure 2.1)or an Embedded Sub-process (compound type), which has a ”plus sign” inthe lower center of the shape (see Figure 2.2). There are seven task types:service, receive, send, user, script, manual and reference. If a task is noneof the above types, it is referred to as a blank task.

• Events may signal the start of a process (start event), the end of a process(end event), the arrival of a message (intermediate message event) or thearrival of a due time during a process (intermediate timer event) (seeFigure 2.3).

2.2 BPMN Basics 13

Figure 2.1: A Task

Figure 2.2: A Sub-Process

Figure 2.3: Event Types

• A Gateway represents a decision point. It may determine branching,forking, merging and joining of paths. It has a diamond shape with anindication of its type as shown in Figure 2.4.

Figure 2.4: Gateway Types

– An Exclusive gateway restricts the flow so that one and only onepath can be taken. There are four kinds of exclusive gateways: adata based exclusive gateway refers to a branching point based ona conditional expression, whereas an event based exclusive gateway


refers to a branching point based on an event. A merge gatewayjoins a set of mutually exclusive alternative sequence flows into onesequence flow.

– An Inclusive gateway represents a branching point where more thanone paths can be taken.

– A Complex gateway is used for handling complex conditions and sit-uations; we do not go into details with this.

– A Parallel gateway is used to indicate parallel paths. There are twokinds of Parallel gateway : parallel fork gateway and parallel joingateway. We can either create concurrent sequence flows using aparallel fork gateway or synchronize concurrent sequence flows usinga parallel join gateway.

Data It can be represented as these four elements: Data Object, Data Input,Data Output and Data Stores. A Data Object provides information about whatactivities are required to be performed and what they produce. Data Inputand Data Output provide information about what processes are required to beperformed and what they produce.

Flow There are four ways of connecting objects:

• Sequence Flow represents the chronological sequence of process steps. Thepreceding steps pass control to the following steps along the connections.Each flow has only one source and only one target.

Figure 2.5: A Sequence Flow

A Sequence Flow can optionally define a condition expression, indicatingthat the control will be passed down only if the expression is evaluated betrue. The source of Sequence Flow can be either Gateway or Activity.

– Conditional Sequence Flow from an Activity must be drawn with adiamond marker at the beginning of the connector (see Figure 2.6).If this type is used from a source Activity, there must be at least oneoutgoing Sequence Flow from the same Activity.

– Conditional Sequence Flow from a Gateway must be drawn withouta diamond marker at the beginning of the connector (see Figure 2.5).The source Gateway must not be of type Parallel or Event.

2.2 BPMN Basics 15

Figure 2.6: A Conditional Sequence Flow

– Default Sequence Flow is taken only if all the other outgoing SequenceFlows from Activity or Gateway (Exclusive, Inclusive or ComplexGateway) are not valid (see Figure 2.7).

Figure 2.7: A Default Sequence Flow

• Message Flow is used to show the flow of Messages between two Par-ticipants, where Participants are represented as two separate Pools (seeFigure 2.8).

Figure 2.8: Message Flow

• Association used to link information such as data object with BPMNgraphical elements using a dotted single line.

• Data Association used to show input and output of Data Object to Activ-ity, which uses the same notation for Association.

Swimlanes A swimlane is used to organize activities into separate visual cat-egories so as to illustrate different functional responsibilities. It can be usedto show how different entities interact. There are two ways of grouping theelements through Swimlanes:

• A Lane is a sub-partition within a process. Activities in the process canbe organized and categorized by using Lanes. They are often used forinternal roles (e.g., Manager), an internal department (e.g., shipping). Itis a square-corner rectangle that be drawn with a solid single line (seeFigure 2.9).

• A Pool represents a Participant in a Collaboration. It can be a partnerentity (e.g., a company) or partner role (e.g., a seller, or a customer). It


Figure 2.9: Lanes

is drawn with a solid single line to a square-cornered rectangle (see Figure2.10).

Figure 2.10: Pool

Artifact Artifact is used to provide additional information of a BusinessProcesses to the reader, we do not go into details with this. More informationrefers to Business Process Model and Notation document [21].

2.3 An Example of a Simple BPMN Model

Now we are taking an easily understood scenario, and build a BPMN modelbased on the graphical specifications introduced in section 2.2. The scenario isabout a hotel booking process: a hotel agent receives a hotel room reservationrequest from a customer; then the agent checks whether a hotel room is availableor not; finally based on the checking result, either reject the reservation requestif the room is unavailable or confirm the request if the room is available (seeFigure 2.11).

2.3 An Example of a Simple BPMN Model 17

Figure 2.11: The Hotel Reservation Scenario - BPMN

The process begins with a Start Message Event, which is used to receive requestmessage from a customer, and then it goes to a Task for checking the availabilityof a hotel room; finally follows a Exclusive Gateway, the process branches toeither ”Confirm Reservation” or ”Reject Reservation” (both are Task activities).Both branches lead to the same End Event at the end.


2.4 BPMN Implementation - Case Study

In this section, we will start to present a design of the office workflow case studyintroduced in Chapter 1.1 by using all the notations and concepts of BPMNthat we have learnt so far.

This office workflow can be seen as several Participants working together toprocess orders from customers (see figure 2.12). It employs several Pools torepresent different functional entities (Order Generator; Credit Check; InventoryCheck, Bill&Ship, Archive). It is worth noting that the imposed requirementsstate that only the Credit Check service is supposed to be external. Thus eachother service might be included in a lane of a single pool, representing a activitywithin the organization. Here we decided to design a more generic situationwhere the different services are offered by external entities by adopting a pool foreach service. Each Participant has their own process, by using Message Flow tocommunicate with each other. Assume that all the processes are asynchronous,the processes will not stop and wait for any participate’s reply. All the processesstart by a Start Message Event, in other words, the Processes are triggered byreceiving a message.

Office Workflow pool is the coordinating entity, starts by receiving a requestmessage from a customer. Then an order is created by calling the Order Genera-tor entity. The process happens within Order Generator pool starts by receivingthe order request message through Message Flow from Office Workflow ; thenexecutes ”Make Order” Task ; finally sends an order back to Office Workflowpool. Once Message Intermediate Event within Office Workflow pool receivesthe order, this order is then sent to both the credit check handler (Credit Checkpool) to check the customer credit’s availability and the inventory check handler(Inventory Check pool) to verify the availability of the product. The latter isperformed only in case the credit check is successful. Same as process happensin Credit Check pool : gets an order from Office Workflow pool ; then executesthe evaluation Task to check the customer credit’s availability; finally uses SendTask to send an evaluation result to Office Workflow pool. After receiving theevaluation result, an Exclusive Data-Based Gateway has been used. In case ofa negative reply from Credit Check pool, a notification is sent to the customer,the order is rejected and the overall workflow terminates. Otherwise the orderis sent to Inventory Check pool. We do the same with the result from InventoryCheck by means of an Exclusive Data-Based Gateway. In case of a negativereply, we notify the customer and reject the order. In case of a positive reply,the order is processed. The Bill&Ship pool represents the entity responsiblefor both the billing and shipping activities by using two lanes (Bill and Ship)in a pool. For the sake of simplicity and readability of the overall workflow,we assume that neither the billing activity nor the shipping activity provides a

2.4 BPMN Implementation - Case Study 19

negative result. When Bill&Ship pool receives the order, the two activities arecalled concurrently by a Parallel Gateway. The same gateway is used to mergethe result from Bill lane and Ship lane. A message containing the bill and shipdetails is sent to Office Workflow pool to calls the Archive pool for storing theorder. Office Workflow process terminates by receiving a response from Archivepool and sending a confirmation notification to the customer.

Now the company decides to do the reconfiguration of the order of billing andshipping activities: moving the billing activity to take place before the shippingactivity and keeping both the old configuration process and new configurationprocess simultaneously available. So our concern is to make structural changessafely without flushing the system. Look at the design we have presented sofar, it should be quite easy to realize that this reconfiguration require a changein the main lane of Bill&Ship only, where the billing and shipping activities arecalled, while the rest of the workflow remains the same. The new configurationBPMN diagram is shown in Figure 2.13. Comparing to the old configurationBPMN diagram in Figure 2.12, the two Parallel Gateways in the main lane ofBill&Ship have been removed and the two activities are called synchronouslynow.

How can the transition from the old configuration (Figure 2.12) to the newconfiguration (Figure 2.13) be done? The BPMN model for the overall workflowduring its reconfiguration transformation is shown in Figure 2.14. In orderto keep both the old configuration process and the new configuration processsimultaneously available, we define a default flow that is identical to the oldconfiguration. This default flow can be altered through an interrupting MessageEvent contained in ”Determine configuration” activity included in a separateReconfig.region pool. This activity determines which configuration should beused when Bill&Ship is called. In this way, we highlight that an authority is incharge of deciding the reconfiguration. Thus, if the interrupt event happens, itwill affect the flow activating the new configuration instead of the old one.


Figure 2.12: The Case Study Workflow - Old Configuration BPMN Model

2.4 BPMN Implementation - Case Study 21

Figure 2.13: The Case Study Workflow - New Configuration BPMN Model


Figure 2.14: The Case Study Workflow - Configuration Transition BPMN Model

Chapter 3

Web Services

This chapter is not intended to as a complete introduction to Web Servicetechnologies but as an overview of what Web Service is; what WSDL is; howa WSDL document is formed and how to create a web service from its WSDLdocument. The motivation of introducing Web Service technologies here is tohelp the readers to understand Business Process Execution Language (BPEL)in the next Chapter 4.

3.1 Web Services

Web Service [13] is any service available and discoverable over the Internet,which is self-describing using a common XML grammar. It uses a XML mes-saging system (XML-RPC, SOAP or HTTP POST/GET) and has universalinteroperability between applications running on disparate platforms that usingdifferent operating systems and programming languages.

There are three major roles within the Web Service architecture: service providerwhich implements the service and makes it available on the Internet; service re-questor which is a consumer of the web service; service registry which is acentralized registry of services. When developers build a web service, normallythey use XML to expose resources on the platform regardless which operation

24 Web Services

systems or programming languages they are using. XML messaging is respon-sible for encoding messages in a XML format, there are two common XMLmessaging systems: XML-RPC (XML Remote Procedure Call) [13] and SOAP(Simple Object Access Protocol) [13], which enables web services to exchangecomplex information using a standardized XML messaging format. Consumersare able to access the resources by simply transmitting XML messages over pro-tocols like Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol(SMTP) and so on. Developers should publish a public interface to a service,which is a human-readable documentation so that other developers can inte-grate the service. WSDL (Web Services Description Language) [4] is been usedto specify such a public interface for web service. There may also be a mech-anism for developers to publish a web service or find other services and locatetheir public interfaces. Currently such a kind of service discovery is handledvia UDDI (Universal Description Discovery and Integration) [8]. Operation inweb services are based on exchange XML-formatted collections of input, outputand fault messages. There are four types of operation: one-way, request andresponse, solicit response, notification. Web services can provide support forboth asynchronous and synchronous interactions.

3.2 Web Services Definition Language (WSDL)

The Web Service Definition Language (WSDL) is a specification of using XMLgrammar to describe web services. Web services self-describe their interactionpoints and the associated data requirements as service interfaces in a WSDLdocument [17]. This allows the developers to build and consume services inan interoperable way. WSDL can be treated as a contract between the servicerequestor and the service provider. A complete WSDL definition contains allthe information necessary to invoke a web service, which can be broken downinto 6 main elements: definitions, types, message, portType, binding and service(see Table 3.1).

WSDL Definition specifies the name of WSDL document and numerousnamespaces that will be used throughout the document. The use of names-paces enables the document to reference multiple external specifications, forinstance WSDL specification, XML Schema specification. It also specifies a tar-getNamespace attribute, which enables WSDL document to refer to itself. Thebasic structure is as follows:

3.2 Web Services Definition Language (WSDL) 25

Element Name DescriptionDefinitions The root element of WSDL documents. It defines

the name of web service, namespaces andall the service elements.

Type Describes abstract data types used for all messagerequests and message responses; defined by XML Schema.

Message Describes abstract messages that are used fromoperations within service; may consists of multiple parts.

portType Describes interface information: the abstract operationsthat are available within service.

Binding Describes a concrete transport protocol is used fora particular portType.

Service Describes a concrete connection details for locatinga specified service.

Table 3.1: WSDL Definition

<definition name=""

targetNamespace=""

xmlns=""

xmlns:xsd=""

...>

WSDL Type allows different data types used by operations in a service. Thebasic structure of type element is as follows:

<defintions ..>

<types>

<xsd:schema targetNamespace=""/>

</types>

</definitions>

WSDL Messages can be used from operations within the service. Eachdefined message describes the names and types of its parameters. Messagesconsist of one or more part elements, where each part is associated with eitheran element or a type. The basic structure is as follows:

<defintions..>

<message name="">

<part name="" element=""/>

</message>

</definitions>

26 Web Services

WSDL port Types defines a group of operations that are available fromservice. For each operation, we describe the name of operation, and the namesand types of parameters used by operation. The basic structure is as follows:

<definitions ..>

<portType name="">

<operation name="">

<input name="" message=""/>

<output name="" message=""/>

</operation>

</portType>

</definitions>

There are four different types of operations to be defined in Table 3.2:

Operation Type DescriptionOne-Way The service endpoint receives a message.

The operation has a single input element.Request/Response The service endpoint receives a message

and sends a response.The operation has one input element followed byone output element;an fault element can also be specified.

Notification The service sends a message to a client.The operation has a single output element.

Solicit/Response The service sends a message and receives a responsefrom the client.The operation has one output element followed byone input element;an fault element can also be specified.

Table 3.2: Operation Types

WSDL Binding The binding element describes protocol given to operations.It provides specific details on how such an operation will be transported overthe Internet. Binding can be made available via multiple transports, such asHTTP GET, HTTP POST or SOAP. The basic structure is as follows:

<definitions..>

<binding name="" type="">

<soap: binding style="" transport=""/>

<wsdl:operation name="">

3.3 XML Schema Data Typing 27

<soap:operation/>

<wsdl:input name="">

<soap:body use=""/>

</wsdl:input>

<wsdl:output name="">

<soap:body use="">

</wsdl:output>

</wsdl:operation>

</binding>

</definitions>

WSDL Service defines a collection of endpoint ports that expose binding, inother word, service element specifies the location of service. The basic structureis as follows:

<definitions..>

<service ..>

<port name="" binding="">

<soap:address location=""/>

</port>

</service>

</defition>

3.3 XML Schema Data Typing

Given a WSDL document, we can manually create a SOAP client to invoke theservice or automatically invoke the service via a WSDL invocation tool. In orderfor a client to communicate effectively with a server, both of them must agreeon a data type format that they are using. WSDL uses W3C XML Schemaspecification [5] as a default, which is also the most widely used specificationfor data type currently. It includes a list of build-in simple types, includingstring, integers, doubles, time and so on. The XML Schema specification alsoprovides a facility for creating new data types. When the service you build goesbeyond simple XML Schema data types, you can create new data types; anddeclare these new data types within WSDL type element.

28 Web Services

3.4 Build a Web Service

There are two ways to create a web service, either starting from Java code orfrom a WSDL document. If you are developing your Java web service you wishto expose it as a web service, the most direct approach is to create policy asser-tions needed to enable emphWSIT technologies [7]. If you want to implementa web service that is already defined by WSDL document, the JAX-WS wsiom-port tool will process this WSDL document. Comparing to the process startingfrom Java, this process is much simpler. Many tools provide the functionalityof building web services from WSDL documents and then deploy and test, suchas NetBeans, Axis and Oracle.

Chapter 4

Business Process ExecutionLanguage (BPEL)

As the development and the use of web service technologies become more andmore popular and mature, many companies reply on such technologies to per-form business processes. In the real world, companies have to keep improvingand modifying their Business Processes based on customer’s requirements.These changes and improvements are reflected in the services that support busi-ness processes. So as to stay competitive on the global market, companies needbusiness processes to be dynamic, that is services can be efficiently adaptedto the change of business processes. Thus a specialized language is required tocomposite the exposed services into business processes. Business Process Execu-tion Language for Web Services (BPEL, or WS-BPEL, BPEL4WS [6]) is sucha kind of language used for composition, orchestration and coordination of webservices. It provides a vocabulary for expressing business processes behaviors,where business processes can be developed in an easy and efficient manner, andquickly adapted to the needs of companies without too much efforts.

30 Business Process Execution Language (BPEL)

4.1 Composite Services into Business Processes

In business processes, services have been defined as business functionalities thatcan provide business values, such as a service for a business booking production.Composition of services provides the support to business processes by following aset of rules. Business processes are defined as a collection of coordinated serviceinvocations and related activities that produce a business result, either withina single organization or across several [19]. For example, a business processfor processing orders from the customers in an organization, it needs invokeserval web services in order to process the order request successfully. From theperspective of business processes, we do not care about the implementation ofeach web service; we do not care whether the process is implemented throughcomposition of other services or not neither. We see the process the same as theother services.

4.2 BPEL for Business Process

BPEL is an XML-based execution environment intended to make a businessprocess definition to a document-centric business process [6]. The core of BPELis BPEL process. When we define a BPEL process, we actually define a newweb service that is a composition of some existing web services. The interfaceof the new BPEL composite web service uses a set of port types, through whichprovide operations. Steps executing in a BPEL process are called activities, andthe BPEL process definition should consist of at least one activity. BPEL caneasily invoke web services’ operations either synchronously or asynchronously;either in sequence or in parallel. The typical scenario of a BPEL business processis: receives a request; then invokes involved web services and finally responds tothe client. Deploying a BPEL process results in a service for that process beingpublished.

Let’s take an example - a simple business process for booking a hotel room. Inan oversimplified scenario: the client invokes the business process, specifyingthe name of the customer, the date to check-in and the room requests. TheBPEL business process invokes a external web service to check the hotel roomstatus and price. Finally, the BPEL process will send a reply to the client. Thestructure of services composed into the business process can represent visuallyusing a BEPL diagram (See Figure 4.1).

The BPEL diagram is the design view of a BPEL process, on the diagram wecan author the business process by adding and configuring activities by hand.

4.2 BPEL for Business Process 31

Figure 4.1: The Hotel Reservation Scenario - BPEL Diagram


The diagram contains some common irons representing different activities of thebusiness process (See Figure 4.2).

Figure 4.2: BPEL Diagram Irons

4.3 BPEL Core Concepts

4.3.1 Invoking Web Service

Before we start writing the BPEL process definition, we have to get familiarwith all web services invoked from our business process, these services calledpartner web services. In our example, only one web service is involved: theHotel web service. The description of this web service is available through itsWSDL, which specifies the operations and port types that the web service offer;the messages it accepts and the types it defines.

• Hotel Web Service: It provides a HotelPortType which is used to check theavailability of a hotel room using the bookHotel operation. This operation

4.3 BPEL Core Concepts 33

will return the room status: available or unavailable; and also the roomprice. The architecture of this web service is schematically shown in Figure4.3.

Figure 4.3: The Hotel Web Service Architecture

• Web service for the BPEL process: The business hotel reservation BPELprocess is exposed as a web service as well. We also need to define a WSDLfor it. The process receives a message from the client and return a result.So it has to expose a port type that will be used by the client to startthe process and get the reply. We define the BookPortType with the bookoperation. The architecture is shown in Figure 4.4.

4.3.2 Partner Link Types

Before we start writing the BPEL process, we need to define partner link types,which represent the interaction between a BPEL process and the involved ex-ternal parties. The web services invoked by the BPEL process and the clientinvokes the BPEL process are associated with partner links. In our example,we have two partners: the client and the hotel service. Each web service shoulddefine the corresponding partner link types in their WSDL [6].

• BookLT :This is used to describe the interaction between the BPEL processclient and the BPEL process itself. This interaction is synchronous. Thepartner link type is defined in the BPEL process WSDL.


Figure 4.4: The Client Web Service Architecture

• HotelLT :This is used to describe the interaction between the BPEL pro-cess and the Hotel web service. This interaction is also synchronous. Thepartner link type is defined in the hotel web service WSDL.

Each partner link type can have one or two roles, which are myRole indicatesthe role of a BPEL process itself and partnerRole indicates the role of partners[19]. For each role we must specify a portType that identifies the interface forcommunicating over the partnerlink. For our example, both the bookOperationand the bookHotelOperation are synchronous, so there is a single role for bothpartner link types. The client invokes the book operation on the BPEL processand waits to get a response only after the operation completes. If this operationis an asynchronous callback operation, we have to specify two roles: one roledescribes the invocation of the book operation by the client; the other roledescribes the invocation of a callback operation. This callback operation wouldbe invoked by BPEL process and would call the client to return the result.

The client uses the BookPortType port type to communicate with the BPELprocess. The interaction is synchronous, so we use a single role called bookSer-viceProvider.

...

<plnk:partnerLinkType name="BookLT">

<plnk:role name="BookServiceProvider" portType="tns:BookPortType"/>

</plnk:partnerLinkType>

...


4.3.3 Business Process Definition

A BPEL business process definition specifies the order of activities that have tobe performed [19]. Firstly it waits for an incoming message to start the businessprocess; then waits for a series of activities occur, either in sequence or inparallel. In our example: the client initiates the BPEL process through sendingan input message: bookRequest. Then BPEL process invokes the Hotel webservice by sending the bookHotelRequst message. Because this is a synchronousinvocation, the process will wait for the bookHotelResponse message. Finallythe BPEL process returns the reply message bookResponse to the initial client.

A BPEL definition contains at least four parts: the initial process root element;the partner links definition; the variables declaration and the main body wherethe business process is defined.

BPEL Process The basic structure of a BPEL process definition is:

<process name="HotelBookProcess" ...>

<partnerLinks>

...

</partnerLinks>

<variables>

...

</variables>

<sequence>

...

</sequence>

</process>

Partner Link Partner link has been defined to link web services and the client[19]. Each BPEL business process has at lease one client partner link, that is theclient first invokes the BPEL process. Parter link type declares how two partiesinteract and what each party offers. partnerLink definitions are nested withinthe partnerLinks element. In our example, the client partner link is BookClient :

...

<partnerLinks>

<partnerLink name="BookClient"

partnerLinkType="tns:BookLT"

myRole="BookServiceProvider"/>

...


The other partner link is called Hotel and characterized by the HotelLT partnerlink type. It is a synchronous interaction, so again we specify only one role.Because the Hotel web service is a partner interacts to the BPEL process, wedescribe the role as a partnerRole here:

...

<partnerLink name="Hotel"

partnerLinkType="tns:HotelLT"

partnerRole="HotelServiceProvider"/>

</partnerLinks>

Variables Variables are used to store messages [19]. Usually we use a variablefor every message send to the partners and receive from the partners. In our ex-ample, we define four variables: BookIn, BookOut, BookHotelIn, BookHotelOut.For each variable we have to specify the type. We use an XML schema elementhere.

...

<variables>

<variable name="BookIn" messageType="tns:bookRequest"/>

<variable name="BookOut" messageType="tns:bookResponse"/>

<variable name="BookHotelIn" messageType="tns:bookHotelRequest"/>

<variable name="BookHotelOut" messageType="tns:bookHotelResponse"/>

</variables>

...

BPEL Process Main Body Within process tag, a BPEL process will havea top-level sequence element that allows us to define several activities that willbe performed sequentially. To invoke the web services in parallel, we can useflow construct. Within the sequence, the process will wait for the first incomingmessage to start the business process, which is modeled within receive construct.In our example, the first incoming message is BookRequest message. Within thereceive construct, we specify the partner link, the port type, the operation nameand the variable (BookIn) that holds the received message.

...

<sequence>

<receive name="ReceiveBookRequest"

createInstance="yes"

partnerLink="BookClient"

operation="book"

portType="ns0:BookPortType"

variable="BookIn"/>

...

Each receive in a BPEL process corresponds to a service operation will be pub-lished when the process is deployed. The top receive activity ReceiveBookRequest


acts as the starting point for a new process execution. So when the customerinvokes the order operation, it will cause a new process execution to start byleaving the initial receive activity.

Next we need to invoke the Hotel web service. Before this, we have to preparethe input for this web service. We can construct a bookHotelRequest message bycopying in part of the message sent by the client. We write the correspondingassignment like:

...

<assign name="Assign1">

<copy>

<from variable="BookIn" part="CustomerName"/>

<to variable="BookHotelIn" part="CustomerName"/>

</copy>

</assign>

...

Now we can invoke the Hotel web service. We make a synchronous invocation byusing invoke activity. We have prepared the input message in the BookHotelInvariable, now we have to store an output message in BookHotelOut variable:

...

<invoke name="InvokeHotel"

partnerLink="Hotel"

operation="bookHotel"

portType="ns1:HotelPortType"

inputVariable="BookHotelIn"

outputVariable="BookHotelOut"/>

...

Then we can copy the BookHotelOut variable to the BookOut variable, whichstores the message will finally return to the client.

...


<copy>

<from variable="BookHotelOut" part="Status"/>

<to variable="BookOut" part="Status"/>

</copy>

</assign>

...

We have come to the final step of the BPEL business process - to return a replyto the client using rely activity. We specify the same partner link, the same porttype and operation name as in the initial receive client. The variable that holdsthe reply message is BookOut :

...

<reply name="ReplyClient"


operation="book"

portType="ns0:BookPortType"

variable="BookOut"/>

</sequence>

</process>

4.3.4 Advanced BPEL Features

In this subsection, we will look at some advanced BPEL features which will beused in Chapter 5.

Loop Sometimes we want to perform an activity or a set of activities in a loop,for instance to invoke a partner web service operation several times. BPEL useswhile activity to support the loop. It repeats the enclosed activities until thedefined Boolean condition no longer holds true. Let us consider a scenario thatif we want to check the availability of a hotel room for a travel group (one thanone person), we need to invoke the hotel web service operation for each person.Two more variables have to be used: one is hold the number of the client; theother one is a counter using in a loop. Then we initialize both variables withstatic values. The code excerpt is shown below:

...

<variables>

<variable name="NoOfClients" type="xsd:int"/>

<variable name="Counter" type="xsd:int"/>

...

</variables>

<assign>

<copy>

<from expression="number(10)"/>

<to variable="NoOfClients"/>

</copy>

<copy>

<from expression="number(0)"/>

<to variable="Counter"/>

</copy>

</assign>

<while name="While1">

<condition>$Counter > NoOfClients</condition>

<sequence>




partnerLink="Hotel"

portType="ns1:HotelPortType"



...



...



<assign>

<copy>

<from $Counter+ 1/>


</copy>

</assign>

</sequence>

</while>

Scope In order to divide a complex business process into hierarchically or-ganized parts, scope has been introduced. Scope provides a way to declarevariables that are only visible within the scope and allows to define the localfault handlers, the compensation handlers and the event handlers [19]. Eachscope has a primary activity, which can be a basic activity invoke or it can bea structured activity using sequence or flow tag. The code excerpt below showshow scopes are defined in BPEL.

<scope>

<variables>



</variables>

<faultHandlers>



</faultHandlers>

<compensationHandler>



</compensationHandler>

<eventHandlers>



</eventHandlers>

<!--Activies>

<invoke>

...

</invoke>

...

</scope>

Pick In most business process, there are two types of events: message events- are triggered by incoming messages through operation invocation on a porttype; alarm events - are triggered by a specified time. Pick activity in BPELspecifies that the business process waits the occurrence of events [19]. Those

events can be either message events or alarm events. For each event we need tospecify at least one activity that should be performed when such event occurs.The syntax is shown below:

<pick>

<onMessage...>

<!--Perform activity>

<\onMessage>

..

<onAlarm...>

<!--Perform activity>

<\onAlarm>

<\pick>

The onMessge element is identical to the receive activity and has the sameattributes.

Event Handlers While a business process executes, we still want to reacton some events and handle them whenever they occur, we can use the eventhandlers. If the corresponding event happens, event handler is invoked concur-rently with the running business process. Event handlers can also be used foreach scope. It starts when the associated scope starts.

Fault handlers BPEL business processes need to handle faults caused by theunreliable communication between web services; logic errors; execution errorsarising from the defects in the infrastructure of web services, etc. So faulthandler has been used. BPEL business processes can signal faults themselvesusing throw activity. The syntax is shown below:

<throw faultName="name"/>

Within a fault handler, the business process defines customer activities that areused to recover from the fault and recover the unsuccessful work of the activitywhere the fault has happened [19]. catch activities specify the faults that wewould like to catch and handle. catchAll activities can be used to handle allother faults.

Termination Handlers BPEL provides a termination handler activity toprovide code to be executed when a BPEL process is unexpectedly exited. Itmust be applied to scope within a process. The syntax is shown below:

<scope>

<terminationHandler>



</terminationHandler>



</scope>

Correlation When the client starts a business process, a new process instanceis created and lives for the lifetime of the business process. If there are mul-tiple business process instances active at the same time, we have to make surethat all messages that are send to the business process are delivered to thecorrect business process instance. So the relationship between a message andits corresponding process instance needs to be maintained. BPEL provides amechanism to use specific business data such as order ID, flight number, etc tomaintain reference to specific business process instances called correlation [19].Such business data used for correlation is contained in the message exchangedbetween partners. A correlation set is a collection of one or more propertiesshared by messages, which is used to determine whether a message correlateswith a process instance. Each correlation set has a name and a message canbe related to a set of correlation sets. The initial message is used to initializethe value of a correlation set; the following messages related to this correlationset must have the same property values as the initial correlation set [19]. Thesyntax is shown as:

<correlationSets>

<correlationSet name=" " properties=" "/>

</correlationSets>

Going back to our Hotel Reservation example, we can define a correlation setnamed BookingOrder with a single property, BookingNO :

<process ... >

<partnerLinks>...</partnerLinks>

<variables>...</variables>

<correlationSets>

<correlationSet name="BookingOrder" properties="tns:BookingNo"/>

</correlationSets>

...

Correlation sets can be used in invoke, receive, reply and pick activities. Weuse the correlation activity to specify which correlation set is used. The syntaxis:


<correlations>

<correlation set="name"

initiate="yes|join|no"?

pattern="request|response|request-response"? />

</correlations>

The attribute ”set” indicates the correlation set used for correlation; ”initiate”attribute has three values: ”yes” means the related activity initiates the corre-lation set; ”join” means the related activity try to initiate the correlate set if itis not initiated; ”no” means the related activity not initiate the correlation set.

4.3.5 Hotel Reservation Example - BPEL code

The whole BPEL code of Hotel Reservation Process is showing here, whichincludes also loop activity introduced before.

<?xml version="1.0" encoding="UTF-8"?>

<process

name="BookHotel"

targetNamespace="http://enterprise.org/bpel/HotelReservation/BookHotel"

....

<import .../>

<partnerLinks>

<partnerLink name="Hotel"

partnerLinkType="tns:HotelLT"

partnerRole="HotelServiceProvider"/>

<partnerLink name="BookClient"

partnerLinkType="tns:BookLT"

myRole="BookServiceProvider"/>

</partnerLinks>

<variables>

<variable name="BookHotelOut" messageType="tns:bookHotelResponse"/>

<variable name="BookHotelIn" messageType="tns:bookHotelRequest"/>

<variable name="BookIn" messageType="tns:bookRequest"/>

<variable name="BookOut" messageType="tns:bookResponse"/>

<variable name="NoOfClients" type="xsd:int"/>

<variable name="Counter" type="xsd:int"/>

</variables>

<sequence>

<receive name="ReceiveBookRequest"

createInstance="yes"


operation="book"

portType="tns:BookPortType"

variable="BookIn"/>

<while name="While1">

<condition>$Counter > $NoOfClients</condition>

<sequence>



<copy>

<from variable="BookIn" part="CustomerName"/>

<to variable="BookHotelIn" part="CustomerName"/>

</copy>

<copy>

<from variable="BookIn" part="Date"/>

<to variable="BookHotelIn" part="Date"/>

</copy>

<copy>

<from variable="BookIn" part="RoomType"/>

<to variable="BookHotelIn" part="RoomType"/>

</copy>

</assign>


partnerLink="Hotel"


portType="tns:HotelPortType"




<copy>

<from variable="BookHotelOut" part="Status"/>

<to variable="BookOut" part="Status"/>

</copy>

<copy>

<from variable="BookHotelOut" part="Price"/>

<to variable="BookOut" part="Price"/>

</copy>

</assign>

<reply name="ReplyClient"


operation="book"

portType="tns:BookPortType"

variable="BookOut"/>

<assign>

<copy>

<from>$Counter + 1 </from>


</copy>

</assign>

</sequence>

</while>

</sequence>

</process>

Chapter 5

Mapping BPMN Models toBPEL

This chapter covers a mapping of a BPMN model to a BPEL process by ana-lyzing and illustrating the existing a transformation approach.

The first problem we have encountered when mapping the BPMN design intoa BPEL implementation comes from the evident observation that BPMN andBPEL are representative of two different classes of languages. BPMN is graphoriented while BPEL is mainly block-structured [14], at least in its commonlyused XLANG [22] derived subset (however, BPEL has been also influenced bythe graph oriented WSFL [15]). A consequence of this divergence is that themapping from BPMN to BPEL is hard and it has a number of limitations sinceBPMN is able to express process patterns which cannot be expressed in BPEL.As a general comment we could say that the block structured nature of a BPELprocess is too limited for modeling purposes.

However, we believe that BPEL cannot be ignored when it comes to workflowmodeling because, although the business analysts more easily work with BPMNas modeling language and use its graphical notation to describe a business pro-cess (Task, Activity, Sequence flow, etc), the system developers manage better towork with an executable language like BPEL to define the composite structureof a business process. In BPEL such a structure is defined in terms of a flow ofstructured activities (Sequence, Parallel, etc) where each activity, in turn, can

46 Mapping BPMN Models to BPEL

contain a nested list of other activities being those web service invocations orother structured activities.

In this work the structure mismatch between BPMN and BPEL has been re-solved following the approach presented in [14] consisting of a complete trans-lation based on the identification of patterns of BPMN fragments which canbe directly mapped onto BPEL code. The transformation approach will be de-scribed in the following of this chapter where we will give an overview of ourmapping and how it is intended to work for the case study in Chapter 1.2 weare considering.

5.1 Basic Activities Translation

As we already know, BPEL activities can be either basic or structured activities.The basic activities correspond to the actual components of a process and canbe realized through web services interaction. This section relates BPEL basicactivities to the corresponding constructs in BPMN. BPMN basic activities(the ones based on messages, events and assignments) can be directly mappedto BPEL according to the following translation schema in Table 5.1:

BPMN BPELSend Task, Service Task, Message Event Invoke

Receive Task, Message Event ReceiveSend Task, Message Event Reply

Assignment AssignTermination end event Exit

Table 5.1: Basic Activities Translation Schema

In the previous chapter, we introduced the concept of Partner Links in BPELto model a relationship between the interacting business processes. Each par-ticipant plays a role in this relationship and the Port Types used to receive themessage from the partner. The BPMN model introduces Send, Receive, ServiceTask, and Message Intermediate Events to deal with the message-based inter-actions, where an asynchronous invoke activity corresponds to a Send Task ora Message Intermediate Event [21].

• Send Task, Service Task, Message Event The partner link of the BPELinvoke activity is derived from the interface referenced by the operationof the Send Task, Service Task or Message Event (see Figure 5.1).

5.1 Basic Activities Translation 47

Figure 5.1: Send Task, Service Task and Message Event

<invoke name="Task name"

partnerLink="Task operation interface"

portType="Task operation interface"

operation="Task operation">

</invoke>

• Receive Task, Message Event The partner link of the BPEL receive activ-ity is derived from the interface referenced by the operation of the ReceiveTask or Message Event (see Figure 5.3).

Figure 5.2: Receive Task and Message Event

<receive name="Task name"

createInstance="instantiate?’yes’:’no’"


portType="Task operation interface"

operation="Task operation">

</receive>


In BPMN model, a process is instantiated when one of its Start Eventsoccurs. Subsequence Start Events will share the same correlation informa-tion as the Start Event that creates the process instance [21]. In general,the BPEL processes are always instantiated through a single message, re-ceived by the receive activity or by the pick activity. They have beenconfigured for instantiation via a boolean attribute createInstance. If Re-ceive Task instantiates a process, we set yes to the createInstance attributeof the BPEL receive activity; otherwise set no.

• Send Task, Message Event The partner link of the BPEL reply activityis derived from the interface referenced by the operation of the Send Taskor Message Event (see Figure 5.3).

Figure 5.3: Receive Task and Message Event

<reply name="Task name"


operation="Task operation"

portType="Task operation interface">

</reply>

• Assignment BPMN Data Objects are mapped to the BPEL variables.BPMN introduces the notation of Data Objects to model the data flow.BPEL defines variables for either a whole process or a certain scope. Thevariable for each Data Object is added in the corresponding BPEL vari-ables section [21] (see Figure 5.4).

<varaible name="Data object name" type="structureDefinition"/>

• Termination End Event A Termination End Event is mapped to the exitactivity in BPEL as shown in the following Figure 5.5:

<exit>

</exit>

5.2 Structured Activities Translation 49

Figure 5.4: Data Object

Figure 5.5: Termination End Event

5.2 Structured Activities Translation

In this section, we classify different types of well-structured BPMN patternsresembling BPEL structured activities - sequence, flow, switch, pick and while.These structured activities are the block-oriented parts of BPEL. The transla-tion to the corresponding constructs in BPMN is sketched in Table 5.2. Compo-nents that can be suitably mapped onto any of these five structured constructsare identified as well-structured patterns[14].

BPMN BPELSequence Flow Sequence

Parallel Fork-Join Gateway FlowExclusive Data-based Gateway Switch

Exclusive Event-based gateway, Message/Timer Event PickLoops While, RepeatUntil

Table 5.2: Structured Activities Translation Schema

• Sequence Pattern A BPMN component consisting of activities connectedby Sequence Flow (see Figure 5.6) is mapped to the BPEL sequence ac-tivity:


Figure 5.6: Sequence Flow

<sequence>

Task1

Task2

Task3

</sequence>

• Flow Pattern A parallel fork-join pattern (see Figure 5.7) is mapped tothe flow activity in BPEL as follows:

Figure 5.7: Parallel Gateway

<flow>

Task1

Task2

</flow>

• Switch Pattern An Exclusive (Data-base) gateway (see Figure 5.8) ismapped as the switch or if-else activity in BPEL as follows; it can gener-alized to n branches in the same manner.


Figure 5.8: Exclusive(Data-base)Gateway

<switch>

<case condition="p1">

Task1

</case>

<otherwise>

Task2

</otherwise>

</switch>

<if> <condition> p1 </condition>

Task1

<else>

Task2

</else>

</if>

• Pick Pattern An Exclusive Event-based Gateway (see Figure 5.9) is mappedinto the pick activity in BPEL as follows. This figure only shows twobranches with one Message Intermediate Event and one Receive Task, inreality this mapping can generalized to n branches with any combinationof the Receive Task, the Intermediate Message or the Timer Event.

<pick>

<onMessage name="Message1">

<invoke name="Task1"/>

</onMessage>

...

<onMessage name="Message2">

<invoke name="Task2"/>


</onMessage>

...

</pick>

Figure 5.9: Exclusive Event-based Gateway

• While Pattern A while loop in BPMN (see Figure 5.10) is mapped to thewhile activity in BPEL as shown. It evaluates the loop condition beforethe body of the loop is executed.

Figure 5.10: While Loop

<while>

<condition> p1 </condition>

Task

</while>

• Repeat Pattern A repeat loop in BPMN (see Figure 5.11) is mapped to therepeatUntil activity in BPEL. In a repeat loop, the condition is checked


after the body of the loop is executed, so the loop is always executed atleast once.

Figure 5.11: Repeat Loop

<repeatUntil>

Task

<condition> not p </condition>

</repeatUntil>

• Embedded Sub-Process An embedded Sub-process (see Figure 5.12) canbe mapped to the scope activity in BPEL as showing below:

Figure 5.12: Sub-process

<scope name="scope"

...

</scope>

• Event Sub-Processes Non-interrupting Message Event Sub-Processes (seeFigure 5.13) can be mapped to the event handlers activity in BPEL asfollows:


Figure 5.13: Event Sub-Processes

<eventHandlers>

<onEvent partnerLink="message operation interface"

operation="message operation">

</onEvent>

<\eventHandlers>

5.3 Overall Mapping Approach Illustration: anOffice Workflow

In this section, we will transform the BPMN design of the office workflow casestudy1 to a BPEL process. The idea is to identify the occurrences of the basicactivities and the structured activities which we have introduced before andgenerate the corresponding BPEL code. And then find out each componentmatched by the well-structured patterns and fold the component into a singletask of the BPMN diagram. Repeating these steps until no pattern is left in theBPMN diagram.

Let’s consider the old configuration of the office workflow shown in Figure 2.12.As the reader can see, the BPMN design is made up of a set of independentcomponents, which are shown as separate Pools with separate sequence flows.It is interesting to note that this is not an abstract process since it includes thespecific service calls involved, i.e. it includes the interactions points between thedifferent participants. There are actually six participants involved (implementedas asynchronous web services).

1see Chapter 1-2: Office Workflow: Requirements.

5.3 Overall Mapping Approach Illustration: an Office Workflow 55

This office workflow can be seen as a Office Workflow process interacts withparticipants Order Generator, Credit Check, Inventory Check, Bill&Ship andArchive via message flows.

Figure 5.14: BPMN Participants

The resulting BPEL process is mapped as:

<process name="OfficeWorkflow">

targetNamespece=""

expressionLanguage=""


suppressJoinFailure="Yes"

xmlns=" ">

<partnerLinks>

...

</partnerLinks>

<varaibles>

...

</varaibles>

<correctionSets>

...

</correctionSets>

...

</process>

Now Let’s look at each part of the BPEL process.

5.3.1 Partner Link

The partner links of the BPEL process are derived from the interfaces associatedwith each participant [21] (see Table 5.3). The interface defines the operationsthat are implemented by services, which can be mapped to WSDL port typesand operations.

BPMN Participant Interface WSDL propertiesParticipant=”” patnerLink=””Interface=”” portType=””

Operation=”” operation=””inMessageRef=”” input message=””

outMessageRef=”” output message=””errorRef=”” fault name=””

Table 5.3: Partner Link Translation

Now we start to define the interface for each participants. There are six partic-ipants involved, which are implemented as asynchronous web services as shownin Table 5.4.

WSDL requires the specification of operations and port types the service isoffering, the accepted messages and their types. Consequently, a precise WSDLdescriptions of the involved services can be derived from the table above. Wenow present in detail the WSDL description for each of the six processes.


Par

tici

pan

tIn

terf

ace

Op

erati

on

inM

essa

geR

ef

Offi

ceW

orkfl

owO

rder

Rec

eip

tPor

tTyp

eO

rder

Rec

eip

tO

rder

Req

ues

tN

otifi

cati

onP

ortT

yp

eC

on

firm

Con

firm

Rej

ect

Rej

ect

Ord

erG

ener

ator

Ord

erG

ener

ator

Por

tTyp

eO

rder

Gen

erato

rO

rder

Gen

erato

rReq

ues

tO

rder

Gen

erat

orR

eply

Por

tTyp

eO

rder

Gen

erato

rRep

lyO

rder

Cre

dit

Ch

eck

Cre

dit

Ch

eckP

ortT

yp

eC

red

itC

hec

kC

ust

om

erC

red

itC

hec

kR

eply

Por

tTyp

eC

red

itC

hec

kR

eply

Ch

eckR

esu

lt

Inve

nto

ryC

hec

kIn

vento

ryC

hec

kP

ortT

yp

eIn

vento

ryC

hec

kIt

emIn

vento

ryC

hec

kR

eply

Por

tTyp

eIn

vento

ryC

hec

kR

eply

Ch

eckR

esu

lt

Bil

lS

hip

Bil

lSh

ipP

ortT

yp

eB

illS

hip

Ord

erB

ill

Ord

erS

hip

Ord

erB

illS

hip

Rep

lyP

ortT

yp

eB

illS

hip

Rep

lyB

illi

ngA

nd

Sh

ipp

ing

Bil

lRep

lyB

illi

ng

Sh

ipR

eply

Sh

ipp

ing

Arc

hiv

eA

rch

iveP

ortT

yp

eA

rch

ive

Arc

hiv

eIte

mA

rch

iveR

eply

Por

tTyp

eA

rch

iveR

eply

AC

K

Tab

le5.

4:P

arti

cip

ants

Inte

rface

Defi

nit

ion

s


• Office Workflow : OrderReceiptPortType allows the order message to bereceived by means of the OrderReceipt operation. To return the result, theWeb service specifies a second port type: NotifyPortType. This port typespecifies Confirm and Reject operations to return notification messagesback to the customer.

<wsdl:portType name="OrderReceiptPortType">

<wsdl:operation name="OrderReceipt">

<wsdl:input message="OrderRequest" name="input"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name="NotificationPortType">

<wsdl:operation name="Confirm">

<wsdl:input message="Confirm" name="input"/>

</wsdl:operation>

<wsdl:operation name="Reject">

<wsdl:input message="Reject" name="input"/>

</wsdl:operation>

</wsdl:portType>

• Order Generator: OrderGeneratorPortType allows generating the ordercode by means of the OrderGenerator operation. The result is returnedthrough the OrderGeneratorReply operation specified by OrderGenerator-ReplyPort Type.

<wsdl:portType name="OrderGeneratorPortType">

<wsdl:operation name="OrderGenerator">

<wsdl:input message="OrderGeneratorRequest" name="Input"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name="OrderGeneratorReplyPortType">

<wsdl:operation name="OrderGeneratorReply">

<wsdl:input message="Order" name="Input"/>

</wsdl:operation>

</wsdl:portType>

• Credit Check: CreditCheckPortType allows checking the identity of thecustomer with the operation CreditCheck. CreditCheckReplyPortType isinstead used to return the check result through the operation CreditCheck-Reply.

<wsdl:portType name="CreditCheckPortType">

<wsdl:operation name="CreditCheck">

<wsdl:input message="Customer" name="Input"/>

</wsdl:operation>

</wsdl:portType>


<wsdl:portType name="CreditCheckReplyPortType">

<wsdl:operation name="CreditCheckReply">

<wsdl:input message="CheckResult" name="Input"/>

</wsdl:operation>

</wsdl:portType>

• Inventory Check: Similarly to the Credit Check service InventoryCheck-PortType is used to check the identity of the product by means of theoperation InventoryCheck. InventoryCheckReplyPortType is instead usedto return the result of the check through the operation InventoryCheck-Reply.

<wsdl:portType name="InventoryCheckPortType">

<wsdl:operation name="InventoryCheck">

<wsdl:input message="Item" name="Input"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name="InventoryCheckReplyPortType">

<wsdl:operation name="InventoryCheckReply">

<wsdl:input message="CheckResult" name="Input"/>

</wsdl:operation>

</wsdl:portType>

• Bill and Ship: BillShipPortType is used to trigger the bill and ship activ-ity through the operation BillShip. The bill activity is performed usingthe operation Bill and the ship activity is performed using the opera-tion Ship. To return the result, the service specifies a second port type:BillShipReplyPortType. The bill details are returned through the opera-tion BillReply while the ship details are returned through the operationShipReply. The overall bill and ship details are returned through the op-eration BillShipReply.

<wsdl:portType name="BillShipPortType">

<wsdl:operation name="BillShip">

<wsdl:input message="Order" name="Input"/>

</wsdl:operation>

<wsdl:operation name="Bill">

<wsdl:input message="Order" name="input"/>

</wsdl:operation>

<wsdl:operation name="Ship">

<wsdl:input message="Order" name="input"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name="BillShipReplyPortType">

<wsdl:operation name="BillShipReply">

<wsdl:input message="BillingAndShipping" name="Input"/>

</wsdl:operation>

<wsdl:operation name="BillReply">

<wsdl:input message="Billing" name="input"/>


</wsdl:operation>

<wsdl:operation name="ShipReply">

<wsdl:input message="Shipping" name="input"/>

</wsdl:operation>

</wsdl:portType>

• Archive: ArchivePortType allows archiving the ordered product for furtherreference using the operation Archive. ArchiveReplyPortType is specifiedto return the result through the operation ArchiveReply.

<wsdl:portType name="ArchivePortType">

<wsdl:operation name="Archive">

<wsdl:input message="ArchiveItem" name="Input"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name="ArchiveReplyPortType">

<wsdl:operation name="ArchiveReply">

<wsdl:input message="ACK" name="Input"/>

</wsdl:operation>

</wsdl:portType>

The interface of Office Workflow participant is mapped to a BPEL partner linkwith a ”myRole” specification; the interfaces of other participants are mappedto the BPEL partner links with a ”partnerRole” specification. Because all theweb services are asynchronous, we should define two roles for each partner link.To make all the services working together BPEL requires the definition of apartnerLink section as follows:

<partnerLinks>

<partnerLink myRole="OrderReceiptServiceProvider"

name="OfficeWorkflow"

partnerLinkType="OfficeWorkflow:OfficeworkflowPLT"

partnerRole="NotifyServiceRequester"/>

<partnerLink myRole="OrderGeneratorReplyServiceRequester"

name="OrderGenerator"

partnerLinkType="OrderGenerator:OrderGeneratorPLT"

partnerRole="OrderGeneratorServiceProvider"/>

<partnerLink myRole="CreditCheckReplyServiceRequester"

name="CreditCheck"

partnerLinkType="CreditCheck:CreditCheckPLT"

partnerRole="CreditCheckServiceProvider"/>

<partnerLink myRole="InventoryCheckReplyServiceRequester"

name="InventoryCheck"

partnerLinkType="InventoryCheck:InventoryCheckPLT"

partnerRole="InventoryCheckServiceProvider"/>


<partnerLink myRole="BillShipReplyServiceRequester"

name="BillandShip1"

partnerLinkType="BillShip1:BillShipPLT"

partnerRole="BillShipSeriveProvider"/>

<partnerLink myRole="ArchiveReplyServiceRequester"

name="Archive"

partnerLinkType="Archive:ArchivePLT"

partnerRole="ArchiveServiceProvider"/>

</partnerLinks>

In this way, the interfaces of the other services which interacts with Office Work-flow are linked to the main BPEL process of the workflow itself.

5.3.2 Variables

Variables defined in BPEL process are created from Properties associated with aprocess in BPMN [21]. Take Office Workflow Process as an example, we defineits properties in Table 5.5.

Property WSDL message BPEL variableName=”CustomerRequest” name=”CustomerRequest” name=

”CustomerRequest”messageType=

”OfficeWorkflow:OrderReceipt”

Type=”structure” Map to WSDL message elementsSub-property WSDL part element

Name=”Customer” name=”customer”Type=”CustomerType” type=”xsd:CustomerType”

Table 5.5: Office Workflow Properties

So the BPEL code for the overall variables definitions are:

<variables>

<variable messageType="OfficeWorkflow:OrderRequest"

name="CustomerRequest"/>

<variable messageType="OfficeWorkflow:Confirm"

name="ConfirmNotify"/>

<variable messageType="OfficeWorkflow:Reject"

name="RejectNotify"/>

<variable messageType="OrderGenerator:OrderGeneratorRequest"


name="OrderRequest"/>

<variable messageType="OrderGenerator:Order"

name="Order"/>

<variable messageType="CreditCheck:Customer"

name="Customer"/>

<variable messageType="CreditCheck:CheckResult"

name="CreditCheckResult"/>

<variable messageType="InventoryCheck:Item"

name="Item"/>

<variable messageType="InventoryCheck:CheckResult"

name="ItemCheckResult"/>

<variable messageType="BillShip1:Order"

name="BillShipOrder"/>

<variable messageType="BillShip1:BillingAndShipping"

name="BillingShippingReply"/>

<variable messageType="Archive:ArchiveItem"

name="ArchiveItem"/>

<variable messageType="Archive:ACK"

name="ACK"/>

</variables>

5.3.3 Correlation Sets

The correlation sets of the BPEL process are derived from the Correlation Keysof the set of message flows. The mapping of the key-based Correlation Key isas follows [21]:

<KeyBasedCorrelationSet name="OrderID">

<Key name="OfficeWorkflow:OrderID"

type="String"

messageRef="OfficeWorkflow:OrderReceipt">

</Key>

</KeyBasedCorrelationSet>

<correlationSets>

<correlationSet name="OrderId" properties="OfficeWorkflow:OrderID"/>

</correlationSets>

For our case study, when Order Generator invokes the OrderGeneratorReplyoperation, the incoming message triggers the process execution to continue byleaving the receive activity. This shows correlation. It means the matchingof incoming service request messages with existing process executions that are


waiting for such an incoming message. If a receive activity is set as initiate, theincoming messages on that operation will lead to the creation of a new processexecution. An unique correlation id is also needed to identify the incomingmessages for the receive activity later in the process.

5.3.4 Office Workflow BPEL Main Body

The main process describing the workflow starts with the reception of an orderrequest coming from a customer, then it asynchronously invokes Order Gener-ator and, after having received a reply from it, Credit Check is asynchronouslyinvoked. It continues asynchronously invoking different services one by one,according to the specification. Two structure patterns can be identified: thesequence pattern involving the whole process and the If-else pattern for han-dling both the credit check reply and the inventory check reply. The BPMNMessage Start Event initiates the process receiving a message. This is mappedinto BPEL using a receive activity.

<sequence>

<receive createInstance="yes"

name="Receiverequestfromcustomer"

operation="OrderReceipt"

partnerLink="OfficeWorkflow"

portType="OfficeWorkflow:OrderReceiptPortType"

variable="CustomerRequest"/>

...

Next, we have to prepare the request message for the Order Generator service.We have to send a message consisting of customer and item parts built throughthe corresponding BPEL assignment activity.

<assign name="Callordergenerator">

<copy>

<from>$CustomerRequest.Customer/Name</from>

<to>$OrderRequest.part1/CustomerName</to>

</copy>

<copy>

<from>$CustomerRequest.Customer/ID</from>

<to>$OrderRequest.part1/CustomerID</to>

</copy>

<copy>

<from>$CustomerRequest.Item/Name</from>


<to>$OrderRequest.part2/ItemName</to>

</copy>

<copy>

<from>$CustomerRequest.Item/Quantity</from>

<to>$OrderRequest.part2/ItemQuantity</to>

</copy>

</assign>

Now, the Order Generator service will be invoked. Because it is an asynchronousservice, the callback will be received using the BPEL receive activity. We haveto invoke the OrderGeneratorReply operation on the OrderGeneratorReplyPort-Type. The callback message contains a Order number (OrderID) which is usedto initiate the correlation set.

<invoke partnerLink="OrderGenerator"

operation="OrderGenerator"

portType="OrderGenerator:OrderGeneratorPortType"

inputVariable="OrderRequest">

</invoke>

<receive name="Receiveorder"

partnerLink="OrderGenerator"

operation="OrderGeneratorReply"

portType="OrderGenerator:OrderGeneratorReplyPortType"

variable="Order">

<correlations>

<correlation set="OrderId" initiate="yes"/>

</correlations>

</receive>

After having received the response message from the Order Generator service,the process will invoke the Credit Check service. This involves checking customeridentity. Mapping the call of the Credit Check service is similar to mapping theOrder Generator service. Again, we start with the preparation of the inputmessage for the Credit Check service and then we invoke the service itself.

<assign name="Callcreditcheck">

<copy>

<from>$Order.part/CustomerName</from>

<to>$Customer.part/CustomerName</to>

</copy>

<copy>


<from>$Order.part/OrderID</from>

<to>$Customer.part/CustomerID</to>

</copy>

</assign>

<invoke partnerLink="CreditCheck"

operation="CreditCheck"

portType="CreditCheck:CreditCheckPortType"

inputVariable="Customer">

<correlations>

<correlation set="OrderId" pattern="out"/>

</correlations>

</invoke>

<receive name="Receivecreditcheckresult"

createInstance="no"

partnerLink="CreditCheck"

operation="CreditCheckReply"

portType="CreditCheck:CreditCheckReplyPortType"

variable="CreditCheckResult">

<correlations>

<correlation set="OrderId" initiate="no"/>

</correlations>

</receive>

The BPMN exclusive gateway following the ”Receive credit check result” mes-sage event is mapped into a BPEL If-else structured activity:

<if name="If1">

<condition>$CreditCheckResult.Part</condition>

<sequence name="Sequence1">

...

</sequence>

<else>

...

</else>

</if>

The Inventory Check works exactly in the same way as the Credit Check. TheBPMN process then moves to ”Receive item check result”, it goes through the”Yes” condition and the BillShip operation is invoked on the BillShipPortTypeof the Bill And Ship service. At this point, two operations bill and ship areinvoked in parallel. We can draw the Bill&Ship pool as shown in Figure 5.15.


Figure 5.15: Bill&Ship BPD

Then we map this new diagram onto a BPEL process by following the approachgiven in [14]. The translation procedure is sketched in four steps showing inFigure 5.16.

Figure 5.16: Bill&Ship Translation Procedure - Step1

Each component is named Ci where i specifies in what order the components areprocessed, and Ci is folded into a task object named TCi. Here four componentsare identified. C3 exhibits a Flow-Pattern and the rest are identified as Sequence-Patterns.

The resulting BPEL process is shown as:

<sequence name="Tc4">

<receive name="Receiveorder"/>


<flow name="Tc3">


<invoke name="Callbill"/>

<receive name="Receivebilldetails"/>

</sequence>


<invoke name="Callship"/>

<receive name="Receiveshipdetails"/>

</sequence>

</flow>

</sequence>

Both bill and ship return their details by means of the operation BillShipReplyand then the Archive service is invoked. After having received the return mes-sage ACK from ArchiveReplyPortType an invoke activity on NotifyPortType isperformed to send a confirmation message back to the customer.

<invoke name="Notifycustomerconfirm"

partnerLink="OfficeWorkflow"

operation="Confirm"

portType="OfficeWorkflow:NotifyPortType"

inputVariable="ConfirmNotify"/>

5.3.5 Change Configuration

To implement in BPEL the BPMN model depicted in Figure 2.13 we have justto replace Bill&Ship. So we need to define a new interface for it and then mapit onto a new partner link. We have to do the same as before and finally weget a new Bill&Ship. This is also an asynchronous process, containing both theinvocation of bill and ship operations and the invocation of a callback operation.

<partnerLink

myRole="BillShipReplyServiceRequester"

name="BillandShip2"

partnerLinkType="BillShip2:BillShipPLT"

partnerRole="BillShipSeriveProvider"/>

The process is simpler than the former ”Bill&Ship”, only one structure patternis now involved: Sequence. After the BillShip operation is invoked on BillShip-


PortType of the Bill And Ship service, the Bill operation is invoked. Then,the return message from BillReplyPortType is received and the Ship operationis invoked. Ship details are returned by the operation ShipReply and the re-turn message sent from BillShipReplyPortType is received. Finally, the Archiveservice is invoked.

<sequence name="Sequence3">

<assign name="Callbill">

<copy>

...

</copy>

</assign>

<invoke inputVariable="BillShipOrder"

operation="Bill"

partnerLink="BillandShip2"

portType="BillShip2:BillShipPortType"/>

<receive createInstance="yes"


operation="BillReply"

portType="BillShip2:BillShipReplyPortType" variable="Billing">

<correlations>

<correlation set="OrderId" initiate="yes"/>

</correlations>

</receive>

<assign name="Receivebilldetails">

<copy>

...

</copy>

</assign>

<invoke inputVariable="BillShipOrder"

operation="Ship"


portType="BillShip2:BillShipPortType"/>

<receive createInstance="no"

partnerLink="BillandShip2" operation="ShipReply"

portType="BillShip2:BillShipReplyPortType" variable="Shipping">

<correlations>

<correlation set="OrderId" initiate="no"/>

</correlations>

</receive>

<assign name="Receiveshipdetails">

<copy>

...

</copy>

</assign>

</sequence>

5.3.6 Transition between Configurations

The most interesting part of the BPMN design is the one depicted in Figure 2.14.To map this to BPEL we have to define a new partner link for a new participantReconf.Region which will be then used to invoke the new configuration. Wedefine a partner link with the role ChangeRole to change configuration:

<partnerLink myRole="ChangeRole"

name="Reconf.Region"

partnerLinkType="Reconf.region:Reconf.RegionPLT"/>

Within Reconf.region there is a BPMN Activity ”Determine Configuration” witha Non-Interrupting Intermediate Message Event, which can be mapped to aBPEL scope with an event handler activity [21].

<scope name="OldConfigScope">

<terminationHandler>

<scope name="NewConfigScope">

<sequence>

<!--perform the new configuration activities>

</sequence>

</scope>

</terminationHandler>

<eventHandlers>

<onEvent partnerLink="Reconf.Region"

operation="DetermineConfig"

portType="Reconf.region:ChangePortType"

variable="Rec"

messageType="Reconf.region:Rec">

<scope name="Scope">

<exit name="terminate"/>

</scope>

</onEvent>

<eventHandlers>

</scope>

<scope name="BillAndShip1">

<!-- perform bill and ship activities in parallel>

</scope>

Let us describe here in details how this works. If the process receive the Recchange message once the OldConfigScope scope has been entered, it will termi-nate the current process and execute the new process defined within the scope


NewConfigScope in the termination handler. This other process is exactly thenew configuration. Otherwise, the order will be enter to BillAndShip1 scopeand be processed accordingly with the original procedure.

Analysis in the dynamic reconfiguration model We need to verify thatduring the reconfiguration interval the requirements given in chapter 1.2 hold.

• The result of the Evaluation activity for any given order shouldnot be affected by the change in procedure. The acceptabilityof an order (Evaluation activity) is computed outside the region to bereconfigured, and there is no interaction between Evaluation and theregion. It means that the Evaluation in the old procedure workflow isexactly the same as in the new procedure workflow.

• All orders accepted after the change in procedure must be pro-ceed according to the new procedure. In order to distinguish betweenthese two situations - receiving the event before billing and shipping ac-tivities have started or after - we use scopes to define different procedures:OldConfigScope represents the procedure running before billing and ship-ping, BillShip1 represents the concurrent billing and shipping and New-ConfigScope represents the new configuration procedure which includessequential billing and shipping. When a management decision is made,the event handler for OldConfigScope will be invoked and it will terminateOldConfigScope, which contains the procedure for order receipt, order eval-uation activities. We use termination handler to replace OldConfigScopewith NewConfigScope representing the new procedure for order receipt,order evaluation and, this time, BillShip2 activities. In this way, after itstermination, the process will restart calling the new procedure.

• All accepted orders must be billed and shipped exactly once,then archived, then confirmed. This process describes billing andshipping happening in any order but both before archiving and confirming.We declare individual variables for BillShip1 and NewConfigScope. Theseare the request messages used to invoke the Bill and Ship services andthey are only visible within their own scope. This means that, if therequest message for billing and shipping has already been created, thisactivity can be invoked without any interrupt. Technically, the eventhandler is used to implement the management decision for change. Whenthe event is received, NewConfigScope will be enabled. However, if theevent is received after the order leaving OldConfigScope, BillShip1 will runbecause the request message has been initialized. If the event is receivedwhile OldConfigScope is running, OldConfigScope will be terminated andNewConfigScope will start redoing order receipt, order evaluation, and


execute BillShip2. BillShip1 will not be run because no request messagehas been initialized and NewConfigScope only calls BillShip2.

In the real world, after the management decision is made to switch to BillShip2,BillShip1 would be not available anymore. It is like ending to offer the BillShip1service. However, in BPEL, we cannot model exactly this situation. All theservices remain available. If we want to ensure all the instances of the workflowcreated after the change run BillShip2 instead of BillShip1, the process needsto continue receiving the ”change reconfiguration” event.

Chapter 6

Tool-based Mapping BPMNModels to BPEL

The BPMN to BPEL mapping we have presented so far has been obtained byfollowing the approach given in [14]. This allowed us to have some flexibilitybut the process had to be entirely manually executed. Another option, althoughmore restrictive, is to use some automatic tool for the translation. In this chapterwe will indeed discuss this option using the Intalio BPMS Designer version 6.0[1].

6.1 Designing and Implementing Process

Intalio BPMS Designer is presented in Figure 6.1, which is a set of Eclipseplugins allowing process designers to model processes with BPMN and to useseveral graphical tools to manage the data. It includes most of the BPMNelements which are relevant to executable business process models. Externalactivities and message flows are mapped into specific interface operations andmessage definitions using WSDL. The message structures are indicated by XMLSchema elements. Service calls are modeled by introducing Pools containing theoperations of the WSDL. The process interacts with this external participantsthrough message flows. After the process has been modeled and concrete ser-

74 Tool-based Mapping BPMN Models to BPEL

vices, messages and data have been defined, Intalio Designer will automaticallygenerate a BPEL description.

Figure 6.1: Intalio BPMS Designer

To model the office workflow with the Intalio Designer the first thing we have todo is creating a ’Business Process Project’ containing Business Process diagrams,XML Schemas, WSDL files. Once the project has been created, we can thencreate a BPMN diagram with the embedded BPMN modeler. The palette (seeFigure 6.2) provides an immediate access to all the existing BPMN shapes.After the BPMN modeling for the office workflow will be completed, we canstart implementing the process Office Workflow by integrating all the operationsfrom the existing Web services, creating the interface to define how it will beexposed to the external users and defining the graphical mappings to invoke theservices.

Integrating web services The tool integrates a full WSDL visual browserwhich allows to edit and introspect WSDL documents. To implement the casestudy we have to create WSDL documents for Office Workflow Service, OrderGenerator Service, Credit Check Service, Inventory Check Service, Bill&ShipService and Archive Service respectively. Then we have to create pools repre-

6.1 Designing and Implementing Process 75

Figure 6.2: BPMN Palette

senting all the external Web services and set them to ’Non-executable’ as thesepools represent the sequence of service operations that will be invoked from themain business process Office Workflow.

It is very important to make the distinction between operations invoked bya process and operations that will invoke a process. An operation in a non-executed pool, represented as a BPMN task either provides the operation orinvokes the operation. The operations like OrderGenerator, CreditCheck, In-ventoryCheck, etc are operations that the Office Workflow process will invoke;whereas OrderGeneratorReply, CreditCheckReply, InventoryCheckReply, etc areoperations that will invoke the process.

Finally, we have to connect the process tasks to the web service operations. Theorder is defined by creating the links. For the operations of Order Generatorwe want the message received from the customer to go from the executable task(”Invoke order generator”) to the corresponding Order Generator operation andthe response message to go from the Order Generator operation to the messageintermediate event (”Receive order”) (see Figure 6.3). In the same way, wehave to integrate Credit Check, Inventory Check, Bill&Ship, Archive. All thedata involved in the Office Workflow process are created automatically whenintegrating the WSDL files.


Figure 6.3: Order Generator Web Service Operations

Generate BPEL code Once the Office Workflow process is ready to be ex-ecuted we can easily deploy it. There are several artifacts being generated atthis point: the BPEL code corresponding to the Office Workflow process (seeAppendix C.3), the WSDL files used by the process to represent its interactionswith the other participants (see Appendix C.2) and the different WSDLs usedto represent external services (see Appendix C.1).

Change Configuration As before, we have to deal with the Office Workflowreconfiguration, i.e. the process will invoke Bill and Ship in sequence instead ofparallel. The remaining parts like partner links, external services, WSDLs arenot altered by this but the BPEL is (see Appendix C.4). We need indeed a newparticipant Reconf.region used to send a reconfiguration message and invoke thenew procedure. We also have to create a WSDL for it (see Appendix C.1).

We need to use a sub-process to include the two configurations and to addan Non-interrupt Message Event to make the choice. If the process receivesthe change message then the configuration2 sub-process will execute (the newconfiguration) otherwise the process will automatically execute the old configu-ration sub-process configuraiton1. The generated BPEL code, partner links areavailable in Appendix C.2 and Appendix C.5.

6.1 Designing and Implementing Process 77

As we can see from the generated BPEL code, the interaction between theReconf.Region web service and BPEL process is mapped into an event handlerand fault hander activity.

<bpel:scope bpmn:label="Reconfiguration" name="Reconfiguration"

bpmn:id="_EPcN4ClKEeCRVpI5R3SUgw">

<bpel:scope bpmn:label="configuration1" name="configuration1"

bpmn:id="_Kw694ClKEeCRVpI5R3SUgw">

<bpel:variables>

<!---define variables>

....

<bpel:variable

name="BillShipReply"

messageType="BillShip1:BillingAndShipping"/>

</bpel:variables>

<bpel:faultHandlers>

<bpel:catch faultName="bpmn:_YPUcsClKEeCRVpI5R3SUgw"

faultVariable="thisChange_ConfigurationRequestMsg"

faultMessageType="this:Change_ConfigurationRequest">

<bpel:scope bpmn:label="configuration2"

name="configuration2"

bpmn:id="_bJFfIClKEeCRVpI5R3SUgw">

<bpel:variables>

....

<bpel:variable name="billShip2ShipReplyRequestMsg"

messageType="BillShip2:Shipping"/>

</bpel:varables>

<bpel:sequence>

<!--perform all the new configuration actvities>

</bpel:sequence>

</bpel:scope>

</bpel:catch>

</bpel:faultHandlers>

<bpel:eventHandlers>

<bpel:onEvent

partnerLink="reconfig.RegionAndOffice_WorkflowPlkVar"

portType="this:ForReconfig.Region"

operation="Change_Configuration"

messageType="this:Change_ConfigurationRequest"

variable="thisChange_ConfigurationRequestMsg"

bpmn:label="Change Configuration"

name="Change_Configuration"

bpmn:id="_YPUcsClKEeCRVpI5R3SUgw">

<bpel:scope bpmn:label="Change ConfigurationScope"

name="Change_ConfigurationScope"

bpmn:id="_YPUcsClKEeCRVpI5R3SUgw_scope">

<bpel:throw faultName="bpmn:_YPUcsClKEeCRVpI5R3SUgw"

faultVariable="thisChange_ConfigurationRequestMsg"/>

</bpel:scope>

</bpel:onEvent>

</bpel:eventHandlers>

<bpel:sequence>

<!--perform the activities happens before calling BillAndShip>

</bpel:sequence>

</bpel:scope>

<bpel:scope bpmn:label="BillShip1Scope" name="BillShip1Scope"

bpmn:id="_S_Dc8ClKEeCRVpI5R3SUgw">

<bpel:variables>

<!--define variables for bill and ship>

</bpel:variables>

<bpel:sequence>

<bpel:variables>

<!--define variables only visible in this scope>

....

<bpel:variable name="billShip1BillShipReplyRequestMsg"

messageType="BillShip1:BillingAndShipping"/>

</bpel:variables>

<!--call bill and ship in parallel>

</bpel:sequence>

</bpel:scope>

</bpel:scope>

<!--call Archive>

...

Thus, if the process receives the change message before invoking the BillAndShipoperation on BillAndShipPortType, the order will be processed according to thenew procedure, otherwise it will be processed according to the old one.

6.2 Comparison Between the two Mapping Ways

In the Intalio BPMS, the message that flows between the executable processand the external web services is the same as when we do the implementationmanually. All the partner link definitions used by the Office workflow process forrepresenting its interaction with the other participants is generated in a WSDLfile. The names for partnerLinkType, myRole, partnerRole are automaticallygenerated by the tool, they are quite long and not well named.

6.2 Comparison Between the two Mapping Ways 79

<bpel:partnerLinks>

<bpel:partnerLink

name="order_GeneratorAndOffice_Workflow-

-ForPortOrderGeneratorReplySOAPPlkVar"

partnerLinkType="diag:Order_GeneratorAndOffice_

WorkflowForPortOrderGeneratorReplySOAPPlk"

initializePartnerRole="yes"

myRole="Office_Workflow_for_Order_Generator"

partnerRole="Order_Generator_for_Office_Workflow"/>

<bpel:partnerLink

name="credit_CheckAndOffice_Workflow-

-ForPortCreditCheckReplySOAPPlkVar"

partnerLinkType="diag:Credit_CheckAndOffice_

WorkflowForPortCreditCheckReplySOAPPlk"


myRole="Office_Workflow_for_Credit_Check"

partnerRole="Credit_Check_for_Office_Workflow"/>

<bpel:partnerLink

name="office_WorkflowAndInterface-

-ForPortNotificationSOAPPlkVar"

partnerLinkType="diag:Office_WorkflowAndInterface-

-ForPortNotificationSOAPPlk"


myRole="Office_Workflow_for_Interface"

partnerRole="Interface_for_Office_Workflow"/>

<bpel:partnerLink

name="inventory_CheckAndOffice_Workflow-

-ForPortInventoryCheckReplySOAPPlkVar"

partnerLinkType="diag:Inventory_CheckAndOffice_

WorkflowForPortInventoryCheckReplySOAPPlk"


myRole="Office_Workflow_for_Inventory_Check"

partnerRole="Inventory_Check_for_Office_Workflow"/>

<bpel:partnerLink

name="archiveAndOffice_Workflow-

-ForPortArchiveReplySOAPPlkVar"

partnerLinkType="diag:ArchiveAndOffice_Workflow-

-ForPortArchiveReplySOAPPlk"


myRole="Office_Workflow_for_Archive"

partnerRole="Archive_for_Office_Workflow"/>

<bpel:partnerLink

name="bill_Ship1AndOffice_Workflow-

-ForPortBillShipReplySOAPPlkVar"

partnerLinkType="diag:Bill_Ship1AndOffice_Workflow-

-ForPortBillShipReplySOAPPlk"



myRole="Office_Workflow_for_Bill_Ship1"

partnerRole="Bill_Ship1_for_Office_Workflow"/>

</bpel:partnerLinks>

The name of variables defined in the BPEL process are also generated by thetool.

<bpel:variables>

<bpel:variable name="tnsOrderReceiptRequestMsg"

messageType="tns:CustomerRequest"/>

<bpel:variable name="tnsRejectRequestMsg"

messageType="tns:Reject"/>

<bpel:variable name="tnsConfirmRequestMsg"

messageType="tns:Confirm"/>

....

</bpel:variables>

All the BPEL activities performance is the same for both implementations (Man-ually mapping (Chapter5) / Tool-based mapping (Chapter6)) of the old config-uration and the new configuration.

The biggest difference between these two implementations is the way to han-dle the dynamical reconfiguration, which is the transition process between twoconfigurations. Manually implementation is using the event handler activity toreact on the change event. Event handler starts when OldConfigScope scopestarts. This scope defines the procedure running before the bill and ship. Weuse the termination handler activity to define a new scope NewConfigScopewhich will start the new procedure for order generator, order evaluation andBillShip2 activities. So when Change Configuration event occurs, all the activ-ities happens before the bill and ship will be terminated and the process willrestart calling the new configuration procedure. BillAndShip1 scope representsthe concurrent billing and shipping procedure (see code in Chapter 5.3.6).

Whereas in the Intalio BPMS implementation, the fault handler activity is usedto define the new configuration procedure that is used to recover from the fault.The generated code is also using the event handler activity to react on theChange Configuration event, but here it will throw an error once the event oc-curs. In the BPMN diagram, it’s not allowed to have two message flows enteringto a same task object, intermediate message event can only receive one message(bill and ship details) either from the Bill&Ship1 web service or the Bill&Ship2web service. So we have to add a new Data Object (BillShipReply) to represent

6.2 Comparison Between the two Mapping Ways 81

a global BillShip reply message for the whole process. If the Bill&Ship1 serviceis invoked, copying the reply message of Bill&Ship1 to this global variable; if theBill&Ship2 service is invoked, copying the reply message of Bill&Ship2 to theglobal variable. The request message for the Archive web service is constructedby this defined global variable (see code in Chapter 6.1).

By comparing these two implementation options, we can see that even thoughthis automatic tool can succeed in generating BPEL code, additional procedureshave still to be provided manually. For example, the variables have to be ini-tialized, correlation set has to be established, etc. Based on a complex case, theBPMN diagram has too many limitations, the generated BPEL process maybenot suitable and satisfied all the requirements. In general, we cannot completelyrely on the code generated by the automatic tools. We have to keep in mindthat the tool-based transformation has weaknesses based on different cases andshould always use the transformation with caution.

Chapter 7

Discussion of an AlternativeBPMN Design

In this chapter we will present an alternative design of the office workflow case1.By comparing this new BPMN design with the design we have chosen to use,we illustrate why we choose not to use the alternative design. At the end wemake an BPEL implementation for the new BPMN design.

7.1 New BPMN Design

The reason for proposing an alternative design here is to give a freedom to themodelers to choose a more suitable design in a real situation. Look at Figure 7.1,7.2, 7.3, where different BPMN diagrams are proposed for the old configuration,new configuration and the transition between configurations of the Office Work-flow. Basically the differences between these two designs are the boundaries ofthe region to be reconfigured. In the new design version, the Bill and Ship areseparated from the reconfiguration region Bill&Ship pool. Thus, the Bill&Shiprepresents the entity responsible for calling the Bill and Ship external services.In the old configuration the Bill and Ship services are called parallel by the

1see Chapter 1-2: Office Workflow: Requirements.

84 Discussion of an Alternative BPMN Design

Bill&Ship1 service (see Figure 7.1); whereas in the new configuration these twoservices are called sequentially by the Bill&Ship2 service (see Figure 7.2. So theBill and Ship represent external services provided by external parties, not spe-cific activities within the same party who offers BillShip activity, which makesour design more generic. Figure 7.3 shows the overall workflow during the recon-figuration. The idea is the same as the old design model, which creates a defaultflow that is the same as the original configuration. When Bill&Ship is called,this default flow can be altered by receiving an interrupting message event. ”De-termine configuration” activity determines which configurations should be usedwhen Bill&Ship is called. If the interrupting event in the ”Determine configu-ration” activity happens, it will call the Bill&Ship2 service. Then Bill&Ship2will execute its own process of calling the Bill and Ship services in sequence;otherwise the original flow will activate by calling the Bill&Ship1 service whichexecutes its own process of calling the Bill and Ship services concurrently.

7.2 Discussion Between Two BPMN Designs

Actually both design decisions are possible to model and implement, but justapply to different situations. It seems that Figure 7.1 represents a more genericsituation where the different services (Bill&Ship, Bill and Ship) are offered bydifferent external parties; whereas Figure 2.12 represents the situation whereBill and Ship are activities belonging to the Bill&Ship service. This is thesame situation for Figure 2.13 and Figure 7.2. By comparing the transitionconfiguration diagrams (Figure 2.14 and Figure 7.3), we find that Bill and Shipactivities have been duplicately used in Figure 2.14, because both Bill&Ship1and Bill&Ship2 service include the same Bill and Ship activities. However inFigure 7.3, the same Bill and Ship services are called by both the Bill&Ship1and Bill&Ship1 services. Thus, the alternative design model seems better.

However when we look at the Bill and Ship pools in Figure 7.3 individually,both of them have two inputs and two outputs, which are not allowed in theBPMN model. In the Office workflow pool, there are also two inputs for theintermediate message event (Receive bill and ship details) which come fromthe different participants (Bill&Ship1 and Bill&Ship2). But the overall workingflow is acceptable, because it only allows to call one Bill&Ship at one time,either Bill&Ship1 or Bill&Ship2. If the interrupting event in the ”Determineconfiguration” activity happens, the message flow only goes to Bill&Ship2. Thusfor the Bill service, the Ship service and the Receive bill and ship details messageevent will be only one input and one output at the time. Although both designdecisions are correct and possible to implement, from a BPEL designer point ofview we would have had go for this alternative design decision, because it keeps

7.3 BPEL Implementation of the New BPMN 85

Figure 7.1: The Case Study Workflow - BPMN Diagrame Shows Old Configu-ration

the configuration and the service modules separate, which is more reasonablefor the reconfigurable systems.

7.3 BPEL Implementation of the New BPMN

The implementation for the alternative design is a little more complex than theprevious design. First of all we must create individual web services for Ship


Figure 7.2: The Case Study Workflow - BPMN Diagrame Shows New Configu-ration

and Bill out of the Bill&Ship service (see Appendix D.1). And then createa Bill&Ship process used to call the Bill and Ship external services. So thewhole process is conduct by the communication between the Office Workflowprocess and the BillShip process. It seems that the reconfiguration process hasbeen extracted out from the whole process. Office Workflow process representsexecuting all the activities except calling bill and ship. After evaluation, thisprocess will call Bill&Ship1 as a default. Then the BillShip1 process will start toexecute, where calling the Bill and Ship services concurrently and then send thereply messages of both the Bill and Ship services back to the Office Workflowprocess. In other words, the Office Worklow process involves the Bill&Ship


Figure 7.3: The Case Study Workflow - BPMN Diagrame Shows ConfigurationTransition

service invocation; and the Bill&Ship service will set up its own process tohandle the bill and ship activities (see Appendix D.3).



<bpel:process

name="BillShip1"

targetNamespace="http://example.com/Configuration1/Bill_Ship1"

....

<bpel:import .../>

<bpel:partnerLinks>

<bpel:partnerLink name="bill_Ship1AndBillForPortBillReplyPlkVar"

myRole="Bill_Ship1_for_Bill"

partnerRole="Bill_for_Bill_Ship1"/>

<bpel:partnerLink name="bill_Ship1AndShipForPortShipReplyPlkVar"

myRole="Bill_Ship1_for_Ship"

partnerRole="Ship_for_Bill_Ship1"/>

<bpel:partnerLink

name="bill_Ship1AndOffice_WorkflowForPortBillShipReplySOAPPlkVar"

myRole="Bill_Ship1_for_Office_Workflow"

partnerRole="Office_Workflow_for_Bill_Ship1"/>


<bpel:variables>

...

</bpel:variables>

<bpel:sequence>

<bpel:receive ...></bpel:receive>

<bpel:flow ..>

<bpel:sequence>

<bpel:invoke ...></bpel:invoke>

<bpel:receive ..></bpel:receive>

</bpel:sequence>

<bpel:sequence>



</bpel:sequence>

</bpel:flow>


</bpel:sequence>

</bpel:process>

For the new configuration, we can easily create a new process calling the Billand ship services in sequence, which conducts by bill&ship2 service. For theOffice Workflow process, it will call Bill&Ship2 instead of Bill&Ship1 after anevaluation (see Appendix D.4).



<bpel:process

name="BillShip2"

targetNamespace="http://example.com/Configuration1/Bill_Ship2"

....

<bpel:import .../>

<bpel:partnerLinks>

<bpel:partnerLink name="bill_Ship2AndBillForPortBillReplyPlkVar"

myRole="Bill_Ship2_for_Bill"

partnerRole="Bill_for_Bill_Ship2"/>

<bpel:partnerLink name="bill_Ship2AndShipForPortShipReplyPlkVar"

myRole="Bill_Ship2_for_Ship"

partnerRole="Ship_for_Bill_Ship2"/>

<bpel:partnerLink

name="bill_Ship2AndOffice_WorkflowForPortBillShipReplySOAPPlkVar"

myRole="Bill_Ship2_for_Office_Workflow"

partnerRole="Office_Workflow_for_Bill_Ship2"/>


<bpel:variables>

...

</bpel:variables>

<bpel:sequence>



<bpel:receive ..></bpel:receive>




</bpel:sequence>

</bpel:process>

For the reconfiguration procedure, we have to keep both Bill&Ship1 and Bill&Ship2available. Event handler and fault handler have been used as well to handle’Change configuration’ event. If the event occurs before the Office Workflowprocess invokes the BillShip1 service, the new configuration procedure definedin fault handler will be invoked, which will call the Bill&Ship2 service to startcalling the Bill and Ship services in sequence process. The Archive service in-vocation must take place after the Office Workflow process receives the replymessages from either BillShip1 or BillShip2 process. So we choose to use pickactivity to react on either receiving reply from the BillShip1 process or the Bill-Ship2 process. And then construct individual request message for the Archiveservice based on each condition (see Appendix D.5).

...

<bpel:pick bpmn:label="Exclusive_Event-Based_Gateway"

name="Exclusive_Event-Based_Gateway"

bpmn:id="_n4S7oCoZEeCcdJTDZPc89Q">

<bpel:onMessage

partnerLink="billShip1AndOffice_Workflow-


portType="BillShip1:BillShipReply"

operation="BillShipReply"

variable="billShip1BillShipReplyRequestMsg"

bpmn:label="Receive BillShip1 reply"

name="Receive__BillShip1_reply"

bpmn:id="_dffUwCoZEeCcdJTDZPc89Q">

<bpel:sequence>

<bpel:assign bpmn:label="Create Archive request1"

name="Create_Archive_request1"

bpmn:id="_qGZK4CoZEeCcdJTDZPc89Q">

....

</bpel:assign>

</bpel:sequence>

</bpel:onMessage>

<bpel:onMessage

partnerLink="billShip2AndOffice_Workflow-


portType="BillShip2:BillShipReply"

operation="BillShipReply"

variable="billShip2BillShipReplyRequestMsg"

bpmn:label="Receive BillShip2 reply"

name="Receive_BillShip2_reply"

bpmn:id="_05ycACoZEeCcdJTDZPc89Q">

<bpel:sequence>

<bpel:assign bpmn:label="Create Archive request2"

name="Create_Archive_request2"

bpmn:id="_3X1LwCoZEeCcdJTDZPc89Q">

...

</bpel:assign>

</bpel:sequence>

</bpel:onMessage>

</bpel:pick>

<!--Call Archive>

...

The processes for BillShip1, BillShip2 is the same as we mentioned before.

Chapter 8

Conclusion

In this thesis we have described the design of a system implementing exampleof a workflow and its reconfiguration in BPMN. We have worked on a BPELimplementation of the system, providing two approaches to generate BPEL spec-ifications from BPMN models. In particular, we discovered the usefulness of theBPEL Recovery Framework for dynamic reconfiguration. We can use the eventhandler activity to receive an administrative decision, and then terminate theoriginal workflow process. The new workflow process will be executed by usingthe fault handler or termination handler activities. This conclusion made a bigcontribution to the research community, who focuses on a workflow reconfig-uration research. The issue of dynamic reconfiguration in dependable systemis always challenging. Further investigation of the BPEL process deploymentneeds to be considered. We also intend to proceed larger industrial case studiesto help us to design and evaluate the BPEL Recovery Framework for dynamicreconfiguration in the future.

92 Conclusion

Appendix A

Paper Submitted toCOORDINATION 2011

Design, Modelling and Analysis ofa Workflow Reconfiguration

M. Mazzara1, F. Abouzaid2, N. Dragoni3 and A. Bhattacharyya1

1 Newcastle University, Newcastle upon Tyne, UK{Manuel.Mazzara, Anirban.Bhattacharyya}@ncl.ac.uk

2 Ecole Polytechnique de Montreal, [email protected]

3 Technical University of Denmark (DTU), [email protected]

Abstract. This paper describes a case study involving interference be-tween application activities and reconfiguration activities in an officeworkflow. We state the requirements on a system implementing the work-flow and its reconfiguration, and describe the system’s design in BPMN.We then use an asynchronous π-calculus and Webπ∞ to model the de-sign and to verify whether or not it will meet the requirements. In theprocess, we evaluate the formalisms for their suitability for the modellingand analysis of dynamic reconfiguration of dependable systems.

1 Introduction

Competition drives technological development, and the development of depend-able systems is no exception. Thus, modern dependable systems are required tobe more flexible, available and dependable than their predecessors, and dynamicreconfiguration is one way of achieving these requirements.

A significant amount of research has been performed on hardware reconfig-uration (see [5] and [9]), but little has been done for reconfiguration of services,especially regarding computational models, formalisms and methods appropri-ate to the service domain. Furthermore, much of the current research assumesthat reconfiguration can be instantaneous, or that the environment can wait dur-ing reconfiguration for a service to become available (see [14] and [13]). Theseassumptions are unrealistic in the service domain. For example, instantaneousmode change in a distributed system is generally not possible, because the sys-tem usually has no well-defined global state at a specific instant (due to signif-icant communication delays). Also, waiting for the reconfiguration to completeis not acceptable if (as a result) the environment becomes dangerously unstableor the service provider loses revenue by the environment aborting the servicerequest.

These observations lead to the conclusion that further research is requiredon dynamic reconfiguration of dependable services, and especially on its formal

foundations, modelling and verification. In particular, the problem of interfer-ence between old configuration activities, new configuration activities and recon-figuration activities that occurs due to overlapping modes needs to be addressed.In a preliminary paper [16], we examined a number of well-known formalismsfor their suitability for reconfigurable dependable systems. In this paper, wefocus on one of the formalisms (Webπ∞) and compare it to a π-calculus inorder to perform a deeper analysis than was possible in [16]. We use a morecomplex case study involving the reconfiguration of an office workflow for orderprocessing, define the requirements on a system implementing the workflow andits reconfiguration, and describe the design of a system in BPMN (see section2). We then use an asynchronous π-calculus with summation (in section 3) andWebπ∞ [18] (in section 4) to model the design and to verify whether or not thedesign will meet the reconfiguration requirements. We chose process algebrasbecause they are designed to model interaction (including interference) betweenconcurrent activities. An asynchronous π-calculus was selected because π-calculiare designed to model link reconfiguration, and asynchrony is suitable for mod-elling communication in distributed systems. Webπ∞ was selected because it isdesigned to model composition of web services.

Thus, the contribution of this paper is to identify strengths and weaknessesof an asynchronous π-calculus with summation and Webπ∞ for modelling dy-namic reconfiguration and verifying requirements (discussed in section 5). Thisevaluation may be useful to system designers intending to use formalisms todesign dynamically reconfigurable systems, and also to researchers intending todesign better formalisms for the design of dynamically reconfigurable systems.

2 Office Workflow: Requirements and Design

This case study describes dynamic reconfiguration of an office workflow for orderprocessing that is commonly found in large and medium-sized organizations [7].These workflows typically handle large numbers of orders. Furthermore, theorganizational environment of a workflow can change in structure, procedures,policies and legal obligations in a manner unforseen by the original designersof the workflow. Therefore, it is necessary to support the unplanned change ofthese workflows. Furthermore, the state of an order in the old configuration maynot correspond to any state of the order in the new configuration. These factors,taken in combination, imply that instantaneous reconfiguration of a workflowis not always possible; neither is it practical to delay or abort large numbers oforders because the workflow is being reconfigured. The only other possibility isto allow overlapping modes for the workflow during its reconfiguration.

2.1 Requirements

A given organization handles its orders from existing customers using a numberof activities arranged according to the following procedure:

1. Order Receipt: an order for a product is received from a customer. The orderincludes customer identity and product identity information.

2. Evaluation: the product identity is used to perform an inventory check on theavailability of the product. The customer identity is used to perform a creditcheck on the customer using an external service. If both the checks are positive,the order is accepted for processing; otherwise the order is rejected.

3. Rejection: if the order is rejected, a notification of rejection is sent to the customerand the workflow terminates.

4. If the order is to be processed, the following two activities are performed concur-rently:

(a) Billing: the customer is billed for the total cost of the goods ordered plusshipping costs.

(b) Shipping: the goods are shipped to the customer.

5. Archiving: the order is archived for future reference.6. Confirmation: a notification of successful completion of the order is sent to the

customer.

In addition, for any given order, Order Receipt must precede Evaluation,which must precede Rejection or Billing and Shipping.

After some time, managers notice that lack of synchronisation between theBilling and Shipping activities is causing delays between the receipt of bills andthe receipt of goods that are unacceptable to customers. Therefore, the managersdecide to change the order processing procedure, so that Billing is performedbefore Shipping (instead of performing the two activities concurrently). Duringthe transition interval from one procedure to the other, the following require-ments must be met:

1. The result of the Evaluation activity for any given order should not beaffected by the change in procedure.

2. All accepted orders must be billed and shipped exactly once, then archived,then confirmed.

3. All orders accepted after the change in procedure must be processed accord-ing to the new procedure.

2.2 Design

We designed the system implementing the office workflow using the BusinessProcess Modeling Notation (BPMN) [4]. We chose BPMN because it is a widelyused graphical tool for designing business processes. In fact, BPMN is a standardfor business process modelling, and is maintained by the Object ManagementGroup (see http://www.omg.org/).

The system is designed as a collection of eight pools: Office Workflow, Or-der Generator, Credit Check, Inventory Check, Reconf. Region, Bill&Ship1,Bill&Ship2 and Archive. The different pools represent different functional enti-ties, and each pool can be implemented as a separate concurrent task (see Figure

1). Office Workflow coordinates the entire workflow: it receives a request from acustomer, and makes a synchronous call to Order Generator to create an order.It then calls Credit Check (with the order) to check the creditworthiness of thecustomer, and tests the returned value using an Exclusive Data-Based Gateway.If the test is positive, Office Workflow calls Inventory Check (with the order) tocheck the availability of the ordered item, and tests the returned value. If eitherof the two tests is negative, the customer is notified of the rejected order andthe workflow terminates. If both tests are positive, Office Workflow calls Reconf.Region, which acts as a switch between configuration 1 and configuration 2 ofthe workflow, and thereby handles the reconfiguration of the workflow.

Reconf. Region calls Bill&Ship1 by default: it makes an asynchronous callto the Main pool within Bill&Ship1, which uses a Parallel Gateway to call Billand Ship concurrently and merge their respective results, and then returns theseresults to Office Workflow. The Office Workflow then calls Archive to store theorder, then notifies the customer of the successful completion of the order, andthen terminates the workflow. However, if Reconf. Region receives a changeconfiguration message, it calls the Main pool within Bill&Ship2 instead, whichmakes sequential a call to Bill and then to Ship, and then returns the results toOffice Workflow.

Notice that for the sake of simplicity, we assume neither Bill nor Ship pro-duces a negative result. Furthermore, the Bill and Ship pools are identical inboth configurations, which suggests their code is replicated (rather than shared)in the two configurations. Finally, we assume the reconfiguration is plannedrather than unplanned.

3 Asynchronous π-Calculus

The asynchronous π-calculus ([10], [3]) is a subset of Milner’s π-calculus [20], andit is known to be more suitable for distributed implementation. It is considered arich paradigm for asynchronous communication, although it is not as expressiveas Milner’s π-calculus in representing mixed-choice constructs, such as a.P+b.P ′

(see [22]).We recall the (monadic) asynchronous π-calculus. Let N be a set of names

(e.g. a, b, c, ...) and V be a set of variables (e.g. x, y, z, ...). The set of the asyn-chronous π-calculus processes is generated by the following grammar:

P ::= xz∣∣ G

∣∣ P |P∣∣ [a = b]P

∣∣ (νx)P∣∣ A(x1, ..., xn)

where guards G are defined as follows:

G ::= 0∣∣ x(y).P

∣∣ τ.P∣∣ G+G

Intuitively, an output xz represents a message z tagged with a name x indi-cating that it can be received (or consumed) by an input process x(y).P which

Fig. 1. Office workflow - BPMN diagram of the reconfiguration

behaves as P{z/y} upon receiving z. Furthermore, x(y).P binds the name y inP and the restriction (νx)P declares a name x private to P and thus binds x.Outputs are non-blocking.

The parallel composition P |Q means P and Q running in parallel. G+G isthe non-deterministic choice that is restricted to τ and input prefixes.

[a = b]P behaves like P if a and b are identical.A(y1, ..., yn) is an identifier (also call, or invocation) of arity n. It represents

the instantiation of a defined agent. We assume that every such identifier has

a unique, possibly recursive, definition A(x1, ..., xn)def= P where the xis are

pairwise distinct, and the intuition is that A(y1, ..., yn) behaves like P with eachyi replacing xi.

Furthermore, for each A(x1, ..., xn)def= P we require: fn(P ) ⊆ {x1, ..., xn},

where fn(P ) stands for the set of free names in P , and bn(P ) for the set ofbound names in P . The input prefix and the ν operator bind the names. Forexample, in a process x(y).P , the name y is bound. In (νx)P , x is considered tobe bound. Every other occurrences of a name like x in x(y).P and x, y in x〈y〉.Pare free.

Due to lack of space we omit to give details on structural congruence andoperational semantics for the asynchronous π-calculus. They can be found in [1]for the version of the calculus we use in this paper.

The Model in Asynchronous π-Calculus The model in asynchronous π-calculus needs to keep the synchronization between actions in sequence coherentwith the workflow definition. So sequence is implemented by using parallel com-position with prefix and postfix on the same channel. Channel names are notrestricted since the full system is not described here and has to be put in paral-lel with the detailed implementation of the environment process described (thatwill be omitted here).

The entire model is expressed in asynchronous π-calculus as follows:

Entire Model

Let params ={customer, item,Archive,ArchiveReply,Bill, BillReply,BillShip, Confirm,CreditCheck, CreditOk,CreditReject, InventoryCheck,InventoryOk, InventoryReject, OrderGenerator,OrderGeneratorReply,OrderReceipt, Reject, Ship, ShipReply, reco, recn}We can define the Workflow process as follows:

Workflow(params) ,(ν order) (OrderReceipt(customer, item).OrderGenerator customer, item|OrderGeneratorReply(order).CreditCheck customer| (creditOk().InventoryCheck item+ CreditReject().Reject order)| (InventoryOk().BillShip + InventoryReject().Reject order)| reco().BillShip().(Bill customer, item, order |Ship customer, item, order)|BillReply(order).ShipReply(order).Archive order

+recn().BillShip().(Bill customer, item, order|BillReply(order).Ship customer, item, order) |ShipReply(order).Archive order|ArchiveReply(order).Confirmorder) |Workflow(params)

In the model, the old region is identified as follows:

reco().BillShip().(Bill customer, item, order |Ship customer, item, order)|BillReply(order).ShipReply(order).Archive order

And the new region is:

recn().BillShip().(Bill customer, item, order|BillReply(order).Ship customer, item, order) |ShipReply(order).Archive order

In the asynchronous π-calculus, two outputs cannot be in sequence. In orderto impose ordering between Bill and Ship, in the new region, it is necessary toput a guard on Ship, which requires enlarging the boundary of the old region toinclude the processes in the environment of the workflow that synchronize withBill and Ship. We did not model these processes because they are outside thesystem being designed, but the limitations of the asynchronous π-calculus implythat we must be able to access the logic of external services for which we knowonly the interfaces. For a more detailed description of this problem, please see[12].

The entire model represents a specific instance of the workflow that spawnconcurrently another instance with fresh customer and item which here areassumed to be fresh names but in reality will be user entered (but it is notrelevant to our purposes). We have to assume the existence of a “higher level”process (at the level of the BPEL engine) that activates the entire workflow andbounds the names that are free in the above π-calculus process. In this modelchannels creditOK, creditReject, InventoryOK and InventoryReject are usedto receive the result of the credit check and inventory check, respectively. Theold/new region is externally triggered using specific channels reco and recn cho-sen according to the value x received on channel region:

(ν x)Workflow(param) | region(x).([x = new]recn | [x = old]reco )

In section 4 we show a more efficient solution using Webπ∞.

Analysis in π-logic Logics have long been used to reason about complex sys-tems, because they provide abstract specifications that can be used to describesystem properties of concurrent and distributed systems. Verification frame-works can support checking of functional properties of such systems by ab-stracting away from the computational contexts in which they are operating.

In the context of π-calculi, one can use the π-logic with the HAL Toolkitmodel-checker [8]. The π-logic has been introduced in [8] to specify the behav-ior of systems in a formal and unambiguous manner by expressing temporalproperties of π-processes.

Syntax of the π-logic The logic integrates modalities defined by Milner ([21])with EFφ and EF{χ}φ modalities on possible future. The π-logic syntax is:

φ ::= true | ∼ φ | φ ∧ φ′ | EX{µ}φ | EFφ | EF{χ}φ

where µ is a π-calculus action and χ could be µ, ∼ µ, or∨i∈I µi and where I is

a finite set.Semantics of π-formulae is given below:

• P |= true for any process P ;• P |=∼ φ iff P 6|= φ;• P |= φ ∧ φ′ iff P |= φ and P |= φ′ ;

• P |= EX{µ}φ iff there exists P ′ such as Pµ−→ P ′ and P ′ |= φ (strong

next);• P |= EFφ iff there exists P0, ..., Pn and µ1, ..., µn, with n ≥ 0, such as

P = P0µ1−→ P1...

µn−→ Pn and Pn |= φ. The meaning of EFφ is that φmust be true sometimes in a possible future.

• P |= EF{χ}φ if and only if there exists P0, ..., Pn and ν1, ..., νn , with n ≥ 0,

such that P = P0ν1−→ P1...

νn−→ Pn and Pn |= φ with:

• χ = µ for all 1 ≤ j ≤ n, νj = µ or νj = τ ;• χ =∼ µ for all 1 ≤ j ≤ n, νj 6= µ or νj = τ ;• χ =

∨i∈I µi : for all 1 ≤ j ≤ n, νj = µi for some i ∈ I or νj = τ .

The meaning of EF{χ}φ is that the truth of φ must be preceded by theoccurrence of a sequence of actions χ.

Some useful dual operators are defined as usual:false, φ ∨ φ, AX{µ}φ (∼ EX{µ} ∼ φ), < µ > φ (weak next), [µ]φ (Dual ofweak next), AGφ (AG{χ}) (always).

Properties of the dynamic reconfiguration modelWe need to verify that during the reconfiguration interval the requirements

given in section 2.1 hold. For this purpose, we need to express the requirementsformally, if possible, using the π-logic.

The result of the Evaluation activity for any given order should notbe affected by the change in procedure. The following formula meanswhatever the chosen path (old or new region), an order will be billed, shippedand archived or refused:

AG{EF{OrderReceipt()}true}AG{

(EF{Bill customer, item, order}true ∧ EF{Ship customer, item, order}true∧

EF{Archive order}true)∨ EF{Reject }true}

All accepted orders must be billed and shipped exactly once, thenarchived, then confirmed. The following formula means that after an orderis billed and shipped, it is archived and confirmed, and cannot be billed norshipped again:

AG{EF{BillShip()}true}AG{EF{Bill customer, item, order}true ∧ EF{Ship customer, item, order}true∧EF{Archive order}true} ∧ EF{Confirmorder}true}AG{{Bill customer, item, order}false ∧ {Ship customer, item, order}false}

All orders accepted after the change in procedure must be processedaccording to the new procedure We can express in the π-logic the follow-ing requirement: “after a reception on the channel recn, no other reception onchannel rec0 will be accepted”. This meets the desired requirement since it isobvious from the model that, if a signal is received on channel recn, the orderwill be processed according to the new procedure.

AG{{recn()}true AG{rec0()}false}

However, since the choice between the old procedure and the new one is non-deterministic, this formula will not be true, although it is an essential require-ment for the model. This result illustrates the difficulty of the asynchronousπ-calculus to model the dynamic reconfiguration properly. A first attempt toanswer this problem is presented in the next section.

4 Webπ∞

Webπ∞ is a conservative extension of the π-calculus developed for modelling andanalysis of Web services and Service Oriented Architectures. The basic theoryhas been developed in [18] and [15], whilst its applicability has been shown inother work: [12] gives a BPEL semantics in term of Webπ∞, [6] clarifies someaspects of the Recovery Framework of BPEL, and [17] exploits a web transactioncase study (a toy example has also been discussed in [16]).

Syntax and Semantics The syntax of webπ∞ processes relies on a countableset of names, ranged over by x, y, z, u, · · · . Tuples of names are written u. Weintend i ∈ I with I a finite non-empty set of indexes.

P ::= 0 | x u |∑

i∈I

xi(ui).Pi | (x)P | P |P | !x(u).P | 〈|P ; P |〉x

It is worth noting that the syntax of webπ∞ simply augments the asyn-chronous π-calculus with a workunit process. A workunit 〈|P ; Q|〉x behaves asthe body P until an abort x is received, and then it behaves as the event handlerQ.

We give the semantics of webπ∞ in two steps, following the approach of Mil-ner [19], separating the laws that govern the static relations between processesfrom the laws that rule their interactions. The static relations between processesare governed by the structural congruence ≡, the least congruence satisfying theAbelian monoid laws for parallel and summation (associativity, commutativityand 0 as identity) and closed with respect to α-renaming and the axioms shownin table 1.

Scope laws (u)0 ≡ 0, (u)(v)P ≡ (v)(u)P

P | (u)Q ≡ (u)(P |Q) , if u 6∈ fn(P )

〈|(z)P ; Q|〉x ≡ (z)〈|P ; Q|〉x , if z 6∈ {x} ∪ fn(Q)

Workunit laws 〈|0 ; Q|〉x ≡ 0

〈|〈|P ; Q|〉y |R ; R′|〉x ≡ 〈|P ; Q|〉y | 〈|R ; R′|〉x〈|(z)P ; Q|〉x ≡ (z)〈|P ; Q|〉x , if z 6∈ {x} ∪ fn(Q)

Floating law 〈|z u |P ; Q|〉x ≡ z u | 〈|P ; Q|〉xTable 1. webπ∞ Structural Congruence

The scope laws are standard while novelties regard workunit and floatinglaws. The law 〈|0 ; Q|〉x ≡ 0 defines committed workunit, namely workunit with0 as body. These ones, being committed, are equivalent to 0 and, therefore,cannot fail anymore. The law 〈|〈|P ; Q|〉y |R ; R′|〉x ≡ 〈|P ; Q|〉y | 〈|R ; R′|〉xmoves workunit outside parents, thus flattening the nesting. Notwithstandingthis flattening, parent workunits may still affect the children by means of names.The law 〈|z u |P ; Q|〉x ≡ z u | 〈|P ; Q|〉x floats messages outside workunit bound-aries. By this law, messages are particles that independently move towards theirinputs. The intended semantics is the following: if a process emits a message,this message traverses the surrounding workunit boundaries until it reaches thecorresponding input. In case an outer workunit fails, recoveries for this messagemay be detailed inside the handler processes.

The dynamic behavior of processes is instead defined by the reduction re-lation → which is the least relation satisfying the axioms and rules shown intable 2 and closed with respect to ≡, (x) , | , and 〈| ; Q|〉z. In the table we

use the shortcut: 〈|P ; Q|〉 def= (z)〈|P ; Q|〉z where z 6∈ fn(P ) ∪ fn(Q)

Rules (com) and (rep) are standard in process calculi and model input-outputinteraction and lazy replication. Rule (fail) models workunit failures: when aunit abort (a message on a unit name) is emitted, the corresponding body is

COM xi v |∑

i∈I xi(ui).Pi → Pi

{v/ui

}

REP x v | !x(u).P → P{v/u}| !x(u).P

FAIL x | 〈|∏i∈I

∑s∈S xis(uis).Pis |

∏j∈J !xj(uj).Pj ; Q|〉x → 〈|Q ; 0|〉

where J 6= ∅ ∨ (I 6= ∅ ∧ S 6= ∅)

Table 2. webπ∞ Reduction Semantics

terminated and the handler activated. On the contrary, aborts are not possibleif the transaction is already terminated (namely every thread in the body hascompleted its own work), for this reason we close the workunit restricting itsname.

The model in Webπ∞ For the modelling purposes of this work, the ideaof workunit and event handler turn out to be particularly useful. Webπ∞ usesthe mechanism of workunit to bound the identified regions, and event raisingis exploited to operate the non immediate change (reconfiguration). The modelcan be expressed as follows (as a shortcut we will use here process invocation):

Workflow(customer, item) ,(ν order) OrderReceipt(customer, item).OrderGenerator customer, item|OrderGeneratorReply(order).CreditCheck customer| (CreditCheckReplyt(order).InventoryCheck item+CreditCheckReplyf (order).Reject order)| (InventoryCheckReplyt(order).BillShip+InventoryCheckReplyf (order).Reject order)| 〈|BillShip().(Bill customer, item, order |Ship customer, item, order| (ν customer)(ν item)Workflow(customer, item)); (ν customer)(ν item)Workflown(customer, item)|〉rec|BillReply(order).ShipReply(order).Archive order|ArchiveReply(order).Confirmorder

Webπ∞ shows here a subtle feature which is important for modelling re-configurable systems. Since the floating laws of structural congruence allow theasynchronous outputs in a workunit to freely escape, once the region to reconfig-ure has been entered and theBillShip has been triggered,Bill customer, item, orderand Ship customer, item, order will not be killed by any incoming rec signal.This means that, once the region has been entered by an order, that order willgo through without being interrupted by reconfiguration events and the old or-der will be processed according to the old procedure, not the new one. Futureorders will find instead only the new procedure Workflown waiting for orders:

Workflown(customer, item) ,

(ν order) OrderReceipt(customer, item).OrderGenerator customer, item|OrderGeneratorReply(order).CreditCheck customer| (CreditCheckReplyt(order).InventoryCheck item+CreditCheckReplyf (order).Reject order)| (InventoryCheckReplyt(order).BillShip +InventoryCheckReplyf (order).Reject order)|BillShip().(Bill customer, item, order |BillReply(order).Ship customer, item, order)|ShipReply(order).Archive order |ArchiveReply(order).Confirmorder| (ν customer)(ν item)Workflown(customer, item)

As in the π-calculus model, we have to assume the existence of a top levelprocess activating the entire workflow and bounding all the names appearingfree in the above π-calculus process. The change in procedure will be activatedwhen the channel t is triggered.

(ν customer)(ν item)(ν rec)Workflow(customer, item) | t().rec

This process is also responsible for triggering the reconfiguration.

Analysis in Webπ∞ Analysis in Webπ∞ is intended as equational reason-ing. At the moment, one severe weakness of Webπ∞ is its lack of tool sup-port, i.e. automatic system verification. However, it is clearly possible to encodeWebπ∞ into the π-calculus, being the only technical complication the encodingof the workunit and its asynchronous interrupt. Once the compilation into theπ-calculus has been done, we can proceed using HAL. From one side, Webπ∞simplifies the modelling of dependable systems expressing with its workunit therecovery behavior. On the other side, it makes the verification more difficult.Luckily, there is an optimal solution using Webπ∞ as modelling language andthe π-calculus as intermediate language, i.e. a verification bytecode. We can thenoffer a practical modelling suite to the designer and still use the tool supportfor the π-calculus. At the moment our research has not gone so far, so we willjust discuss the three requirements here. We will analyse the requirements interms of equational reasoning (see [18] and [15]). The case study of this paper isinteresting at showing both the modelling power of Webπ∞ and the weaknessesof its reasoning system.

The result of the Evaluation activity for any given order should notbe affected by the change in procedure. The acceptability of an order(Evaluation activity) is computed outside the region to be reconfigured, andthere is no interaction between Evaluation and the region. That means thatthe Evaluation in the old procedure workflow is exactly the same as in thenew procedure workflown, i.e. the checks are performed in the same exact or-der. We can formally express it, in term of equational reasoning, stating that

the Evaluation activity in the old procedure workflow is bisimilar to theEvaluation activity in the new procedure workflown which is trivially true.

All accepted orders must be billed and shipped exactly once, thenarchived, then confirmed. The presence of a workunit does not affect how theorder itself is processed. The workflow of actions described by the requirementcan be formally expressed as follows:

(ν x)(ν y) (Bill customer, item, order |Ship customer, item, order|BillReply(order).x |ShipReply(order).y |x().y().Archive order|ArchiveReply(order).Confirmorder)

In plain words this process describes billing and shipping happening in anyorder but both before archiving and confirming. The channels x and y are thereprecisely to work as a joint for billing and shipping. If we want to express therequirements in term of equational reasoning, we can require that both the oldand the new regions have to be bisimilar with the above process. However, thisis too strict since the above process allows a set of traces which is a supersetof both the set of traces of the old configuration and the new one. In this casesimilarity could be considered instead of bisimilarity.

All orders accepted after the change in procedure must be processedaccording to the new procedure To show this requirements has been imple-mented in the model semantic reasoning is not necessary, structural congruenceis sufficient. The change in procedure is here modelled by triggering the rec chan-nel and spawning the workunit handler. The handler then activates a new in-stance of the workflow based on the new procedure scheme which has been calledworkflown. The floating laws of structural congruence of Webπ∞ (definition 1)allow the asynchronous outputs in a workunit to freely escape the workunit itself.Thus, once the region to reconfigure has been already entered and the BillShiphas been triggered, Bill customer, item, order and Ship customer, item, orderwill not be killed by any incoming rec signal. Thus, once the region has beenentered by an order, that order will be not interrupted by reconfiguration eventsso that old order will be processed according to the old procedure and not thenew one.

5 Discussion

In this section, we discuss three issues which arose during design and modelling:how the modelling influenced our design, how the π-calculus and Webπ∞ com-pare with respect to modelling, and correctness criteria for verification of theworkflow reconfiguration.

Modelling and Design Different formalisms have different biases on designbecause of their different perspectives. In one of the alternative designs we con-sidered, the Bill and Ship pools were outside the reconfiguration region, so thattheir code was shared between the two configurations. Thus, the boundary of thereconfiguration region was different. We chose the design in section 2.2 becauseit is easier to model. It is the job of a formalist to model what the system design-ers produce, and ask them to change the design if it cannot be modelled or isunverifiable. Our experience with asynchronous π-calculi and Webπ∞ suggestedthat extending the boundary of the reconfiguration region to include billing andshipping was a practical choice. This is because in the asynchronous π-calculus(and consequently in Webπ∞), two outputs cannot be in sequence. So, in orderto impose ordering between Bill and Ship, we had to enlarge the boundaryof the reconfiguration region to include the processes in the environment of theworkflow that synchronize with them. The negative side of this solution is thatwe have been forced to include in the region parts of the system that were notintended to be changed. Here the asynchronous π-calculus shows its weaknessin terms of reconfiguring processes dynamically.

Comparison of π-calculus and Webπ∞ This paper has shown the Webπ∞workunit as being able to offer a more efficient solution to the problem of mod-elling the case study. By means of the Webπ∞ floating laws, interference betweenapplication activities and reconfiguration activities can also be better handled.However, at the moment, one weakness of Webπ∞ is its lack of tool support,whereas the π-calculus is supported by verification tools (e.g. TyPiCal [11] andHAL [8]). Therefore, Webπ∞ has to be intended as a a front end for modellingwith the the π-calculus as the verification bytecode. As mentioned above, neitherthe asynchronous π-calculus nor Webπ∞ can have two outputs in sequence, andthis leads to the specific design choice.

Correctness Criteria The standard notion of correctness used in process al-gebras is congruence based on bisimulation. However, our requirements are notall expressible as congruences between processes. The first and third require-ments can be expressed as congruences, and so we have used bisimulation inour reasoning about them. The second requirement cannot be expressed as acongruence because the old and new configurations are not behaviourally con-gruent. So, we have used reasoning based on simulation instead. Thus, we foundthat congruence as it has been used in section 4 is not always applicable for veri-fying the correctness of our models. Therefore, in section 3 we have investigatedmodel checking.

The discussion leads us to the following:

1. It is easier to model workflow reconfiguration in Webπ∞ than in the asyn-chronous π-calculus. However, modelling would be even easier in a syn-chronous version of Webπ∞.

2. Model checking is more widely applicable than equational reasoning basedon congruences for verifying workflow reconfiguration.

These two conclusions seem to have wider applicability than just reconfigu-ration of workflows; but this needs to be verified.

Future Work We intend to proceed with a deeper analysis of alternative de-signs for this case study, and evaluate other formalisms, such as VDM [2] andPetri nets [23]. We are also working on a BPEL implementation of the system.We also need larger industrial case studies to help us to design and evaluateformalisms for the modelling and analysis of dynamic reconfiguration.

Acknowledgments

This work is partly funded by the EPSRC under the terms of a graduate studentship.The paper has been improved by conversations with John Fitzgerald, Cliff Jones,Alexander Romanovsky, Jeremy Bryans, Gudmund Grov, Mario Bravetti, MassimoStrano, Michele Mazzucco, Paolo Missier and Mu Zhou. We also want to thank mem-bers of the Reconfiguration Interest Group (in particular, Kamarul Abdul Basit, CarlGamble and Richard Payne), the Dependability Group (at Newcastle University) andthe EU FP7 DEPLOY Project (Industrial deployment of system engineering methodsproviding high dependability and productivity).

References

1. R. M. Amadio, I. Castellani, and D. Sangiorgi. On bisimulations for the asyn-chronous π-calculus. Theoretical Computer Science, 195(2):291 – 324, 1998.

2. D. Bjorner and C. B. Jones, editors. The Vienna Development Method: The Meta-Language, volume 61 of Lecture Notes in Computer Science. Springer, 1978.

3. G. Boudol. Asynchrony and the π-calculus. rapport de recherche 1702. Technicalreport, INRIA, Sophia-Antipolis, 1992.

4. BPMN. Bpmn - business process modeling notation. ‘http://www.bpmn.org/.5. A. Carter. Using dynamically reconfigurable hardware in real-time communica-

tions systems: Literature survey. Technical report, Computer Laboratory, Univer-sity of Cambridge, November 2001.

6. N. Dragoni and M. Mazzara. A formal semantics for the ws-bpel recovery frame-work - the pi-calculus way. In WS-FM’09, Springer Verlag, 2009.

7. C. Ellis, K. Keddara, and G. Rozenberg. Dynamic change within workflow systems.In Proceedings of the Conference on Organizational Computing Systems (COOCS1995). ACM, 1995.

8. G. L. Ferrari, S. Gnesi, U. Montanari, and M. Pistore. A model-checking verifica-tion environment for mobile processes. ACM Transactions on Software Engineer-ing and Methodology, 12(4):440–473, 2003.

9. P. Garcia, K. Compton, M. Schulte, E. Blem, and W. Fu. An overview of re-configurable hardware in embedded systems. EURASIP J. Embedded Syst., 2006,January 2006.

10. K. Honda and M. Tokoro. An object calculus for asynchronous communica-tion. In P. America, editor, European Conference on Object-Oriented Programming(ECOOP), page 133147. Lecture Notes in Computer Science 512, 1991.

11. N. Kobayashi. Typical: Type-based static analyzer for the pi-calculus.http://www.kb.ecei.tohoku.ac.jp/ koba/typical/.

12. R. Lucchi and M. Mazzara. A pi-calculus based semantics for ws-bpel. Journal ofLogic and Algebraic Programming, 70(1):96–118, 2007.

13. J. Magee, N. Dulay, and J. Kramer. Structuring parallel and distributed programs.Software Engineering Journal (Special Issue), 8(2):73–82, 1993.

14. J. Magee, J. Kramer, and M. Sloman. Constructing distributed systems in conic.IEEE Transactions on Software Engineering, 15(6):663–675, 1989.

15. M. Mazzara. Towards Abstractions for Web Services Composition. PhD thesis,Department of Computer Science, University of Bologna, 2006.

16. M. Mazzara and A. Bhattacharyya. On modelling and analysis of dynamic recon-figuration of dependable real-time systems. In DEPEND, International Conferenceon Dependability, 2010.

17. M. Mazzara and S. Govoni. A case study of web services orchestration. In CO-ORDINATION, pages 1–16, 2005.

18. M. Mazzara and I. Lanese. Towards a unifying theory for web services composition.In WS-FM, pages 257–272, 2006.

19. R. Milner. Functions as processes. Mathematical Structures in Computer Science,2(2):119–141, 1992.

20. R. Milner. Communicating and Mobile Systems: the Pi-Calculus. CambridgeUniversity Press, 1999.

21. R. Milner, J. Parrow, and D. Walker. Modal logics for mobile processes. TheoreticalComputer Science, 1993.

22. C. Palamidessi. Comparing the expressive power of the synchronous and theasynchronous pi-calculus. In Mathematical Structures in Computer Science, pages256–265. ACM, 1997.

23. C. A. Petri. Kommunikation mit Automaten. PhD thesis, Fakultt Matematik undPhysik, Technische Universitaet Darmstadt, 1962.

110 Paper Submitted to COORDINATION 2011

Appendix B

Source Codes for the OfficeWorkflow Case Study -generated by manually

mapping

B.1 WSDLs

Source codes location:

• Office Workflow Service

\ManuallyMapping\WSDLs\OfficeWorkflowService

• Order Generator Service

\ManuallyMapping\WSDLs\OrderGeneratorService

• Credit Check Service

112Source Codes for the Office Workflow Case Study - generated by manually

mapping

\ManuallyMapping\WSDLs\CreditCheckService

• Inventory Check Service

\ManuallyMapping\WSDLs\InventoryCheckService

• Bill Ship1 Service

\ManuallyMapping\WSDLs\BillShip1Service


\ManuallyMapping\WSDLs\BillShip2Service

• Archive Service

\ManuallyMapping\WSDLs\ArchiveService

• Reconfig.Region Service

\ManuallyMapping\WSDLs\ReconfigService

B.2 BEPL Process for the Old Configuration

Source code location:

\ManuallyMapping\BPELs\OldOfficeWorkflowProcess

B.3 BEPL Process for the New Configuration


\ManuallyMapping\BPELs\NewOfficeWorkflowProcess

B.4 BEPL Process for the Reconfiguration Transition 113

B.4 BEPL Process for the Reconfiguration Tran-sition


\ManuallyMapping\BPELs\ReconfigOfficeWorkflowProcess

114Source Codes for the Office Workflow Case Study - generated by manually

mapping

Appendix C

Source Codes for the OfficeWorkflow Case Study -

generated by tool-basedmapping

C.1 WSDLs



\ToolMapping\WSDLs\OfficeWorkflowService


\ToolMapping\WSDLs\OrderGeneratorService


116Source Codes for the Office Workflow Case Study - generated by

tool-based mapping

\ToolMapping\WSDLs\CreditCheckService


\ToolMapping\WSDLs\InventoryCheckService


\ToolMapping\WSDLs\BillShip1Service


\ToolMapping\WSDLs\BillShip2Service

• Archive Service

\ToolMapping\WSDLs\ArchiveService


\ToolMapping\WSDLs\ReconfigService

C.2 WSDL for Partner Links


• Partner links for the old configuration

\ToolMapping\PartnerLinks\Configuration1

• Partner links for the new configuration

\ToolMapping\PartnerLinks\Configuration2

• Partner links for the reconfiguration transition

\ToolMapping\PartnerLinks\ConfigurationTransition

C.3 BEPL Process for the Old Configuration 117

C.3 BEPL Process for the Old Configuration


\ToolMapping\BPELs\Configuration1-Office_Workflow

C.4 BEPL Process for the New Configuration


\ToolMapping\BPELs\Configuration2-Office_Workflow

C.5 BEPL Process for the Reconfiguration Tran-sition


\ToolMapping\BPELs\ConfigurationTransition-Office_Workflow

118Source Codes for the Office Workflow Case Study - generated by

tool-based mapping

Appendix D

Source Codes for the OfficeWorkflow Case Study

(alternative design)-generated by tool-based

mapping

D.1 WSDLs



\AlternativeToolMapping\WSDLs\OfficeWorkflowService


\AlternativeToolMapping\WSDLs\OrderGeneratorService

120Source Codes for the Office Workflow Case Study (alternative design)-

generated by tool-based mapping


\AlternativeToolMapping\WSDLs\CreditCheckService


\AlternativeToolMapping\WSDLs\InventoryCheckService


\AlternativeToolMapping\WSDLs\BillShip1Service


\AlternativeToolMapping\WSDLs\BillShip2Service

• Bill Service

\AlternativeToolMapping\WSDLs\BillService

• Ship Service

\AlternativeToolMapping\WSDLs\ShipService

• Archive Service

\AlternativeToolMapping\WSDLs\ArchiveService


\AlternativeToolMapping\WSDLs\ReconfigService

D.2 WSDL for Partner Links


• Partner links for the old configuration

\AlternativeToolMapping\PartnerLinks\Configuration1

• Partner links for the new configuration

\AlternativeToolMapping\PartnerLinks\Configuration2

• Partner links for the reconfiguration transition

\AlternativeToolMapping\PartnerLinks\ConfigurationTransition

D.3 BEPL Processes for the Old Configuration 121

D.3 BEPL Processes for the Old Configuration


• Office Workflow Process:

\AlternativeToolMapping\BPELs\Configuration1-Office_Workflow

• Bill Ship Process:

\AlternativeToolMapping\BPELs\Configuration1-Bill_Ship1

D.4 BEPL Processes for the New Configuration



\AlternativeToolMapping\BPELs\Configuration2-Office_Workflow

• Bill Ship Process:

\AlternativeToolMapping\BPELs\Configuration2-Bill_Ship2

D.5 BEPL Processes for the Reconfiguration Tran-sition



\AlternativeToolMapping\BPELs\ConfigurationTransition-Office_Workflow

122Source Codes for the Office Workflow Case Study (alternative design)-

generated by tool-based mapping

• Bill Ship1 Process:

\AlternativeToolMapping\BPELs\ConfigurationTransition-BillShip1

• Bill Ship2 Process:

\AlternativeToolMapping\BPELs\ConfigurationTransition-BillShip2

Bibliography

[1] Intalio BPMS Designer 6.0. Tutorials avaliable athttp://community.intalio.com/tutorials-6.0.html (checked Febru-ary 3, 2011).

[2] Object Management Group. Avaliable at http://www.omg.org (checkedFebruary 3, 2011).

[3] Yaoqiang BPMN Editor 2.0. Avaliable at http://bpmn.yaoqiang.org/

(checked February 3, 2011).

[4] Web Services Description Language, March 2001. Avaliable athttp://www.w3.org/TR/wsdl (checked February 3, 2011).

[5] XML Schema, October 2004. Avaliable athttp://www.w3.org/TR/xmlschema-2/ (checked February 3, 2011).

[6] Web Services Business Process Execution Language Version 2.0,May 2007. Avaliable at http://docs.oasis-open.org/wsbpel/2.0/

Primer/wsbpel-v2.0-Primer.pdf (checked February 3, 2011).

[7] The WSIT Tutorial: For Web Services Interoperability Technologies. Ora-cle, August 2007.

[8] Universal Description Discovery and Integration, February 2011. Avaliableat http://en.wikipedia.org (checked February 3, 2011).

[9] F. Abouzaid, A. Bhattacharyya, N. Dragoni, J.S. Fitzgerale, M. Mazzara,and M. Zhou. A case study of workflow reconfiguration: Design, modelling,analysis and implementation. 2011. Working report, draft version no.14.To be published as a technical report at University of Newcastle.

124 BIBLIOGRAPHY

[10] A.Carter. Using dynanmically reconfigurable hardware in real-time com-munications system: Literature survay. Technical report, Computer Labo-ratory, University of Cambridge, November 2001.

[11] Algirdas Avizienis, Jeans-Claude Laprie, and Brian Randell. Fundamentalconcepts of dependability, 2001.

[12] R. Baird, M. Hepner, R. Gamble, and T. Gamble. Reconfiguring workflowsof web services. In IEEE Int’l Conference on COTSBased Software Systems(ICCBSS), pages 131–140, Banff, Alberta, Canada, 2007.

[13] Ethan Cerami. Web Services Essentials. O’Reilly, February 2002.

[14] Ouyang Chun, Marlon Dumas, and Arthur H.M. ter Hofstede. From bpmnprocess models to bpel web services. In Proceedings of the IEEE Interna-tional Conference on Web Services, pages 285–293. IEEE Computer Soci-ety, Los Alamitos, 2006.

[15] F.Leymann. Web Service Flow Language (wsfl1.0). Avaliable athttp://www-01.ibm.com/software/solutions/soa/ (checked February3, 2011).

[16] P. Garcia, K. Compton, M. Schulte, E. Blem, and W. Fu. An overview ofreconfigurable hardware in embedded systems. In EURASIP Journal onEmbedded Systems, pages 1–19. Hiindawi Publishing Corp. New York, NY,United States, 2006.

[17] M. Hepner. Dynamic changes to workflow instances of web services. Tech-nical report, Dept. Mathematical Computer Sciences. Ph.D. Diss., TheUniversity of Tulsa, 2007.

[18] M. Hepner, R. Baird, and R. Gamble. Dynamically changing workflows ofweb services. In Services, IEEE Congress on, volume 0, pages 422–429, LosAlamitos, CA, USA, 2009. IEEE Computer Society.

[19] Matjaz B. Juric. Business Process Execution Language for Web Services.PACKT, April 2006.

[20] M. Mazzara and A. Bhattacharyya. On modelling and analysis of dynamicreconfiguration of dependable real-time systems. In DEPEND, Interna-tional Conference on Dependability, 2010.

[21] OMG. Business Process Model and Notation(BPMN) version2. OMG Doc-ument, 2010.

[22] S. Thatte. Xlang: Web services for business process design. MicrosoftCorporation, 2001.

BIBLIOGRAPHY 125

[23] W. Tsai, W. Song, R. Paul, Z. Cao, and H. Huang. Service-oriented dy-namic reconfiguration framework for dependable distributed computing. In28th Annual International Computer Software and Applications Conference(COMPSAC04), pages 554–559, Hongkong, 2004.

[24] M. Wermelinger. Towards a chemical model for software architecture recon-figuration. In Configurable Distributed Systems, 1998. Proceedings. FourthInternational Conference on, pages 111–118, may 1998.

a case study of workflow reconfiguration: design and ...etd.dtu.dk/thesis/275152/ep11_10.pdf ·...

Documents