410
IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 10, NO. 4, DECEMBER 2013
Verifying the Concurrent Properties in BPEL Based Web Service Composition Process Bixin Li, Shunhui Ji, Dong Qiu, Hareton Leung, and Gongyuan Zhang
Abstract—The relatively new web service software paradigm involves services which are loosely coupled, highly reusable and flexible. By specifying the workflow of individual services, Web service composition enhances the ability to handle more complex business processes and provides many value-added services. In this article, we propose an extended control flow graph (XCFG) to formally model the workflow of Web service composition specified in BPEL, and corresponding techniques to verify concurrent properties, such as deadlock-free, non-conflict, and link non-redundant. XCFG can model not only the workflow of BPEL but also the synchronization control dependencies among concurrent activities. Meanwhile, each element of XCFG keeps record of related information of corresponding activity in BPEL so as to support further analysis and verification. Experimental study validates the effectiveness and efficiency of the proposed XCFG-based technique. Index Terms—Formal verification; Web service composition; BPEL; XCFG.
I. I NTRODUCTION
W
ITH the continuous improvement of SOA (ServiceOriented Architecture), more and more Web service techniques are applied in application development. The distributed software systems have been evolved based on SOA and Web services. Web service is a function that is welldefined, self-contained, and independent of the context or state of other services. By Web service composition (WSC), we can integrate the existing heterogeneous services to compose new services that offer more complicated functions. In addition, we can achieve higher services reusability and acquire valueadded services. Web Service Business Process Execution Language (WS-BPEL)[1], used to draw up the workflow of Web services, is one of the standard Web service composition languages designed to enable universal inter-operability. On the other hand, WSC brings some new challenges: How to assure the process of Web service composition is correct? How to verify that composite services satisfy some desirable features? It is necessary and very important to study how to model, analyze and verify WSC in an effective and efficient
Manuscript received November 28, 2012; revised June 3 and October 19, 2013. The associate editor coordinating the review of this paper and approving it for publication was C. Bartolini. This article is supported partially by the National Natural Science Foundation of China under Grant No. 60973149, partially by the Doctoral Fund of the Ministry of Education of China under Grant No. 20100092110022, and partially by the College Industrialization Project of Jiangsu Province under Grant No.JHB2011-3. B. Li, S. Ji, D. Qiu, and G. Zhang are with the School of Computer Science and Engineering, Southeast University, Nanjing, China, 210096 (email: {bx.li, dongqiu}@seu.edu.cn). H. Leung is with the Department of Computing, Hong Kong Polytechnic University, Hong Kong, China (e-mail:
[email protected]). Digital Object Identifier 10.1109/TNSM.2013.111113.120379
way. Especially, it is more difficult to analyze and solve these problems when dealing with concurrent behaviors in BPEL based Web service composition (BWSC) process. In this article, we focus on analyzing and verifying concurrent properties in BWSC. The concurrent constructs in BPEL specification supports the execution of complex business tasks[2]. However, the f low mechanism in BPEL is different from the traditional concurrent mechanism due to the link semantic. The links for which activity A is the source are called A’s outgoing links, and the links for which activity A is the target are called A’s incoming links. If A is the target of a link that has activity B as the source, then A has a synchronization dependency on B, which means that A is ready to start iff all its incoming links have been determined. This requires new model and analysis of BPEL concurrent mechanism before formal verification can be performed. We propose simple and efficient techniques to verify whether following three concurrent properties, deadlock-free, non-conflict and link non-redundant are satisfied in BWSC. To realize this objective, we introduce an extended control flow graph (XCFG) to model the workflow of service composition specified in BPEL, and design a series of mapping and verifying algorithms. The rest of this article is organized as follows: Section 2 is a preliminary part, where we will overview our approach and introduce BPEL and BPEL Object Model (BOM) briefly; Section 3 gives a formal definition of XCFG and discusses how to transform BPEL into XCFG; Section 4 discusses the verification algorithms of three main concurrent properties in BPEL; Section 5 discusses how to perform experimental study using an implemented tool(called XCFGV4BPEL) to validate the effectiveness and efficiency of XCFG-based technique; Section 6 discusses related works and Section 7 concludes this article and discusses some future work. II. P RELIMINARY In this section, we first give an overview of our approach for verifying the concurrent properties of BPEL. Then we present the prerequisite knowledge of BPEL and BOM. Finally, a motivating example is provided for convenient illustration in next sections. A. Overview of our approach Our approach have two main tion and property verification. To cess of modeling, analysis and we first use an open source
c 2013 IEEE 1932-4537/13/$31.00
tasks: XCFG construcsimplify the whole proverification of BPEL, package from Apache,
LI et al.: VERIFYING THE CONCURRENT PROPERTIES IN BPEL BASED WEB SERVICE COMPOSITION PROCESS
Fig. 1.
Overview of XCFGV4BPEL.
org.apache.ode.bpel.compiler.bom[3] to parse BPEL document into BPEL Object Model(BOM). We have designed and implemented a tool for verifying concurrent properties of BPEL-based service composition, called XCFGV4BPEL, which means a XCFG-based verifier for BPEL. Fig.1 shows the overview of XCFGV4BPEL, which has three main parts: • Parser: The Parser is implemented using open source package org.apache.ode.bpel.compiler.bom from apache, where BPEL document of a composite service is inputed to the Parser, which parses the BPEL document and implements the transformation from BPEL workflow of composite service to BOM object; • BOM Analyzer: It uses the BOM objects from Parser as input and adopts the analysis techniques of BOM objects mentioned in earlier sections and the formal definition of XCFG, to generate XCFG of corresponding service composition workflow, and implements the transformation from BOM objects to XCFG; • Verifier: It uses XCFG from BOM Analyzer as input, and adopts the verification algorithms to verify three properties (deadlock free, non-conflict, and non-redundant), and then feedbacks the results to the designer of composite service to improve their design. B. BPEL Process and BOM BPEL process consists of many activities which are classified into basic activities and structural activities. The basic activities specified in BPEL describe the elemental steps of process behavior and can exist independently or in a structural activity. The main basic activities in BPEL 2.0 specification are invoke, receive, reply, assign, throw, wait, empty, extensionActivity, exit and rethrow. The structural activities specified in BPEL prescribe the order in which a collection of activities are executed. They encode the control-flow of process, and can contain other basic or structural activities. The main structural activities in BPEL 2.0 are sequence, if , pick, while, repeatU ntil, f orEach, and f low, which respectively denote sequence, choice, repetition and concurrency relationship of contained activities. More details about these activities can refer to BPEL 2.0 specification[2]. Most BPEL activities are considered in this article, and we focus on the concurrency related constructs, especially the link
411
semantics in f low construct that implements the synchronous dependency between concurrent activities. BPEL Object Model(BOM)[3] covers all elements in BPEL specification, and provides corresponding definition of classes. Fig.2 depicts a part of inheritance hierarchy of BOM. From Fig.2, we can see that BpelObject is the base class, which records the basic information of BOM. The other classes correspond to the BPEL elements, such as, Scope and P rocess correspond to the element scope and process respectively, V ariable and Link provide the description of variables and links declared in BPEL, Expression provides the descriptions of all expressions, including deadline, duration, transitionCondition, joinCondition, etc, Activity is the common interface to all BPEL activities, AssignActivity and ReplyActivity correspond to assign and reply, CompositeActivity is the base interface for structural activities, whose child classes SequenceActivity, If Activity, F lowActivity and F orEachActivity correspond to sequence, if , f low and f orEach respectively. By invoking the member functions of these classes, we can get the needed information of BPEL elements. C. A Motivating Example We choose BPEL-based DSL fulfillment process[4], which defines fulfillment scenario with BPEL, as a sample case. DSL is one of the examples of eTOM’s fulfillment process[5,6], which is responsible for service providers to provide customers with their requested products in a timely and correct manner. Based on the work in the literature [4], we provide an entire process description of DSL fulfillment with BPEL (please refer to http://cse.seu.edu.cn/people/bx.li/publication.htm). The participants of the BPEL process include customerManager, serviceManager, resourceManager and supplierManager. On receiving the customer order, the process requests serviceManager for the order design, and then concurrently request external component and internal resource. After the design being confirmed by the customer, the process activates the external and internal resources to complete the service, and reply the customer with the solution finally. In order to illustrate the violation to the three concurrent properties, we make some changes to the fulfillment process. Partner billManager, which deals with the price calculation for the order, is added to be concurrently executed with external and internal resource invoke. While some of the processing can proceed concurrently, there are synchronization dependencies between the three branches. The outline of the DSL fulfillment process is shown in Fig.3, where free grouping of sequences represents concurrent sequences, solid arrows represent sequencing, and dotted arrows represent synchronization dependency between concurrent activities. III. E XTENDED C ONTROL F LOW G RAPH BPEL specification draws up the workflow of member services to achieve services collaboration. It is natural that we try some form of control flow graph(CFG) to model and analyze the workflow of composite services specified in BPEL. In this section, we introduce an extended control
412
IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, VOL. 10, NO. 4, DECEMBER 2013
BpelObject Ͳ_element : Element Ͳ_children : List +getElement() : Element #getChildren() : List
Scope
+getVariables() +getEvents() +getAlarms() +getPartnerLinks()
Process
+getName() +getRootActivity()
Variable
+getName() +getTypeName()
AssignActivity
+getCopies()
Ă
Activity
Link
+getLinkSources() +getLinkTargets() +getJoinCondition() +getName()
ReplyActivity
+getVariable()
SequenceActivity
Expression
+getLinkName()
+getExpression()
CompositeActivity
+getActivities()
IfActivity
FlowActivity
ForEachActivity Ă
+getActivity() +getCases()
Fig. 2.
+getLinks()
+getChild()
Part of inheritance hierarchy of BOM.
flow graph (XCFG) to model service composition. It has following advantages: (1) XCFG supports concurrent control flow compared with traditional CFG; (2) XCFG can model link which indicates the synchronization dependency between concurrent activities; (3) field in XCFG is introduced to record the information of related elements for the purpose of analysis and verification. We next define XCFG and discuss how to construct XCFG from BPEL.
respectively; E = EC ∪EL where EC and EL denote Control Edge and Link Edge respectively. More detailed description about XCFG elements are given as follows. •
A. Formal Definition of XCFG Traditional control flow graph for BPEL only represents sequence and choice control flow dependency. It can be formalized as G = (N, E), where N denotes the set of nodes, each represents a command or a block of commands; E denotes the set of edges, each describes the sequence dependency between two nodes, and the choice dependency can be drawn up through multi-outgoing edges from the choice node. Whereas, the traditional control flow graph is not able to fully describe the workflow of composite service specified in BPEL. This is mostly due to the f low construct and the links contained in f low which provides the concurrency semantics and synchronization dependencies among concurrent activities. We introduce XCFG, an extension of CFG, which adds concurrency and synchronization dependency to model workflow of composite web service. Meanwhile, each element in XCFG also keeps record of necessary information to support further analysis and verification. Definition: XCFG is defined as a triple (N, E, F), where N is a finite set of nodes, E is a finite set of edges, and F is the field of related information of XCFG elements. N = NN ∪NS ∪NE ∪NC where NN , NS , NE , NC denote Normal Node, Sequence Node, Exclusive Node and Concurrent Node
•
•
N = NN ∪ NS ∪ NE ∪ NC : denotes a finite set of nodes. NN is created for basic activities in BPEL, such as receive, reply, assign and so on. Additionally it is also created for onAlarm in pick. NS is created for sequence activity in BPEL. It has two sub types, Sequence Start Node NSS and Sequence End Node NSE , which represent the start and end of sequence construct respectively. NE is created for conditional activities, including if , pick, while and repeatU ntil. Its two sub types: Exclusive Decision Node NED and Exclusive Merge Node NEM represent the start and end of choice construct respectively. NC is created for f low activity. It also has two sub types, Concurrent Branch Node NCB and Concurrent Merge Node NCM which represent the start and end of concurrency construct respectively. E = EC ∪ EL : denotes a finite set of directed edges. EC is created for control flow of activities. (n1 , n2 ) ∈ EC means that activity n2 will be performed after the completion of n1 . In addition, we distinguish directed control edges into three types: SEQUENCE, CHOICE and CONCURRENCY, which respectively represent sequence, choice and concurrency dependency in BPEL. EL is created for a finite set of links which represent synchronization dependencies among concurrent activities. F : denotes the field of related information of XCFG elements and is a determinative part in XCFG definition. Different element has different field. 1): N denotes the set of XCFG nodes, and each node
LI et al.: VERIFYING THE CONCURRENT PROPERTIES IN BPEL BASED WEB SERVICE COMPOSITION PROCESS
Receive Customer Order
Confirm Customer Order
Initiate Customer Order
Request Design
Request External Component
Request Resource
Complete Design
Complete Price Calculation Price
