A Case Study of Workflow Reconfiguration: Design and Implementation

Transcription

1 A Case Study of Workflow Reconfiguration: Design and Implementation Mu Zhou s Kongens Lyngby 2011 IMM M.Sc

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax

3 Summary Dependable systems are more and more expected to operate in dynamic environments to deal with the new problems and tasks. One way of achieving the flexibility of the system is to use dynamic reconfiguration. A system can be implemented as a collection of configurations, where each configuration can be optimized for each service. Therefore, dynamic reconfiguration can provide maximum flexibility of the system by replacing one configuration by another at runtime. Furthermore, it makes the system more dependable because the overall architecture of the system has not been changed by adding or removing configurations. However the problem of interferences between the old and the new configurations needs to be addressed. The purpose of our research is to design, model, verify and implement a case study involving the reconfiguration of an office workflow for order processing, based on the requirements on a system implementing the workflow and its reconfiguration. In this thesis, we design a system for an example of an office workflow using the Business Process Modeling Notation (BPMN), which is a widely used graphical tool for designing business processes. Applications that provide specific business functions are being exposed as Web services. These services are reusable components that can build business processes. In order to facilitate the design of business processes, Business Process Execution Language (BPEL) is used. BPEL is an XML-based workflow language that uses basic and structured activities to describe the logic of a business process. We present and discuss a mapping from BPMN model to BPEL process based on the identification of patterns 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 the differences between these two mapping ways. In this work, we investigate also

4 ii whether or not the design will meet the reconfiguration requirements and discuss the strengths and weaknesses of BPEL in modeling dynamic reconfiguration. We include with a discussion of an alternative design and motivate why we find the alternative less suitable for this project. This thesis has been developed in the context of an international research collaboration on Evaluation of Formalisms for Dynamic Reconfiguration of an Office Workflow: Design, Modeling, Analysis and Implementation among Embedded Systems Engineering Section, DTU Informatics, Technical University of Denmark (DTU) Reconfiguration Interest Group at Newcastle University, Newcastle upon Tyne, UK CRAC Laboratory at École Polytechnique de Montréal, Montréal, Canada Department of Computer Science and System Engineering, Faculty of Engineering (CPS), University of Zaragoza. The joint project focuses on design, modeling, analysis and implementation of an office workflow case study, in particular, on evaluating several well-known formalisms for their suitability for reconfigurable dependable systems. This thesis has mainly accomplished the design and implementation of the case study and its reconfiguration. Preliminary results of the project have been submitted to the 13th International Conference on Coordinating Models and Languages (COORDINATION 2011). The submitted paper is included in Appendix A.

5 Preface This thesis was prepared at Informatics Mathematical Modelling, the Technical University of Denmark in partial fulfillment of the requirements for acquiring the M.Sc. degree in engineering. The thesis deals with using Business Process Modeling Notation (BPMN) design system and implementing the system in Business Process Execution Language (BPEL). The main focus is present a case study involving interference between application activities and reconfiguration activities in a office workflow in terms of BPMN design and implement it in BPEL. This thesis has been developed in the context of an international research collaboration on Evaluation of Formalisms for Dynamic Reconfiguration of an Office Workflow: Design, Modeling, Analysis and Implementation. Lyngby, February 2011 Mu Zhou

6 iv

7 Structure of this Thesis The thesis is structured as shown in Figure 1. Chapter 1 introduces basic concepts of dynamic reconfiguration, workflow, and presents our particular case study. The following chapters start from two points of view addressing the problem: describing the design of a system implementing the workflow in BPMN and implementing the system in BPEL. Chapter 2 explains BPMN in more details and includes a BPMN design for our case study. At the implementation side, Chapter 3 introduces some underlying concepts and technologies about Web services, which is a fundamental background supports for understanding the BPEL language will be introduced in chapter 4 ; all the Chapter 2, 3, 4 are background concepts used to reach two implementation approaches in Chapter 5 and chapter 6. At the end, an alternative BPMN design and its corresponding BPEL implementation is introduced in chapter 7.

8 vi Figure 1: Structure of this thesis

9 Acknowledgements I am thankful to everyone who all supported me to complete my thesis effectively and on time. I am grateful to my supervisor Nicola Dragoni. He gave me support and guided me in different matters regarding the topic. I am deeply grateful for all the comments provided by Henning Christiansen, Kristian Glejboel and Manuel Mazzara. I would also like to thank my family who helped me a lot in everything. Although they are far away in China, they always encouraged me over the phone.

10 viii

11 Contents Summary Preface Structure of this Thesis Acknowledgements i iii v vii 1 Dynamic Reconfiguration of an Office Workflow Office Workflow: Requirements Office Workflow: Dynamic Reconfiguration Business Process Modeling and Notation (BPMN) What is BPMN? BPMN Basics An Example of a Simple BPMN Model BPMN Implementation - Case Study Web Services Web Services Web Services Definition Language (WSDL) XML Schema Data Typing Build a Web Service Business Process Execution Language (BPEL) Composite Services into Business Processes BPEL for Business Process BPEL Core Concepts

12 x CONTENTS 5 Mapping BPMN Models to BPEL Basic Activities Translation Structured Activities Translation Overall Mapping Approach Illustration: an Office Workflow Tool-based Mapping BPMN Models to BPEL Designing and Implementing Process Comparison Between the two Mapping Ways Discussion of an Alternative BPMN Design New BPMN Design Discussion Between Two BPMN Designs BPEL Implementation of the New BPMN Conclusion 91 A Paper Submitted to COORDINATION B Source Codes for the Office Workflow Case Study - generated by manually mapping 111 B.1 WSDLs B.2 BEPL Process for the Old Configuration B.3 BEPL Process for the New Configuration B.4 BEPL Process for the Reconfiguration Transition C Source Codes for the Office Workflow Case Study - generated by tool-based mapping 115 C.1 WSDLs C.2 WSDL for Partner Links C.3 BEPL Process for the Old Configuration C.4 BEPL Process for the New Configuration C.5 BEPL Process for the Reconfiguration Transition D Source Codes for the Office Workflow Case Study (alternative design)- generated by tool-based mapping 119 D.1 WSDLs D.2 WSDL for Partner Links D.3 BEPL Processes for the Old Configuration D.4 BEPL Processes for the New Configuration D.5 BEPL Processes for the Reconfiguration Transition

13 Chapter 1 Dynamic Reconfiguration of an Office Workflow Dependable systems are more and more expected to operate in dynamic environments, to deal with arbitrary changes such as technology changes, the application environment changes, the human need changes and so on. In order to cope with these new demands, system have to evolve continuously, and a reconfiguration process may be applied to rearrange the components of the system. Reconfiguration supports a set of actions such as adding or deleting components, changing links between systems, and modifying component configuration. If the reconfiguration occurs while the system is running, we can say the architecture is dynamically reconfigurable [24]. In this way, the system do not have to be taken off-line or rebooted to adapt the changes that applied to a system through reconfiguration. Traditionally, there are a wide variety of studies based on the software architecture, where the software architecture specifications have been exploited to represent the configuration and connection of system components [23]. There are also many studies focus on runtime dynamic reconfigurations which replaces one configuration by another at runtime. It allows a system to evolve from its current configuration into another at run-time without affecting the system s execution. The paper [20] indicates that hardware reconfiguration is an extensively researched area (e.g., [10] [16]), but little has been done so far for services reconfiguration. Here the service is a well defined interface offer to the clients,

14 2 Dynamic Reconfiguration of an Office Workflow through which some entity can be accessed and be asked to perform a task for the clients. Services are quite dynamic than typical components because they are located, bound, and executed at runtime over the Internet using some standard protocols. Different configurations can be optimized by different services. Since it is relatively easy to create configurations that provide new services and remove configurations that no longer required the providing services, service reconfiguration makes the system more flexible. Dynamic reconfiguration research utilizing web services has primarily focused on two area, the dynamic exchange of one service for another in workflow and the dynamic composition of services using semantics [17]. However such systems have to face problems caused by continually developing new web services and modifying or terminating existing web services. These changes directly affect the system dependability. Dependability is an integrative concept that encompasses availability, reliability, safety, security and maintainability attributes. Dependability of a computing system has been characterized by [11] as is the ability to deliver service that can justifiable be trusted. When we say a computing system is dependable, it means we place reliance on the service that the system delivers, which characterized in terms of system s functionality, availability, safety, security and maintainability and so on. In paper [23] is proposed a framework that can automatically reconfigure participating services at runtime and certify each service to see whether it satisfies the dependability 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 verification of dynamic reconfiguration of dependable services. The problem of interface between old configuration activities, new configuration activities and reconfiguration activities that occurs due to overlapping modes needs to be addressed. Thus this thesis has been developed in the context of an international research collaboration on Evaluation of Formalisms for Dynamic Reconfiguration 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 Execution Language.

15 1.1 Office Workflow: Requirements Office Workflow: Requirements This case study is about a medium-sized organization that handles product orders from existing customers using a series of activities according to the following procedure: when an order is received from a customer, a form including customer identity information and inventory identity information is filled out. Then this form is sent to credit check to evaluate customer identity, and then pass 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 processed and passed on to billing and shipping. The billing procedure will cause the customer be billed for the total cost of all ordered items plus their shipping costs; the shipping procedure will cause the items send to the customer. After that, the order is archived for further reference and a confirmation notification will be sent to the customer. The requirements of the case study given by the paper [9] are listed below. The reason for choosing to use this case study is that it describes a simple but abundant order processing commonly found in a medium-sized organization. 1. Order Receipt: an order for a product is received from a customer. The order includes customer identity and product identity information. 2. Evaluation: the product identity is used to perform an inventory check on the availability of the product. The customer identity is used to perform a credit check on the customer using an external service. If both the checks are positive, the order is processed; otherwise the order is rejected. 3. Rejection: if the order is rejected, a notification of rejection is sent to the customer and the workflow terminates. 4. If the order is processed, the following two activities are performed concurrently: (a) Billing: the customer is billed for the total cost of the products ordered 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 sent to the customer. This is a wholly automated process, which consists of tasks and information in order to proceed an order. We use a simple figure to represent this procedure. (See figure 1.1).

16 4 Dynamic Reconfiguration of an Office Workflow Figure 1.1: The Case Study - an Office Workflow

17 1.2 Office Workflow: Dynamic Reconfiguration 5 As you can see, Figure 1.1 depicts a workflow, which automates a business process during which tasks are communicated among participants according to the procedural rules. We can also represent this workflow specific to web services, where exposing and accessing the functionality of applications as web services (see Figure 1.2). 1.2 Office Workflow: Dynamic Reconfiguration Workflow can be subjected to change because of many reasons, such as new development, administrative decisions (e.g., modification of existing product lines, incorporation of new resources) and so on. These reasons can cause workflow changes by adding a new task, deleting an existing task, making a modification to the order of execution of tasks. Here we suppose that the organization decides to change its order processing procedure by moving the billing step to take place before the shipping step (see Figure 1.3 and Figure 1.4). This change modifies the workflow definition and is introduced to improve an old workflow process. However the problem of interferences between old configuration and new configuration needs to be addressed. The state of an order in the old configuration may not correspond to any state of the order in the new configuration. The safe way to do this change is to stop or abort the work on the ongoing process, and ensure that no work case is in progress when the change is made. It can be done by delaying and not processing any new customer request until after the change and at same time wait until all accepted orders are completed before making the change. Then make adjustments to the workflow and initiate work again. However it is unpractical to delay or abort large numbers of orders because the workflow is being reconfigured. We have to allow overlapping modes for the workflow during its reconfiguration, that is to say that keeping both the old procedure and the new procedure simultaneously available. It must be ensured that the following requirements are met during the transition interval from one procedure to the other [9]: 1. The result of the Evaluation activity for any given order should not be affected 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 according to the new procedure.

18 6 Dynamic Reconfiguration of an Office Workflow Figure 1.2: The Case Study - a Service-based Office Workflow

19 1.2 Office Workflow: Dynamic Reconfiguration 7 Figure 1.3: The Case Study - a New Office Workflow

20 8 Dynamic Reconfiguration of an Office Workflow Figure 1.4: The Case Study - a New Service-based Office Workflow

21 1.2 Office Workflow: Dynamic Reconfiguration 9 In Chapter 2 below we will introduce some basic concepts background on Business Process Modeling Notation (BPMN) and then present a system design of this office workflow case study using BPMN. In order to understand the implementation of the system part, we will give a general introduction to the background of web services in Chapter 3 and explain how to establish a business process using Business Process Execution Language (BPEL) in Chapter 4. In the following Chapter 5 we present a BPEL implementation based on the BPMN design model by using theories of mapping BPMN to BPEL. A toolbased transition will also be provided in Chapter 6. Finally we provide the reader with an alternative BPMN design model for this case study and its corresponding BPEL implementation. The main goal of this thesis is to model and implement this office workflow case study, including the old configuration, the new configuration and the reconfiguration process between two configurations. From this case study, we have found that although BPEL itself has not been designed to cope with dynamic reconfiguration, it presents some features which can be used to this purpose.

22 10 Dynamic Reconfiguration of an Office Workflow

23 Chapter 2 Business Process Modeling and Notation (BPMN) This chapter intends to provide a high-level overview and introduction to Business Process Modeling and Notation (BPMN). A small set of notation categories has been described here so that the reader of a BPMN diagram can easily recognize the basic types of elements and understand the diagram. We also present a design of the workflow case study using BPMN. The choice of using BPMN as a design tool is motivated by its wide adoption as a standard notation for designing and managing business processes. We choose to use Yaoqiang BPMN 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 developed by the Object Management Group (OMG) [2]. It aims to provide a graphical representation for specifying business processes that is readable and understandable by business users. BPMN also provides a mapping to the execution language of BPM Systems (WS-BPEL) that will execute these Business Processes. Business Process Management (BPM) [21] focuses on improving how things are done for the benefit of shareholders, stakeholders and produce

24 12 Business Process Modeling and Notation (BPMN) greatest profits. It requires understanding business processes in order to improve them. The current Wikipedia gives a definition to a Business Process, is a collection of related, structured activities or tasks that produce a specific service or product for a particular customer or customers. So for some companies, if they kick off to address a new challenge, they will start building business process model to illustrate a flow of works and related activities. When it comes to modeling a multifaceted world of work, business process model needs a certain degree of rigors - graphic notations such as box and arrow have to stand for something. That is what the BPMN is about - a modeling notation specification representing business processes for descriptive purposes at a high-level. Once the business analysts create the initial draft of a process, the technical developers will implement the technology to perform this process; and at the end the business users can manage and monitor the process [21]. So we can say that BPMN creates a bridge for the gap between Business Processes design and business processes implementation as well. 2.2 BPMN Basics BPMN defines a Business Process Diagram (BPD), which is a flowchart made up of a set of specialized graphical elements to depict a process [21]. The basic categories of elements of BPD are Flow Objects, Data, Connecting Objects, Swimlanes and Artifacts. Flow Objects They are main graphical elements used to define the Business Process, 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.1 and 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 in the 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 none of 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 the arrival of a due time during a process (intermediate timer event) (see Figure 2.3).

25 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 an indication 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 one path can be taken. There are four kinds of exclusive gateways: a data based exclusive gateway refers to a branching point based on a conditional expression, whereas an event based exclusive gateway

26 14 Business Process Modeling and Notation (BPMN) refers to a branching point based on an event. A merge gateway joins a set of mutually exclusive alternative sequence flows into one sequence flow. An Inclusive gateway represents a branching point where more than one paths can be taken. A Complex gateway is used for handling complex conditions and situations; we do not go into details with this. A Parallel gateway is used to indicate parallel paths. There are two kinds of Parallel gateway: parallel fork gateway and parallel join gateway. We can either create concurrent sequence flows using a parallel fork gateway or synchronize concurrent sequence flows using a 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 what activities are required to be performed and what they produce. Data Input and Data Output provide information about what processes are required to be performed and what they produce. Flow There are four ways of connecting objects: Sequence Flow represents the chronological sequence of process steps. The preceding 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, indicating that the control will be passed down only if the expression is evaluated be true. The source of Sequence Flow can be either Gateway or Activity. Conditional Sequence Flow from an Activity must be drawn with a diamond 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 one outgoing Sequence Flow from the same Activity. Conditional Sequence Flow from a Gateway must be drawn without a diamond marker at the beginning of the connector (see Figure 2.5). The source Gateway must not be of type Parallel or Event.

27 2.2 BPMN Basics 15 Figure 2.6: A Conditional Sequence Flow Default Sequence Flow is taken only if all the other outgoing Sequence Flows from Activity or Gateway (Exclusive, Inclusive or Complex Gateway) 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 Participants, where Participants are represented as two separate Pools (see Figure 2.8). Figure 2.8: Message Flow Association used to link information such as data object with BPMN graphical elements using a dotted single line. Data Association used to show input and output of Data Object to Activity, which uses the same notation for Association. Swimlanes A swimlane is used to organize activities into separate visual categories so as to illustrate different functional responsibilities. It can be used to show how different entities interact. There are two ways of grouping the elements through Swimlanes: A Lane is a sub-partition within a process. Activities in the process can be organized and categorized by using Lanes. They are often used for internal roles (e.g., Manager), an internal department (e.g., shipping). It is a square-corner rectangle that be drawn with a solid single line (see Figure 2.9). A Pool represents a Participant in a Collaboration. It can be a partner entity (e.g., a company) or partner role (e.g., a seller, or a customer). It

28 16 Business Process Modeling and Notation (BPMN) Figure 2.9: Lanes is drawn with a solid single line to a square-cornered rectangle (see Figure 2.10). Figure 2.10: Pool Artifact Artifact is used to provide additional information of a Business Processes to the reader, we do not go into details with this. More information refers 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 model based on the graphical specifications introduced in section 2.2. The scenario is about a hotel booking process: a hotel agent receives a hotel room reservation request from a customer; then the agent checks whether a hotel room is available or not; finally based on the checking result, either reject the reservation request if the room is unavailable or confirm the request if the room is available (see Figure 2.11).

29 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 request message from a customer, and then it goes to a Task for checking the availability of a hotel room; finally follows a Exclusive Gateway, the process branches to either Confirm Reservation or Reject Reservation (both are Task activities). Both branches lead to the same End Event at the end.

30 18 Business Process Modeling and Notation (BPMN) 2.4 BPMN Implementation - Case Study In this section, we will start to present a design of the office workflow case study introduced in Chapter 1.1 by using all the notations and concepts of BPMN that we have learnt so far. This office workflow can be seen as several Participants working together to process orders from customers (see figure 2.12). It employs several Pools to represent different functional entities (Order Generator; Credit Check; Inventory Check, Bill&Ship, Archive). It is worth noting that the imposed requirements state that only the Credit Check service is supposed to be external. Thus each other service might be included in a lane of a single pool, representing a activity within the organization. Here we decided to design a more generic situation where the different services are offered by external entities by adopting a pool for each service. Each Participant has their own process, by using Message Flow to communicate with each other. Assume that all the processes are asynchronous, the processes will not stop and wait for any participate s reply. All the processes start by a Start Message Event, in other words, the Processes are triggered by receiving a message. Office Workflow pool is the coordinating entity, starts by receiving a request message from a customer. Then an order is created by calling the Order Generator entity. The process happens within Order Generator pool starts by receiving the order request message through Message Flow from Office Workflow; then executes Make Order Task; finally sends an order back to Office Workflow pool. Once Message Intermediate Event within Office Workflow pool receives the order, this order is then sent to both the credit check handler (Credit Check pool) to check the customer credit s availability and the inventory check handler (Inventory Check pool) to verify the availability of the product. The latter is performed only in case the credit check is successful. Same as process happens in Credit Check pool: gets an order from Office Workflow pool; then executes the evaluation Task to check the customer credit s availability; finally uses Send Task to send an evaluation result to Office Workflow pool. After receiving the evaluation result, an Exclusive Data-Based Gateway has been used. In case of a negative reply from Credit Check pool, a notification is sent to the customer, the order is rejected and the overall workflow terminates. Otherwise the order is sent to Inventory Check pool. We do the same with the result from Inventory Check by means of an Exclusive Data-Based Gateway. In case of a negative reply, 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 responsible for 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

31 2.4 BPMN Implementation - Case Study 19 negative result. When Bill&Ship pool receives the order, the two activities are called concurrently by a Parallel Gateway. The same gateway is used to merge the result from Bill lane and Ship lane. A message containing the bill and ship details is sent to Office Workflow pool to calls the Archive pool for storing the order. Office Workflow process terminates by receiving a response from Archive pool and sending a confirmation notification to the customer. Now the company decides to do the reconfiguration of the order of billing and shipping activities: moving the billing activity to take place before the shipping activity and keeping both the old configuration process and new configuration process simultaneously available. So our concern is to make structural changes safely without flushing the system. Look at the design we have presented so far, it should be quite easy to realize that this reconfiguration require a change in the main lane of Bill&Ship only, where the billing and shipping activities are called, while the rest of the workflow remains the same. The new configuration BPMN diagram is shown in Figure Comparing to the old configuration BPMN diagram in Figure 2.12, the two Parallel Gateways in the main lane of Bill&Ship have been removed and the two activities are called synchronously now. How can the transition from the old configuration (Figure 2.12) to the new configuration (Figure 2.13) be done? The BPMN model for the overall workflow during its reconfiguration transformation is shown in Figure In order to keep both the old configuration process and the new configuration process simultaneously available, we define a default flow that is identical to the old configuration. This default flow can be altered through an interrupting Message Event contained in Determine configuration activity included in a separate Reconfig.region pool. This activity determines which configuration should be used when Bill&Ship is called. In this way, we highlight that an authority is in charge of deciding the reconfiguration. Thus, if the interrupt event happens, it will affect the flow activating the new configuration instead of the old one.

32 20 Business Process Modeling and Notation (BPMN) Figure 2.12: The Case Study Workflow - Old Configuration BPMN Model

33 2.4 BPMN Implementation - Case Study 21 Figure 2.13: The Case Study Workflow - New Configuration BPMN Model

34 22 Business Process Modeling and Notation (BPMN) Figure 2.14: The Case Study Workflow - Configuration Transition BPMN Model

35 Chapter 3 Web Services This chapter is not intended to as a complete introduction to Web Service technologies but as an overview of what Web Service is; what WSDL is; how a WSDL document is formed and how to create a web service from its WSDL document. The motivation of introducing Web Service technologies here is to help the readers to understand Business Process Execution Language (BPEL) in the next Chapter 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 messaging system (XML-RPC, SOAP or HTTP POST/GET) and has universal interoperability between applications running on disparate platforms that using different operating systems and programming languages. There are three major roles within the Web Service architecture: service provider which implements the service and makes it available on the Internet; service requestor which is a consumer of the web service; service registry which is a centralized registry of services. When developers build a web service, normally they use XML to expose resources on the platform regardless which operation

36 24 Web Services systems or programming languages they are using. XML messaging is responsible for encoding messages in a XML format, there are two common XML messaging systems: XML-RPC (XML Remote Procedure Call) [13] and SOAP (Simple Object Access Protocol) [13], which enables web services to exchange complex information using a standardized XML messaging format. Consumers are able to access the resources by simply transmitting XML messages over protocols 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 integrate the service. WSDL (Web Services Description Language) [4] is been used to specify such a public interface for web service. There may also be a mechanism for developers to publish a web service or find other services and locate their public interfaces. Currently such a kind of service discovery is handled via UDDI (Universal Description Discovery and Integration) [8]. Operation in web services are based on exchange XML-formatted collections of input, output and fault messages. There are four types of operation: one-way, request and response, solicit response, notification. Web services can provide support for both asynchronous and synchronous interactions. 3.2 Web Services Definition Language (WSDL) The Web Service Definition Language (WSDL) is a specification of using XML grammar to describe web services. Web services self-describe their interaction points and the associated data requirements as service interfaces in a WSDL document [17]. This allows the developers to build and consume services in an interoperable way. WSDL can be treated as a contract between the service requestor and the service provider. A complete WSDL definition contains all the information necessary to invoke a web service, which can be broken down into 6 main elements: definitions, types, message, porttype, binding and service (see Table 3.1). WSDL Definition specifies the name of WSDL document and numerous namespaces that will be used throughout the document. The use of namespaces enables the document to reference multiple external specifications, for instance WSDL specification, XML Schema specification. It also specifies a targetnamespace attribute, which enables WSDL document to refer to itself. The basic structure is as follows:

37 3.2 Web Services Definition Language (WSDL) 25 Element Name Definitions Type Message porttype Binding Service Description The root element of WSDL documents. It defines the name of web service, namespaces and all the service elements. Describes abstract data types used for all message requests and message responses; defined by XML Schema. Describes abstract messages that are used from operations within service; may consists of multiple parts. Describes interface information: the abstract operations that are available within service. Describes a concrete transport protocol is used for a particular porttype. Describes a concrete connection details for locating a 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. The basic structure of type element is as follows: <defintions..> <types> <xsd:schema targetnamespace=""/> </types> </definitions> WSDL Messages can be used from operations within the service. Each defined message describes the names and types of its parameters. Messages consist of one or more part elements, where each part is associated with either an element or a type. The basic structure is as follows: <defintions..> <message name=""> <part name="" element=""/> </message> </definitions>

38 26 Web Services WSDL port Types defines a group of operations that are available from service. For each operation, we describe the name of operation, and the names and 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 One-Way Request/Response Notification Solicit/Response Description The service endpoint receives a message. The operation has a single input element. The service endpoint receives a message and sends a response. The operation has one input element followed by one output element; an fault element can also be specified. The service sends a message to a client. The operation has a single output element. The service sends a message and receives a response from the client. The operation has one output element followed by one 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 over the Internet. Binding can be made available via multiple transports, such as HTTP GET, HTTP POST or SOAP. The basic structure is as follows: <definitions..> <binding name="" type=""> <soap: binding style="" transport=""/> <wsdl:operation name="">

39 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, in other word, service element specifies the location of service. The basic structure is 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 the service or automatically invoke the service via a WSDL invocation tool. In order for a client to communicate effectively with a server, both of them must agree on a data type format that they are using. WSDL uses W3C XML Schema specification [5] as a default, which is also the most widely used specification for data type currently. It includes a list of build-in simple types, including string, integers, doubles, time and so on. The XML Schema specification also provides a facility for creating new data types. When the service you build goes beyond simple XML Schema data types, you can create new data types; and declare these new data types within WSDL type element.

40 28 Web Services 3.4 Build a Web Service There are two ways to create a web service, either starting from Java code or from a WSDL document. If you are developing your Java web service you wish to expose it as a web service, the most direct approach is to create policy assertions needed to enable emphwsit technologies [7]. If you want to implement a web service that is already defined by WSDL document, the JAX-WS wsiomport tool will process this WSDL document. Comparing to the process starting from Java, this process is much simpler. Many tools provide the functionality of building web services from WSDL documents and then deploy and test, such as NetBeans, Axis and Oracle.

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

42 30 Business Process Execution Language (BPEL) 4.1 Composite Services into Business Processes In business processes, services have been defined as business functionalities that can provide business values, such as a service for a business booking production. Composition of services provides the support to business processes by following a set of rules. Business processes are defined as a collection of coordinated service invocations and related activities that produce a business result, either within a single organization or across several [19]. For example, a business process for processing orders from the customers in an organization, it needs invoke serval web services in order to process the order request successfully. From the perspective of business processes, we do not care about the implementation of each web service; we do not care whether the process is implemented through composition of other services or not neither. We see the process the same as the other services. 4.2 BPEL for Business Process BPEL is an XML-based execution environment intended to make a business process definition to a document-centric business process [6]. The core of BPEL is BPEL process. When we define a BPEL process, we actually define a new web service that is a composition of some existing web services. The interface of the new BPEL composite web service uses a set of port types, through which provide operations. Steps executing in a BPEL process are called activities, and the BPEL process definition should consist of at least one activity. BPEL can easily invoke web services operations either synchronously or asynchronously; either in sequence or in parallel. The typical scenario of a BPEL business process is: receives a request; then invokes involved web services and finally responds to the client. Deploying a BPEL process results in a service for that process being published. Let s take an example - a simple business process for booking a hotel room. In an oversimplified scenario: the client invokes the business process, specifying the name of the customer, the date to check-in and the room requests. The BPEL business process invokes a external web service to check the hotel room status and price. Finally, the BPEL process will send a reply to the client. The structure of services composed into the business process can represent visually using a BEPL diagram (See Figure 4.1). The BPEL diagram is the design view of a BPEL process, on the diagram we can author the business process by adding and configuring activities by hand.

43 4.2 BPEL for Business Process 31 Figure 4.1: The Hotel Reservation Scenario - BPEL Diagram

44 32 Business Process Execution Language (BPEL) The diagram contains some common irons representing different activities of the business process (See Figure 4.2). Figure 4.2: BPEL Diagram Irons 4.3 BPEL Core Concepts Invoking Web Service Before we start writing the BPEL process definition, we have to get familiar with all web services invoked from our business process, these services called partner web services. In our example, only one web service is involved: the Hotel web service. The description of this web service is available through its WSDL, 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 the availability of a hotel room using the bookhotel operation. This operation

45 4.3 BPEL Core Concepts 33 will return the room status: available or unavailable; and also the room price. The architecture of this web service is schematically shown in Figure 4.3. Figure 4.3: The Hotel Web Service Architecture Web service for the BPEL process: The business hotel reservation BPEL process is exposed as a web service as well. We also need to define a WSDL for 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 start the process and get the reply. We define the BookPortType with the book operation. The architecture is shown in Figure 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 external parties. The web services invoked by the BPEL process and the client invokes the BPEL process are associated with partner links. In our example, we have two partners: the client and the hotel service. Each web service should define the corresponding partner link types in their WSDL [6]. BookLT :This is used to describe the interaction between the BPEL process client and the BPEL process itself. This interaction is synchronous. The partner link type is defined in the BPEL process WSDL.

46 34 Business Process Execution Language (BPEL) Figure 4.4: The Client Web Service Architecture HotelLT :This is used to describe the interaction between the BPEL process and the Hotel web service. This interaction is also synchronous. The partner link type is defined in the hotel web service WSDL. Each partner link type can have one or two roles, which are myrole indicates the 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 for communicating over the partnerlink. For our example, both the bookoperation and the bookhoteloperation are synchronous, so there is a single role for both partner link types. The client invokes the book operation on the BPEL process and waits to get a response only after the operation completes. If this operation is an asynchronous callback operation, we have to specify two roles: one role describes the invocation of the book operation by the client; the other role describes the invocation of a callback operation. This callback operation would be invoked by BPEL process and would call the client to return the result. The client uses the BookPortType port type to communicate with the BPEL process. The interaction is synchronous, so we use a single role called bookserviceprovider.... <plnk:partnerlinktype name="booklt"> <plnk:role name="bookserviceprovider" porttype="tns:bookporttype"/> </plnk:partnerlinktype>...

47 4.3 BPEL Core Concepts Business Process Definition A BPEL business process definition specifies the order of activities that have to be performed [19]. Firstly it waits for an incoming message to start the business process; then waits for a series of activities occur, either in sequence or in parallel. In our example: the client initiates the BPEL process through sending an input message: bookrequest. Then BPEL process invokes the Hotel web service by sending the bookhotelrequst message. Because this is a synchronous invocation, the process will wait for the bookhotelresponse message. Finally the 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 where the 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 the client first invokes the BPEL process. Parter link type declares how two parties interact and what each party offers. partnerlink definitions are nested within the partnerlinks element. In our example, the client partner link is BookClient:... <partnerlinks> <partnerlink name="bookclient" partnerlinktype="tns:booklt" myrole="bookserviceprovider"/>...

48 36 Business Process Execution Language (BPEL) The other partner link is called Hotel and characterized by the HotelLT partner link 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, we describe 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 variable for every message send to the partners and receive from the partners. In our example, we define four variables: BookIn, BookOut, BookHotelIn, BookHotelOut. For each variable we have to specify the type. We use an XML schema element here.... <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 have a top-level sequence element that allows us to define several activities that will be performed sequentially. To invoke the web services in parallel, we can use flow construct. Within the sequence, the process will wait for the first incoming message to start the business process, which is modeled within receive construct. In our example, the first incoming message is BookRequest message. Within the receive construct, we specify the partner link, the port type, the operation name and 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 published when the process is deployed. The top receive activity ReceiveBookRequest

49 4.3 BPEL Core Concepts 37 acts as the starting point for a new process execution. So when the customer invokes the order operation, it will cause a new process execution to start by leaving the initial receive activity. Next we need to invoke the Hotel web service. Before this, we have to prepare the input for this web service. We can construct a bookhotelrequest message by copying in part of the message sent by the client. We write the corresponding assignment 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 by using invoke activity. We have prepared the input message in the BookHotelIn variable, 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, which stores the message will finally return to the client <assign name="assign2"> <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 reply to the client using rely activity. We specify the same partner link, the same port type and operation name as in the initial receive client. The variable that holds the reply message is BookOut:

50 38 Business Process Execution Language (BPEL)... <reply name="replyclient" partnerlink="bookclient" operation="book" porttype="ns0:bookporttype" variable="bookout"/> </sequence> </process> Advanced BPEL Features In this subsection, we will look at some advanced BPEL features which will be used 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 uses while activity to support the loop. It repeats the enclosed activities until the defined Boolean condition no longer holds true. Let us consider a scenario that if we want to check the availability of a hotel room for a travel group (one than one 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; the other one is a counter using in a loop. Then we initialize both variables with static 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> <!-- Invoke the web service --> <invoke name="invokehotel" partnerlink="hotel" operation="bookhotel"

51 4.3 BPEL Core Concepts 39 porttype="ns1:hotelporttype" inputvariable="bookhotelin" outputvariable="bookhotelout"/>... <!-- Process the results... -->... <!-- Increment the counter --> <assign> <copy> <from $Counter+ 1/> <to variable="counter"/> </copy> </assign> </sequence> </while> Scope In order to divide a complex business process into hierarchically organized parts, scope has been introduced. Scope provides a way to declare variables that are only visible within the scope and allows to define the local fault handlers, the compensation handlers and the event handlers [19]. Each scope has a primary activity, which can be a basic activity invoke or it can be a structured activity using sequence or flow tag. The code excerpt below shows how scopes are defined in BPEL. <scope> <variables> <!-- Variables definitions local to scope --> </variables> <faulthandlers> <!-- Fault handlers local to scope --> </faulthandlers> <compensationhandler> <!-- Compensation handlers will be discussed later in this chapter --> </compensationhandler> <eventhandlers> <!-- Event handlers will be discussed later in this chapter --> </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 port type; alarm events - are triggered by a specified time. Pick activity in BPEL specifies that the business process waits the occurrence of events [19]. Those

52 40 Business Process Execution Language (BPEL) events can be either message events or alarm events. For each event we need to specify 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 same attributes. Event Handlers While a business process executes, we still want to react on some events and handle them whenever they occur, we can use the event handlers. If the corresponding event happens, event handler is invoked concurrently with the running business process. Event handlers can also be used for each scope. It starts when the associated scope starts. Fault handlers BPEL business processes need to handle faults caused by the unreliable communication between web services; logic errors; execution errors arising from the defects in the infrastructure of web services, etc. So fault handler has been used. BPEL business processes can signal faults themselves using throw activity. The syntax is shown below: <throw faultname="name"/> Within a fault handler, the business process defines customer activities that are used to recover from the fault and recover the unsuccessful work of the activity where the fault has happened [19]. catch activities specify the faults that we would like to catch and handle. catchall activities can be used to handle all other faults. Termination Handlers BPEL provides a termination handler activity to provide code to be executed when a BPEL process is unexpectedly exited. It must be applied to scope within a process. The syntax is shown below:

53 4.3 BPEL Core Concepts 41 <scope> <terminationhandler> <!--perform activities necessary after unexpected exit--> </terminationhandler> <!--scope activities--> </scope> Correlation When the client starts a business process, a new process instance is created and lives for the lifetime of the business process. If there are multiple business process instances active at the same time, we have to make sure that all messages that are send to the business process are delivered to the correct business process instance. So the relationship between a message and its corresponding process instance needs to be maintained. BPEL provides a mechanism to use specific business data such as order ID, flight number, etc to maintain reference to specific business process instances called correlation [19]. Such business data used for correlation is contained in the message exchanged between partners. A correlation set is a collection of one or more properties shared by messages, which is used to determine whether a message correlates with a process instance. Each correlation set has a name and a message can be related to a set of correlation sets. The initial message is used to initialize the value of a correlation set; the following messages related to this correlation set must have the same property values as the initial correlation set [19]. The syntax is shown as: <correlationsets> <correlationset name=" " properties=" "/> </correlationsets> Going back to our Hotel Reservation example, we can define a correlation set named 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. We use the correlation activity to specify which correlation set is used. The syntax is:

54 42 Business Process Execution Language (BPEL) <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 correlation set; join means the related activity try to initiate the correlate set if it is not initiated; no means the related activity not initiate the correlation set Hotel Reservation Example - BPEL code The whole BPEL code of Hotel Reservation Process is showing here, which includes also loop activity introduced before. <?xml version="1.0" encoding="utf-8"?> <process name="bookhotel" targetnamespace=" <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" partnerlink="bookclient" operation="book" porttype="tns:bookporttype" variable="bookin"/> <while name="while1"> <condition>$counter > $NoOfClients</condition> <sequence>

55 4.3 BPEL Core Concepts 43 <assign name="assign1"> <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> <invoke name="invokehotel" partnerlink="hotel" operation="bookhotel" porttype="tns:hotelporttype" inputvariable="bookhotelin" outputvariable="bookhotelout"/> <assign name="assign2"> <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" partnerlink="bookclient" operation="book" porttype="tns:bookporttype" variable="bookout"/> <assign> <copy> <from>$counter + 1 </from> <to variable="counter"/> </copy> </assign> </sequence> </while> </sequence> </process>

56 44 Business Process Execution Language (BPEL)

57 Chapter 5 Mapping BPMN Models to BPEL This chapter covers a mapping of a BPMN model to a BPEL process by analyzing and illustrating the existing a transformation approach. The first problem we have encountered when mapping the BPMN design into a BPEL implementation comes from the evident observation that BPMN and BPEL are representative of two different classes of languages. BPMN is graph oriented while BPEL is mainly block-structured [14], at least in its commonly used XLANG [22] derived subset (however, BPEL has been also influenced by the graph oriented WSFL [15]). A consequence of this divergence is that the mapping from BPMN to BPEL is hard and it has a number of limitations since BPMN 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 BPEL process is too limited for modeling purposes. However, we believe that BPEL cannot be ignored when it comes to workflow modeling because, although the business analysts more easily work with BPMN as modeling language and use its graphical notation to describe a business process (Task, Activity, Sequence flow, etc), the system developers manage better to work with an executable language like BPEL to define the composite structure of a business process. In BPEL such a structure is defined in terms of a flow of structured activities (Sequence, Parallel, etc) where each activity, in turn, can

58 46 Mapping BPMN Models to BPEL contain a nested list of other activities being those web service invocations or other structured activities. In this work the structure mismatch between BPMN and BPEL has been resolved following the approach presented in [14] consisting of a complete translation based on the identification of patterns of BPMN fragments which can be directly mapped onto BPEL code. The transformation approach will be described in the following of this chapter where we will give an overview of our mapping and how it is intended to work for the case study in Chapter 1.2 we are 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 can be realized through web services interaction. This section relates BPEL basic activities to the corresponding constructs in BPMN. BPMN basic activities (the ones based on messages, events and assignments) can be directly mapped to BPEL according to the following translation schema in Table 5.1: BPMN Send Task, Service Task, Message Event Receive Task, Message Event Send Task, Message Event Assignment Termination end event BPEL Invoke Receive Reply Assign Exit Table 5.1: Basic Activities Translation Schema In the previous chapter, we introduced the concept of Partner Links in BPEL to model a relationship between the interacting business processes. Each participant plays a role in this relationship and the Port Types used to receive the message from the partner. The BPMN model introduces Send, Receive, Service Task, and Message Intermediate Events to deal with the message-based interactions, where an asynchronous invoke activity corresponds to a Send Task or a Message Intermediate Event [21]. Send Task, Service Task, Message Event The partner link of the BPEL invoke activity is derived from the interface referenced by the operation of the Send Task, Service Task or Message Event (see Figure 5.1).

59 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 activity is derived from the interface referenced by the operation of the Receive Task or Message Event (see Figure 5.3). Figure 5.2: Receive Task and Message Event <receive name="task name" createinstance="instantiate? yes : no " partnerlink="task operation interface" porttype="task operation interface" operation="task operation"> </receive>

60 48 Mapping BPMN Models to BPEL In BPMN model, a process is instantiated when one of its Start Events occurs. Subsequence Start Events will share the same correlation information as the Start Event that creates the process instance [21]. In general, the BPEL processes are always instantiated through a single message, received by the receive activity or by the pick activity. They have been configured for instantiation via a boolean attribute createinstance. If Receive Task instantiates a process, we set yes to the createinstance attribute of the BPEL receive activity; otherwise set no. Send Task, Message Event The partner link of the BPEL reply activity is derived from the interface referenced by the operation of the Send Task or Message Event (see Figure 5.3). Figure 5.3: Receive Task and Message Event <reply name="task name" partnerlink="task operation interface" 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. The variable for each Data Object is added in the corresponding BPEL variables section [21] (see Figure 5.4). <varaible name="data object name" type="structuredefinition"/> Termination End Event A Termination End Event is mapped to the exit activity in BPEL as shown in the following Figure 5.5: <exit> </exit>

61 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 patterns resembling BPEL structured activities - sequence, flow, switch, pick and while. These structured activities are the block-oriented parts of BPEL. The translation to the corresponding constructs in BPMN is sketched in Table 5.2. Components that can be suitably mapped onto any of these five structured constructs are identified as well-structured patterns[14]. BPMN Sequence Flow Parallel Fork-Join Gateway Exclusive Data-based Gateway Exclusive Event-based gateway, Message/Timer Event Loops BPEL Sequence Flow Switch Pick While, RepeatUntil Table 5.2: Structured Activities Translation Schema Sequence Pattern A BPMN component consisting of activities connected by Sequence Flow (see Figure 5.6) is mapped to the BPEL sequence activity:

62 50 Mapping BPMN Models to BPEL Figure 5.6: Sequence Flow <sequence> Task1 Task2 Task3 </sequence> Flow Pattern A parallel fork-join pattern (see Figure 5.7) is mapped to the 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) is mapped as the switch or if-else activity in BPEL as follows; it can generalized to n branches in the same manner.

63 5.2 Structured Activities Translation 51 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 mapped into the pick activity in BPEL as follows. This figure only shows two branches with one Message Intermediate Event and one Receive Task, in reality this mapping can generalized to n branches with any combination of the Receive Task, the Intermediate Message or the Timer Event. <pick> <onmessage name="message1"> <invoke name="task1"/> </onmessage>... <onmessage name="message2"> <invoke name="task2"/>

64 52 Mapping BPMN Models to BPEL </onmessage>... </pick> Figure 5.9: Exclusive Event-based Gateway While Pattern A while loop in BPMN (see Figure 5.10) is mapped to the while activity in BPEL as shown. It evaluates the loop condition before the 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 the repeatuntil activity in BPEL. In a repeat loop, the condition is checked

65 5.2 Structured Activities Translation 53 after the body of the loop is executed, so the loop is always executed at least once. Figure 5.11: Repeat Loop <repeatuntil> Task <condition> not p </condition> </repeatuntil> Embedded Sub-Process An embedded Sub-process (see Figure 5.12) can be 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 (see Figure 5.13) can be mapped to the event handlers activity in BPEL as follows:

66 54 Mapping BPMN Models to BPEL Figure 5.13: Event Sub-Processes <eventhandlers> <onevent partnerlink="message operation interface" operation="message operation"> </onevent> <\eventhandlers> 5.3 Overall Mapping Approach Illustration: an Office Workflow In this section, we will transform the BPMN design of the office workflow case study 1 to a BPEL process. The idea is to identify the occurrences of the basic activities and the structured activities which we have introduced before and generate the corresponding BPEL code. And then find out each component matched by the well-structured patterns and fold the component into a single task of the BPMN diagram. Repeating these steps until no pattern is left in the BPMN diagram. Let s consider the old configuration of the office workflow shown in Figure As the reader can see, the BPMN design is made up of a set of independent components, 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 the specific service calls involved, i.e. it includes the interactions points between the different participants. There are actually six participants involved (implemented as asynchronous web services). 1 see Chapter 1-2: Office Workflow: Requirements.

67 5.3 Overall Mapping Approach Illustration: an Office Workflow 55 This office workflow can be seen as a Office Workflow process interacts with participants Order Generator, Credit Check, Inventory Check, Bill&Ship and Archive via message flows. Figure 5.14: BPMN Participants The resulting BPEL process is mapped as: <process name="officeworkflow"> targetnamespece="" expressionlanguage=""

68 56 Mapping BPMN Models to BPEL suppressjoinfailure="yes" xmlns=" "> <partnerlinks>... </partnerlinks> <varaibles>... </varaibles> <correctionsets>... </correctionsets>... </process> Now Let s look at each part of the BPEL process Partner Link The partner links of the BPEL process are derived from the interfaces associated with each participant [21] (see Table 5.3). The interface defines the operations that are implemented by services, which can be mapped to WSDL port types and operations. BPMN Participant Interface Participant= Interface= Operation= inmessageref= outmessageref= errorref= WSDL properties patnerlink= porttype= operation= input message= output message= fault name= Table 5.3: Partner Link Translation Now we start to define the interface for each participants. There are six participants involved, which are implemented as asynchronous web services as shown in Table 5.4. WSDL requires the specification of operations and port types the service is offering, the accepted messages and their types. Consequently, a precise WSDL descriptions of the involved services can be derived from the table above. We now present in detail the WSDL description for each of the six processes.

69 5.3 Overall Mapping Approach Illustration: an Office Workflow 57 Participant Interface Operation inmessageref Office Workflow OrderReceiptPortType OrderReceipt OrderRequest NotificationPortType Confirm Confirm Reject Reject Order Generator OrderGeneratorPortType OrderGenerator OrderGeneratorRequest OrderGeneratorReplyPortType OrderGeneratorReply Order Credit Check CreditCheckPortType CreditCheck Customer CreditCheckReplyPortType CreditCheckReply CheckResult Inventory Check InventoryCheckPortType InventoryCheck Item InventoryCheckReplyPortType InventoryCheckReply CheckResult Bill Ship BillShipPortType BillShip Order Bill Order Ship Order BillShipReplyPortType BillShipReply BillingAndShipping BillReply Billing ShipReply Shipping Archive ArchivePortType Archive ArchiveItem ArchiveReplyPortType ArchiveReply ACK Table 5.4: Participants Interface Definitions

70 58 Mapping BPMN Models to BPEL Office Workflow: OrderReceiptPortType allows the order message to be received by means of the OrderReceipt operation. To return the result, the Web service specifies a second port type: NotifyPortType. This port type specifies Confirm and Reject operations to return notification messages back 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 order code by means of the OrderGenerator operation. The result is returned through 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 the customer with the operation CreditCheck. CreditCheckReplyPortType is instead 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>

71 5.3 Overall Mapping Approach Illustration: an Office Workflow 59 <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 the operation InventoryCheck. InventoryCheckReplyPortType is instead used to 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 activity through the operation BillShip. The bill activity is performed using the operation Bill and the ship activity is performed using the operation Ship. To return the result, the service specifies a second port type: BillShipReplyPortType. The bill details are returned through the operation BillReply while the ship details are returned through the operation ShipReply. The overall bill and ship details are returned through the operation 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"/>

72 60 Mapping BPMN Models to BPEL </wsdl:operation> <wsdl:operation name="shipreply"> <wsdl:input message="shipping" name="input"/> </wsdl:operation> </wsdl:porttype> Archive: ArchivePortType allows archiving the ordered product for further reference using the operation Archive. ArchiveReplyPortType is specified to 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 link with a myrole specification; the interfaces of other participants are mapped to the BPEL partner links with a partnerrole specification. Because all the web services are asynchronous, we should define two roles for each partner link. To make all the services working together BPEL requires the definition of a partnerlink 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"/>

73 5.3 Overall Mapping Approach Illustration: an Office Workflow 61 <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 Workflow are linked to the main BPEL process of the workflow itself Variables Variables defined in BPEL process are created from Properties associated with a process in BPMN [21]. Take Office Workflow Process as an example, we define its properties in Table 5.5. Property WSDL message BPEL variable Name= CustomerRequest name= CustomerRequest name= CustomerRequest messagetype= OfficeWorkflow: OrderReceipt Type= structure Map to WSDL message elements Sub-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"

74 62 Mapping BPMN Models to BPEL 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> Correlation Sets The correlation sets of the BPEL process are derived from the Correlation Keys of the set of message flows. The mapping of the key-based Correlation Key is as 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 OrderGeneratorReply operation, the incoming message triggers the process execution to continue by leaving the receive activity. This shows correlation. It means the matching of incoming service request messages with existing process executions that are

75 5.3 Overall Mapping Approach Illustration: an Office Workflow 63 waiting for such an incoming message. If a receive activity is set as initiate, the incoming messages on that operation will lead to the creation of a new process execution. An unique correlation id is also needed to identify the incoming messages for the receive activity later in the process Office Workflow BPEL Main Body The main process describing the workflow starts with the reception of an order request coming from a customer, then it asynchronously invokes Order Generator and, after having received a reply from it, Credit Check is asynchronously invoked. It continues asynchronously invoking different services one by one, according to the specification. Two structure patterns can be identified: the sequence pattern involving the whole process and the If-else pattern for handling both the credit check reply and the inventory check reply. The BPMN Message Start Event initiates the process receiving a message. This is mapped into 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 through the 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>

76 64 Mapping BPMN Models to BPEL <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 asynchronous service, the callback will be received using the BPEL receive activity. We have to invoke the OrderGeneratorReply operation on the OrderGeneratorReplyPort- Type. The callback message contains a Order number (OrderID) which is used to 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 customer identity. Mapping the call of the Credit Check service is similar to mapping the Order Generator service. Again, we start with the preparation of the input message 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>

77 5.3 Overall Mapping Approach Illustration: an Office Workflow 65 <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 message event is mapped into a BPEL If-else structured activity: <if name="if1"> <condition>$creditcheckresult.part</condition> <sequence name="sequence1">... </if> </sequence> <else>... </else> The Inventory Check works exactly in the same way as the Credit Check. The BPMN process then moves to Receive item check result, it goes through the Yes condition and the BillShip operation is invoked on the BillShipPortType of the Bill And Ship service. At this point, two operations bill and ship are invoked in parallel. We can draw the Bill&Ship pool as shown in Figure 5.15.

78 66 Mapping BPMN Models to BPEL Figure 5.15: Bill&Ship BPD Then we map this new diagram onto a BPEL process by following the approach given in [14]. The translation procedure is sketched in four steps showing in Figure Figure 5.16: Bill&Ship Translation Procedure - Step1 Each component is named C i where i specifies in what order the components are processed, and C i is folded into a task object named T Ci. Here four components are identified. C 3 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"/>

79 5.3 Overall Mapping Approach Illustration: an Office Workflow 67 Figure 5.16: Bill&Ship Translation Procedure - Step2 Figure 5.16: Bill&Ship Translation Procedure - Step3 Figure 5.16: Bill&Ship Translation Procedure - Step4

80 68 Mapping BPMN Models to BPEL <flow name="tc3"> <sequence name="tc1"> <invoke name="callbill"/> <receive name="receivebilldetails"/> </sequence> <sequence name="tc2"> <invoke name="callship"/> <receive name="receiveshipdetails"/> </sequence> </flow> </sequence> Both bill and ship return their details by means of the operation BillShipReply and then the Archive service is invoked. After having received the return message ACK from ArchiveReplyPortType an invoke activity on NotifyPortType is performed to send a confirmation message back to the customer. <invoke name="notifycustomerconfirm" partnerlink="officeworkflow" operation="confirm" porttype="officeworkflow:notifyporttype" inputvariable="confirmnotify"/> Change Configuration To implement in BPEL the BPMN model depicted in Figure 2.13 we have just to replace Bill&Ship. So we need to define a new interface for it and then map it onto a new partner link. We have to do the same as before and finally we get a new Bill&Ship. This is also an asynchronous process, containing both the invocation 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 pattern is now involved: Sequence. After the BillShip operation is invoked on BillShip-

81 5.3 Overall Mapping Approach Illustration: an Office Workflow 69 PortType of the Bill And Ship service, the Bill operation is invoked. Then, the return message from BillReplyPortType is received and the Ship operation is invoked. Ship details are returned by the operation ShipReply and the return message sent from BillShipReplyPortType is received. Finally, the Archive service is invoked. <sequence name="sequence3"> <assign name="callbill"> <copy>... </copy> </assign> <invoke inputvariable="billshiporder" operation="bill" partnerlink="billandship2" porttype="billship2:billshipporttype"/> <receive createinstance="yes" partnerlink="billandship2" 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" partnerlink="billandship2" 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>

82 70 Mapping BPMN Models to BPEL Transition between Configurations The most interesting part of the BPMN design is the one depicted in Figure To map this to BPEL we have to define a new partner link for a new participant Reconf.Region which will be then used to invoke the new configuration. We define 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 with a Non-Interrupting Intermediate Message Event, which can be mapped to a BPEL 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 Rec change message once the OldConfigScope scope has been entered, it will terminate the current process and execute the new process defined within the scope

83 5.3 Overall Mapping Approach Illustration: an Office Workflow 71 NewConfigScope in the termination handler. This other process is exactly the new configuration. Otherwise, the order will be enter to BillAndShip1 scope and be processed accordingly with the original procedure. Analysis in the dynamic reconfiguration model We need to verify that during the reconfiguration interval the requirements given in chapter 1.2 hold. The result of the Evaluation activity for any given order should not be affected by the change in procedure. The acceptability of an order (Evaluation activity) is computed outside the region to be reconfigured, and there is no interaction between Evaluation and the region. It means that the Evaluation in the old procedure workflow is exactly the same as in the new procedure workflow. All orders accepted after the change in procedure must be proceed according to the new procedure. In order to distinguish between these two situations - receiving the event before billing and shipping activities have started or after - we use scopes to define different procedures: OldConfigScope represents the procedure running before billing and shipping, BillShip1 represents the concurrent billing and shipping and New- ConfigScope represents the new configuration procedure which includes sequential billing and shipping. When a management decision is made, the event handler for OldConfigScope will be invoked and it will terminate OldConfigScope, which contains the procedure for order receipt, order evaluation activities. We use termination handler to replace OldConfigScope with NewConfigScope representing the new procedure for order receipt, order evaluation and, this time, BillShip2 activities. In this way, after its termination, 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 and shipping happening in any order but both before archiving and confirming. We declare individual variables for BillShip1 and NewConfigScope. These are the request messages used to invoke the Bill and Ship services and they are only visible within their own scope. This means that, if the request message for billing and shipping has already been created, this activity can be invoked without any interrupt. Technically, the event handler is used to implement the management decision for change. When the event is received, NewConfigScope will be enabled. However, if the event is received after the order leaving OldConfigScope, BillShip1 will run because the request message has been initialized. If the event is received while OldConfigScope is running, OldConfigScope will be terminated and NewConfigScope will start redoing order receipt, order evaluation, and

84 72 Mapping BPMN Models to BPEL execute BillShip2. BillShip1 will not be run because no request message has 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 BillShip1 service. However, in BPEL, we cannot model exactly this situation. All the services remain available. If we want to ensure all the instances of the workflow created after the change run BillShip2 instead of BillShip1, the process needs to continue receiving the change reconfiguration event.

85 Chapter 6 Tool-based Mapping BPMN Models to BPEL The BPMN to BPEL mapping we have presented so far has been obtained by following the approach given in [14]. This allowed us to have some flexibility but the process had to be entirely manually executed. Another option, although more restrictive, is to use some automatic tool for the translation. In this chapter we 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 Eclipse plugins allowing process designers to model processes with BPMN and to use several graphical tools to manage the data. It includes most of the BPMN elements which are relevant to executable business process models. External activities and message flows are mapped into specific interface operations and message definitions using WSDL. The message structures are indicated by XML Schema elements. Service calls are modeled by introducing Pools containing the operations of the WSDL. The process interacts with this external participants through message flows. After the process has been modeled and concrete ser-

86 74 Tool-based Mapping BPMN Models to BPEL vices, messages and data have been defined, Intalio Designer will automatically generate a BPEL description. Figure 6.1: Intalio BPMS Designer To model the office workflow with the Intalio Designer the first thing we have to do is creating a Business Process Project containing Business Process diagrams, XML Schemas, WSDL files. Once the project has been created, we can then create a BPMN diagram with the embedded BPMN modeler. The palette (see Figure 6.2) provides an immediate access to all the existing BPMN shapes. After the BPMN modeling for the office workflow will be completed, we can start implementing the process Office Workflow by integrating all the operations from the existing Web services, creating the interface to define how it will be exposed to the external users and defining the graphical mappings to invoke the services. Integrating web services The tool integrates a full WSDL visual browser which allows to edit and introspect WSDL documents. To implement the case study we have to create WSDL documents for Office Workflow Service, Order Generator Service, Credit Check Service, Inventory Check Service, Bill&Ship Service and Archive Service respectively. Then we have to create pools repre-

87 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 these pools represent the sequence of service operations that will be invoked from the main business process Office Workflow. It is very important to make the distinction between operations invoked by a process and operations that will invoke a process. An operation in a nonexecuted pool, represented as a BPMN task either provides the operation or invokes the operation. The operations like OrderGenerator, CreditCheck, InventoryCheck, etc are operations that the Office Workflow process will invoke; whereas OrderGeneratorReply, CreditCheckReply, InventoryCheckReply, etc are operations that will invoke the process. Finally, we have to connect the process tasks to the web service operations. The order is defined by creating the links. For the operations of Order Generator we want the message received from the customer to go from the executable task ( Invoke order generator ) to the corresponding Order Generator operation and the response message to go from the Order Generator operation to the message intermediate event ( Receive order ) (see Figure 6.3). In the same way, we have to integrate Credit Check, Inventory Check, Bill&Ship, Archive. All the data involved in the Office Workflow process are created automatically when integrating the WSDL files.

88 76 Tool-based Mapping BPMN Models to BPEL Figure 6.3: Order Generator Web Service Operations Generate BPEL code Once the Office Workflow process is ready to be executed we can easily deploy it. There are several artifacts being generated at this point: the BPEL code corresponding to the Office Workflow process (see Appendix C.3), the WSDL files used by the process to represent its interactions with the other participants (see Appendix C.2) and the different WSDLs used to represent external services (see Appendix C.1). Change Configuration As before, we have to deal with the Office Workflow reconfiguration, i.e. the process will invoke Bill and Ship in sequence instead of parallel. The remaining parts like partner links, external services, WSDLs are not altered by this but the BPEL is (see Appendix C.4). We need indeed a new participant Reconf.region used to send a reconfiguration message and invoke the new 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 add an Non-interrupt Message Event to make the choice. If the process receives the change message then the configuration2 sub-process will execute (the new configuration) otherwise the process will automatically execute the old configuration sub-process configuraiton1. The generated BPEL code, partner links are available in Appendix C.2 and Appendix C.5.

89 6.1 Designing and Implementing Process 77 As we can see from the generated BPEL code, the interaction between the Reconf.Region web service and BPEL process is mapped into an event handler and 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"

90 78 Tool-based Mapping BPMN Models to BPEL 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 BillAndShip operation on BillAndShipPortType, the order will be processed according to the new 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 process and the external web services is the same as when we do the implementation manually. All the partner link definitions used by the Office workflow process for representing its interaction with the other participants is generated in a WSDL file. The names for partnerlinktype, myrole, partnerrole are automatically generated by the tool, they are quite long and not well named.

91 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" initializepartnerrole="yes" myrole="office_workflow_for_credit_check" partnerrole="credit_check_for_office_workflow"/> <bpel:partnerlink name="office_workflowandinterface- -ForPortNotificationSOAPPlkVar" partnerlinktype="diag:office_workflowandinterface- -ForPortNotificationSOAPPlk" initializepartnerrole="yes" myrole="office_workflow_for_interface" partnerrole="interface_for_office_workflow"/> <bpel:partnerlink name="inventory_checkandoffice_workflow- -ForPortInventoryCheckReplySOAPPlkVar" partnerlinktype="diag:inventory_checkandoffice_ WorkflowForPortInventoryCheckReplySOAPPlk" initializepartnerrole="yes" myrole="office_workflow_for_inventory_check" partnerrole="inventory_check_for_office_workflow"/> <bpel:partnerlink name="archiveandoffice_workflow- -ForPortArchiveReplySOAPPlkVar" partnerlinktype="diag:archiveandoffice_workflow- -ForPortArchiveReplySOAPPlk" initializepartnerrole="yes" myrole="office_workflow_for_archive" partnerrole="archive_for_office_workflow"/> <bpel:partnerlink name="bill_ship1andoffice_workflow- -ForPortBillShipReplySOAPPlkVar" partnerlinktype="diag:bill_ship1andoffice_workflow- -ForPortBillShipReplySOAPPlk" initializepartnerrole="yes"

92 80 Tool-based Mapping BPMN Models to BPEL 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 the tool. <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 (Manually mapping (Chapter5) / Tool-based mapping (Chapter6)) of the old configuration and the new configuration. The biggest difference between these two implementations is the way to handle the dynamical reconfiguration, which is the transition process between two configurations. Manually implementation is using the event handler activity to react on the change event. Event handler starts when OldConfigScope scope starts. This scope defines the procedure running before the bill and ship. We use the termination handler activity to define a new scope NewConfigScope which will start the new procedure for order generator, order evaluation and BillShip2 activities. So when Change Configuration event occurs, all the activities happens before the bill and ship will be terminated and the process will restart calling the new configuration procedure. BillAndShip1 scope represents the concurrent billing and shipping procedure (see code in Chapter 5.3.6). Whereas in the Intalio BPMS implementation, the fault handler activity is used to 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 the Change Configuration event, but here it will throw an error once the event occurs. In the BPMN diagram, it s not allowed to have two message flows entering to 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&Ship2 web service. So we have to add a new Data Object (BillShipReply) to represent

93 6.2 Comparison Between the two Mapping Ways 81 a global BillShip reply message for the whole process. If the Bill&Ship1 service is invoked, copying the reply message of Bill&Ship1 to this global variable; if the Bill&Ship2 service is invoked, copying the reply message of Bill&Ship2 to the global variable. The request message for the Archive web service is constructed by this defined global variable (see code in Chapter 6.1). By comparing these two implementation options, we can see that even though this automatic tool can succeed in generating BPEL code, additional procedures have still to be provided manually. For example, the variables have to be initialized, correlation set has to be established, etc. Based on a complex case, the BPMN diagram has too many limitations, the generated BPEL process maybe not suitable and satisfied all the requirements. In general, we cannot completely rely on the code generated by the automatic tools. We have to keep in mind that the tool-based transformation has weaknesses based on different cases and should always use the transformation with caution.

94 82 Tool-based Mapping BPMN Models to BPEL

95 Chapter 7 Discussion of an Alternative BPMN Design In this chapter we will present an alternative design of the office workflow case 1. 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 we make 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 the modelers 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 Workflow. Basically the differences between these two designs are the boundaries of the region to be reconfigured. In the new design version, the Bill and Ship are separated from the reconfiguration region Bill&Ship pool. Thus, the Bill&Ship represents 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 1 see Chapter 1-2: Office Workflow: Requirements.

96 84 Discussion of an Alternative BPMN Design Bill&Ship1 service (see Figure 7.1); whereas in the new configuration these two services are called sequentially by the Bill&Ship2 service (see Figure 7.2. So the Bill and Ship represent external services provided by external parties, not specific activities within the same party who offers BillShip activity, which makes our design more generic. Figure 7.3 shows the overall workflow during the reconfiguration. The idea is the same as the old design model, which creates a default flow 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. Determine configuration activity determines which configurations should be used when Bill&Ship is called. If the interrupting event in the Determine configuration activity happens, it will call the Bill&Ship2 service. Then Bill&Ship2 will 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 which executes 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 just apply to different situations. It seems that Figure 7.1 represents a more generic situation where the different services (Bill&Ship, Bill and Ship) are offered by different external parties; whereas Figure 2.12 represents the situation where Bill and Ship are activities belonging to the Bill&Ship service. This is the same situation for Figure 2.13 and Figure 7.2. By comparing the transition configuration diagrams (Figure 2.14 and Figure 7.3), we find that Bill and Ship activities have been duplicately used in Figure 2.14, because both Bill&Ship1 and Bill&Ship2 service include the same Bill and Ship activities. However in Figure 7.3, the same Bill and Ship services are called by both the Bill&Ship1 and 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 the BPMN model. In the Office workflow pool, there are also two inputs for the intermediate message event (Receive bill and ship details) which come from the different participants (Bill&Ship1 and Bill&Ship2). But the overall working flow 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 Determine configuration activity happens, the message flow only goes to Bill&Ship2. Thus for the Bill service, the Ship service and the Receive bill and ship details message event will be only one input and one output at the time. Although both design decisions are correct and possible to implement, from a BPEL designer point of view we would have had go for this alternative design decision, because it keeps

97 7.3 BPEL Implementation of the New BPMN 85 Figure 7.1: The Case Study Workflow - BPMN Diagrame Shows Old Configuration the configuration and the service modules separate, which is more reasonable for the reconfigurable systems. 7.3 BPEL Implementation of the New BPMN The implementation for the alternative design is a little more complex than the previous design. First of all we must create individual web services for Ship

98 86 Discussion of an Alternative BPMN Design Figure 7.2: The Case Study Workflow - BPMN Diagrame Shows New Configuration and Bill out of the Bill&Ship service (see Appendix D.1). And then create a Bill&Ship process used to call the Bill and Ship external services. So the whole process is conduct by the communication between the Office Workflow process and the BillShip process. It seems that the reconfiguration process has been extracted out from the whole process. Office Workflow process represents executing all the activities except calling bill and ship. After evaluation, this process will call Bill&Ship1 as a default. Then the BillShip1 process will start to execute, where calling the Bill and Ship services concurrently and then send the reply messages of both the Bill and Ship services back to the Office Workflow process. In other words, the Office Worklow process involves the Bill&Ship

99 7.3 BPEL Implementation of the New BPMN 87 Figure 7.3: The Case Study Workflow - BPMN Diagrame Shows Configuration Transition service invocation; and the Bill&Ship service will set up its own process to handle the bill and ship activities (see Appendix D.3).