A WS-BPEL Based Structural Testing Approach for Web Service Compositions

Abstract

In recent years WS-BPEL has gain significant

attention due to its ability to specify and orchestrate Web services participating in a business process. As the business process becomes complex, the XML-based WS-BPEL document used to describe the interactions among the Web services becomes difficult to understand and test. This paper proposes a structural testing approach for Web service compositions implemented with WS-BPEL. A test model is presented to capture the control flow of the WS-BPEL process. Specifically, the model takes into account the concurrency and synchronization characteristics of WS-BPEL while adapting the BPMN notation to depict the possible process execution flow. Based on the test model, test paths of a WS-BPEL process can be identified and test cases can be derived to validate the compositions of Web services. 1. Introduction

In recent years, Service-Oriented Architecture (SOA) has received a wide acceptance as a paradigm for integrating distributed software components. One major application of SOA is in the area of business process management (BPM) in which distributed business activities are often developed as Web services and can be accessed over a network, such as the Internet, using XML-based SOAP protocol [1].

Several industrial standards have been proposed to integrate different Web services across organizational boundaries for business process-oriented applications. Among these standards, Web Services Businesses Process Execution Language, which is called WS-BPEL (or BPEL for short) [2], is currently considered a prominent language to specify and execute business processes. In particular, WS-BPEL can be used to describe the control logic for orchestrating multiple

Web services participating in a process flow. It allows a company to quickly create or adapt new business processes by coordinating different Web services.

The use of WS-BPEL can facilitate the implementation of Web service compositions. However, the WS-BPEL specification is more like a XML-based “programming language.” The WS-BPEL description for a complex business process involving tens to hundreds Web services can be difficult to understand and is inherently error-prone. Thus, there is a growing interest in testing the flow logic of WS-BPEL process in order to ensure the correctness of Web service compositions.

Currently, many existing tools for testing Web service compositions implemented with WS-BPEL are solely based on the functional testing approach (i.e., black-box testing). For example, the popular WS-BPEL development tools, such as Oracle BPEL process manager [3] and ActiveBPEL Designer [4], support manual functional testing mechanisms that allow testers to test the WS-BPEL descriptions and the service compositions based on the requirements. Nevertheless, the WS-BPEL processes are complex and difficult to understand. The functional testing approach may not be adequate to ensure the correctness of WS-BPEL descriptions and service compositions, especially to reveal the structural errors in the WS-BPEL processes.

In this paper, we propose a novel testing approach for Web service compositions implemented with WS-BPEL based on the structural testing technique (i.e., white-box testing). The proposed approach can be considered as a complement method to existing functional testing approaches for Web service compositions. In particular, our approach presents a test model to abstract the control flow of WS-BPEL process. The test model captures different activity constructs defined in the WS-BPEL specification and takes into account its concurrency and synchronization

Chien-Hung Liu Dept. of Computer Science and

Information Engineering National Taipei Univ. of Technology

cliu@ntut.edu.tw

Shu-Ling Chen Dept. of Management and Information Technology

Southern Taiwan University slchen@mail.stut.edu.tw

Xue-Yuan Li Dept. of Computer Science and

Information Engineering National Taipei Univ. of Technology

t5598003@ntut.edu.tw

2008 IEEE International Symposium on Service-Oriented System Engineering

978-0-7695-3499-2/08 $25.00 © 2008 IEEE

DOI 10.1109/SOSE.2008.30

135

semantics. To make the complex WS-BPEL process easy to understand, the test model adapts a subset of the Business Process Modeling Notation (BPMN) [5] to represent the WS-BPEL process. The BPMN is a standard graphical notation proposed by Business Process Management Initiative (BPMI) to represent business processes. By adapting the BPMN notation, the proposed test model can serve as a communication mechanism between the WS-BPEL process developers and testers so as to facilitate the service compositions analyzing and testing.

Based on the proposed test model, an algorithm is described to derive the test paths of the WS-BPEL process. Specifically, the algorithm computes the sequential paths of the WS-BPEL process while considering possible parallel paths introduced by concurrent activities under different synchronization conditions and process states. Moreover, the branch conditions imposed on the activities are also collected and analyzed for identifying infeasible test paths.

This paper is organized as follows. Section 2 briefly reviews recent testing approaches for Web service compositions that are related to our work. Section 3 provides the background of the WS-BPEL. Section 4 presents the definitions of the BPMN-based test model for representing the control flow of WS-BPEL process. Section 5 describes the method to derive test paths for a WS-BPEL process based on the test model. Section 6 shows an example to illustrate the effectiveness of the proposed approach. Section 7 provides the conclusion remarks and our future work. 2. Related Work

As Web services become an emerging paradigm for service-oriented applications, there is an increasing interest in testing Web services. In particular, substantial efforts have been spent on testing a single Web service and service compositions. For testing a single Web service, most research works exploit the information of WSDL specification [6], such as message types and operations, to generate test cases for ensuring the correctness of the service [7][8]. In addition, several works propose a test framework to facilitate Web service testing [9][10].

For testing service compositions, Tsai et al. [11] propose a group testing technique to test composite services and Zhu [12] suggests a service-oriented framework for testing service compositions. In particular, for testing service compositions implemented using WS-BPEL, several works are proposed to address the unit testing of BPEL. Li et al. [13] propose a BPEL unit test framework to facilitate

the testing and debugging of BPEL processes. The framework including a BPEL process composition model, a test architecture, a lifecycle management schema, and a test process design outline can provide the foundation for BPEL unit testing tools.

Mayer and Lübke [14] propose a framework called BPELUnit for white-box BPEL unit testing. The framework consists of four layers: test specification, test organization, test execution, and test results that can facilitate the specification and organization of BPEL test cases and support automated test execution and test management of BPEL processes.

In addition to BPEL unit testing tools, several works focus on providing systematic methods to generate BPEL test cases. Yan et al. [15] propose an extended Control Flow Graph (XCFG) to represent a BPEL specification. From the XCFG, all the sequential test paths are generated and then combined to form concurrent test paths. A symbolic execution method is used to extract a set of constraints of the test paths. Finally, a constraint solver is employed to solve the constraints and generate feasible test cases.

Yuan et al. [16] describe a graphical model, called BPEL Flow Graph (BFG), to represent the control flow of a BPEL program. By traversing the BFG, concurrent test paths for the BPEL program can be derived. The test data for each path are then generated using a constraint solving method.

In addition to generate BPEL test cases using flow graph, Zheng et al. [17] propose a test case generation framework for BPEL based on the model checking technique. Basically, the proposed approach transforms the BPEL program into an automata model and captures the variables of the BPEL program to construct a data flow model. Based on the automata and data flow model, coverage criteria, such as state, transition, and all-du-path, are used to generate test cases for testing the control flow and data flow of BPEL.

Moreover, instead of testing BPEL programs, several works aim to verify the BPEL using model checking and Petri net techniques. Cao et al. [18] propose a BPEL verification framework. In the framework, BPEL program is modeled using UML activity diagram. The activity diagram is then transformed into PROMELA and verified with a model checker. Similarly, Dong et al. [19] translate the BPEL specification to High-level Petri nets (HPN) and then verify the HPN using a simulator.

Our work is more similar to the works of Yan et al. [15] and Yuan et al. [16] those generate test cases from the flow graph of BPEL program. The major difference is that we adapt the BPMN notation to depict the BPEL flow graph. This makes our flow

136

graph more intuitive for testers since it closes to the design model of the BPEL process. Thus, our model can facilitate the understanding and testing of BPEL processes. In addition, the method used to generate test paths is different, too. Moreover, our approach can model the effects of “crossing-boundary” and “Dead Path Elimination (DPE)” in the BPEL flow graph.

3. Background of the WS-BPEL

WS-BPEL is an XML-based language that is standardized by OASIS [20] to orchestrate multiple Web services for building complex business processes. A WS-BPEL process is composed of various activities including basic activities and structured activities. The basic activities describe the elemental steps of business process behavior, such as receive, reply, invoke, and assign. On the other hand, the structured activities, such as sequence, flow, if, and while, encode the control logic of a process and contain other basic and/or structured activities recursively.

The structured activities are similar to the control constructs in the programming languages. For example, the activities contained within a sequence structure will be executed sequentially. The activities contained within a flow structure will be executed concurrently. In particular, the synchronization among the concurrent activities within a flow structure is provided using links. Each link connects a source activity to a target activity and has an associated transition condition (a Boolean XPath expression). The transition condition determines whether a link is followed during runtime. If the transition condition is not specified, the value of the link is defined to be true and the link will be followed.

Moreover, an activity can be the source and/or target of multiple links. An activity that is the target of an incoming link has an associated join condition. The join condition is a Boolean XPath expression that is evaluated based on the state of the process instance and the values of all incoming links of the associated activity. The join condition of an activity is set to be the disjunction of the activity’s incoming links by default. An activity can be executed only when all the incoming links are defined and when the join condition of the activity evaluates to true.

In general, if the join condition of an activity evaluates to false, the activity will not be performed and a fault “bpel:joinFailure” will be generated. This fault will be suppressed if the “suppressJoinFailure” attribute of the activity or process is set to “yes.” In such situation, the activity will be skipped and the status of all outgoing links from the activity will be set

to “negative.” The link status will be propagated along entire paths by consecutive links until a join condition is reached and evaluates to true. This is called Dead-Path Elimination.

Note that a link entering or leaving a syntactic construct is said to cross the boundary of the construct. Although the source and target activities of a link can be nested inside different syntactic constructs, the link must not cross the boundary of a repeatable construct, an event handler, or a compensation handler. In addition, a link that crosses a fault-handler boundary must be outbound and a link must not create a control cycle. These restrictions of links must be statically enforced and are called “boundary-crossing restrictions” [2]. 4. The WS-BPEL Control Flow Graph

To abstract the execution flow of a WS-BPEL process, a test model, called the WS-BPEL Control Flow Graph (BCFG), is proposed. In particular, to facilitate the understanding of WS-BPEL processes and the communications between the business process developers and testers, a subset of the BPMN notation is adapted to depict the BCFG. The BPMN notation is a standard business process modeling notation used to create a graphical representation for business processes and is readily understandable by most business users, such as business analysts, business managers, and technical developers [5].

Table 1 lists the set of BPMN core graphical elements that are adapted to represent the BCFG constructs. The start node and end node represent the start and end events of the BPEL process. The intermediate node is used to indicate an event, such as an error, that affects the flow of the process. The normal node represents a BPEL basic activity. The sub-process node represents a sub-process and hides the details of the sub-process. The fork/join node is used to split and combine the concurrent flow paths. The branch/merge node is used to control the divergence and convergence of multiple sequence flow. The sequence edge shows the execution order of activities in the process. The default edge represents the default path of a branch. The conditional edge represents a flow path with condition expressions, such as the transition condition associated with a link, that are evaluated at runtime to determine whether or not the flow will be used.

To model a WS-BPEL process, each basic activity in the process is represented by a normal node in the BCFG. The flow between the activities is represented using the sequence, default, and conditional edges

137

depending on the process logic. Since a structured activity can contain basic and/or structured activities recursively, each structured activity in the process can

be constructed using normal nodes, fork/join nodes, or branch/merge nodes, etc. Table 2 shows the constructs of the structured activities used in the BCFG.

In Table 2, the construct for the pick or switch activity is modeled using a set of event/activity branches in which exactly one of the branches will be selected. Specifically, the pick activity has an <onAlarm> attribute that corresponds to a timer-based alarm. If the specified duration value has passed, then the <onAlarm> event is executed immediately and all <onMessage> events are ignored. Thus, we can model the <onAlarm> event as a default activity in the pick structure. Similarly, the switch activity uses a <case> attribute to represent each case branch and uses an <otherwise> attribute to represent the otherwise branch. As a result, the <otherwise> event can be modeled as a default activity in the switch structure. Moreover, the scope activity provides a way to organize the activities in a BPEL process into logical sections and, thus, is modeled as a sub-process in the BCFG.

Note that the concurrent activities within a flow structure are synchronized using links and a basic activity can be the source and/or target of the links. To capture the semantics of links, the construct of the basic activity within a flow structure is refined in order to represent the synchronization effects of links. Figure 1 illustrates the graphical model used to capture the semantics of links. Figure 1(a) shows the original construct for a basic activity. If the basic activity is a source of links, a fork node is attached to the basic activity in order to model the outgoing links of the activity. Figure 1(b) illustrates the construct for a source activity with outgoing links.

If the basic activity is a target of links, a join node followed by a branch node is added in front of the basic activity to represent the synchronization and join condition of the incoming links. When the join condition is evaluated to true, the activity will be performed; otherwise, the activity will not be executed and a fault “bpel:joinFailure” is generated. The join failure is represented using an intermediate node.

Figure 1(c) illustrates the construct for a target activity with incoming links and Figure 1(d) illustrates the construct for a basic activity that has both incoming and outgoing links.

In addition, if the join condition evaluates to false and the attribute “supressJoinFailure” is set to “yes,” then the situation of DPE will occur. This means that the fault will be suppressed and the activity will be skipped. To model the construct for an activity with DPE, an alternative flow that skips the activity will be added. This alternative flow and the normal flow are then merged as shown in Figure 1(e), where the activity has both incoming and outgoing links.

(a) (b) (c)

(d) (e) Figure 1. The graphical models for a basic

activity with different link semantics 5. Generation of Test Paths

With the proposed test model, test paths of a BPEL process can be derived by traversing the BCFG. The main idea of the BCFG traversing method is similar to that of search algorithm described in [16]. However, if the BCFG contains a loop, our traversing method will skip the loop or explore the loop only one time. The following briefly outlines the traversing method for the BCFG:

Table 1. A set of BPMN core graphical elements used in the BCFG

Start node

Intermediate node

End node

Normal node (Activity)

Sub- Process

Fork/Join node

Branch/Merge node

Sequence Edge

Default Edge

Conditional Edge

Table 2. The constructs of WS-BPEL structured activities

If Else While Repeat Until Sequence Pick/Switch Flow Scope For Each

138

(1) Create a test path and let the start node of the BCFG be the start point of the path. Let the start node be the node under examined.

(2) If the node is a start node, a normal node, or a merge node, add this node to the current test path.

(3) If the node is a fork node, add this node to the current path and explore all the sub-paths of the fork node concurrently.

(4) If the node is a join node, add this node to the current path after all of its incoming edges are explored.

(5) If the node is an unvisited branch node with n outgoing edges, add this node to the current path and duplicate the current path to n test paths where each path will be explored along with one outgoing edge of the branch node. If the node is a branch node visited before, simply add the node to the current path.

(6) For each path, repeat from Step (2) to explore all the unvisited successors and those visited branch successors of this node until the path ends with the end node or the intermediate node.

(7) Identify the path condition of each test path. A path condition is the conjunction of all branch conditions of the path where a branch condition can be the join condition of a target activity or the condition expression of a structured activity.

(8) Analyze the path condition of each test path and remove infeasible test paths.

6. An Illustration Example

To illustrate the proposed testing approach, a simple loan approval process introduced in the WS-BPEL specification [2] is used. Figure 2 shows the design of the loan approval process. Basically, the process interacts with an assessor service to assess the risk associated with the customer and an approver service to evaluate the loan request. The process begins by receiving a loan request that includes personal information and requested amount. With this information, the loan approval process will generate either a “loan approved” or “loan rejected” message. The result is determined based on the amount requested and the risk associated with the customer. For a low-risk customer with a requested amount less than $10,000, the loan is approved automatically. If the requested amount is greater than $10,000 or the loan is requested by a medium or high-risk customer, the loan needs to be examined by an approver.

In the loan approval process, all activities are nested within a flow structure and are synchronized with links. The process flow is then determined by the transition

conditions associated with the sources of the links and the join conditions associated with the targets of the links. Since no join condition is specified in the process, the join condition of a target activity is the disjunction of the link status of all incoming links associated with the activity. In addition, the attribute “suppressJoinFailure” of the process is set to “yes” which means the DPE is enabled.

Figure 2. The loan approval process

Figure 3 shows the BCFG of the loan approval process. To simplify the BCFG, Figure 3 shows only the normal flow of the process and does not include the flow of fault hander. In Figure 3, the BCFG consists of six links to synchronize the activities. Each link has an associated transition condition and is represented by a conditional edge. Except for the receive activity, all other activities are targets of the links and each activity has a join condition that is the disjunction of the link status of its incoming links. In addition, these target activities can be skipped if the situation of DPE occurs.

Start

End

invokeApprover

invokeAssessor

receive

reply

assign

receive-to-assessreceive-to-approval

approval-to-reply

assess-to-setMessage

assess-to-approval

setMessage-to-reply

C1

C3

C2

C4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1

17

Join Conditions:C1 = amount <10000C2 = amount <10000 and risk = LowC3 = amount >=10000 or (amount < 10000 and risk != Low)C4 = C2 or C3

Figure 3. The BCFG of loan approval process

139

Figure 4. The detailed steps to traverse the BCFG for deriving the test path P6

Table 3. The test paths for the loan approval process

Path No Executive Order (The notations‧and || indicate sequential & parallel activities, respectively) Path Conditions Feasible Path P1 Start‧1‧2‧7‧8‧9‧10‧((11‧12‧13)∥(3‧4‧5‧6))‧14‧15‧16‧17‧End C1 ∧ C2 ∧ C3 ∧ C4 no

P2 Start‧1‧2‧7‧8‧9‧10‧((11‧13) ∥(3‧4‧5‧6))‧14‧15‧16‧17‧End C1 ∧ ¬C2 ∧ C3 ∧ C4 yes (amount < 10000 ∧ risk != Low)

P3 Start‧1‧2‧7‧8‧9‧10‧((11‧12‧13)∥(3‧4‧6))‧14‧15‧16‧17‧End C1 ∧ C2 ∧ ¬C3 ∧ C4 yes (amount <10000 ∧ risk = Low)

P4 Start‧1‧2‧7‧8‧9‧10‧((11‧13) ∥(3‧4‧6))‧14‧15‧16‧17‧End C1 ∧ ¬C2 ∧ ¬C3 ∧ C4 no P5 Start‧1‧2‧7‧9‧10‧((11‧12‧13)∥(3‧4‧5‧6))‧14‧15‧16‧17‧End ¬C1 ∧ C2 ∧ C3 ∧ C4 no P6 Start‧1‧2‧7‧9‧10‧((11‧13) ∥(3‧4‧5‧6) )‧14‧15‧16‧17‧End ¬C1 ∧ ¬C2 ∧ C3 ∧ C4 yes (amount >=10000)P7 Start‧1‧2‧7‧9‧10‧((11‧12‧13) ∥(3‧4‧6))‧14‧15‧16‧17‧End ¬C1 ∧ C2 ∧ ¬C 3 ∧ C4 no P8 Start‧1‧2‧7‧9‧10‧((11‧13) ∥(3‧4‧6))‧14‧15‧16‧17‧End ¬C1 ∧ ¬C2 ∧ ¬C 3 ∧ C4 no P9 Start‧1‧2‧7‧8‧9‧10‧((11‧12‧13)∥(3‧4‧5‧6))‧14‧15‧17‧End C1 ∧ C2 ∧ C3 ∧ ¬C4 no

P10 Start‧1‧2‧7‧8‧9‧10‧((11‧13) ∥(3‧4‧5‧6))‧14‧15‧17‧End C1 ∧ ¬C2 ∧ C3 ∧ ¬C4 no P11 Start‧1‧2‧7‧8‧9‧10‧((11‧12‧13) ∥(3‧4‧6))‧14‧15‧17‧End C1 ∧ C2 ∧ ¬C3 ∧ ¬C4 no P12 Start‧1‧2‧7‧8‧9‧10‧((11‧13) ∥(3‧4‧6))‧14‧15‧17‧End C1 ∧ ¬C2 ∧ ¬C3 ∧ ¬C4 no P13 Start‧1‧2‧7‧9‧10‧((11‧12‧13) ∥(3‧4‧5‧6))‧14‧15‧17‧End ¬C1 ∧ C2 ∧ C3 ∧ ¬C4 no P14 Start‧1‧2‧7‧9‧10‧((11‧13) ∥(3‧4‧5‧6))‧14‧15‧17‧End ¬C1 ∧ ¬C2 ∧ C3 ∧ ¬C4 no P15 Start‧1‧2‧7‧9‧10‧((11‧12‧13) ∥(3‧4‧6))‧14‧15‧17‧End ¬C1 ∧ C2 ∧ ¬C3 ∧ ¬C4 no P16 Start‧1‧2‧7‧9‧10‧((11‧13) ∥(3‧4‧6))‧14‧15‧17‧End ¬C1 ∧ ¬C2 ∧ ¬C3 ∧ ¬C4 no

C1:= (amount <10000); C2:= (amount <10000 ∧ risk = Low); C3:= (amount >=10000 ∨ (amount < 10000 ∧ risk != Low)); C4:= (C2 ∨ C3) = True

The test paths of the process can be derived based on the BCFG traversing method described in previous section. Figure 4 shows the process to traverse the BCFG step by step for deriving a particular path. The traverse of the BCFG begins from the start node. The shaded area in the figure indicates the nodes being visited so far. If the visited node is a fork node, the successors of the fork node are explored concurrently as indicated in step (4). If the visited node is a join node, the traverse of this node will wait until all the

incoming edges of the join node are explored. If the visited node is a branch node, the paths will be duplicated as depicted in steps (5), (8), (9), and (13). For illustration, only one of the duplicated paths is selected to explore further. The traverse of the BCFG will stop when the end node is visited.

By following the traversing process depicted in Figure 4, test paths of the loan approval service can be generated. Table 3 lists all possible test paths derived from the BCFG and the path condition associated with

140

each path. By analyzing the path conditions, only paths P2, P3, and P6 are feasible and, hence, three test cases can be derived to test the loan approval process. 7. Conclusions and Future Work

In this paper, we have proposed a structural testing approach for Web service compositions implemented with WS-BPEL. The approach uses a BPMN-based BCFG to represent the control flow of a WS-BPEL process. Test paths of the process can be derived by traversing the BCFG. In addition, path conditions are collected and analyzed in order to remove infeasible test paths. The advantage of the approach is that the proposed BCFG can capture the semantics of concurrency, synchronization, and dead path elimination. Moreover, the representation of BCFG is close to the design of WS-BPEL process and, hence, it can facilitate the understanding and testing of service compositions.

Currently, a tool to support automatic construction of BCFG and computation of test paths is in progress. In the future, we plan to extend the BCFG to model the fault handling and compensation mechanisms as well as other WS-BPEL features. We also plan to extend the BCFG to support data flow analysis and testing for WS-BPEL processes. 8. Acknowledgements

This work was supported in part by the National Science Council, Taiwan under grant No. NSC 96-2221-E-027-033. 9. References [1] Simple Object Access Protocol, Version 1.2,

http://www.w3.org/TR/soap [2] Web Services Business Process Execution Language

Version 2.0, OASIS Standard, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

[3] ActiveBPEL Designer, http://www.active-endpoints.com/active-bpel-designer.htm

[4] Oracle BPEL Process Manager, http://www.oracle.com/technology/products/ias/bpel/index.html

[5] Business Process Modeling Notation Specification, Version 1.0, http://www.bpmn.org/

[6] Web Services Description Language, Version 1.1, http://www.w3.org/TR/wsdl

[7] J. Offutt and W. Xu, “Generating Test Cases for Web Services Using Data Perturbation,” ACM SIGSOFT Software Engineering Notes, Vol. 29, No. 5, September 2004, pp. 1-10.

[8] X. Bai, W. Dong, W.-T. Tsai, and Y. Chen, “WSDL-Based Automatic Test Case Generation for Web Services Testing,” In Proceedings of Service-Oriented System Engineering on IEEE International Workshop (SOSE 2005), Oct. 2005, pp. 207-213.

[9] W. T. Tsai, R. Paul, L. Yu, A. Saimi, and Z. Cao, “Scenario-Based Web Service Testing with Distributed Agents”, IEICE Transaction on Information and System, Vol. E86-D, No. 10, 2003, pp. 2130-2144.

[10] H. Mei and L. Zhang, “A framework for testing Web services and its supporting tool,” In Proceedings of the 2005 IEEE International Workshop on Service-Oriented System Engineering, 2005, pp. 199- 206.

[11] W. T. Tsai, Y. Chen, R. Paul N. Liao, and H. Huang, “Cooperative and Group Testing in Verification of Dynamic Composite Web Services,” In Workshop on Quality Assurance and Testing of Web-Based Applications, in conjunction with COMPSAC 2004, 2004, pp. 170-173.

[12] H. Zhu, “A Framework for Service-Oriented Testing of Web Services,” In Proceedings of the 30th Computer Software and Applications Conference (COMPSAC’06), Sept. 2006, pp.145-150.

[13] Z. Li, W. Sun, Z.-B. Jiang, and X. Zhang, “BPEL4WS Unit Testing: Framework and Implementation,” In Proceedings of the IEEE International Conference on Web Services (ICWS'05), 2005, pp. 103-110.

[14] P. Mayer and D. Lübke, “Towards a BPEL Unit Testing Framework,” In Proceedings of the 2006 workshop on Testing, analysis, and verification of web services and applications, 2006, pp. 33- 42.

[15] J. Yan, Z. Li, Y. Yuan, W. Sun, and J. Zhang, “BPEL4WS Unit Testing: Test Case Generation Using a Concurrent Path Analysis Approach,” In Proceedings of the 17th International Symposium on Software Reliability Engineering (ISSRE '06), 2006, pp.75-84.

[16] Y. Yuan, Z. Li, and W. Sun, “A Graph-Search Based Approach to BPEL4WS Test Generation,” In Proceedings of the IEEE International Conference on Software Engineering Advances (ICSEA '06), 2006, pp.14-14.

[17] Y. Zheng, J. Zhou, and P. Krause, “A Model Checking based Test Case Generation Framework for Web Services,” In Proceedings of the Fourth International Conference on Information Technology(ITNG’07), April 2007, pp. 715-722.

[18] H. Cao, S. Ying, and D. Du, “Towards Model-based Verification of BPEL with Model Checking,” In Proceedings of The Sixth IEEE International Conference on Computer and Information Technology (CIT'06), Sept. 2006, pp. 190-190.

[19] W.-L. Dong, H. Yu, and Y.-B. Zhang, “Testing BPEL-based Web Service Composition Using High-level Petri Nets,” In Proceedings of The 10th IEEE International Enterprise Distributed Object Computing Conference(EDOC’06), Oct. 2006, pp. 441-444.

[20] OASIS, http://www.oasis-open.org/home/index.php

141