Verifying and Testing BPEL Processes

1 downloads 0 Views 1MB Size Report
Business Process Execution Language for Web Services (BPEL) is another of these higher level ...... .
Facult´e de Sciences Appliqu´ees Service Ing´enierie Informatique et de la D´ecision (CoDE)

Verifying and Testing BPEL Processes Fr´ ed´ eric Servais Directeur: Prof. Esteban Zim´ anyi Codirecteur: Prof. Jean-Fran¸cois Raskin

M´emoire pr´esent´e en vue de l’obtention ´ du Diplˆome d’Etude Approfondie en Sciences Appliqu´ees Ann´ee acad´emique 2006–2007

Contents 1 Introduction 1.1 Web Services Stack . . . . . . . . . . . . . . 1.2 BPEL . . . . . . . . . . . . . . . . . . . . . 1.2.1 Coordination . . . . . . . . . . . . . 1.2.2 Composition and Workflow . . . . . . 1.3 Verification and Testing of BPEL Processes 2 Web Services Basics 2.1 XML - eXtensible Markup Language . . . . 2.2 XML Schema . . . . . . . . . . . . . . . . . 2.3 WSDL - Web Services Description Language 2.3.1 Types . . . . . . . . . . . . . . . . . 2.3.2 Messages . . . . . . . . . . . . . . . . 2.3.3 Port Types and Operations . . . . . 2.3.4 Example: The Loan Assessor . . . . 2.4 XPath . . . . . . . . . . . . . . . . . . . . . 2.5 Conclusion . . . . . . . . . . . . . . . . . . . 3 BPEL 3.1 Example - Loan Approval Service 3.2 Overview of BPEL Language . . 3.2.1 Process . . . . . . . . . . 3.2.2 Variables . . . . . . . . . . 3.2.3 Expressions . . . . . . . . 3.2.4 Basic Activities . . . . . . 3.2.5 Structured Activities . . . 3.2.6 Links . . . . . . . . . . . . 3.3 Conclusion . . . . . . . . . . . . .

1

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . .

4 5 6 6 7 9

. . . . . . . . .

11 11 12 16 17 17 18 19 20 21

. . . . . . . . .

22 22 28 28 29 29 30 32 35 36

CONTENTS

2

4 Model Checking BPEL Services 4.1 Petri Nets model . . . . . . . . . . . . . . . . . . . . . 4.1.1 Mapping BPEL into Petri Nets . . . . . . . . . 4.1.2 Static Analysis of BPEL Processes . . . . . . . 4.2 Guarded Automata Model . . . . . . . . . . . . . . . . 4.2.1 Guarded Automata Peers Model . . . . . . . . . 4.2.2 LTL Properties . . . . . . . . . . . . . . . . . . 4.2.3 From BPEL to Guarded Automata to Promela . 4.2.4 Results . . . . . . . . . . . . . . . . . . . . . . . 4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 5 Testing BPEL Web Services 5.1 Test Suites . . . . . . . . . . . . . . . . . . . 5.2 Generating Test Cases using SPIN for BPEL 5.2.1 BPEL to Promela . . . . . . . . . . . 5.2.2 SPIN to Test Cases . . . . . . . . . . 5.2.3 Results . . . . . . . . . . . . . . . . . 6 Conclusions and Future Works

. . . . . Services . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

. . . . .

. . . . . . . . .

37 38 38 43 45 46 47 48 52 53

. . . . .

54 54 55 56 58 58 60

Acknowledgment I hereby express my deepest gratitude to my supervisor Professor Esteban Zimanyi and my co-supervisor Professor Jean-Francois Raskin for supporting this work all over the year. I also warmly thank Koen, Ivan, Candide and last but certainly not least Jean-Michel for their invaluable help.

3

Chapter 1 Introduction Contents 1.1

Web Services Stack . . . . . . . . . . . . . . . . .

5

1.2

BPEL

. . . . . . . . . . . . . . . . . . . . . . . . .

6

1.2.1

Coordination . . . . . . . . . . . . . . . . . . . . .

6

1.2.2

Composition and Workflow . . . . . . . . . . . . .

7

1.3

Verification and Testing of BPEL Processes . .

9

When Internet first developed, it was meant to be used for the sharing of information. Soon, client and server applications communicating through the web appeared. While html-based web applications and applets were the visible part of that trend, the business world invested heavily in getting their inter-enterprise application integrated in order to streamline their operations. The need to unite around universally accepted standards for system interaction through the internet quickly materialized. Supervised by the World Wide Web Consortium and other associations like OASIS, the standardisation effort involves the whole industry as well as numerous academics. After more than 10 years many standards have been proposed: XML, HTML, HTTP, FTP, DTD, XML Schema, XPath, SOAP, WSDL, WS-BPEL, WSTransaction, . . . The emergence of this wide range of broadly accepted standards enables the reengineering of the whole intra and inter-enterpise application integration. The Web Services technologies play a central role in this trend to global businesses integration.

4

CHAPTER 1. INTRODUCTION

1.1

5

Web Services Stack

According to the W3C’s Web Services Architecture Working Group, a Web Service is “a software system designed to support interoperable machineto-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards” [13]. Web services can thus be viewed as a stack of standards (see Figure 1.1).

Figure 1.1: Web Services Architecture Stack [13]. At the very bottom of this stack we find the communication standards that are already used for every single interaction through the Web: http, smtp, ftp,. . . They are responsible for transporting messages between applications. The base technologies constituted the next layer of the stack: XML, DTD, XML Schema, XPath, XQuery. . . They are used for the description and manipulation of the information appearing throughout the Web Services

CHAPTER 1. INTRODUCTION

6

stack. XML is really the cornerstone of the Web standardization. Applications will communicate through messages formatted in XML. They will use a message exchange protocol like OASIS’s SOAP standard or XMLRPC or other alternatives like REST. These messaging protocols will be used and associated with Interface Definition Languages, such as the Web Service Definition Language (WSDL), to provide a machine readable definition of the offered service. A WSDL document is essentially a bare list of the operations supported by the Web Service. These layers conclude the basic Web Services infrastructure upon which the other, higher level standards will build. Higher level standards include: WS-Transaction for interactions requiring long running transaction management, WS-Federation for grouping disparate user and machine identities across heterogeneous systems, WS-Provisioning to facilitate interoperability between different provisioning systems,. . . Business Process Execution Language for Web Services (BPEL) is another of these higher level specifications.

1.2

BPEL

BPEL is a coordination and composition language for Web Services. It can also be viewed as a workflow language for Web Services. We present in more details these notions now.

1.2.1

Coordination

The standards defined above (WSDL, SOAP, HTTP. . . ) enable the implementation of basic Web Services. They permit in particular interactions where the client invokes a single operation. New standards are needed if we want to support interactions involving several invocations. Indeed the sequences of invocations necessary to use a service must usually follow a given order and comply with business rules. The client and the server will have to obey these constraints. Examples A travel service will require the customer firstly to reserve his flight before actually paying or canceling it. The payment nor the cancellation can be done before the reservation. An online shop will require the customer to add at least one item to his shopping cart before checking out. These rules can be documented informally and then manually translated into the programming language used on the client and on the server. A

CHAPTER 1. INTRODUCTION

7

better approach is to use a declarative language to define the interaction rules, just as WSDL defines the interface of a web service. Having a standard, declarative language to define these interactions makes it possible to attach these service constraints to the definition of the service. Programmers can make use of these definitions, easing the development of compliant clients. The term conversation denotes a sequence of invocations that occur between the client and the server during a web service interaction. The term coordination protocol, or business protocol is used to denote the specification of the set of valid conversations. The coordination is focused on the external perspective of the interaction involving several invocations, nothing is being said about how to implement the mechanism to conduct these conversations (client and server side). A BPEL process can define a coordination protocol, using the notion of abstract process.

1.2.2

Composition and Workflow

The relevance of coordination pertains to the external view of the interactions. Composition concerns the internal part of the mechanisms implementing these compliant conversations. A composite service is a Web Service implemented by combining several other Web Services1 . The process of developing a composite service is called Web Service composition. Example: The Loan Approval Service. This service provides a Web Service port to which customers can send their loan requests. A loan request includes personal information of the customer and the desired amount. The automated service must send a reply to the customer with an ’approved’ or ’rejected’ message, it proceeds as follows. First, It checks if the amount is greater than $10.000. If it is, then the Loan Approval Web Service will be invoked by forwarding the request, passing the personal information and the amount requested. When called, the Loan Approval service takes a final decision that will be transmitted to the customer. If the amount requested by the customer below $10.000, a procedure is invoked on the Risk Assessment Web Service. If the Risk Assessment service tags the request as ’low’ risk, then the request is automatically approved. If the Risk Assessment service tags the customer request as ’high’ 1

Actually it is a combination of some of the operations offered by the involved Web Services.

CHAPTER 1. INTRODUCTION

Figure 1.2: The Loan Approval Service.

8

CHAPTER 1. INTRODUCTION

9

risk then the request is forwarded to the Loan Approval Web Service that takes the final decision. The Loan Approval Service is a Web Service obtained by composition of two Web Services: the Risk Assessment Web Service and the Loan Assessment Web Service. A more complex Web Service is here built from simpler ones. The coordination protocol imposes constraints on the composition, since the order of composition must be compliant with the rules defined by the coordination protocol. On the other hand, the internal composition defines the conversations the service (client or server) is able to execute. There is, thus, a tight relationship between the internal composition and the external coordination of a Web service. A BPEL process can define a composition of Web Services using the notion of executable process. Workflow When a customer makes a loan request to the Loan Approval Service, we say that a new case has started. This case will flow through the business process, i.e. the decision making procedure, presented above. Evolution of a case is discrete in nature, it has a beginning and an end, and can be uniquely identified. A workflow, or business process, consists of a number of tasks that must be performed and a set of conditions that determine the order and nature of these tasks. A task is a logical unit of work. In the Loan Approval Process the tasks are the reception of a request, the risk assessment, the loan assessment and the reply to the customer. There are two conditions. The first is based on the comparison of the requested amount and ’$10.000’, the second is based on the risk level. In [23], the authors identify four basic constructs of workflow structure: sequence, selection, iteration and parallelization. All processes can be, in principle, modeled with these basic elements. BPEL can be viewed as a language to define workflows, where the tasks are basic Web Service operations, like receive, invoke or reply.

1.3

Verification and Testing of BPEL Processes

The need to verify and validate BPEL processes is obvious. As with any other software system, validating the implementation against the expected behav-

CHAPTER 1. INTRODUCTION

10

ior is essential. Two popular methods are available for software verification and validation: model checking and testing. Model Checking [14] is a set of techniques for verifying properties of formal systems through modeling. Properties are often specified in Linear temporal Logic (LTL) or Computation Tree Logic (CTL). The system to be verified is first transformed into a model, e.g. a finite state machine. The desired properties of the system are expressed as properties of the model in such a way that if the properties hold in the model then it will hold in the system. Or alternatively, if the property does not hold in the model then it should be possible to deduce an execution of the system leading to the violation of the original property. The use of model checking and formal methods helps reduce the number of errors in the early stages of development of a software. In the later stages, testing is a popular method for verifying the correctness of the implementation against its expected behavior. Testers usually write test cases. A test case or unit test is the description of an input on which the software is to be executed. A test case can also contain the expected result or response from the program. The program passes the test if the actual response is the response that was expected. A set of test cases is called test set or test suite. In this paper we explore the results of the application of model checking techniques to the verification and testing of BPEL processes. In Chapter 2, we present the standards BPEL is relying on: XML, XML Schema, WSDL and XPath. In Chapter 3, we introduce the main concepts of BPEL. In Chapter 4, some important results on the verification of BPEL processes are presented. Finally in Chapter 5, we outline what has been done in the field of BPEL process testing based on model checking techniques.

Chapter 2 Web Services Basics Contents 2.1

XML - eXtensible Markup Language

. . . . . .

11

2.2

XML Schema

. . . . . . . . . . . . . . . . . . . .

12

2.3

WSDL - Web Services Description Language . .

16

2.3.1

Types . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.2

Messages . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.3

Port Types and Operations . . . . . . . . . . . . . 18

2.3.4

Example: The Loan Assessor . . . . . . . . . . . . 19

2.4

XPath . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.5

Conclusion

21

. . . . . . . . . . . . . . . . . . . . . .

In this chapter we present the main technologies BPEL is based on: XML, XML Schema, WSDL and XPath.

2.1

XML - eXtensible Markup Language

The Extensible Markup Language [26], known as XML, version 1.1 is a W3C Recommendation since February 2004. XML is a worldwide standard defining a way to encode structured data. A document following the XML specification is called an XML document. We very briefly, with an example, expose the basis of an XML document. An element is the basic construct of an XML document. It is composed of an opening () and a closing tag (). An XML document is a set of elements grouped in a tree structure, it has thus

11

CHAPTER 2. WEB SERVICES BASICS

12

exactly one root element. Elements can have child elements and attributes. The data is located within the element itself or one of its attribute. Example < t i t l e>B a s i c bread F l o u r Yeast < i n s t r u c t i o n s> Mix a l l i n g r e d i e n t s t o g e t h e r . Knead , p l a c e i n a t i n then bake i n t h e oven .

The recipe element is the root element, it has 4 child elements: title, ingredient, ingredient and instructions. It has 3 attributes: name, preptime and cooktime. An XML document is said to be well-formed if it complies with all XML’s syntax rules.

2.2

XML Schema

XML Schema [30], a W3C Recommendation, is a language for the description of a family, or type, of XML documents. An XML Schema, schema for short, is an XML document composed of a set of rules, that apply restrictions to elements, attributes and their content. An XML document is valid against a given schema if it conforms to its rules. While the well-formedness was a syntactic property, the validity of an XML document against a schema is a property about its structure and its content. The schema first defines a set of types, simple and complex, which are then used to define the valid XML structures by giving each possible element a type. We very briefly review, with a simple example, the main concepts of XML Schema. XML Schema has a powerful data type definition mechanism. It differentiates between simple types and complex types. Elements that have children and/or that have attributes are said to be of complex type. While attributes and elements without children and attributes are said to be of simple type. Simple types XML Schema has a collection of built-in simple types. The types are represented in the Figure 2.1 below, it includes: date, int, boolean, string, float,. . .

CHAPTER 2. WEB SERVICES BASICS

Figure 2.1: XML Schema data types [30].

13

CHAPTER 2. WEB SERVICES BASICS

14

Simple types can be derived from these built-in ones. The element simpleType declares a new simple type, it will be referred to with its name from the name attribute. In the example below, a new type nameType is declared and is of type string with a maximum of 32 characters. The type isbnType declares a string type that must be composed of 10 digits. < x s : r e s t r i c t i o n b a s e=” x s : s t r i n g ”> < x s : r e s t r i c t i o n b a s e=” x s : s t r i n g ”>

Complex type definition There is no built-in complex type. Complex types are defined with the complexType element. There are many available constructs to define complex types: the simpleContent Schema element is used to declare types of elements containing data within themselves, element declares a child, attribute Schema element declares an attribute and its type (limited to simple type), sequence Schema element declares an order list of subelements, minOccurs and maxOccurs Schema attributes are used to express the number of occurrences the concerned element can have, and so on. In the example below, a purchase order is declared. A valid element against that Schema type must have an attribute orderDate conforming to the date Schema type, and has an ordered list of children: a shipTo element, a billTo element, an optional comment element and one items element, all of their respective types.

CHAPTER 2. WEB SERVICES BASICS

15

Element definitions Element definition enforces structure by putting elements in hierarchical relation and giving them a type. The Schema element used for this is element. Example < x s : r e s t r i c t i o n b a s e=” x s : s t r i n g ”> < x s : r e s t r i c t i o n b a s e=” x s : s t r i n g ”> < x s : a t t r i b u t e name=” i s b n ” type=” isbnType ” />

A valid document against that schema is the following: < t i t l e> Being a Dog I s a F u l l −Time Job C h a r l e s M. S c h u l z

CHAPTER 2. WEB SERVICES BASICS

2.3

16

WSDL - Web Services Description Language

The Web Services Description Language [28], known as WSDL, is an XML document format for describing Web Services. The current version, WSDL 1.1, is a W3C note but was not endorsed as a W3C recommendation. Nevertheless, version 2.0 is expected to become a W3C recommendation in the near future. A WSDL document is composed of seven elements: Types definition of data types used in this service. Message definition of messages involved in the interactions with this service. Operation abstract operations. Port Type abstract group of operations supported by the service. Binding concrete protocol and data format for a port type of this service. Port binding and network address. Service a collection of ports. Types, Message, Operation and Port Type belong to the abstract part of the service description. The abstract part is clearly separated from the concrete part, i.e. Binding, Port and Service, to allow reuse of the abstract description. A WSDL document has the following structure: < d e f i n i t i o n s name=” . . . ”> [...] [...] [...] [...] [...]

CHAPTER 2. WEB SERVICES BASICS

17

In this document we are exclusively concerned with the abstract part of the description. We now describe the types, messages, operations and port type declarations.

2.3.1

Types

WSDL does not have a standard for data type definition, instead it is designed to be very flexible and has a mechanism for plugging in any data type system. WSDL does however use the XML Schema data type system by default (see Section 2.2). An WSDL engine implementation must support this data type system in order to be WSDL compliant. The types element enables the declaration of types into a WSDL document. In the sample below an array of string is defined in the standard XML Schema way.

2.3.2

Messages

Messages are the units of communication for Web services, they are used as input, output and reporting of faults of the operations. A message has a name and is a flat structure composed of ’parts’. Each part has a name and a type declared in the type element of the document. In the example below, messages creditInformationMessage, loanRequestErrorMessage, riskAssessmentMessage and approvalMessage are defined. The involved types must be defined in the types element of the document.



CHAPTER 2. WEB SERVICES BASICS

18



2.3.3

Port Types and Operations

Port types regroup operations under a port type name. An operation can be seen as a function in the C programming language. There are four types of operation: One-way. The service receives a message. Request-response. The service receives a message, and sends a correlated message. Solicit-response. The service sends a message, and receives a correlated message. Notification. The service sends a message. Operation definitions require a name, input parameters, an output type and the errors that can be raised during processing of the request. The input and output types are messages defined in the message element of the document. Depending on the type of operation the input, output and fault messages can or not be present. The example below illustrates the declaration of two port types, the loanApprovalPT and the riskAssessmentPT. Each contains a single operation using messages (for input, output and fault) defined in the message section 2.3.2. The riskAssessmentPT port type has one check operation that takes a creditInformationMessage as input and sends a riskAssessmentMessage as response. < f a u l t name=” l o a n P r o c e s s F a u l t ” message=” l o a n d e f : l o a n R e q u e s t E r r o r M e s s a g e ” />

CHAPTER 2. WEB SERVICES BASICS

19

< f a u l t name=” l o a n P r o c e s s F a u l t ” message= ” l o a n d e f : l o a n R e q u e s t E r r o r M e s s a g e ” />

2.3.4

Example: The Loan Assessor

A WSDL document starts with the definitions root element in which the namespace aliases that will be used in the document are usually declared. Subsequently, the types, messages, port types with operations, bindings and services section are declared. Putting all the above samples together, and adding some type definitions, we obtain the WSDL definition of the loan approval service. It defines a service with one port type, the riskAssessmentPT defined in Section 2.3.3. [...] [...]

. . . .

CHAPTER 2. WEB SERVICES BASICS

20

[...]



The bindings define the concrete message formats, protocol details for operations and messages defined by a particular port type. A port defines an individual endpoint by linking a binding to an address. Finally, a service groups a set of related ports together. The most popular binding practice is with the SOAP protocol [27]. WSDL includes a binding for SOAP 1.1 endpoints.

2.4

XPath

XPath [29], a W3C Recommendation since the 16th November 1999, is a query and expression language for XML documents. Originally, XPath aimed at providing a common syntax for functionalities shared between XSL Transformations (XSLT) and XPointer (XPointer), however it quickly evolved into an independent language for querying XML documents. The central construct of XPath is the expression. The evaluation of an expression on an XML document yields to an XML node, a set of XML nodes, a number, a string or a boolean value. The evaluation of the expression depends on a context. The context contains the XML document, a node, called the context node or current node, and other context informations. We illustrate XPath with a few examples. A path expression returns a node or a set of nodes. Examples: • author - returns the set of child nodes of the context node named author. • * - returns the set of all children of the current node.

CHAPTER 2. WEB SERVICES BASICS

21

• @name - returns the attribute named name of the current node. • /doc/chapter[5]/section[2] - returns the second section of the fifth chapter of the root node doc. • //recipe/ingredients - returns the all ingredients direct children of the root node recipe. • chapter[@number="3"] - returns the chapters whose attribute number is 3. • employee[@secretary and @assistant] - returns all the employee children of the context node that have both a secretary attribute and an assistant attribute. General expressions return number, string or boolean values: • 3.141529 - numeric constant. • 2+2 - additive expression. • ’All I Have Is Now’ - string constant. • true - boolean constant. • //recipe/ingredient[1][@quantity]

22

CHAPTER 3. BPEL

23

< f a u l t name=” l o a n P r o c e s s F a u l t ” message=” l n s : e r r o r M e s s a g e ” /> < f a u l t name=” l o a n P r o c e s s F a u l t ” message=” l n s : e r r o r M e s s a g e ” />

To each of these port types corresponds a partner link type. A partner link type is the association of a port type with roles. The roles are played by partners. However in this case the interaction are one way. Indeed, the loan service never invoke an operation of the customer and the loan assessor nor the risk assessor invoke an operation of the loan service. Thus each partner link just involved one partner. Partner link are needed to define a BPEL process.



There are four different types of message involved in the interaction with the Loan Approval Service. The creditInformationMessage sent by the customer and forwarded to the loan assessor, approvalMessage reply of the loan approval service (to the customer), riskAssessmentMessage in reply from the risk assessment service and errorMessage for all the interaction in case of failure.

CHAPTER 3. BPEL

24



These message types, port types and partner links must be defined in the appropriate WSDL documents. We can now define the BPEL process for the Loan Approval Service. Process Each BPEL document starts with the process element in which one usually declares the namespace that will be used in the document. In this case the default namespace refers to the BPEL namespace, lns refers to the appropriate WSDL definitions.



The first step is to declare the parties involved in the interaction. In this case there are four parties: the loan service, the customer, the approver and the assessor. We refer to the loan service as ’the service’, while the other parties are the partners. Each partner is declared in the partner element, child of the process element. A partner is given a name by which it will be referred in the rest of the BPEL document and is associated to the WSDL interface it is assumed it complies to. In the example below, the customer is involved in the loanApproavalLink as a client of this process which plays the approver, i.e. this process must comply to the loanApprovalPT which has only one operation: approve. The approver partner is involved in the same link type but it plays the role of the approver and this process plays the client (will invoke the approve operation of the approver). Finally the assessor plays the assessor in an riskAssessmentLink in which this process plays the client.



CHAPTER 3. BPEL

25



The second steps is to declare, in the variables element, the variables that are local to the process. These variables persist the state of the interaction. Each of the variable declared in a variable element is accessible during the whole life cycle of the process. These variables are identifiable with their names. Their types must be one declared in a WSDL message definition.

Now everything is in place to actually define the business process in itself. The process is defined as a flow. The flow construct permits launching several activities concurrently. The links defined in the flow scope permits to enforce precedence between these activities, i.e. it permits synchronization. In other words the flow construct associated with links permits defining an activity diagram. The process, as illustrated by the diagram in Figure 3.1, starts when the approve operation of the service is invoked, this is declared in the first receive element named receive1. Once this call is received, the link receiveto-assess is activated if the corresponding condition is true, else the receiveto-approval link is activated. Thus accordingly the assessor or the approver will be invoked. If invoked, the approver will trigger the reply. The assessor will invoke the approver that will trigger the reply or will activate the assign activity that will trigger the reply. The actual BPEL definition is little more than the translation of the diagram above with BPEL construct.

CHAPTER 3. BPEL

26

Decision

receive1

receive-to-assess receive-to-approval invokeAssessor

invokeapprover assess-to-approval

approval-to-reply

Decision

reply setMessage-to-reply

assess-to-setMessage assign

Figure 3.1: Flow diagram of the Loan Approval Service.. < l i n k s>



Finally, it is possible to declare fault handlers. A handler will be executed if the corresponding fault is triggered by any of the process activity. In this case, if a loanProcessFault is raised, the process will reply to the customer with an invalidRequest fault (which is defined in the WSDL document), containing the error message.

CHAPTER 3. BPEL

28



3.2 3.2.1

Overview of BPEL Language Process

. . .

. . . . . . . . . . . . . . . . . . [ Activity ]

The process element is the root of the BPEL document. It is composed of the following optional children: partnerLinks, partners, variables, correlationSets, faultHandlers, compensationHandlers, eventHandlers. These elements permits the global declaration of the corresponding constructs (partners, variables, fault handler, . . . ). Then the process elements contains the actual workflow definition with the top level activity declaration, one of the type described in the next section. An activity can be a basic activity: receive, reply, invoke, assign, throw, terminate, wait, empty or a structured activity which itself contains other activities: sequence, switch, while, pick, flow, scope, compensate We briefly describes each of these activities in Section 3.2.4 and Section 3.2.5 but first starts with the variables definition and the expressions.

CHAPTER 3. BPEL

3.2.2

29

Variables

The variables element of the BPEL document, a direct child of the process element, provides the means to define the variables that will store the state of the interaction during the whole business process. +

The type of each variable can be a WSDL messageType, an XML Schema simple type or an XML Schema element. The corresponding attribute should be used (messageType, type or element respectively). Variables declared with a WSDL messageType are the one that can be used as an input, output or fault variable of the invoke, reply, receive, throw constructs. The variables are uninitialized at the beginning of the process, the assign and receive are the constructs that can change the value of variables.

3.2.3

Expressions

Four types of expression are found in BPEL document. Boolean expressions are found in conditions (join, transition, while and case conditions). Deadline-valued and duration-valued expressions are found in onAlarm and wait constructs. Finally general expressions are found in assignment for simple calculation in the logic of the process. BPEL provides a flexible mechanism that enable to use any expression language for the expressions. However compliant implementations must support XPath 1.0 [29]. The specification explicitly states that XPath is not the ultimate solution and that the specification should evolve to support a more suitable expression language, including support for more nuanced constraints (e.g. string manipulation). The expressions are built upon the variables of the process and its links status. Accessing the variables and the link status (see Section 3.2.6) is done through extension functions to XPath: bpws:getVariableProperty(’variableName’, ’propertyName’) returns the value of the variable. bpws:getLinkStatus(’linkName’) returns a boolean corresponding to the status of the link. As example we have two boolean functions, one general expression (decreasing the counter ’tryCount’ of the variable ’assessment’), one duration (3 days and 10 hours) and one deadline expression:

CHAPTER 3. BPEL

30

• bpws:getVariableProperty(’stockResult’, ’level’)>0 • bpws:getLinkStatus(’AtoB’) and bpws:getLinkStatus(’CtoB’) • bpws:getVariableProperty(’assessment’, ’tryCount’) - 1 • ’P3DT10H’ • ’2002-12-24T18:00+01:00’

3.2.4

Basic Activities

The receive activity

The receive activity defines a blocking wait for a message matching the portType and the operation defined in the construct. Actually the receive construct is one (with the reply construct) defining the external interface of the Web Service defined by the BPEL document, i.e. every receive element defines an operation available at this Web Service. A business process MUST never have two receive activities for the same partner link, port type and operation active at the same time. In such a case the BPEL specification let the semantic undefined. The reply activity

The reply activity allows the process to send a message in response to a message received through a preceding receive activity with the same partner link, port type and operation. If there is not a preceding matching receive activity, then the BPEL specification let the semantic of the process undefined. Replies can be of two types. First, a reply can be a normal response, the variable attribute can be present and must match the declared response message type of the operation. The second type of response is a fault, in that case the faultName attribute is present and the variable attribute must match the message type of this fault’s variable.

CHAPTER 3. BPEL

31

The invoke activity + [ Activity ] [ Activity ] . . .

The invoke construct permits defining the invocation of a partner’s Web Service. The invoke activity requires the partner link, port type and the operation and optionally an input variable and an output variable, the latter only in the case the interaction is synchronous (indeed, in the case of asynchronous interaction there is no direct response). The nested catch construct defines the treatment of possible faults raised by the partner in handling the request. This can only occur in the case of synchronous interaction. The fault name must be one of the fault defined for this operation in the partner WSDL definition. A general catchAll element can also be used to treat all faults indiscriminately. Finally a compensation handler can be defined. Compensation handler are aimed at rolling back the effect of the activity in case of failure. They can be invoked explicitly or by the default compensation mechanism. Compensation handler and their mechanisms are explained latter on. The throw activity

The throw constructs is aimed at raising internal fault. It can optionally specify additional data that will be available to the fault handler, e.g. to handle the fault or populate the messages sent to calling services. The wait activity

or

CHAPTER 3. BPEL

32

The wait construct allows to specify a delay or a deadline during/before which the process is blocked. The empty activity

The empty activity is used when there is a need of doing nothing. The assign activity
+ . . . . . .

The assign construct enables to copy messages from one variable to another. The variables are the one declared in the top variable tag. More than just copy, the assign construct permits the use of general expressions (see Section 3.2.3) to perform simple computation often required to define a business process, and assigning the result to a variable.

3.2.5

Structured Activities

The sequence activity [ Activity ] +

A sequence construct contains a list of activities, basic or structured, that must be executed sequentially, following the order in which they are listed. The sequence activity completes when the last activity of the sequence has completed. The switch activity + [ Activity ]

CHAPTER 3. BPEL

33

[ Activity ]

The switch construct permits to define different behaviors of the process depending on boolean condition. The first activity whose condition is true will be executed. If all conditions are false the activity in the otherwise construct is executed, or an empty activity if the otherwise is not present. The boolean conditions are defined in Section 3.2.3. The while activity [ Activity ]

The while activity will execute the inner activity, basic or structured, as long as the boolean condition is true. The pick activity

+ [ Activity ] ∗ [ Activity ]

The pick activity is waiting for events to happen. To each event is associated an activity. The first occurring event will trigger the associated activity. All the subsequent event will be ignored. The pick activity completes when the triggered task completes. There are basically two types of events. The first type is the arrival of a message, i.e. a partner invokes an operation, defined with a onMessage construct, similar to a receive activity. The second kind of event is alarm based. It can be defined, as in the case of the wait activity, with a duration or an absolute deadline. It is defined with the onAlert element. The flow activity

CHAPTER 3. BPEL

34

< l i n k s> [ Activity ] +

The flow construct permits launching several activities concurrently. The links defined in the flow scope permits to enforce precedence between these activities, i.e. it permits synchronization. We present the link semantics in Section 3.2.6. The flow activity completes when all activities in the flow have completed. Completion of an activity however includes the possibility of it to be skipped. This happens when its enabling condition is false. This is explained in the Dead-Path-Elimination Section (3.2.6). The scope activity . . . . . . . . . . . . . . . [ Activity ]

The scope constructs defines the context, i.e. local variables, fault handlers, compensation handlers and others, of the enclosed activities. Its structure is similar to the process constructs. The compensate activity [ Activity ]

Compensation handlers permit recovering from a fault on a case by case basis, its role is to recover to the state before the activity started. The compensation handler will be called with the following rule: ’Run all available compensation handlers for immediately enclosed scopes in the reverse order of completion of the corresponding scopes’. However a compensation handler can also be called explicitly through the compensate constructs.

CHAPTER 3. BPEL

3.2.6

35

Links

The link construct enables the expression of synchronization between concurrent activities, that is somewhere in the scope of a flow element. A link has a name, a source and a target. In its simplest expression, the link express the fact that the target activity waits for the source activity to complete. Links are declared as children of the flow construct (see Section 3.2.5). Any activity can be declared source or target of a link, via the source or target attribute respectively. Each link must have exactly one source and one target. The source activity may also declare a transition condition through the transitionCondition attribute. This condition when evaluated, just after the source activity completes, will determine the status of the link: positive or negative if the condition evaluates to true or false respectively. The status of the link will determine if the target activity is executed or skipped. The target activity can also specify a join condition, i.e. boolean function dependent on the incoming links’ status, that will define if the activity will be executed or skipped. To determine if a concurrent activity can start or must be skipped three steps are taken. First it should be checked that without join condition the activity can start. Next, the status of all its incoming link should be determined (the source activities must have completed or been skipped). Finally, the activity is executed if the join condition evaluates to true and skipped otherwise. In case of normal execution the transition condition sets the status of the outgoing links, or, if absent, they are set to positive. however, if an activity is skipped, because its join condition evaluates to false, then all its outgoing links’ status are set to negative. The idea is that links set to false will lead to other activities being skipped. This phenomenon is called Dead-PathElimination. Example < l i n k s>

CHAPTER 3. BPEL

36



3.3

Conclusion

In this chapter, we presented the main concepts of the BPEL language. We saw that BPEL has four main characteristics. Firstly, BPEL has built-in constructs to interact with external WSDL Web Services through the invoke, receive, reply and throw constructs. Secondly, all data and messages are encoded in XML documents with a strong incentive to use XML Schema as the data type definition system. Thirdly, the data manipulation is done through XPath expressions. Finally, the flow construct associated with the link concept enables out-of-the-box definitions of concurrent executions.

Chapter 4 Model Checking BPEL Services Contents 4.1

4.2

4.3

Petri Nets model . . . . . . . . . . . . . . . . . . .

38

4.1.1

Mapping BPEL into Petri Nets . . . . . . . . . . . 38

4.1.2

Static Analysis of BPEL Processes . . . . . . . . . 43

Guarded Automata Model . . . . . . . . . . . . .

45

4.2.1

Guarded Automata Peers Model . . . . . . . . . . 46

4.2.2

LTL Properties . . . . . . . . . . . . . . . . . . . . 47

4.2.3

From BPEL to Guarded Automata to Promela . . 48

4.2.4

Results . . . . . . . . . . . . . . . . . . . . . . . . 52

Conclusions . . . . . . . . . . . . . . . . . . . . . .

53

Model checking of BPEL services has been the attention of quite a lot of works recently. In [3, 8] the authors use finite state machine models to formalize and check LTL properties of BPEL processes. Their modeling stays at the control flow level, abstracting the data manipulation part of the process. Petri nets modelization is popular too. Indeed the control flow constructs found in BPEL are inspired by the concepts found in workflow definition languages and thus very close to them. The Petri net model has been shown to be a powerful tool to analyze workflow [23]. The Petri net based analysis of BPEL processes has been studied thoroughly in [15, 21, 31]. Abstract state machine models are also applied to the verification of BPEL processes in [5, 6]. Finally process algebra is also a natural fit to verify temporal logic properties as well as concurrent ones. Koshkina [16] verifies a simplified version of 37

CHAPTER 4. MODEL CHECKING BPEL SERVICES

38

BPEL, called the BPE-calculus, using the Concurrency Workbench of New Century (CWB), a general tool for verifying finite-state concurrent systems. Some efforts is also invested in process algebra in [7]. We choose to briefly introduce the Petri net modelization of van der Aalst et al. [18] since it is the first full formalization of control flow of BPEL processes. Moreover their formalization culminates in an automated tool that permits useful static verification. Finally we present, also very briefly, the work of Bultan et al. Their work [9] is the first attempt to verify BPEL processes including modelization of the data manipulation part of the process, i.e. the XPath expressions.

4.1

Petri Nets model

W. van der Aalst et al. validate the soundness of using Petri nets as a model for the analysis of the control flow of BPEL processes. This is achieved through a complete mapping of the control flow constructs onto Petri nets. As a first result, a fully complete formal semantics for BPEL processes at the control flow level is obtained [18]. This formal Secondly, a tool, wofBPEL [19] , automating this mapping and the static analysis of the resulting Petri net was developed. The automatic translation from BPEL to PNML, Petri net modeling language, is performed via BPEL2PNML. So that wofBPEL can statically analyze the corresponding Petri net and thus the modeled process. We briefly presents this mapping now.

4.1.1

Mapping BPEL into Petri Nets

Activity Activities are modeled as shown in Figure 4.1. An activity can have a number of targets (incoming links). For each of these targets we have two places, one for the positive status (true target) and one for the negative status of the link (false target). The join condition (see Section 3.2.6) is a boolean condition over the set of targets, it is modeled with the arcs linking the target and the ’sf’ and ’st’ transitions. There will be one ’st’ transition for each set of target values such that the join condition evaluates to true. And exactly one ’sf’ for each set of target values such that the join condition evaluates to false. When the activity has completed the transition ’et’ or ’ef’, depending if the activity has been skipped or not, forwards the token to the correct value of the sources and puts a token in the end place.

that will be traversed if this activity has either been completed or skipped. If skipped, the corresponding link will have a negative status. If completed, then an optional transition condition determines its status. The targets are the incoming st et start. Aend links that needstart to be traversed beforeActivity this activity can traversed target can have either a positive or started a negative status. completed CHAPTER 4. MODEL CHECKING BPEL SERVICES

false targets start

Fig. 2. Mapping for skipa link-less activity. sf

ef

39

false sources end

Figure 2 shows how we map an activity without sources or targets. Becaus Activity et st truemust refer trueflow activity highe ny source or target to some link defined in some targets sources started p in the hierarchy, the top activity in thecompleted hierarchy cannot have sources o rgets. Thus, this top activity will have exactly one source place (start) an Figure 4.1: Petri net representing an activity. xactly one sink place (endFig. ). 1. Mapping for an activity.

2

Figure 1 Links

The activity itself is a sub-petri-net, one of the constructs presented below. The source and target places are components of links that we present shows how we map this onto a Petri net fragment. The now.

place start contains a token if the hierarchical structure enables this activity. For every target, a trueLinks place and a false place are present. If the corresponding link has been traversed, either the true place contains a token (indicating that the link has a positive status) or the false false place contains a token false (indicating that the link ff sourcejoin condition is mappedtarget has a negative status). The onto a set of st (start true) transitions: One st transition for every valid combination of targets. For every tf invalid combination of targets, a sf (start false) transition is present. If the set of positive targets is valid, that to “true”, then the true true is, if the join condition evaluates tt target source activity is started. After the activity has been completed, the corresponding et (end true) transition forwards control to both the next activity in the hierarchical structure (through placeFigure end )4.2:and tonetthe sources.a Link If the Petri representing [25].set of positive targets is Fig. 3. Mapping for a link.

The links (see Figure 4.2), in the model of van der Aalst are actually a model of the transition condition. If the activity has been skipped, the false source has a token, this token is passed along to the negative target (deathIf theaprevious activity a executed the positive If the sourc gure 3 showspth-elimination). how we map link onto Petrinormally, net fragment. source has a token, which will be passed to the positive or negative targets ctivity was skipped, then place false source contains a token, and we simply hav following the transition condition of the BPEL process. For every source and of an path activity elimination) we will have such ato construct pass this negative control ontarget (dead the target activit modeling its link. However some activities don’t have any source, nor a hrough the place false target. If the source activity was completed, then plac target, these are simply modeled as below.

ue source contains a token, and the transition condition determines whethe positive control or a negative control needs to be forwarded. If the transitio ondition evaluates to “true”, then a positive control is forwarded through plac ue target (that is, transition tt fires), otherwise a negative control is forwarde hat is, transition tf fires). Note that transition tf (true false) is absent if n ansition condition is given for this link.

that a roll back will set the status of all its incoming links to positive. Because the activity had been started, its join condition must have been evaluated to “true”, and we assume that a join condition will evaluate to “true” if all incoming links have a positive status. Therefore, it seems safe to roll back to a state where all incoming links have a positive status. CHAPTER 4. MODEL CHECKING BPEL SERVICES

3.4

40

Sequence Activities Sequence

Activity A

Activity B

Activity C

started

completed

Fig. Mapping a sequence activity. Figure5.4.3: Petri net for representing a Sequence [25]. A Sequence construct is trivially modeled by putting the activities in sequence linking each activity to the next (Figure 4.3. The Sequence completes activity contains set of activities, and takes care of when the last activity ordered has completed.

A sequence executing these contained activities in the given order. Figure 5 shows how this can be Switch onto a Petri net fragment. (trivially) mapped between Activities A, B and5C (and can be in modeled in Figure to 4.4. come), it is AlthoughA itswitch is not shown in Figure manyas figures With one token in the started place, one of the Activities A, B or C will possible that links exists between enclosed activities. For example, there could execute. The actual switch condition is not modeled and thus is part of be links fromtheActivity to Activity C,model, fromit Activity tofor Activity ’black-box’Bassumptions of the is supposedA that any of theC, and there condition is some run inactivities which this condition be sequence. true. could be even links there to and from outsidewill the Figures 1 and Moreover in the BPEL specification a switch statement is an ordered sequence of activities with an associated condition, the first activity with its condition evaluating to true will be executed. This model, since it’s not taking into account the actual condition, cannot detect that an activity can never execute if, for example, its associated condition is true only when a prior activity’s condition is true. Finally the BPEL specification asks for an empty activity being executed when none of the condition is true. How the translation process deals with this problem is not clear (adding an empty activity or not?). While The while construct will execute Activity A as long as a condition is true (Figure 4.5). This model abstracts the condition and thus suppose Activity A will or will not execute eventually. The While activity completes as soon as the condition is false.

3 show how such links are mapped onto Petri net fragments, which extend the Petri net fragment resulting from Figure 5. CHAPTER 4. MODEL CHECKING BPEL SERVICES

3.5

41

Switch Activities

Activity A

Activity B started

completed Activity C

Fig. 6.4.4: Mapping a switch activity. Figure Petri net for representing a Switch [25].

A switch activity contains an ordered set of activities with associated conditions, and executes the first contained activity for which the associated condition evaluates to “true”. The last activity in the ordered set of activities can be an otherwise activity, for which the associated condition always evaluates to “true”. If no otherwise activity is present, an empty otherwise activity is considered present. ct Thus, one of the associated conditions will evaluate to “true”. Figure 6 shows how we can map this onto a Petri net fragment. Note that we abstract from the started Activity A actual conditions and the order in which they are evaluated. Also note that in case all conditions can evaluate to “false”, we need to add an empty activity, that is, a transition that forwards control from the started place to the completed completed cf place. Note that each of the activities in a switch may have links. As a result, parts of the model may not while they contain Figure 4.5:executed Petri netfor representing a activity. While [25]. links that may block Fig. 7. be Mapping a while concurrent activities. Although [5] is not completely clear about the semantics such constructs, the text “If, during the performance of structured activity S, thetransition semanticsctof(condition S dictate that activity X nested withinto S the will contained not be performed en true) will forward control activity as partactivity of the behavior of S, then theput status all outgoing X is setconto When A completes, it will theofcontrol back. links If thefrom associated negative.” (page 65, [5]) transition suggest that need tofalse) be taken anyway. the A similar tion evaluates to “false”, cf links (condition will forward control problem occursplace, on theindicating receiving side. thiswhile paper, we willhas abstract from these the completed that In this activity now completed. problems and assume that both the source and target of a link are traversed or both are skipped. This problem is not limited to switch activity but also applies

7

Pick Activities

A. When activity A completes, it will put the control back. If the associated condition evaluates to “false”, transition cf (condition false) will forward the control to the completed place, indicating that this while activity has now completed. 3.7

Pick Activities

CHAPTER 4. MODEL CHECKING BPEL SERVICES

event A

Activity A

event B

Activity B

started

Activity C

42

completed

Figure 4.6:8.Petri net representing a Pick [25]. Fig. Mapping for a pick activity.

A pick activity contains a (non-zero) number of onMessage elements and a (posActivity A sibly zero) number of onAlarm elements. Each onMessage element contains a reference to some event, a possible set of correlations, and an activity. As soon as Activity B aj as the event has occurred, the pick activity can start the corresponding activity. completed Each onAlarm started element contains either a absolute time or a relative time, and Activity C has been reached or the relative time an activity. As soon as the absolute time has been passed, the pick activity can start the corresponding activity. A pick activity starts only one activity. After it has started an activity, a pick activity Fig.has 9. for aAflow Figure 4.7:Mapping Petri net representing Flow [25]. completes as soon as its waits until that activity completed. pickaactivity. activity started activity completes. Figure 8 shows how we can map this onto a Petri net fragment.Pick parallel. However, due tocontains the link structure, activities might not be able to A pick construct a set of activities some each waiting for an event to start (Figure 4.6). The first activitycompletes that receivedas thesoon expected event execute. activities start immediately. A flow activity as all itswill contained 3.8 Flow Activities The pick activity9 completes whenwe the can started innerthe activity has completed. have completed. Figure shows how map hierarchical structure onto A flow contains a number of links a (non-zero) of activia Petri netactivity fragment, for the link structure weand refer to Figure 1number and Figure 3. Flow In the hierarchical structure, all contained activities are enabled In ties. Figure 9, transition as activity (AND-split) enables all activities, and transition aj in In a flow construct, all activities are executed concurrently, this is modeled by (AND-join) producing completes the flow activity. a token in the started place of each of the activities (Figure 4.7). 3.9

A

The Flow completes when all the concurrent sub-activities have completed. This is achieved by the ’aj’ transition that can fire only when all the subactivities have completed, placing a token in the corresponding place. Reduction

false targets

ef

sf skip

start st

false sources end

et

places “started” and “completed”. As a result, we will show places like “start” and “true sources” only if they are relevant for the activity at hand. 3.3

CHAPTER 4. MODEL CHECKING BPEL SERVICES

43

Basic Activities

Basic Activity

started start

true targets

completed false sources

c

b

a

end

4.8: Note Basic activity mapping [25]. Fig. 4. Mapping for a basic Figure activity. that standard connections shown in Figure 1 have been omitted. A Basic Activity (reply, receive, invoke. . . ) is modeled with the Petri net in Figure 4.8. The ’c’ transition denotes the normal execution of the activity, the ’a’ transition models its abortion and the ’b’ transition is for rolling back of the(like, activity.for example, invoke, receive, and reply) does activity

A basic not contain any other activity. A basic activity can be completed, aborted (by not catching a 4.1.2 Static Analysis of BPEL Processes thrown exception), or rolled back (using a compensation handler). Figure 4 shows [24] is a state-of-the-art Petri-net-based analysis tool for verifying the how we map Woflan this onto a Petri net fragment. Transition c models the completion correctness of a workflow process. Woflan was developed by Eric Verbeek and of the activity, abortion, andin transition b its rolling Wil transition van der Aalst a as aits tool to detect errors workflows formalized as WF- back. Note net.will Theyset extended this toolof in all a natural way to handle BPEL by Because the that a roll back the status its incoming links toprocesses positive. simply pluging-in an automatic translator of BPEL processes to PNML, the activity had been started, join condition must have been evaluated to “true”, Petri-net modeling its language. and we assume that a join condition will evaluate to “true” if all incoming links Reachability Analysis have a positive status. Therefore, it seems safe to roll back to a state where all Reachability all activities is desired for any BPEL process, i.e. the posincoming links have a of positive status. 3.4

sibility for any one of the activities that appear in the process definition to be executed. This won’t be the case if we have some dead transition in the corresponding Petri net. Sequence Activities The authors deployed, without receiving any warning from the BPEL container, the BPEL process described below. It is easy to see that the empty activity named ’nonEric’ can never execute. Indeed, for this activity to execute the link ’linkEric’ must be activated and thus the condition of the first ’case’ of the switch construct must be true. This is not possible since Activity Activity B we are already in Athe otherwise condition. The processActivity will C wait infinitely for the link to be activated. started

completed

Fig. 5. Mapping for a sequence activity.

A sequence activity contains ordered set of activities, and takes care of executing these contained activities in the given order. Figure 5 shows how this can be

CHAPTER 4. MODEL CHECKING BPEL SERVICES

44

< l i n k s>

Using WofBPEL the deadlock was reported. Moreover the tool accurately points the empty task in the otherwise construct to be the cause of the error. Competing Message-Consuming Activities In Section 3.2.4 we mention that “A business process MUST never have two receive activities for the same partnerLink, portType and operation active at the same time”. In short, a process cannot have two competing messageconsuming activities, competing being interpreted as above: same partner link, port type and operation. More generally, this constraint must hold for any consuming activity, which are not only the receive activities but also the pick activities and the event handlers.

In [20] the petri nets model permits detection of processes violating this constraint. In the example above, two sequences are run concurrently. If invoke ’A1’ and receive ’rcv2’ have completed, then ’rcv3’ and ’rcv1’ are competing for the message ’pl2/pt2/op2’. To discover this competing messageconsumption violation a full state space search was needed. Garbage Collection of Queued Messages Using the same model, it is possible to compute for each activity ’a’ of a process all the possible message types that could eventually be consumed by the process after the execution of ’a’. Computing this set for each activity enables the annotation of the BPEL process, by indicating for each activity the message types that are still relevant to the process. If the process, after execution of activity ’a’, receives a message that is not in the corresponding set of message types of ’a’, then this message can be discarded (garbage collected).

4.2

Guarded Automata Model

In the Loan Approval Service, we find 3 partners: the Loan Approval Service, the assessor and the customer. Each of these services could possibly be implemented as a BPEL process. They can be viewed as interacting distributed processes (Figure 4.9). In this paper [9], Xiang Fu et al. expose a method to transform interacting BPEL processes into Promela, the input language of the well-known SPIN model checker. This enables them to check the BPEL processes against LTL properties. Moreover, building on previous work [10], their translation allows for the handling of XPath expressions which are central to control the flow of the BPEL process. This constitutes an interesting enhancement over older approaches that were completely abstracting the data manipulation part of the process. This leads to a more fine grained verification.

andards for web services dation. Since communied on different locations tforms, agreeing on a set

Customer

RACTIONS

46

Assessor

risk assessment service. services. In particular, One can use pre- and post-conditions to associate behavmodel as an intermediate ioral descriptions for “atomic” web services that are speciervices results in a modfied in WSDL [17]. These pre- and post-conditions can be or our web service analused to reason about the composed behaviors of web services ecification languages can [13]. However, BPEL provides more expressive behavioral d various model checking descriptions. BPEL not only allows manipulation of XML ty analysis introduced in data structures using XPath expressions [26], but also proback-end. CHAPTER 4. programming MODEL CHECKING vides constructs BPEL such asSERVICES sequence, conditional as follows. Section 2 disand case statements, parallelism, and loops. ces and interaction modr the technical problems efines a formal model for n 4 presents two translaLoanProcess rded automata, and from pectively. Section 5 imction 4 by proposing the ives sufficient conditions on 6 concludes the paper.

Figure 3: Interacting BPEL Web Services

Figure 4.9: Loan Approval Service Interactions [9]. 622 Finally they exhibit the synchronizability concept as a way to handle infinite queues. This important result permits the complete verification of properties of a large class of Web services with unbounded input queues.

4.2.1

Guarded Automata Peers Model

As intermediate representation between BPEL and Promela the authors use a model based on guarded automata communicating through message queues. The model consists of three elements (Figure 4.10). Firstly a conversation schema declares the communicating peers, i.e. the BPEL processes involved, and all the possible type of messages that they can exchange. In the example below there are three peers (A, B and C) with msg1 the only message type that A can send to B, msg2 and msg6 the possible types of message peer B can send to A, and so on. Secondly, there are the guarded automata peers that represent the BPEL processes them self. A message queue that store the incoming messages sent by the other peers is attached to each automata. Finally a virtual watcher records all the messages by all peers in the order that they are produced. It actually records the whole conversation. A guarded automata, here, is a tuple (Miin , Miout , Li , si , Fi , ∆i ). Miin is the set of incoming message types, Miout is the set of outgoing message types, Li are the local variables, and Ti , si , Fi are the states, the initial state and the set of final states. All the messages, in and out, as well as all the values of the local variables are all XML documents. ∆i is the transition relation. A transition t ∈ ∆i is in one of the following three forms: (q1 , g, q2 ), called a local transition, (q1 , ?a, q2 ), a receive transition and (q1 , (b!, g), q2 ), called a

CHAPTER 4. MODEL CHECKING BPEL SERVICES

Conversation Schema

msg1

Peer A

Peer A

msg2, msg6

msg4

Peer B

Input Queue

In our model, messages are XML d messages correspond to XML Sche type c ∈ M , let dom(c) denote all th are of type c. Given a set of mess the message alphabet as Σ = c∈M element m ∈ Σ is called a messag denote the type of message m. We s of type(m).

Peer C

Peer C

Peer B !msg1

msg3, msg5

?msg1 !msg3

?msg3 !msg2

?msg2 ?msg5

!msg5 ?msg6

!msg6

... Virtual Watcher

!msg4

?msg4

?

47

G(msg1 ⇒F(msg3 ! msg5)) LTL property

Figure 4: A Simple Example Demonstrating Our Model

Figure 4.10: Guarded Automata model [10].

3.1 Guarded Automata Pee

For each peer pi , its implementat tomaton (Miin , Miout , Li , Ti , si , Fi , ∆ are incoming (outgoing) message ty of local variables for pi , and Ti , si , the initial state, and the set of final s messages, we assume that local vari uments. For each local variable l ∈ denote all the XML documents that laration of l. Similar to message t variables also correspond to XML S

Figure 3 shows a part of the composite loan processing

Each transition τ ∈ ∆i of the gua send transition. ofthat these transitions change the state the peer from q1 webEach service includes LoanProcess, Assessor, andof Cuspeer pi has a source state q1 ∈ Ti tomer. individualcondition services mayand be specified BPEL or, to q2 . The guard g isThe a boolean a set ofinassignments. Send q2 ∈ Tand i and is in one of the followin in simple cases, WSDL. The directed edges represent the local transition are executed only if the guard condition evaluates to true. communication links among the individual services. Note τ = (q1 , g, q2 ) The receive transition executes when the corresponding message is 1.atlocal-transition, the that Assessor may contact Customer directly. As a result, tion guard. The transition c front of the message queue theservice peer. that Thecan assignments of the send transitions there is no singleofweb keep track of automaton from q1 to q2 and “global” state of the service execution (i.e., there is no meables represent the content of the message being sent. The assignment of local based on the guard g. diator process as described in [13]). Clearly, analyzing intertransitions update local The guard actions the of such webvariables. services presents a great conditions challenge dueand the2.guard receive-transition, τ = (q1 , ?a assignments are XPath expressions, to their distributed behaviorjust [13].as in the BPEL process. The transition changes the s goalproperties in this paper to analyze and verifyi.e. properfrom In order to Our verify onis the conversation, the sequence of q1 to q2 and removes th ties of composite web services consisting of multiple BPEL type a) from the input queue messages exchanged, allcommunicating the messagesasynchronously sent between peers web services such as theare one recorded in a virtual watcher, concept introduced in [11]. Every message being added to a shown in Figure 3. 3. send-transition, τ = (q1 , (!b, g and g is the transition guard. peer’s message queue is also added to the virtual watcher in the order they the state of the automaton fro are produced.3. A FORMAL MODEL FOR the sent message (of type b) to receiving peer. INTERACTING WEB SERVICES

give a formal model for composite Note that, sent messages are not re web services which consists of multiple peers communicating chronously, rather, they are instan with asynchronous messaging. 4 gives informal il-on the converThe authors used LTL formulas [17] to Figure express the an properties the appropriate input queue. A m lustration of our conversation based model. A composite after it moves sations. The web LTLservice formulas areofbased on twoschema type of atomic propositions, a to the head of the inp consists a conversation that specifies A guard consists of a guard con peers and the transmitted peers, message type the m set or of a predicate onmessages the message typeamong m.pred. signments. A send- or local-transit and a set of guarded automata specifying the behavior of guard condition evaluates to true, each individual peer. As communication among web serhave no guards because they simp Example vices is asynchronous, each peer is equipped with a FIFO from the head of the input queue queue to store incoming messages. We assume that there send-transition, then the assignmen • G($register -> watcher F($accept v $reject)) is a virtual which records the sequence of messages the contents of the message that is b as they are sent by the peers. The sequence of messages tion is a local-transition, then the a recorded by the watcher is-> called a conversation. (Note that • G($register//stockID==a F($request//stockID==a)) update the values of the local varia the virtual watcher is a construct we use to reason about Given a send-transition τ = (s, (! the interactions among different peers and it is not implethe sender for the message type b, g mented.) A conversation can be regarded as a linearization the following form: g(m, m " × "l ), w of the message events, similar to the approach used in definbeing sent, the vector m " contains t ing the semantics of Message Sequence Charts [16] in [1]. message type that is received or sen Formally, a composite web service is a tuple S = !(P, M ), Miout ) and "l represents the values A1 , . . . , An ", where (P, M ) is a conversation schema, n = Li . |P | and each Ai is an implementation for peer pi ∈ P . A Given a local-transition τ = (s, g conversation schema is a pair (P, M ) where P is a finite set is a predicate of the following form of peers and M is a finite set of message types. Each message type c ∈ M is transmitted between only one pair of peers. and "l are as described above, and

4.2.2

this section, we LTLInProperties

CHAPTER 4. MODEL CHECKING BPEL SERVICES

48

The first proposition (which has nothing to do with the previous example), based on message types as atomic propositions, states that each message ’register’ will be eventually followed by an ’accept’ or a ’reject’ message. The second, an example of formula with predicates on message content, states that every stockID that appears in a register will finally appear in a request message. In order to verify that a BPEL process satisfies a property, the author developed a translation tool from BPEL to the guarded automata peers model and from this model to Promela, the input language of the SPIN modelchecker which verifies LTL properties. However even in a simple case verifying properties is not decidable [9]: “Given a composite web service S with finite content and an LTL property φ, checking that S satisfies φ is undecidable”. A web service composition is said to be with finite content when the set of all possible messages (not just the message types) in the system is finite. Since this result is due to the presence of unbounded message queues, putting a bound on these queues enables verification and the use of the SPIN model checker.

4.2.3

From BPEL to Guarded Automata to Promela

BPEL to Automata Model Translating the BPEL definition to the guarded automata can be done in two steps. First, the conversation schema must be derived. Then each guarded automaton is produced from the BPEL document. The conversation schema consists of, firstly, the declaration of the peers, one per BPEL input document. Secondly the message types, as well as their senders and receivers, are easily deduced from the BPEL and WSDL documents of the partners in all interactions. These message types of the conversation schema must be unique for a sender, a receiver and an operation. The translation of BPEL documents into extended guarded automata is similar to its translation into Petri nets as in the previous section. The table below exemplifies the translation of the assign, receive, invoke, sequence and flow constructs. The XPath expressions are directly translated into guard conditions and assignment expressions. The flow construct is translated through a Cartesian product of all subactivies (interleaving).This may lead to a great number of states in the resulting automaton and has a scaling problem as a consequence.

CHAPTER 4. MODEL CHECKING BPEL SERVICES

BPEL

Sample Code

assign



receive



invoke



49

Translation

[ aprvInfo / accept := ‘yes’ ]

[request := approve_In] ? approve_In

[approve_In := request] ! approve_In loanfault ? loanfault

!

? approve_Out

handler1 [aprvInfo := approve_Out]

!

fault1 act1

fault2 !

act1 [b_link1 := cond1 ]

act2

[b_link1] product

act2

Figure 5: From BPEL to Guarded Automata

Figure 4.11: Translation to Guarded Automata Model [10]. We first construct the conversation schema, and then translate the control flow of each BPEL process. As BPEL process specifications are fed as input, the peer list P of the schema tuple (P, M ) is already known. Message types M are extracted from WSDL files. For each input/output/fault parameter of an operation in each port and each service link of each BPEL process, a message type is declared. For example if a BPEL process loanProcess has an operation approve declared in a port aprvPT, and its input parameter is of WSDL message format creditInfo , a message type loanProcess aprvPT approve In will be declared in the com-

tion expresses the ass different approaches f word part used in the We translate all of th and these XPath exp guards of the generate is translated into a two transition receives the signs the input variab invoke statement is tr first transition sends that is being invoked, ceive the response and there are no exception during invoke, and w tions to handle them which leads to an “ex about the fault is asso a fault handler is wrap translator connects th exception exit. BPEL control flow and while are used t cussed above. In Fig sequence. We connect local transitions, and except the last one. T are recollected and pr constructs can be han trol flow to the transit for flow construct (w its branches), we simp all its branches. The among the activities each link into a boole reflected in the guard activity. Translation of the c chines or petri-nets h ference in our work is nipulation using guar as XPath expressions about XML data ma done using approache stract away the data c

4.2 Translation

CHAPTER 4. MODEL CHECKING BPEL SERVICES

50

Automata to Promela Translating a model composed of a conversation schema and the corresponding guarded automata into Promela is not an easy task. The main difficulties reside in the translation of the types and of the XPath expressions. This translation can be presented in 4 steps: types, processes, channels and XPath. Types The types of the variables in a Promela specification are essential to the success of the verification. Indeed, the state space explosion problem is directly linked to the size of the domain of the system variables, i.e. their types. Each type of the specification is mapped to a typedef in Promela. Strings are used only as constants, they are mapped to the enumerated type of Promela, mtype. Boolean and numeric types are mapped to the corresponding Promela types. Processes Each automaton is translated into a Promela process, proctype. Inside each proctype, corresponding to an automaton, i.e. corresponding to a BPEL document, we find the declaration of the local variables, corresponding to each variable of the BPEL document. Moreover an additional variable is declared to record the current state of the automaton. The process itself is composed of a single loop. This loop contains one big switch/case statement. Each branch, or case, of this statement corresponds to a transition of the automata. The condition for the branch to be taken is, firstly that the current state of the automaton is the source state of that transition and secondly that the corresponding guard condition evaluates to true. The guard condition is an XPath expression that must be translated as explained below. Furthermore, for receive transitions, the corresponding message is also required, i.e. a message of that type must be in the process channel. A send transition is translated in a similar way. Finally a final transition will be translated into a jump out of the loop. Channels The queue of the automaton is associated with a Promela communication channel. The Promela channels have a finite fixed length, this corresponds to bounded queues. While this is a serious restriction on the model, the author exhibited a property ’synchronizability’ that permits the full model checking of a large class of BPEL processes with unbounded queues.

CHAPTER 4. MODEL CHECKING BPEL SERVICES

51

XPath XPath translation is hard. In [10], the author proposes a method for translating bounded XML data and XPath expressions into Promela. Since SPIN is a finite state system verification tool, the model variables must all be bounded. Thus the XML data in this case are supposed to be bounded, i.e. there should only be a finite number of XML documents as possible value of a variable. While we will not introduce the method here, we give an example of the translation that speaks for itself on the complexity of the task. We observe that this simple XPath leads to a complex Promela translation containing 5 integer and 4 boolean variables. This could leads to into scalability issues due to the state explosion problem. $ r e q u e s t // s t o c k I D / i n t ()= $ r e g i s t e r // s t o c k I D [ i n t ( ) > 5 ] [ p o s i t i o n ()= l a s t ( ) ] / i n t ( )

translates into: /∗ r e s u l t o f t h e XPath e x p r e s s i o n ∗/ bool bResult = f a l s e ; /∗ r e s u l t s o f t h e p r e d i c a t e s 1 , 2 , and 1 r e s p . ∗/ b o o l bRes1 , bRes2 , bRes3 ; /∗ index , p o s i t i o n ( ) , l a s t ( ) , index , p o s i t i o n ( ) ∗/ i n t i1 , i2 , i3 , i4 , i 5 ; i 2 =1; /∗ pre−c a l c u l a t e t h e v a l u e o f l a s t ( ) , s t o r e i n i 3 ∗/ i 4 =0; i 5 =1; i 3 =0; do : : i4 < v r e g i s t e r . requestList . stockID occ −> /∗ compute f i r s t p r e d i c a t e ∗/ bRes3 = f a l s e ; if : : v r e g i s t e r . r e q u e s t L i s t . s t o c k I D [ i 4 ] . i n t v a l u e >5 −> bRes3 = t r u e : : e l s e −> s k i p fi ; if : : bRes3 −> i 5 ++; i 3 ++; : : e l s e −> s k i p fi ; i 4 ++; : : e l s e −> break ; od ; /∗ t r a n s l a t i o n o f t h e whole e x p r e s s i o n ∗/ i 1 =0;

CHAPTER 4. MODEL CHECKING BPEL SERVICES

52

do : : i1 < v r e g i s t e r . requestList . stockID occ −> /∗ f i r s t p r e d i c a t e ∗/ bRes1 = f a l s e ; if : : v r e g i s t e r . r e q u e s t L i s t . s t o c k I D [ i 1 ] . i n t v a l u e >5 −> bRes1 = t r u e : : e l s e −> s k i p fi ; if : : bRes1 −> /∗ s e c on d p r e d i c a t e ∗/ bRes2 = f a l s e ; if : : ( i 2 == i 3 ) −> bRes2 = t r u e ; : : e l s e −> s k i p fi ; if : : bRes2 −> /∗ t r a n s l a t i o n o f e x p r e s s i o n ∗/ if : : ( v r e q u e s t . s t o c k I D . i n t v a l u e == v r e g i s t e r . r e q u e s t L i s t . stockID [ i 1 ] . i n t v a l u e ) −> b R e s u l t = t r u e ; : : e l s e −> s k i p fi : : e l s e −> s k i p fi ; /∗ update p o s i t i o n ( ) ∗/ i 2 ++; : : e l s e −> s k i p fi ; i 1 ++; : : e l s e −> break ; od ;

The full translation is shown in [9]. More important are the concrete results of the application of this technique and their scalability problems. This is presented in the next section.

4.2.4

Results

In contrast to previous work, Bultan et al. present an approach that does not abstract the data manipulation part of the BPEL process. Their tool, WSAT [22], permits the verification of LTL properties of interacting BPEL processes with bounded queues. WSAT also checks if the process verifies the

CHAPTER 4. MODEL CHECKING BPEL SERVICES

53

synchronizability property and if it is, proceed to the appropriate modification of the model that permits the verification of the LTL properties, the results are then still valid for unbounded queues. While a class of processes can be verified with unbounded queues, the processes that are synchronizable, there are still lots of processes that do not verify that property and thus the verification of LTL property are limited to finite queues for these processes. Moreover, the method does not scale well. In their conclusion, the authors report on their experiments on a model containing 3 peers: “When integer domain is set to [0,1], the verification time is 3 seconds and memory consumption is around 50MB. When the domain is increased to [0,3], the memory consumption grows to over 600MB. However, our experience shows that SPIN is still useful in identifying errors in protocols by restricting the data domains”.

4.3

Conclusions

Verification of BPEL processes has been investigated for some times now. Two approaches have been subject to research. The first approach makes abstraction of XPath expressions, the data manipulation part of a BPEL process, it concentrates fully on the control flow level. This first approach is quite successful and several automated tools have been developed enabling verification of soundness and LTL properties. The second tries to include XPath expressions in the model. While some results are obtained, the method does not scale well, verification is limited to very simple processes.

Chapter 5 Testing BPEL Web Services Contents

5.1

5.1

Test Suites . . . . . . . . . . . . . . . . . . . . . .

54

5.2

Generating Test Cases using SPIN for BPEL Services . . . . . . . . . . . . . . . . . . . . . . . .

55

5.2.1

BPEL to Promela . . . . . . . . . . . . . . . . . . 56

5.2.2

SPIN to Test Cases

5.2.3

Results . . . . . . . . . . . . . . . . . . . . . . . . 58

. . . . . . . . . . . . . . . . . 58

Test Suites

The use of model checking and formal methods helps reducing the number of errors in the early stages of software development. In the later stages, testing is a popular method for verifying the correctness of the implementation against its expected behavior. Testers usually write a lot of test cases. A test case or unit test is the description of an input on which the software is to be executed. A test case can also contains the expected result or response from the program. The program passes the test if the actual response is the response that was expected. A set of test cases is called test set or test suite. Judging the quality of a test suite is the subject of a lot of researches [32]. Coverage analysis is a popular way of assessing the quality of a test set. However there are several different coverage criteria that have been proposed and argued. Statement coverage checks that every statement is executed. 54

CHAPTER 5. TESTING BPEL WEB SERVICES

55

Branch coverage checks that every branch is actually taken. Path coverage check that every path is taken. Mutation coverage checks that the tests discriminate against every small change in the code, i.e. mutation of the code. Let consider the following code: if(t==0) { a = 1; } if(s==0} { b = 1; } To have 100 percent statement coverage it is sufficient to have t==0 and s==0, so a single test is required. To have full branch coverage the true and false branch of each test must be covered. It is sufficient to have two tests, one with t==0 and s==0 and another where t!=0 and s!=0. Finally to have complete path coverage at least four tests are required, one for each combination of possible values of t==0 and s==0. The mutation coverage is not illustrated here, it strongly depends on the mutation operator (e.g. syntactic mutation of the code). To achieve full coverage the results of the tests must detect all non-equivalent mutants. Getting a test set that is of good quality with regards to one of the criteria above can be tedious. Automatically generating these test cases alleviates that task.

5.2

Generating Test Cases using SPIN for BPEL Services

Model checking can be used to help generate test cases [14, 2]. Indeed, model checkers like SPIN or SMV check if a property, specified as an LTL formula, holds for a given model. If it does not hold, then the model checker extracts the trace of an execution on the model that violates the property, i.e. a counterexample. In order to get a test case for a property C, it suffices to run the model checker on the model with the property ’C never holds’. The model checker will, thus, exhibit a counterexample that describes an execution where the C property holds. This counter example, if it exists, can be the source of a test case.

CHAPTER 5. TESTING BPEL WEB SERVICES

56

In [12], the authors used SPIN to generate test cases for BPEL processes. Firstly, they transform the BPEL process into Promela. Next, they identify all the transitions, from one activity to another, of the BPEL process. Finally the generation proceeds as follows. To each transition, X, is associated the LTL property: ’Transition X is never executed’. The SPIN model checker is run with the Promela model and each of the above LTL properties. The counterexample is an execution that triggers the transition X. A test case can be produced accordingly. The overall process is illustrated in the Figure 5.1. This method will generate a test suite that covers all transitions of the BPEL process, provided that a counterexample can be found for each transition. Other coverage criteria can be used, so long as one can express it as an LTL formula.

5.2.1

BPEL to Promela

The translation into Promela is quite similar to the one presented in Section 4.2.3. However, instead of going through an intermediate representation, i.e. the guarded automata model, the authors present a direct transformation. While this Promela translation has a lot in common with the previous one, there are also important differences. The BPEL process is translated into a Promela process construct, as are all the partner processes. However, unlike in the former translation, the partner processes are deduced from the BPEL document, i.e. no need here to provide (simple) BPEL documents for each partner. These partners are deduced from the partner definition in the BPEL document, via the associated WSDL definition. Additionally, the behavior of the partner, the messages it sends, is deduced by analysis of how the process actually uses the information. For example, in the Loan Approval Service, the process receives a riskAssessment.risk from the assessor. The value of the risk variable is tested against the constant ’low’. Therefore the corresponding Promela process will send ’low’ or ’other’ as risk response in order to cover all branches of the test. The behavior of the deduced Promela process follows 3 rules: 1. If the BPEL document has no reference to the data, then its unique possible value is undefined 2. If the BPEL document compares it to a numerical constant: the possible value are the constant as well as a lower and an higher value

CHAPTER 5. TESTING BPEL WEB SERVICES

Garcia-Fanjul, Tuya, de la Riva

Fig. 3. An overview of the proposed method

Figure 5.1: Generation of test cases with SPIN [12].

consisting of three attributes of type byte. Each portType will have two channels: one for input messages and another for output. Message types are declared as typedefs in PROMELA (a construct similar to “record” in the C programming language). BPEL data types are discretized from the original ones: every simple data type becomes byte except for boolean, which stays the same. Each activity must be appropriately modelled to represent the behaviour of the business process. For example, invoke and receive activities use the ! and ? 88

57

CHAPTER 5. TESTING BPEL WEB SERVICES

58

3. If the value is discrete in the BPEL document: the possible values are all the discrete values as well as other. Afterwards, the partner processes and the process in itself are mapped into the Promela specification. The processes port types are transformed into Promela channels, the message types into Promela typedefs and each data type is discretized from the BPEL type into boolean for all data, except for boolean that are mapped to Promela boolean. The invoke and receive activities are modeled through the ! and ? channel operators. The flow controls, i.e. sequence, while, link, flow constructs. . . , are then mapped (manually?) into the Promela specification.

5.2.2

SPIN to Test Cases

To fulfill the transition coverage criteria, LTL formulae are used to produce counterexamples triggering the targeted transitions. In their implementation the authors use a boolean variable for each transition, e.g. for transition X the variable is transX. This variable will be set to true in the Promela model when the transition is executed. The corresponding LTL formula will thus be : ’[] !transX’ (i.e. always not transX). To deduce the actual test case from a counterexample, one must simply use the sequence of exchanged messages. Indeed, they give a complete description of the interaction between the partners leading to the execution of the targeted transaction. To produce the complete transition coverage, one has to run the model checker with the LTL formula of not yet executed transitions as long as such transition exists. In some cases some transitions are just unreachable, however the authors do not explicitly treat this case.

5.2.3

Results

The authors applied their technique to the Loan Approval Services. In less than three runs they obtained a test suite covering all transitions. The performance on this simple example was really good. The paper is only preliminary results and it is the first and only one investigating the application of model for test suite generation for BPEL processes. The translation process is not automated. Moreover, the example investigated is very basic, it has only trivial XPath expressions. The application to BPEL process with more complex XPath must be studied. Even more, as we saw in Section 4.2.3, a generic translation of BPEL to Promela, including XPath expression, has a scalability problem. The scalability of the

CHAPTER 5. TESTING BPEL WEB SERVICES

59

present technique, i.e. with more complex, real life BPEL processes, must be looked into.

Chapter 6 Conclusions and Future Works BPEL is a fully fledged, high level programming language for business processes based on Web Services. As with any other software system, the need to verify and validate BPEL processes is clear. Commonly two methods are used for verifying and validating softwares: model checking and testing. Model checking of BPEL processes has been closely investigated. These researches about it split into two approaches. The first approach makes abstraction of the XPath expressions, the data manipulation part of a BPEL process, it concentrates fully on the control flow level. This first approach is quite successful and several automated tools have been developed enabling verification of soundness and LTL properties. The second approach tries to include the XPath expressions in its model. While some results are obtained, the method does not scale well, verification is limited to very simple processes. On the testing side of the validation, very few works explicitly tackle the generation of test suites based on model checking techniques. The one we presented in Chapter 5 is a proof of concept. More investigations are needed to assess the scalability of the technique. Abstract interpretation techniques like the one used in the Blast model checker [1] is an alternative model checking technique. Its application to BPEL processes and especially to XPath expressions could yield interesting results and should be explored. Moreover Blast was extended to automatically generate test suites from counterexamples [4]. However, more research is needed to handle with Blast the concurrency capability built into BPEL.

60

List of Figures 1.1 Web Services Architecture Stack [13]. . . . . . . . . . . . . . . 1.2 The Loan Approval Service. . . . . . . . . . . . . . . . . . . .

5 8

2.1

XML Schema data types [30]. . . . . . . . . . . . . . . . . . . 13

3.1

Flow diagram of the Loan Approval Service.. . . . . . . . . . . 26

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Petri net representing an activity. . . . . Petri net representing a Link [25]. . . . . Petri net representing a Sequence [25]. . Petri net representing a Switch [25]. . . . Petri net representing a While [25]. . . . Petri net representing a Pick [25]. . . . . Petri net representing a Flow [25]. . . . . Basic activity mapping [25]. . . . . . . . Loan Approval Service Interactions [9]. . Guarded Automata model [10]. . . . . . Translation to Guarded Automata Model

5.1

Generation of test cases with SPIN [12]. . . . . . . . . . . . . 57

61

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [10].

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

39 39 40 41 41 42 42 43 46 47 49

Bibliography [1] The blast model checker. http://embedded.eecs.berkeley.edu/blast/. [2] Paul Ammann, Paul E. Black, and William Majurski. Using model checking to generate tests from specifications. In ICFEM, page 46, 1998. [3] Jes´ us Arias-Fisteus, Luis S´anchez Fern´andez, and Carlos Delgado Kloos. Formal verification of bpel4ws business collaborations. In EC-Web, pages 76–85, 2004. [4] Dirk Beyer, Adam J. Chlipala, and Rupak Majumdar. Generating tests from counterexamples. In ICSE ’04: Proceedings of the 26th International Conference on Software Engineering, pages 326–335, Washington, DC, USA, 2004. IEEE Computer Society. [5] Dirk Fahland. Complete abstract operational semantics for the web service business process execution language. Technical report, HumboldtUniversit at zu Berlin, 2005. [6] Roozbeh Farahbod, Uwe Gl¨asser, and Mona Vajihollahi. Specification and validation of the business process execution language for web services. In Abstract State Machines, pages 78–94, 2004. [7] Andrea Ferrara. Web services: a process algebra approach. In ICSOC ’04: Proceedings of the 2nd international conference on Service oriented computing, pages 242–251, New York, NY, USA, 2004. ACM Press. [8] H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-based verification of web service compositions. Eighteenth IEEE International Conference on Automated Software Engineering (ASE), Montreal, Canada, 2003., 2003. [9] X. Fu, T. Bultan, and J. Su. Analysis of interacting bpel web services. In ACM Press, editor, the 13th International World Wide Web Conference (WWW’04), USA, 2004., 2004. 62

BIBLIOGRAPHY

63

[10] X. Fu, T. Bultan, and J. Su. Model checking xml manipulating software, 2004. [11] Xiang Fu, Tevfik Bultan, and Jianwen Su. Conversation protocols: a formalism for specification and verification of reactive electronic services. Theor. Comput. Sci., 328(1-2):19–37, 2004. [12] Jos´e Garc´ıa-Fanjul, Javier Tuya, and Claudio de la Riva. Generating test cases specifications for bpel compositions of web services using spin. In International Workshop on Web Services Modeling and Testing (WSMaTe), 2006. [13] Web Services Architecture Group. Web services architecture. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. [14] Elsa Gunter and Doron Peled. Model checking, testing and verification working together. Form. Asp. Comput., 17(2):201–221, 2005. [15] Sebastian Hinz, Karsten Schmidt, and Christian Stahl. Transforming bpel to petri nets. In W.M.P. van der Aalst, B. Benatallah, F. Casati, and F. Curbera, editors, Proceedings of the Third International Conference on Business Process Management (BPM 2005), volume 3649 of Lecture Notes in Computer Science, pages 220–235, Nancy, France, September 2005. Springer-Verlag. [16] Mariya Koshkina and Franck van Breugel. Modelling and verifying web service orchestration by means of the concurrency workbench. SIGSOFT Softw. Eng. Notes, 29(5):1–10, 2004. [17] Shin NAKAJIMA. Model-checking verification for reliable web service. In OOPSLA 2002 Workshop on Object-Oriented Web Services., 2002. [18] C. Ouyang, W.M.P. van der Aalst, S. Breutel, M. Dumas, A.H.M. ter Hofstede, and H.M.W. Verbeek. Formal semantics and analysis of control flow in ws-bpel. Technical report, BPM-05-13, BPMcenter.org, 2005. [19] Chun Ouyang, Eric Verbeek, Wil M. P. van der Aalst, Stephan Breutel, Marlon Dumas, and Arthur H. M. ter Hofstede. Wofbpel: A tool for automated analysis of bpel processes. In ICSOC, pages 484–489, 2005. [20] Chun Ouyang, Eric Verbeek, Wil M. P. van der Aalst, Stephan Breutel, Marlon Dumas, and Arthur H. M. ter Hofstede. Wofbpel: A tool for automated analysis of bpel processes. In ICSOC, pages 484–489, 2005.

BIBLIOGRAPHY

64

[21] Karsten Schmidt and Christian Stahl. A petri net semantic for bpel4ws - validation and application. In Ekkart Kindler, editor, Proceedings of the 11th Workshop on Algorithms and Tools for Petri Nets (AWPN’04), pages 1–6. Universit¨at Paderborn, October 2004. [22] Jianwen Su, Tevfik Bultan, and Xiang Fu. The wsat analysis tool. http://www.cs.ucsb.edu/ su/WSAT/. [23] Wil v. d. van der Aalst and Kees v. van Hee. Workflow Management: Models, Methods, and Systems (Cooperative Information Systems). The MIT Press, January 2002. [24] Eric Verbeek and Wil van der Aalst. http://is.tm.tue.nl/research/woflan/.

The woflan model checker.

[25] H.M.W. Verbeek and W.M.P. van der Aalst. Analyzing bpel processes using petri nets. In of the Second International Workshop on Applications of Petri Nets to Coordination, Workflow and Business Process Management, pages pages 59–78. Florida International University Miami, Florida, USA, 2005. [26] W3C. Extensible markup language (xml). http://www.w3c.org/XML. [27] W3C. Simple object http://www.w3.org/TR/SOAP/. [28] W3C. Web services http://www.w3.org/TR/wsdl/.

access description

protocol

(soap).

language

(wsdl).

[29] W3C. Xml path language (xpath). http://www.w3.org/TR/xpath/. [30] W3C. Xml schema. http://www.w3c.org/XML/Schema. [31] YanPing Yang, QingPing Tan, and Yong Xiao. Verifying web services composition based on hierarchical colored petri nets. In IHIS ’05: Proceedings of the first international workshop on Interoperability of heterogeneous information systems, pages 47–54, New York, NY, USA, 2005. ACM Press. [32] Hong Zhu, Patrick A. V. Hall, and John H. R. May. Software unit test coverage and adequacy. ACM Comput. Surv., 29(4):366–427, 1997.