two formal approaches for web services: process algebras & action

SAPIENZA UNIVERSITA DI ROMA

DOTTORATO DI RICERCA IN INGEGNERIA INFORMATICA

XX CICLO – 2008

Two Formal Approaches for Web Services:Process Algebras & Action Languages

Antonella Chirichiello

SAPIENZA UNIVERSITA DI ROMA

DOTTORATO DI RICERCA IN INGEGNERIA INFORMATICA

XX CICLO - 2008

Antonella Chirichiello

Two Formal Approaches for Web Services:Process Algebras & Action Languages

Thesis Committee

Prof. Marco Schaerf (Advisor)Prof. Luigia Carlucci AielloProf. Roberto Baldoni

Reviewers

Prof. Enrico GiunchigliaProf. Yves Lesperance

AUTHOR’S ADDRESS:Antonella ChirichielloDipartimento di Informatica e Sistemistica Antonio RubertiSapienza Universita di RomaVia Ariosto 25, I-00185 Roma, Italy.E-MAIL: [email protected]: http://www.dis.uniroma1.it/∼chirichiello/

To my beloved Andrea

Abstract

Web services emerged recently as a promising way to develop applications throughthe Internet. Nowadays, an increasing number of companies and organizations onlyimplement their core business and outsource other application services over Internet.

A central challenge is the development of modelling techniques and tools for en-abling the (semi)-automatic composition and analysis of these services, taking intoaccount their semantic and behavioral properties. Research and standards are explor-ing a variety of approaches, which can be broken along several dimensions. A keydimension concerns whether the focus is on message passing (as found in WSDLand BPEL4WS) or actions performed (as found in OWL-S). Another key dimen-sion concerns how behaviors should be modelled, including both the behavior ofindividual Web services and also the desired or actual behaviors of compositions ofWeb services. Possibilities here include flowchart-based approaches (e.g., workflow,BPEL4WS), automata-based models, or goal-driven approaches (e.g., OWL-S).

This dissertation addresses the problem of engineering composite Web services,i.e., designing services that combine existing services to satisfy new requirements.Specifically, the research objective is to describe, simulate, (automatically) compose,verify, and develop Web services. Motivated by the challenge discussed above, wehave experimented with two formalisms, namely process algebras and action lan-guages, and investigated how they differ w.r.t. the research issues.

On the one hand, we argue that the essential facets of Web Services, and espe-cially, those useful to understand their interaction, can be described using processalgebra languages. In fact, Web service description and execution languages, such asBPEL4WS, are essentially process description languages. They are based on prim-itives for behavior description and message exchange, which can also be found inprocess algebras. Our investigation has proved that the Web service community canbenefit from the sophisticated languages developed in the process algebra area. Pro-cess algebras can be used to provide solutions to a number of challenges raised bythe Web service paradigm, since they are very well studied and have formal founda-tion for investigating various aspects of interests of process-based systems in general.Furthermore, they are equipped with tools that are effective at verifying that compo-sitions of services conform their requirements and respect desired properties. Process

iii

algebras can be used also to develop certified Web services following a well-definedmethod. To this end, we suggest a general framework based on a mapping betweenprocess algebras and Web services written in BPEL4WS, and illustrate both the mod-elling of services by process algebras and the use of reasoning tools.

On the other hand, we present a declarative approach to Web services compo-sition based on reasoning about actions formalisms, and in particular on action lan-guages. Action languages are attractive because they are concise and because theirsemantics is based on a theory of causality: the meaning of a domain descriptionin such languages can be represented as a transition diagram, a directed graph withvertices corresponding to states of the world and edges denoting the changes causedby the occurrence/nonoccurence of actions. Various action languages have been pro-posed in literature, offering different capabilities and expressiveness. In this disser-tation we focus on the action language C+. Our approach is based on a vision ofservices similar to OWL-S process model. Atomic services are described by speci-fying their preconditions and effects in an action theory. We show how the problemof Web services composition can be formulated in the action theory as a planningtask. Such a characterization allows us to use the tool CCALC that implements (afragment of) C+, for finding the solution to the problem and automatically synthe-sizing a composite service for the client request. The idea of using reasoning aboutaction formalisms, mainly Situation Calculus, in the context of Web services is notnew. Very few proposals exploit the expressiveness capabilities of action languagesfor workflows specification. The contribution of our investigation to the research inthis direction is the presentation of a declarative approach which is very flexible. Wespecify the effects of the activities of Web services without any specific knowledgeabout how they are implemented and how they should be coordinated. Furthermore,the entailment relation that characterizes the action language enables us to reasonabout the correctness of the specification of a composite service in terms of achiev-ing a client request. Although promising, this approach is based on a simplifiedassumption of complete knowledge, which in the context of the Web is unrealistic.As a first attempt to investigate complex scenarios involving incomplete information,we describe an extension of the action language framework for dealing with actionsthat explicitly affect knowledge. Specifically, we propose a generalization of theaction language C+ by introducing epistemic modalities in the underlying logic todistinguish what is known about the world from what is unknown. Then, we suggesthow the expressive capabilities of the new language could be exploited for describingthe additional aspects of services related to information requirements and knowledgegain.

Acknowledgments

I would like to thank all of the people that have consistently helped me during theyears of my Ph.D. First of all, I am grateful to Luigia Carlucci Aiello who encouragedme throughout all phases of my Ph.D. studies, and to my supervisor Marco Schaerf,who gave me the opportunity to work in his group as a research assistant. I thank mysupervisor also for the travel opportunities and for the possibility he gave me to par-ticipate within the Project ASTRO, funded by the Italian Ministry for Research underFIRB framework (funds for basic research), which partially supported my work. Mygratitude is also due to Marco Cadoli, Paolo Liberatore, and Amedeo Cesta, for theirpatience concerning technical questions, and for the fruitful discussions that providedme with many valuable ideas and insights.

A special thank goes to Vladimir Liftschitz for taking the time to read and com-ment on early drafts of some parts of this dissertation, and for suggesting to meseveral improvements. I am also thankful to the committee members and the externalreviewers, for their advises about the contents and presentation of this dissertation.

Many thanks to Andrea Vitaletti, Lucas Bordeaux, and in particular to GwenSalaun, for their scientific and human support. They have been precious mentorsand colleagues since the very beginning of my studies. I have also benifited frommany discussions with teachers and friends of the Diparimento di Informatica e Sis-temistica Antonio Ruberti. I must mention Vincenzo Bonifaci, Vittorio Amos Ziparo,Adnan Mian Noor, Giuseppe Paolo Settembre, Luca Allulli, Marco Fratarcangeli,Federico Pecora, Paolo Romano, Fabio Patrizi and Andrea Ribichini. Additionally,I would like to thank Maria Grazia Giacon and Giuseppina Melita, secretaries of theDiparimento di Informatica e Sistemistica Antonio Ruberti, for their constant encour-agement in these last years of hard work and study.

Last, but not least, I want to express my special gratitude to my father and mother,Giuseppe and Giuseppa, to my brother Mirko, and to my dearest friends Alessandra,Caterina and her lovely daughter Sara, Lucilla, Cristina, Michelangelo, Filomena,Sabrina, Emanuele, Agostino, for cheering up my life. Without their support, nothingof this work could have been accomplished. Finally, I want to thank my belovedAndrea. He has been patient, understanding, and above all, always encouraging meto do my best.

v

Contents

Abstract iii

Acknowledgments v

Contents ix

List of Figures xi

List of Tables xiii

1 Introduction 11.1 Automated Web Service Composition . . . . . . . . . . . . . . . . 11.2 Research Objectives and Contributions . . . . . . . . . . . . . . . . 51.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Web Services 112.1 Service Oriented Computing . . . . . . . . . . . . . . . . . . . . . 112.2 Web Service Approach to SOC . . . . . . . . . . . . . . . . . . . . 142.3 Web Service Description . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Web Service Composition . . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 BPEL4WS . . . . . . . . . . . . . . . . . . . . . . . . . . 262.5 Semantic Web Services . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5.1 OWL-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.2 OWL-S versus WSDL/BPEL . . . . . . . . . . . . . . . . . 38

2.6 Example: A Stock Management System . . . . . . . . . . . . . . . 392.7 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

vii

3 Formal Approaches for Web Services 473.1 Labelled Transition Systems . . . . . . . . . . . . . . . . . . . . . 473.2 Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3 Process Algebras . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4 AI Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.1 Hierarchical Task Networks . . . . . . . . . . . . . . . . . 553.4.2 Planning as Model Checking . . . . . . . . . . . . . . . . . 563.4.3 PDDL and Estimated Regression Planning . . . . . . . . . 583.4.4 Situation Calculus . . . . . . . . . . . . . . . . . . . . . . 593.4.5 Event Calculus . . . . . . . . . . . . . . . . . . . . . . . . 603.4.6 Action Languages . . . . . . . . . . . . . . . . . . . . . . 61

3.5 Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . 623.6 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4 Representing and Reasoning about Web Services with Process Algebras 654.1 Introduction to Process Algebras . . . . . . . . . . . . . . . . . . . 69

4.1.1 Common Process Algebras Constructs . . . . . . . . . . . . 704.1.2 CCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.1.3 LOTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2 Description of Web Services . . . . . . . . . . . . . . . . . . . . . 754.3 Composition of Web Services . . . . . . . . . . . . . . . . . . . . . 77

4.3.1 Choreography . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.2 Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.4 Automated Reasoning on Web Services . . . . . . . . . . . . . . . 814.5 Negotiation Among Web Services . . . . . . . . . . . . . . . . . . 86

4.5.1 What Does Negotiation Involve? . . . . . . . . . . . . . . . 874.5.2 Negotiation Using LOTOS/CADP . . . . . . . . . . . . . . 88

4.6 Development of Web Services . . . . . . . . . . . . . . . . . . . . 964.6.1 From Process Algebras to BPEL . . . . . . . . . . . . . . . 974.6.2 On Correctness and Completeness of the Encoding . . . . . 106

4.7 Example: A Stock Management System cont’d . . . . . . . . . . . 1084.7.1 Specification and Validation . . . . . . . . . . . . . . . . . 1084.7.2 Translation into BPEL . . . . . . . . . . . . . . . . . . . . 111

4.8 Comparison with Related Work . . . . . . . . . . . . . . . . . . . . 1124.9 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5 Representing and Reasoning About Web Services with Action Languages1175.1 The Action Language C+ . . . . . . . . . . . . . . . . . . . . . . . 120

5.1.1 Multivalued Propositional Formulas . . . . . . . . . . . . . 1205.1.2 Syntax of C+ . . . . . . . . . . . . . . . . . . . . . . . . . 1215.1.3 Nonmonotonic Causal Theories . . . . . . . . . . . . . . . 122

5.1.4 Semantics of C+ . . . . . . . . . . . . . . . . . . . . . . . 1255.1.5 Transition Systems, Paths, Plans and Goals . . . . . . . . . 1305.1.6 Reasoning about Actions . . . . . . . . . . . . . . . . . . . 1315.1.7 The Causal Calculator (CCALC) . . . . . . . . . . . 134

5.2 Describing and Reasoning About Web Services with C+ . . . . . . 1345.2.1 Description of Web Services . . . . . . . . . . . . . . . . . 1355.2.2 Composition of Web Services . . . . . . . . . . . . . . . . 142

5.3 Example: The On-line Municipal Agency . . . . . . . . . . . . . . 1435.4 Dealing with Incomplete Information . . . . . . . . . . . . . . . . 147

5.4.1 Towards an Epistemic Extension of the Action Language C+ 1495.4.2 Using KC+ for Web Services . . . . . . . . . . . . . . . . 161

5.5 Comparison with Related Work . . . . . . . . . . . . . . . . . . . . 1645.6 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

6 Discussion and Conclusions 1696.1 Critical Evaluation of the Two Proposed Approaches . . . . . . . . 1696.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736.3 Future Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . 175

A Translation of the LOTOS Choice Operator into BPEL 179A.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179A.2 Basic Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 180A.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

B Abbreviations for C+ Causal Laws 193

Bibliography 216

List of Figures

2.1 A Service Oriented Architecture . . . . . . . . . . . . . . . . . . . 122.2 The Web Service Architecture . . . . . . . . . . . . . . . . . . . . 152.3 A Composite Web Service . . . . . . . . . . . . . . . . . . . . . . 152.4 The Web Service Stack . . . . . . . . . . . . . . . . . . . . . . . . 162.5 A WSDL Service Specification . . . . . . . . . . . . . . . . . . . . 192.6 Web Services Choreography . . . . . . . . . . . . . . . . . . . . . 242.7 Web Services Orchestration . . . . . . . . . . . . . . . . . . . . . . 252.8 Orchestration vs. Choreography . . . . . . . . . . . . . . . . . . . 252.9 Behavioral Interfaces: Local Store and Supplier . . . . . . . . . . . 402.10 Overview of the Service-to-be and its Mates . . . . . . . . . . . . . 40

4.1 Overview of the Process Algebras Approach . . . . . . . . . . . . . 674.2 An Example of Choreography . . . . . . . . . . . . . . . . . . . . 794.3 An Example of Orchestration . . . . . . . . . . . . . . . . . . . . . 814.4 Example of Executions of CCS Processes: Process1 and Process2 . 834.5 Example of Executions of CCS Processes: Process3 and Process4 . 844.6 Datatypes Dependence Graph . . . . . . . . . . . . . . . . . . . . . 894.7 Process Involved in the Negotiation Steps . . . . . . . . . . . . . . 90

5.1 Transition Diagram for C+ Action Description AD . . . . . . . . . 1295.2 Transition Diagram for KC+ Action Description ADk . . . . . . . 161

xi

List of Tables

4.1 Practical Assessment of the Approach . . . . . . . . . . . . . . . . 944.2 Correspondence Between Process Algebras (LOTOS) and BPEL Con-

structs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.1 Translation of C+ to Causal Theories . . . . . . . . . . . . . . . . 1275.2 Common Epistemic Axioms . . . . . . . . . . . . . . . . . . . . . 151

A.1 Encoding the LOTOS Choice into BPEL . . . . . . . . . . . . . . . 190A.2 Encoding the LOTOS Choice into BPEL (cont’d) . . . . . . . . . . 191A.3 Encoding the LOTOS Choice into BPEL (cont’d) . . . . . . . . . . 192

B.1 Abbreviations for Causal Laws in C+ . . . . . . . . . . . . . . . . 194B.2 Abbreviations for Causal Laws in C+ cont’nd . . . . . . . . . . . . 195

xiii

Chapter 1

Introduction

Web services are network-based software components deployed and then accessedthrough the Internet using standard interface description languages and uniform com-munication protocols. Each service solves a precise task, and may communicate withother services by exchanging messages. Nowadays, an increasing number of compa-nies and organizations implement their core business and outsource other applicationservices over the Internet. Thus, the ability to efficiently and effectively select andintegrate interorganizational and heterogeneous services on the Web at runtime, is animportant step towards the development of Web service applications.

1.1 Automated Web Service Composition

Given a repository of services and a client request, the Web service composition prob-lem involves finding multiple services that can be put together in correct order ofexecution to satisfy the client request. The multiple services should be composedpreferably in an automated fashion. The word automated in this context refers to thefact that the methodology should be able to construct the composite Web service fromalready existing ones with minimal developer intervention. An important character-istic of Web service composition is that it can be iterated, thus allowing the definitionof increasingly complex applications by aggregating components: the composite ser-vice can be used as a component service by other (composite) services.

Automated Web service composition is emerging as a paradigm for enablingapplication integration within and across organizational boundaries. Several initia-tives have been conducted with the intention to provide platforms (e.g., IBM’s Web-Sphere Toolkit [IBM, WebSphere], Sun’s Open Net Environment [Sun Microsys-tem, ONE] and Microsoft’s .Net [Microsoft, Net]) and languages (e.g., SOAP [W3C,2007a], WSDL [W3C, 2001a; W3C, 2007b; W3C, 2007c; W3C, 2007d], BPEL4WS

1

2 1. Introduction

[Curbera et al., 2002], OWL-S [DMAL, 2006]) that support and allow an easy in-tegration of of such heterogeneous systems. At the same time, this trend has trig-gered a considerable number of research efforts on the composition of Web services.Research cuts across many areas of computer science - Data Integration, ArtificialIntelligence (Knowledge Representation, Planning and Reasoning About Actions),Theoretical Computer Science (Program Synthesis and Verification), and SoftwareEngineering (Software Components) - and comes with numerous proposals that ad-dress several aspects of Web service composition including Web service description,simulation, verification and development. Formal approaches play a fundamentalrole in this context. They allow us to deal with Web services and then to tackleseveral issues in an abstract way. For example, they can help us to define unambigu-ous semantics for the languages and protocols that underpin existing Web serviceinfrastructures, and provide a basis for checking the conformance and complianceof bundled services. They can also empower dynamic discovery and binding withcompatibility checks against behavioral properties.

Despite all the efforts, the automated composition of Web services is still a com-plex task and it is not clear which method serves it best. Broadly speaking, we cansay that all the proposed techniques fall into one of these two categories: methodsbased on a predefined workflow model and methods based on Artificial Intelligence(AI) planning.

Methods Based on a Predefined Workflow Model. This approach is adoptedwidely in industry. It considers the composite service similar to a workflow thatdescribes the interaction protocol among component services and specifies the con-trol and data flow among services. In this case the automation means that the methodcan locate the correct services if the abstract workflow model is given.

The industry approach looks at Web services mainly from the runtime perspec-tive of functions, data and control flows. It uses XML-based standards like SOAP,UDDI [OASIS, 2002], and WSDL to formalize the specification of Web services,and BPEL4WS (BPEL for short, recently evolved into WS-BPEL [OASIS, 2007])that provides the basis for manually specifying composite Web services using a pro-cedural language that coordinates the activities of other services.

The Web Service Definition Language (WSDL) describes a Web service via itsset of visible operations. They can be thought of as message endpoints, or set of mes-sages that the service can send and receive. An operation is either reactive, in whicha message is received by the service, or proactive, in which a message is sent outfrom the service. A reactive operation can be declared one-way, i.e., it does not re-turn a response, or request-response, and the return type is also declared. A proactiveoperation can be declared either as notification, i.e., the message is sent out withoutwaiting for a response, or as solicit-response, which blocks the execution of the ser-vice till the arrival of the response, whose type is also declared. Receive and response

1.1. Automated Web Service Composition 3

types are defined by using XML Schema [W3C, 2001b]. WSDL provides a function-centric description of Web services covering inputs and outputs. A service is viewedboth as a server (via its reactive operations) and as a client (via its proactive opera-tions). Business Process Execution Language for Web Services (BPEL4WS - BPELfor short) is the de facto standard language for describing workflows in Web servicearea. A BPEL process, also called business process, describes the behavior of anorchestrator by means of workflow constructs and communication primitives. BPELintroduces a stateful model of Web services interacting by exchanging sequences ofmessages between business partners. The major parts of a BPEL process definitionconsist of (i) partners of the business process (Web services that the process interactswith), (ii) a set of variables that keep the state of the process, and (iii) an activitydefining the logic behind the interactions between the process and its partners. Activ-ities that can be performed are categorized into basic, structured, and scope-relatedactivities. Basic activities perform simple operations like receive, reply, invoke andothers. Structured activities impose an execution order on a collection of activitiesand can be nested. Then, scope-related activities enable defining logical units of workand delineating the reversible behavior of each unit.

Generally, workflow descriptions encoded in BPEL are written by domain ex-perts. Thus, they won’t change until the experts that wrote them decide to modifythem. Industry likes workflows because they offer predictable performance: oncea company develops a workflow, the actors are expected to follow it to the letter.Moreover, the workflow implementers can analyze and modify it if data from pastexperiences shows inefficiencies. These workflows also have some degree of faulttolerance thanks to their fault-handling mechanisms. However, they are largely rigid.The only flexibility in dynamically adapting the workflow schema is in the specifica-tion of binding details at runtime, and in executing specific branches in it.

Methods Based on AI Planning. This approach has been investigated mainly inacademic communities where the focus is on reasoning about Web services by ex-plicitly declaring their preconditions and effects with terms defined in ontologies. Ifthe user can specify the preconditions and effects required by the composite service, aplan or process is generated automatically by logical theorem provers or AI plannerswithout knowledge of a predefined workflow. During the planning, the business logiccan provide constraints in the planning setting. In this case, the automation meansthat the method can generate the abstract workflow model automatically.

The Semantic Web [Berners-Lee, Hendler, & Lassila, 2001] provides a commonframework that allows data to be shared and reused across application, enterprises,and community boundaries. It is a collaborative effort led by the World Wide WebConsortium (W3C) [W3C, World Wide Web Consortium] with participation from alarge number of researchers and industrial partners. The goal is to provide machine-readable descriptions of Web services, in order to enable automated discovery, nego-

4 1. Introduction

tiation with, composition, enactment, and monitoring of Web services. The SemanticWeb project has resulted in initiatives like OWL-S, which is an OWL-based ontology[W3C, 2004a] language designed to model and describe the meanings and intendedusage of Web services more precisely than is currently supported by industrial stan-dards. OWL-S describes Web services in terms of their process model. The basicbuilding block of the OWL-S process model is the notion of process. This includesboth atomic and composite processes. Processes are specified to have inputs, outputs,preconditions, and (conditional) effects (IOPEs). Inputs specify the information thatthe service requires for its execution, whereas outputs are generated as a result ofthe execution. Preconditions specify conditions that must be satisfied for a service toexecute correctly, whereas effects describe the conditions in the world that must besatisfied after the execution of the service. Composite processes can be created bycombining atomic processes using a set of flow control constructs such as Sequence,Split, Split+Join Unordered, Choice, If-Then-Else, Iterate, and Repeat-Until.

OWL-S is the only Web service language that can be directly connected with AIplanning. In general, a planning problem is described as a tuple 〈S, S0, G, A,Γ〉,where

• S is the set of all possible states of the world

• S0 ⊂ S denotes the set of initial states of the world

• G ⊂ S denotes set of goal states of the world the planner attempts to reach

• A is the set of actions the planner can perform in attempting to change onestate to another state in the world

• Γ ⊆ S × A × S is the transition relation that defines the precondition andeffects for the execution of each action.

In the context of Web services, S0 and G denote the initial state and the goal statespecified in the requirement of Web service requesters. A is a set of available services.Γ denotes the state change function of each service, specified through the precondi-tion and effect properties of the service model. Therefore, given a representation ofservices as OWL-S processes, AI planning techniques can be exploited for automaticservice composition by treating this problem as a planning problem. Ideally, given aclient objective and a set of Web Services, a planner would find a collection of WebService requests that achieve the objective. Observe that the planning problems thatwill naturally occur are not classical, for the obvious reason that, due to the natureof the Web, we cannot assume complete information. Recently, much work on plan-ning and reasoning about actions has studied how to generate (either conditional orconformant) plans in presence of incomplete information in the initial situation andon the effects of actions, possibly also dealing with partial state observability. Suchtechniques can therefore be profitably applied to the composition of Web services

1.2. Research Objectives and Contributions 5

when only a partial description of the component services is available, and to analyzethe implications of partial state observability.

1.2 Research Objectives and Contributions

This dissertation addresses the problem of engineering composite Web services, i.e.,designing services that combine existing services to satisfy new requirements. Specif-ically, the research objective is to describe, simulate, (automatically) compose, verify,and develop Web services. Inspired by the Web service initiatives proposed both inindustry and in academia, and motivated by the need for semantically well-foundedand algorithmically manageable formalisms for tackling several issues of Web ser-vices, in this dissertation we advocate the use of two different types of formalisms,namely process algebras and action languages, for describing and reasoning aboutWeb services, and investigate how they differ w.r.t. the research issues.

Process Algebras. It is generally recognized (see for instance [Meredith & Bjorg,2003]) that Web services and their interaction are best described by using processdescription languages, and it is clear that the standards for describing and composingWeb services, like BPEL, are actually such languages. Abstract processes can be usedto describe services at different level of expressiveness and to compose them in orderto build more complicated services. Process algebras [Bergstra, Ponse, & Smolka,2001] appeared to us as a natural formalism for providing solutions to a number ofchallenges raised by the Web service paradigm. Our interest in using process algebrasis motivated by the fact that they are very well studied and have a formal foundation.Generally speaking, process calculi provide a simple and expressive framework inwhich to represent and reason about Web services. Moreover, they are equipped withtools that are effective at verifying that compositions of services conform their re-quirements and respect desired properties. Finally, abstract descriptions may also beused as a first step to develop certified Web services following a well-defined method.To this end, we suggest a general framework based on a mapping between abstractprocesses and executable services, and illustrate both the modelling of services byprocess algebras and the use of reasoning tools.

Central to the process algebras approach is the definition of a two-way mappingbetween abstract processes and executable services (implementations and their asso-ciated interfaces). Our main contribution to this work can be identified in the defi-nition of a methodology for encoding process algebraic description of Web servicesinto executable code. In particular, starting from an initial proposal [Salaun, Fer-rara, & Chirichiello, 2004; Salaun, Bordeaux, & Schaerf, 2006], we have defined[Chirichiello & Salaun, 2006; Chirichiello & Salaun, 2007] in a more precise waythe correspondence between abstract processes and executable services and, based

6 1. Introduction

on this correspondence, we have elaborated some systematic guidelines to enable de-velopers to develop and deploy running Web services from abstract and validated de-scriptions of services-to-be. Regarding the Web service(s) to be implemented (com-pared to the other ones which are viewed as behavioral interfaces), we concentrate,at the concrete level, on WSDL interfaces and BPEL services. The proposed methodhas been elaborated empirically, via simulation experiments carried out using theOracle BPEL Process Manager 2.0 [Oracle, BPEL Process Manager]. We have de-veloped and deployed running Web services, thus our ideas have not remained at aconceptual level, as is most of the time the case. Furthermore, to illustrate the interestof the process algebras approach to Web services, we have considered an applicationto the problem of negotiation. This problem is a typical example of services involvingboth data (prices, goods, stocks, etc) and behaviors. Negotiation issues appear whenseveral participants (clients and providers) have to interact to reach an agreement thatis beneficial to all of them. In this context, we have experimented with the use of theprocess algebra LOTOS [ISO, 1989] and its tool CADP (Construction and Analysisof Distributed Processes) [VASY, CADP], to ensure trustworthy and automated ne-gotiation steps. Summarizing all the results of our investigation, we have proved thatthe Web services community can benefit from the sophisticated languages developedin the process algebra area. In fact, process algebras can be used

• to tackle the composition of Web services because they are compositional lan-guages (complex Web services can be built from basic ones easily by usingprocess algebra constructs). In general, we can distinguish two notions ofcomposition: choreography, that aims at finding a global model for servicesdescribing their interaction in a precise way; and orchestration, that aims atsolving more complex tasks by building a new service (the orchestrator) usingexisting services by exchanging messages with them. Concerning the chore-ography issue, process algebras can be used to represent the behavior of allinteracting Web services, and consequently perform on-the-fly compatibilitychecks in order to ensure that the component services can cooperate for solv-ing the given tasks. Concerning the orchestration issue, process algebras canbe used to verify that the interaction between the orchestrator and each of theselected partners works properly;

• to support the correct development of Web services. In particular, on one handthey can be used for encoding purposes during the design stage, i.e., for speci-fying abstractly the new service and its interactions with the other participants,and then translating it into an executable language. In this case, process alge-bras are especially worthy as a first description step because they enable us toanalyze the problem at hand, to clarify some points, and to sketch a (first) solu-tion using an abstract language (thus dealing only with essential concerns).From such a formal description of one or more services-to-be, verificationtools can be used to validate their correct execution and, if necessary, to verify

1.2. Research Objectives and Contributions 7

and ensure relevant temporal properties such as safety and liveness [Manna &Pnueli, 1995]. On the other hand, they can be used for reverse engineeringpurposes, i.e., for extracting an abstract representation from the service imple-mentation (accordingly, the developer implements directly the service using anexecutable language) to validate its behavior with respect to its mates.

Action Languages. The process algebras approach allows us to cope with severalissues related to Web services. However, process algebras (like any other formalautomata-based language) have several drawbacks that limit their practical viabilityand wide-scale adoption. For specifying functional requirements, process algebrastechnique for service composition requires the service developer to provide a specifi-cation of the desired behavior of the composite service in its entirety. Consequently,the developer has to deal with the cognitive burden of handling the entire composi-tion graph (comprising appropriate data and control flows) which becomes hard tomanage with the increasing complexity of the composite service. Furthermore, ifthe composite service specification cannot be realized using the set of available com-ponent services, the entire composition task fails. Observe that, in many cases thefailure is due to the incompleteness of the composite service specification.

To overcome these limitations, we decide to adopt a declarative approach to Webservice composition based on reasoning about actions formalisms, and in particularon action languages. Action languages are attractive because they are concise andbecause their semantics is based on a theory of causality: the meaning of a domaindescription in such languages can be represented as a transition diagram, that is a di-rected graph with vertices corresponding to states of the world and edges denoting thechanges caused by the occurrence/nonoccurence of actions. Various action languageshave been proposed in the literature, offering different capabilities and expressiveness[Gelfond & Lifschitz, 1998]. In this dissertation, we focus on the action language C+[Giunchiglia et al., 2004]. The rationale behind the choice of this language lies in itsexpressiveness. In fact, C+ allows us to express various reasoning problems (e.g.,planning, prediction, postdiction) in presence of concurrency, nondeterminism, rami-fications, etc. Furthermore, this language is equipped with a tool CCALC (The CausalCalculator) [TAG at Austin, CCALC] which answers queries about action domainsexpressed in a fragment of C+.

The framework for representing and reasoning about Web services with C+ isbased on the OWL-S process model that distinguishes between atomic and compos-ite services. Atomic services are described by specifying their preconditions andeffects in an action theory. Composite services are sequences of atomic servicesobtained by solving a planning problem for a given client request. We begin by as-suming complete information about the environment in which component serviceshave to be executed. Thus, we show how C+ propositions (actually the subset of C+implemented in CCALC) can be used to describe services and how the composition

8 1. Introduction

problem can be formulated as a reasoning task in C+. Such a characterization of thecomposition problem allows us to use CCALC for finding the solution to the problemand automatically synthesizing a composite service for the client request.

C+ and its tool CCALC have been applied to several benchmark problems in thetheory of commonsense knowledge (see, for instance, [Campbell & Lifschitz, 2003;Akman et al., 2004] and the examples provided on the CCALC Web site). Other appli-cations are the formalization of multiagent computational systems [Artikis, Sergot,& Pitt, 2002; Artikis, Sergot, & Pitt, 2003; Chopra & Singh, 2003; Chopra & Singh,2006; Sergot & Craven, 2006], and the specification of business protocols as chore-ographies modelled via commitments [Desai, Chopra, & Singh, 2007]. In this dis-sertation, we aim to show the use of the language C+ in another realistic application,namely the Web service composition. The expressive power of the language providesus with a framework for the formal description of Web services and the specificationof Web service composition. This basic framework can be seen as a first step towardsa declarative method for describing, reasoning about, and automatically composingWeb services. Currently, it is based on the simplified assumption of complete knowl-edge which in the context of the Web is unrealistic. To accommodate the needs ofthe application domain in which the information is inherently incomplete, we shouldmodify our framework in order to model not only world altering effects but alsoinformation providing effects. As a first attempt to investigate complex scenariosinvolving incomplete information, we describe an extension of the action languageframework for dealing with actions that explicitly affect knowledge. Specifically, bycombining epistemic logic and the action language C+, we create a new action lan-guage, named KC+, for representing and reasoning about actions with incompleteinformation, and we suggest how it could be exploited for describing the additionalaspects of services related to information requirements and knowledge gain.

The idea of using reasoning about action formalisms, mainly Situation Calculus[McIlraith & Son, 2002; Narayanan & McIlraith, 2003; Berardi et al., 2003b], in thecontext of Web services is not new. There exist very few proposals (for instance [Tra-jcevski, Baral, & Lobo, 2001]) that exploit the expressiveness capabilities of actionlanguages but for workflows specification. The contribution of our investigation inthis context is twofold

• we propose a flexible declarative approach for describing and reasoning aboutWeb services and their compositions. We specify the effects of the activities ofWeb services without any specific knowledge about how they are implementedand how they should be coordinated. Furthermore, the entailment relation thatcharacterizes the action language enables us to reason about the correctness ofthe specification of a composite service in terms of achieving a client request;

• we propose a new action language KC+ for reasoning about actions with in-complete information. This language requires very little machinery, since itis obtained by extending the underlying logic of C+ with epistemic operators,

1.3. Outline 9

and is suitable to describe actions that affect the knowledge of the reasoningagent.

Part of the results of this dissertation have been published in international jour-nals, conference and workshop proceedings [Salaun, Ferrara, & Chirichiello, 2004;Chirichiello & Salaun, 2005; Chirichiello & Salaun, 2006; Chirichiello & Salaun,2007].

1.3 Outline

The remainder of this dissertation is organized as follows.

Chapter 2. In this chapter we discuss the reference computing model of Web ser-vices and introduce the Web Service technologies, with a particular regard to thosespecifications related to service description and composition: WSDL and BPEL. Fur-thermore, we provide a brief introduction to the Semantic Web by illustrating the roleof Web services in this context, and also describe the salient characteristics of OWL-Slanguage.

Chapter 3. This chapter is a survey of some interesting work in a number of formalapproaches proposed to deal with Web services that are somehow related to the resultspresented in this dissertation.

Chapter 4. The goal of this chapter is to illustrate the process algebras approachto Web services. We discuss some of the issues related to Web services for whichprocess algebras are useful and the results obtained in this context. We start withan overview of process algebras, describing in particular the two languages usedin our experimentation, namely CCS and LOTOS. Then, we discuss how processalgebras and their tools may be used (i) to describe and reason about Web services,(ii) to compose Web services, providing a solution to choreography and orchestrationissues, and (iii) to develop Web services following a well-defined process.

Chapter 5. In this chapter we illustrate a framework for representing and reason-ing about Web services based on the action language C+. Starting from an initialassumption of complete knowledge, we exploit the expressiveness of the languageto represent several aspects of service execution and interaction. The compositionproblem is described as a planning task in C+ and solved by using the tool CCALC.Then, we extend the language C+ in order to deal with actions that explicitly affectknowledge, by allowing epistemic modalities in the underlying logic to distinguishwhat is known about the world from what is unknown. Finally, we discuss how our

10 1. Introduction

approach could be extended to more complex scenarios involving incomplete infor-mation, by showing how the new action language, called KC+, could be used torepresent additional aspects of Web services concerning information providing andgathering.

Chapter 6. We discuss how process algebras and action languages differ w.r.t. theresearch issues and summarize the results presented in this dissertation. We alsoprovide an outlook on future work by considering some possible extensions and im-provements that can be devised for the two approaches presented in this dissertation.

We have also included two appendixes which gather the links presented within thisdissertation.

Appendix A. In this appendix we provide the details of the encoding of the LOTOSchoice operator in BPEL, by also discussing several aspects of how we deal withnondeterministic behaviors at both the abstract and concrete level.

Appendix B. Causal laws of C+ can be abbreviated in several ways. This appendixreports the comprehensive list of such abbreviations.

Chapter 2

Web Services

The purpose of this chapter is twofold: to discuss the reference computing model ofWeb services, and to introduce the Web Service technologies, with a particular regardto those specifications related to service description and composition.

2.1 Service Oriented Computing

Service Oriented Computing (SOC) [Alonso et al., 2004; Papazoglou et al., 2007] is aparadigm aiming at realizing distributed applications in heterogeneous environmentsby reusing existing services as basic building blocks. A service is an autonomous,interoperable, platform-independent, computational entity which can be dynamicallydiscovered and composed with other services, in order to perform different tasks.Services are accessed by standardized public interfaces and stored within serviceregisters. These registers are queried by other applications for retrieving, at run-time, a specific service for a specific task. Services can be reused and replaced,depending on the execution context of the specific distributed application, and theycan be exploited by different application systems at the same time.

The service-oriented approach is independent of specific programming languagesor operating systems. It allows organizations to expose their core competencies overthe Internet or a variety of networks (e.g., cable, UMTS, XDSL, Bluetooth, etc.) us-ing standard languages and protocols. SOC is changing the way software applicationsare designed, delivered and consumed, by supporting rapid, low-cost and easy inter-operation of loosely coupled heterogeneous distributed applications. It is exploited inseveral ITC (Information Technology and Communication) areas like, for example,e-government, e-business and e-science. Nowadays, big corporations and consortia,like Microsoft [Microsoft, Microsoft Corporation], IBM [IBM, International Busi-ness Machines Corporation], and W3C [W3C, World Wide Web Consortium] just to

11

12 2. Web Services

mention a few, are putting efforts and amount of money in developing tools whichdeal with SOC applications.

The key to realizing the SOC vision is the Service Oriented Architecture (SOA)[Ort, 2005]. A SOA (depicted in Figure 2.1) is an information technology approachof designing a software system, in which applications make use of services avail-able in a network. Implementing a SOA can involve developing applications that useservices, making applications available as services so that other applications can usethem, or both. A service provides a specific function, typically a business function,which can be a single discrete function (e.g., converting one type of currency into an-other), or it can perform a set of related business functions (e.g., handling the variousoperations in an airline reservations system). Multiple services can be used togetherin a coordinated way in order to satisfy a more complex business requirement. EachSOA building block can play one or more of the following roles:

• service provider (the owner of a service): it is the subject that provides services(it may be, for example, an organization);

• the service requestor (also referred to as client): it is the subject looking forand invoking the service in order to fulfill some tasks;

• the service directory: it is the subject providing a repository of service descrip-tions, where providers publish their services and requestors find services.

ClientClient

ServiceService

ServiceService

Directory

Service

Directory

Service

ServiceServiceServiceService

Business

Partners

Other

Providers

Customers

Figure 2.1: A Service Oriented Architecture

2.1. Service Oriented Computing 13

When a provider wants to make available a service, it publishes its interface, whichcontains information about the functionalities provided by the service and how itshould be invoked. A requestor that wants to perform a task by exploiting a service’sfunctionalities, finds a suitable service in the registry, and connects to the serviceprovider in order to invoke it, by using the information exposed in the service inter-face. In what follows, we briefly discuss some of issues that must be addressed whenusing the SOA technology [Alonso et al., 2004; Turner, Budgen, & Brereton, 2003].

Service Description. It deals with how to describe services in order to associate toeach service a precise syntax and a semantics. It is based on interfaces and interfacedescription languages.

Service Discovery. It deals with how clients can locate appropriate services thatmeet their functional needs, and how such services can be selected, invoked and fi-nally executed. It can be done both at design-time by browsing the directories whereservice descriptions are stored and identifying the most relevant services, and at run-time by using dynamic binding techniques. Other related issues are: service adver-tisement, which focuses on how providers can advertise their services so that clientscan easily discover them; service negotiation, which deals with how clients and ser-vice providers can achieve agreements on the terms and conditions for supplying aservice.

Service Interaction. It is concerned with the infrastructures and tools that enableservices interaction. It deals with the definition of protocols for supporting informa-tion transport and exchange.

Service Composition. It considers how more complex services can be built fromother existing services. A service implemented by composing other services is calledcomposite service, whereas a service implemented and invoked directly by accessingthe local system is called atomic service. Observe that, whether a service is atomicor composite is irrelevant from the client’s perspectives, as it is an implementationissue.

Security and Privacy. It deals with identifying mechanisms for authenticating au-thorized clients to which a service should be delivered, and guaranteing the non-disclosure of private information.

Quality of Services (QoS). It determines services usability and utility. QoS coversa whole range of techniques that match the needs of service requestors with thoseof the service providers based on the network resources available. By QoS, we re-fer to non-functional properties of services such as: availability - the percentage of

14 2. Web Services

time that a service is operating; reliability - some tangible measure that a service isexpected to achieve; integrity - both syntactic and semantic during the service trans-action; scalability - capability of presenting mechanisms or adding capacities as load(e.g., number of clients, transactions and messages, as well as their type) increases;response time - time taken to respond to various types of requests; throughput - rateat which a service can process requests.

2.2 Web Service Approach to SOC

Web services are currently the most promising SOC-based technology. The WorldWide Web Consortium (W3C) [2004c] defines a Web service as a

“software application identified by a URI 1, whose public interfaces and bindings aredefined, described and discovered as XML artifacts. A Web service supports directinteractions with other software agents using XML-based messages exchanged viaInternet-based protocols”.

In essence, Web services are self-describing, modular applications that expose busi-ness logic as services that can be published, discovered, and invoked over the Internet.Based on XML (eXtensible Markup Language) [W3C, 2000] standards, Web servicescan be developed as loosely coupled application components using any programminglanguage, any protocol, or any platform. This facilitates the delivery of business ap-plications as services accessible to anyone, anytime, at any location, and using anyplatform. Loose coupling means that the way a client communicates with a servicedoesn’t depend on the implementation of the service itself. The communication isset up according to a specified, well-defined interface. It is up to the service imple-mentation to perform the necessary processing. If the implementation of the servicechanges, the client communicates with it in the same way as before, provided that theinterface remains the same.

Web services can be used to implement a SOA. A major focus of Web services isto make functional building blocks accessible over standard Internet protocols. Theseservices can be new applications or just wrapped around existing legacy systems tomake them network-enabled. Figure 2.2 shows an operation scenario that producesor utilizes an atomic Web Service. Web services can be composed by aggregating anumber of services, either atomic or composite, and by following a certain composi-tion pattern and rules in order to achieve complex business goals. For example (seeFigure 2.3) service client X can use services provided by service providers A, B andC, but it can also acts as a Web service aggregator, offering a single service obtainedby grouping services A, B, and C.

1A Uniform Resource Identifier (URI) is a compact string of characters used to identify or name a

resource on the Internet.

2.2. Web Service Approach to SOC 15

Web Service

Register

Web Service

Register

Web Service

Provider

Web Service

Provider

Web Service

Client

Web Service

ClientService Invocation

Ser

vice

Dis

cove

ry

Service

Pub

lication

Figure 2.2: The Web Service Architecture

Web Service

Provider A

Web Service

Provider A

Web Service

Provider B

Web Service

Provider B

Web Service

Provider C

Web Service

Provider C

Web Service

Client X

Web Service

Client X

Figure 2.3: A Composite Web Service

16 2. Web Services

Web services are based on standards built over XML which in the last ten years,has become the de facto standard for describing data to be exchanged on the Web.As its name indicates, XML is a markup language. It involves the use of tags that“mark up” the contents of a document. An XML tag identifies information in adocument to which is assigned a particular meaning. XML documents are typicallyassociated with Document Type Definition (DTD)[W3C, 2000] or an XML Schema[W3C, 2001b], that specifies what tags are allowed in the document, their structure,and other rules such as, for instance, what type of data is expected in a tag (or nodata if it is an empty tag). Because valid XML documents must be well-formed andconform to the associated schema, it is relatively easy to process XML documents.Applications can send XML documents to each other, and process the information inthose documents, relying on the commonly understood meanings associated with theXML tags.

The Web service community has proposed dozens of standard languages for mod-elling and specifying the different facets of SOC. Figure 2.4 provides an overviewof commonly used standards and their positions in the application of Web services.Invocations are performed over standard network protocols, like HTTP, SMTP, FTP,

Services Process

BPEL4WS, BizTalk, J2EE, .Net, …

Services Discovery

UDDI, WSIL

Services Description

WSDL, WSCL, SSDL, MEP

Message Protocol

XML-RPC, SOAP, REST, IIOP, ...

Network

HTTP, SMTP, FTP, BEEP, …

Figure 2.4: The Web Service Stack

and BEEP, by sending XML messages packaged using one messaging protocol suchas SOAP [W3C, 2007a], REST, IIOP and XML-RPC. The description of the serviceis based on standardized XML oriented languages, like WSDL [W3C, 2001a; W3C,2007b; W3C, 2007c; W3C, 2007d], WSCL [W3C, 2002b], SSDL [Webber & Paras-

2.3. Web Service Description 17

tatidis, 2005], and MEP [W3C, 2007d]. Service discovery and service publicationare standardized in UDDI [OASIS, 2002] and WSIL [Ballinger et al., 2001]. Serviceprocess, based on several platforms such as, J2EE [Sun Microsystem, J2EE], .Net[Microsoft, Net], PiDUCE [Carpineti, Laneve, & Padovani, 2008], and BPEL4WS[Curbera et al., 2002] (WS-BPEL [OASIS, 2007]), support this stack in a way that itis transparent to the user.

In the rest of this chapter, we describe and discuss in details the languages ad-dressing two of the SOA technical issues discussed so far, namely the Service De-scription and the Service Composition.

2.3 Web Service Description

Web service description is based on interfaces and on interface description languages(IDLs). The W3C has proposed many Web service description languages for differentpurposes:

• Web Service Description Language (WSDL), for describing Web services interms of their static interfaces;

• Web Service Conversation Language (WSCL), for describing the conversationsthat are supported by a Web service2;

• Web Service Choreography Interface (WSCI), for describing the observablebehavior of a Web service in a message exchange, in the context of a collabo-rative business process or workflows.3

Observe that, w.r.t. the SOA, all these languages concern the service provider, whichexploits them to describe the Web service to be published in the service registry. Fur-thermore, they only allow the specification of interface descriptions which are notenough for describing Web services. In fact, to completely describe a service, it isnecessary to specify not only its interface but also the business protocols4 it supports.Business protocols are imposed by service providers for services, and consist of setof rules defining which conversations are valid and understood by a service in aninteraction with a client and/or with other services. In this regard, languages likeBusiness Process Execution Language for Web Services (BPEL4WS) [Curbera et

2A Web service often offers a number of operations that clients must invoke in a certain order to

achieve their goals. The sequence of messages exchanged during the interaction with a client describes

the behavior of the Web service, and is usually referred to as conversation.3The observable behavior of a Web service is the behavior seen by the client of the service. This is

expressed in terms of temporal and logical dependencies among the messages exchanged between the

client and the service, featuring sequencing rules, correlation, exception handling, and transactions.4The term “business” is used to differentiate the protocol from a communication protocol.

18 2. Web Services

al., 2002] (recently evolved in WS-BPEL [OASIS, 2007]), and Web Service - Chore-ography Description Language (WS-CDL) [W3C, 2005] can be used for describingservices and their business protocols. However, since they are more targeted towardsspecifying how multiple services are coordinated, they will be introduced in the nextsection.

In the following, we cover the WSDL language [W3C, 2001a; W3C, 2007b;W3C, 2007c; W3C, 2007d] in details. The reader who is interested in WSCL andWSCI, may refer to [W3C, 2002b] and to [W3C, 2002a], respectively.

2.3.1 WSDL

The dominant proposal in the area of Web service description is the Web ServiceDescription Language (WSDL). A working draft of WDSL 2.0 is available [W3C,2007b; W3C, 2007c; W3C, 2007d]. However, here we focus on the previous standardWSDL 1.1 [W3C, 2001a], which was the dominant one at the time we started thework of this dissertation.

WSDL has a role and purpose similar to that of IDLs in conventional middlewareplatforms, but with some differences. As discussed in [Alonso et al., 2004], WSDLspecifications are XML documents that describe Web services, and in particular theirinterfaces. A significant difference w.r.t. conventional IDLs is that, in addition tospecifying the operations offered by a service, WSDL also must define how the ser-vice can be accessed. In fact, since existing IDLs are tied to concrete middlewareplatforms, they are only concerned with the description of the service interface, interms of service name and signature (input and output parameters). The rest of theinformation is implicit, as the access mechanisms are the same for all services avail-able on a specific middleware platform. In the context of Web services, each servicemay be accessed using different protocols, and therefore, this information must beprovided as a part of the service description. Another difference due to the lack ofa common middleware platform, is the need for specifying the location at which theservice is available. In fact, in conventional middleware, the service provider imple-ment an interface and register the service with the middleware. A client can invokea service without knowing its location, since it is the middleware that takes care ofactivating the service. On the contrary, the absence of a centralized platform in Webservices means that the client must be able to identify the location at which the ser-vice is made available, so that it knows where to send SOAP messages. Therefore,also the location information should be specified in the Web service interface. Otherdifferences between WSDL and conventional IDLs are concerned with the interactionmodes, which in the context of Web services are often asynchronous. ConventionalIDLs are typically used to describe a single entry point to a service (a single RPCinteraction). On the contrary, the invocation of a Web service typically involves theexchange of several asynchronous messages between clients and providers. For sup-porting these needs, WSDL includes a collection of different interaction paradigms,


along with the ability to combine operations or groups of operations within an inter-face.

As depicted in Figure 2.5 (taken from [Alonso et al., 2004]), WSDL specifica-tions are characterized by an abstract part which is conceptually analogous to conven-tional IDLs, and a concrete part which defines protocol binding and other informa-tion. In the following, we present and discuss the structure of a WSDL document that

WSDL specification

abstract part

concrete part

types

messages

operations

port types

bindings

services and ports

Figure 2.5: A WSDL Service Specification

combines all the abstract and concrete elements of a WSDL interface. This specifica-tion uses an informal syntax to describe the XML grammars of a WSDL document.The characters appended to elements and attributes have the following meaning: ?means 0 or 1; * means 0 or more; + means 1 or more.

<wsdl:definitions name="nmtoken" ? targetNamespace="uri" ?>

<import namespace="uri" location="uri"/> *

<wsdl:documentation ..../> ?

<wsdl:types> ?

<wsdl:documentation .... />?

<xsd:schema ..../> *

<-- extensibility element --> *

20 2. Web Services

</wsdl:types>

<wsdl:message name="nmtoken"> *

<wsdl:documentation .... /> ?

<part name="nmtoken" element="qname"? type="qname"?/> *

</wsdl:message>

<wsdl:portType name="nmtoken"> *


<wsdl:operation name="nmtoken"> *


<wsdl:input name="nmtoken"? message="qname"> ?

<wsdl:documentation.... /> ?

</wsdl:input>

<wsdl:output name="nmtoken"? message="qname"> ?


</wsdl:output>

<wsdl:fault name="nmtoken" message="qname"> *


</wsdl:fault> </wsdl:operation>

</wsdl:portType>

<wsdl:binding name="nmtoken" type="qname"> *



<wsdl:operation name="nmtoken"> *



<wsdl:input> ?



</wsdl:input>

<wsdl:output> ?



</wsdl:output>

<wsdl:fault name="nmtoken"> *



</wsdl:fault>


</wsdl:operation>

</wsdl:binding>

<wsdl:service name="nmtoken"> *


<wsdl:port name="nmtoken" binding="qname"> *



</wsdl:port>


</wsdl:service>


</wsdl:definitions>

The tag <definitions> is the main tag of a WSDL document. It includes all theother tags that compose the specification. It is worth noticing that WSDL documentcan be obtained by composing other documents. This can be done through the tag<import> which allows for the inclusion of other WSDL documents.

A message is declared using the tag <message>, and represents a unit of commu-nication with a Web service, containing the data exchanged in a single transmission.In order to interpret the data being exchanged, correctly at both ends of the commu-nication, like any IDL, WSDL uses a type system. Unlike IDLs in conventional mid-dleware where the type system is imposed by the underlying platform (e.g., CORBAor J2EE), in WSDL the type system usually adopted is that of XML Schema, but itis possible to specify different type systems if necessary. XML Schema has built-indata types and allows users to defined more complex data types. Each message is atyped document characterized by a name and divided into parts. Each part is declaredthrough the <part> tag, and is characterized by a name and by a type, which refersto a type defined in XML Schema.

The abstract part of a WSDL specification is made of port type definitions, whichare analogous to interfaces in traditional IDLs. Each <portType> tag describes alogical collection of operations, which are deployed at the same location under thesame protocol. An operation is an abstract description of an action supported by theservice. Each <operation> tag comprises several elements defining a simple ex-change of messages. These messages can be input messages declared in the <input>

element, or output messages declared in the <output> element of the <operation>

tag. In addition to normal input and output messages, we can also specify fault mes-sages that we wish to use in the event of an error. Fault messages are declared by the<fault> element of the <operation> tag.

There are four basic kinds of operations, which involve a single message or theexchange of two messages:

22 2. Web Services

• One-way - the client invokes a service by sending a message, specified in the<input> element of the corresponding <operation> tag.

• Notification - the service sends a message, specified in the <output> elementof the corresponding <operation> tag.

• Request-response - the client invokes a service and waits for a response. Themessage for the request is specified in the <input> element, whereas the mes-sage for the response in the <output> element of the corresponding <operation>

tag.

• Solicit-response - the service makes a request and expects a response in return;in this case the message for the request is specified in the <output> element,whereas the message for the response in the <input> element of the corre-sponding <operation> tag.

Request-response operations are used to model synchronous interactions, while one-way and notification operations are used to model asynchronous interactions.

The concrete part of a WSDL interface defines a concrete service that implementsall the above definitions. It is described using the following three constructs:

• Bindings, that specify the message encoding and protocol bindings for all op-erations and messages defined in a given port type. They are declared usingthe tag <binding>. By this information users know what protocols to use, howto structure XML messages to interact with a service, and what to expect fromthe contacted service.

• Ports, that combine bindings information with a network address (specified bya URI) at which the implementation of the port type can be accessed. Portsare declared through the <port> tag, and represent the real access points of theWeb service. By ports information users know the network address at whichthe functionality of a port type is implemented.

• Services, which represent logical groups of ports. They are declared using thetag <service>. By services definitions users get to know all the ports that areimplemented as a group.

2.4 Web Service Composition

A Web service can be implemented by invoking other Web services, possibly pro-vided by other companies. By a composite service, we mean a Web service imple-mented by invoking other Web services, and by an atomic service, a Web serviceimplemented and invoked directly. As observed in [Alonso et al., 2004], whether a

2.4. Web Service Composition 23

Web service is atomic or composite is irrelevant from the perspective of the clients,as it is only an implementation issue. This is due to the fact that, in any case, Webservices are described, discovered and invoked in the same way. Furthermore, servicecomposition can be iterated, thus allowing the definition of increasingly complex ap-plications by aggregating components: a client itself can be a Web service, and assuch it can be used as a component by other (composite) services.

Web service composition is an implementation technology. It is based on a com-position model and a composition language, which both specify the compositionschema. The composition schema defines the services to be combined, the orderin which these are to be invoked (possibly based on run-time conditions), and theway messages that constitute the service invocation parameters, are built.

A composition model can be characterized in terms of six different aspects [Alonsoet al., 2004]:

• Component model, defining the nature of the elements to be composed andwhat is assumed about them;

• Orchestration model, defining abstractions and languages that specify the orderin which services must be invoked;

• Data and data access model, describing how data is specified and exchangedbetween components;

• Service selection model, specifying how a specific service is selected as a com-ponent, through a static or dynamic binding;

• Transactions, describing the transactional semantics associated to the compo-sition;

• Exception handling, defining how exceptional situations occurring during theexecution of the composite service can be handled, in order to avoid the abor-tion of the composite service.

The composition schema can be designed through a development environment, whichis normally provided with a GUI interface that helps the designer’s task. The designersimply drags and drops Web services into canvas, and designs graphs denoting theorder in which the services are to be invoked. Once specified, the composite Webservice can be executed by the run-time environment, which invokes the componentservices defined in the schema. Each execution of a composite service is called acomposition instance. There exists two kinds of composition models: Orchestrationand Choreography. The two terms, Orchestration and Choreography, describe twoaspects of creating business processes from composite Web Services [Peltz, 2003]:

• Choreography concerns the interactions of services with their client/users: Ittracks the sequence of messages, operations, states and conditions which occur

24 2. Web Services

during the interaction. The pattern prescribed by a choreography, if success-fully followed, leads to the completion of some functions (see Figure 2.6);

Web ServiceWeb Service

Web ServiceWeb ServiceWeb ServiceWeb Service

Collaboration

Figure 2.6: Web Services Choreography

• Orchestration defines the sequence and conditions in which one Web Serviceinvokes other Web services in order to realize some functions. An orchestrationmay be seen as the pattern of interactions that a Web service agent must followto achieve its goals (see Figure 2.7).

Figure 2.8 depicts the difference between Orchestration and Choreography: the for-mer refers to an executable business process that can interact with both internal andexternal services (the process is always controlled from the perspective of one of thebusiness parties); the latter is more collaborative, in which each party involved inthe process describes the part it plays in the interaction (none of them truly owns theconversation).

The success of composition as a technique for building complex systems dependson the availability of precise descriptions of components functionalities (what theydo), as well as of the interfaces and protocols they support (how they can be inter-connected with the other components). Moreover, these descriptions must followa standard notation and syntax in order to be universally understandable and eas-ily implementable. Web services have well-defined interfaces, and their behavior isspecified as part of the information provided in Web services registries. They are de-scribed using the same language (WSDL), and invoked by sending XML documents



Web ServiceWeb Service Web ServiceWeb Service

Process Flow

Figure 2.7: Web Services Orchestration

Orchestration OrchestrationChoreography

request

acknowledge

acknowledge

accept





Figure 2.8: Orchestration vs. Choreography

26 2. Web Services

packaged in SOAP messages. Web services offer standardized directory and serviceselection mechanisms (UDDI) that can be adopted and adapted by any compositionsystem.

Efforts devoted to the standardization of composition models are aimed to sup-port the rapid development of complex services from basic ones. Two languages,proposed by the W3C, are emerging as the leading composition languages:

• Business Process Execution Language for Web Services (BPEL4WS), for spec-ifying the orchestration of services. A BPEL4WS file denotes the specificationof the orchestrator, the process that composes the component services. Thisspecification is then executed by the orchestration engine, which is in chargeof coordinating the component services on the basis of the specification;

• Web Service - Choreography Description Language (WS-CDL), for specify-ing the coordination of multiple services. A WS-CDL specification is a multi-participant contract that describes the observable behavior of collaborating ser-vices, from an external point of view. The basic architecture is a peer-to-peerarchitecture: component services coordinate themselves on the basis of theWS-CDL specification, with no centralized control.

The reader interested in WS-CDL can refer to [W3C, 2005]. In the rest of the chapter,we cover the BPEL4WS language focusing on the different aspects of the servicecomposition model. In particular, we refer to the version of the language describedin [Curbera et al., 2002], since it was the standard available at the time we startedthis dissertation. The Organization for the Advancement of Structured InformationStandards (OASIS)5 technical committee voted to change the name into WS-BPELto align BPEL4WS with other Web Service standard naming conventions which startwith WS, and recently proposed a new version 2.0, described in [OASIS, 2007].

2.4.1 BPEL4WS

Business Process Execution Language for Web Services (BPEL4WS) is an XML-based language for specifying the orchestration of Web services. We will use theacronym BPEL, as opposed to the lengthly BPEL4WS that appears in the relateddocuments. A BPEL process, also called business process, describes the behaviorof an orchestrator by means of workflow constructs and communication primitives.A business process is executed by the orchestration engine, which is an executionenvironment that takes in input a BPEL specification and animates it. A process canbe of two types:

5OASIS is a global consortium that drives the development, convergence and adoption of e-business

and Web service standards [OASIS, Organization for the Advancement of Structured Information Stan-

dards].


• abstract - it defines sequences of messages sent and received by a service, andthe order in which the send and receive operations should be done (businessprotocol);

• executable - it defines the implementation logic of the composite service (in-teraction protocol).

Abstract and executable processes are described using a similar formalism. The maindifferences rely in the data handling part. Abstract processes handle only protocol-relevant data, in the sense that messages parameters and control flow data can be leftunspecified.

BPEL business processes represent stateful long-running interactions in whicheach interaction has a beginning, defined behavior during its lifetime, and an end. Aninteraction starts with the creation of a business process instance, and ends with thetermination of the process instance behavior. A process instance can have a normalor an abnormal termination. Abnormal terminations can occur due to faults duringthe execution, or can be forced deliberately.

BPEL is layered on top of several XML specifications: WSDL, XML Schema,and XPath [W3C, 1999a], XSLT [W3C, 1999b], and XQuery [W3C, 2007e]. WSDLmessages and XML Schema type definitions provide the data model used by BPELprocesses. XPath, XSLT, and XQuery provide support for data manipulation. BPELassumes that the process itself and its partners are modelled as WSDL services. Inparticular, a BPEL process represents all partners6 and interactions with these part-ners in terms of abstract WSDL interfaces (portTypes and operations). The inter-action is based on the exchange of WSDL messages. A business process can haveseveral partners and, for each of them, can have several interactions. In order to dealwith specific aspects of the business process and the conversations that it sets up withthe partners, the WSDL file of the BPEL process is extended with additional tags thatare not part of the WSDL grammar. These additional tags will be described in detailsbelow.

In the following, we introduce the BPEL language. Specifically, we illustrate thesix aspects of the composition model discussed at the beginning of this section, alsoby providing some pieces of sample XML code.

Component Model

BPEL has a fine-grained component model, consisting of activities. All the activitiescharacterizing the behavior of a business process are defined within the <process>

tag, which is the initial tag of any BPEL specifications. Activities can be basic orstructured. Structured activities are used to define the orchestration. They prescribethe order in which a collection of activities take place. Basic activities correspond

6In general, we call a partner a service that interacts with the business process.

28 2. Web Services

to the invocation of a WSDL operation performed by a service playing a role onto aservice playing a different role. BPEL offers several basic activities.

Invoke - It is defined by using the <invoke> tag. It represents the invocation ofa synchronous request-reply operation or an asynchronous one-way operation, of-fered by the component Web service. The partnerLink attribute of the <invoke>

tag denotes the client, and the portType and operation attributes denote the op-eration that this client is invoking (provided by the process). Synchronous invo-cations are blocking activities (the process waits for a reply from the invoked ser-vice). In this case, we need to specify both an input variable and an output variableto store the exchanged messages, respectively denoted by the inputVariable andoutputVariable attribute in the invoke tag.

<invoke partnerLink="Adder"

portType="tns:requestResultPortType"

operation="requestResultOperation"

inputVariable="x"

outputVariable="y"/>

Asynchronous invocations are not blocking. For such kind of activities we specifyonly the input variable that is used to store the message data to be emitted by theinvoked service.


portType="tns:requestPortType"

operation="requestOperation"

inputVariable="x"/>

Receive - It is defined by using the <receive> tag. It corresponds to the receiptof a message from a client, in a request-reply or one-way operation. These kindof activities are used to provide services to partners. They are blocking, since theexecution of the composite Web service does not proceed until a message is received.

<receive partnerLink="Requester"

portType="tns:requestPortType"

operation="requestOperation"

variable="x"/>

The partnerLink attribute of the <receive> tag refers to the partner from whichit is expected to receive a value; the portType and operation attributes denote theoperation that the partner is invoking (provided by the process); and the variable

attribute specifies the variable that stores the message data received. A receive ac-tivity annotated with the createInstance attribute set to yes is used to instantiate abusiness process.


<receive partnerLink=...

portType=...

operation=...

variable=...

createInstance="yes"/>

Such kind of activities are usually called “start activities”. Each business processmust contain at least one start activity, which appears as the initial one, in the sensethat there is no basic activity that logically precedes it in the execution flow.Reply - It is defined by using the <reply> tag. This activity is used to send a responseto a request, previously accepted through a receive activity. The message data sent inreply is stored in the variable specified by its variable attribute.

<reply partnerLink="Requester"



variable="y"/>

Observe that, such responses are meaningful only for synchronous interactions. Asyn-chronous response is always sent by invoking the corresponding one-way operationon the partner’s service.

Assign - It is defined by using the <assign> tag. This activity allows for assigningdata to variables, copying data from other variables or for creating new data usingexpressions. The source for data is specified in the <from> element of the <assign>

tag, and the destination is specified in the <to> element.

<assign name="initialization">

<copy>

<from expression="0"/>

<to variable="y"/>

</copy>

<copy>


<to variable="z"/>

</copy>

</assign>

Wait - This activity is expressed by the <wait> tag. It is used for defining pointsin the process where the execution should block for a certain period of time (forattribute) or until a certain deadline is reached (until attribute).

<wait until="2002-12-24T18:00+01:00"/>

Empty - This activity represents an operation that does nothing. It is specified by the<empty> tag.

30 2. Web Services

Orchestration Model

BPEL allows the definition of several structured activities. They group a set of otherstructured or basic activities.Sequence - It contains a set of activities to be executed sequentially, in the order inwhich they are listed in the <sequence> tag.

<sequence>

<invoke .../>

<sequence/>

The sequence activity completes when the final activity in the sequence is completed.Switch - It is defined by a <switch> tag. The activity consists of an ordered listof one or more branches defined by <case> elements, followed optionally by an<otherwise> branch. The case branches are considered in the order in which theyappear. The first branch whose condition is true is taken and provides the activityperformed for the switch. If no branch with a condition is taken, then the otherwisebranch is taken. If the otherwise branch is not explicitly specified, then an otherwisebranch with an empty activity is assumed to present.

<switch>



<case condition="bpws:getVariableData(’x’) < 5">

<assign name="result">

<copy>

<from expression="bpws:getVariableData(’x’) +

bpws:getVariableData(’z’)"/>

<to variable="y"/>

</copy>

</assign>

...

<reply ... variable="y"/>

</case>

</switch>

The switch activity completes when the activity of the selected branch completes.

Pick - It defines a set of events, each associated with an activity, within a <pick> tag.An event can be the receipt of a message in a request-response or one-way operation,or the expiration of an alarm. When one of the event occurs, its associated activityis executed and the pick is considered completed. If more than one event occurs,then the selection of the activity to execute depends on which event occurred first. Ifevents occur almost simultaneously, there is a race, and the choice of the activity tobe executed depends on both timing and implementation.

<pick>

<onMessage partnerLink="buyer"

portType="orderEntry"

operation="inputLineItem"

variable="lineItem">



...

</onMessage>

<onMessage partnerLink="buyer"

portType="orderEntry"

operation="orderComplete"

variable="completionDetail">


...

</onMessage>

<onAlarm>



<for>P3DT10H</for>


...

</onAlarm>

</pick>

Pick activities can be start activities. If instantiation has to occur as a result of areceipt of one of a set of messages, the pick activity should be annotated with acreateInstance attribute to yes).

<pick createInstance="yes">

<onMessage ...>

...

<\onMessage>

In this case, the events in the pick are all be inbound messages and each of thoseis equivalent to a receive with the attribute createInstance="yes". No alarms arepermitted for this special case.

While - It is defined by the <while> tag. This activity supports repeated execution ofa specified activity, which can be basic or structured.

<while condition="bpws:getVariableData(’input’,’payload’,’/value’)

<= number(3)">

32 2. Web Services

<sequence>

...

</sequence>

</while>

The iterated activity is executed while the specific condition is true.

Flow - The <flow> tag groups a set of activities to be started in parallel.

<flow>



<sequence>

<invoke name="invokeUL".../>

...

</sequence>



<sequence>

<invoke name="invokeAL".../>

...

</sequence>

</flow>

It is considered completed when all the included activities are completed.

Data and Data Transfer

BPEL maintains the state of the process and manipulates control data by means ofvariables. The state consists of messages received and sent as well as other relevantdata such as time-out values. BPEL variables are analogous to variables in conven-tional programming languages. They are defined by using the <variable> tag. Eachvariable has a name and a type. The type is specified as a reference either to a WSDLmessage type, or XML Schema simple type or XML Schema elements. Variablesmust be defined in the process specification, before being used. They provide themeans to pass values to messages and then exchange them with partners. They canalso store data that are needed for holding state related to the process and never ex-changed with partners.

<variables>

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


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

...

</variables>

...

<sequence>

...


<copy>


<to variable="y"/>

</copy>

<copy>


<to variable="z"/>

</copy>

</assign>

...

</sequence>

The assign activity can be used to copy data from one variable to another, as wellas to construct and insert new data to be manipulated in expressions. Several kindsof functions may be called at this level such as core XPath functions, BPEL XPathfunctions, or custom ones. XPath expressions appear in the assign activity. Theysimplify the extraction of information from elements or the storage of a value intoa variable. Complex data manipulation may also be written using XSLT, XQueryor JAVA (e.g., JAVA <exec> tags enable one to insert Java code into BPEL code).Another way to describe data operations is to use a database and specify adequatequeries to access and manipulate stored information.

Abstract and executable processes differ on how data handling and assignment isdone. In abstract processes data assignments may be opaque, i.e., the source of thedata is left unspecified. In other words, in abstract processes it is possible to specifythat a variable will change value, without defining how the new value is determined.Since variables are used to control the orchestration and to form message parameters,opaque assignments enable nondeterministic specifications both in the orchestrationand in the data transfer between activities. This is how abstract processes hide imple-mentation details from clients, and specify only the external behavior of a service.

Service Selection

Service selection in BPEL is based on the notion of partner link types, partner links,and endpoint reference. Partner link types identify pairs of roles that exchange mes-

34 2. Web Services

sages during process execution, and the WSDL port types that the services playingthese roles are required to implement. They are described in the WSDL specifica-tions through the <partnerLinkType> tag, which defines up to two role names bythe <role> tag; and the port types that each role must support for the interaction tobe carried out successfully by listing the corresponding <portType> tags.

<message name="requestMessage".../>

<message name="resultMessage".../>

</message>

...

<portType name="requestResultPortType">

<operation name="requestResultOperation">

...

</operation>

</portType>

...

<plnk:partnerLinkType

name="requestResultPartnerLinkType">

<plnk:role name="requestResultAdder">

<plnk:portType

name="tns:requestResultPortType"/>

</plnk:role>

<plnk:role name="requestResultRequester">

<plnk:portType


</plnk:role>

</plnk:partnerLinkType>

Partner links identify services invoked during the execution of a process, and aretherefore bound to specific endpoint. The definition of a partner link is done by a<partnerLink> tag and refers to a partner link type. In this way, it is identified therole played by the process, indicated by the attribute myRole, and the one played bythe partner with respect to that link, indicated by the attribute partnerRole.

<partnerLinks>

<partnerLink name="ResultRequester"

partnerLinkType="tns:requestResultPartnerLinkType"

partnerRole="requestResultAdder"

myRole="requestResultRequester"/>


...

</partnerLinks>

Partner link information is then used in the <invoke>, <receive> and <reply> ac-tivities to identify the partners of the process in a conversation. It is specified in thepartnerLink attribute of the activity.

The association between the partner link and the specific endpoint can be doneat composite service deployment time, in a manner that is dependent on the specificBPEL implementation, and it is therefore not part of the specification. Otherwise,these associations can be done dynamically at run time, by assigning endpoint refer-ence to partner links, just as it is possible to assign values to variables. The assign-ment can be done several times during the execution. This means that the processcan invoke different Web services during the execution, each having the same partnerlink type and role.

Exception and Transactions

In the context of Web service composition, the term exception refers to a deviationfrom the expected execution of the composition. Exceptions are typically caused bya failure in the system or in the invoked applications. BPEL adopts a try-catch-throwapproach for exception handling. This mechanism associates an exception-handlinglogic to activities, which is executed when a certain condition related to the exceptionis verified. After the exception as been handled, the process execution can proceed,or the failed activity can be retried, or the process can be terminated.

In BPEL, each (basic or structured) activity implicitly defines a scope. Scopescan also be declared explicitly by the <scope> tag. Any scope-defining element caninclude the <faultHandlers> tag which is the specification of one or more faulthandlers, dictating how a certain exception should be managed. A fault handler ischaracterized by a <catch> element, that defines the fault it manages and the activityto be executed if the fault occurs. Faults can be generated during the execution of anactivity within the scope, either by the invoked operation (returning a WSDL faultmessage), or by the execution engine (due to run time errors). When a fault occurswithin a given scope, a BPEL engine will terminate all running activities in thatscope and execute the activity specified in the fault handler for the scope. If nohandler exists for a given fault, then a default handler (which is associated by defaultto each scope) is executed. BPEL allows also to semantically undo the execution ofactivities in a scope. The compensation logic is defined in a compensation handler bythe <compensationHandler> tag, consisting of a single (basic or structured) activitythat performs whatever actions are needed to compensate for the execution. Everyscope has associated a default compensation handler, which is in charge of executingthe compensation handlers for each enclosed scope in reverse order.

36 2. Web Services

Instance Routing

Instance Routing is an aspect of service composition that is not part of the composi-tion model, but is important anyway. It refers to the mapping of messages received bythe orchestration engine to specific composition instance. BPEL addresses this issueby the definition of correlation sets within the composition schema. Correlation setsare defined within the <correlations> tag. They can be associated with messagessent or received by the composite service within invoke, receive and reply activities.By associating a pair of messages to the same correlation set, the designer specifiesthat if the message has the same value of the correlation set, then it belongs to thesame instance. The characteristics that enable the identification of an instance fromthe message data may change based on the messages being exchanged and on the ser-vice provider to be invoked. In this case, it is possible to define multiple correlationsets.

2.5 Semantic Web Services

In this section, we provide a brief introduction to a novel approach to SOA: the Se-mantic Web Services and the supporting Semantic Web technology.

Current Web service technologies address only the syntactic aspects of servicesand thus provide a set of rigid Web services that cannot adapt to a changing envi-ronment without human intervention. The vision underlying Semantic Web services[McIlraith, Son, & Zeng, 2001] is to create a Semantic Web of services whose prop-erties, capabilities, interfaces, and effects are encoded in an unambiguous, machine-understandable form. The term Semantic Web appeared for the first time in [Berners-Lee, Hendler, & Lassila, 2001]. The goal of the Semantic Web is to solve the currentlimitations of the Web by augmenting Web information with a formal representationof its meaning. A direct benefit of this machine processable semantics would bethe enhancement and automation of several information management tasks, such assearch or data integration. The Semantic Web relies on ontologies to formalize thedomain concepts that are shared among Web services. The Internet is therefore seenas a globally linked database in which Web pages are marked with semantic annota-tions. Given such an infrastructure, it is possible to design applications that use theannotations and suitable inference engines to automatically discover, execute, com-pose and interoperate services.

Critical to the vision of the Semantic Web is the provision of a markup languagethat has a well-defined syntax and semantics to enable unambiguous computer inter-pretation. The language must also be sufficiently expressive to describe the propertiesand capabilities of Web services. Over the last several years, a number of SemanticWeb markup languages have been proposed. These include XML, Resource De-scription Format (RDF) and RDF Schema (RDFS) [W3C, 2004b], and most recently

2.5. Semantic Web Services 37

Ontology Web Language (OWL) [W3C, 2004a] (formerly DAML+OIL). OWL isan AI-inspired description logic-based language for describing taxonomic informa-tion. The OWL language builds on top of XML and RDF/RDFS to provide a lan-guage with both a well-defined semantics and a set of language constructs includingclasses, subclasses and properties with domains and ranges, for describing a Webdomain. OWL-S (formerly DAML-S) [DMAL, 2006] is a OWL ontology for Webservices developed by a group of Semantic Web researchers, under the auspices ofthe DARPA Agent Markup Language (DAML) program. In the rest of this section,we illustrate the basic concepts of OWL-S.

2.5.1 OWL-S

OWL-S enables the definition of Semantic Web service content vocabulary in termsof objects and complex relationships between them, including class, subclass rela-tions, cardinality restrictions, etc., and all XML typing information. In particular, theontology comprises:

• the service profile: it describes what the service requires from and gives tousers, i.e., its capabilities, its inputs, outputs, its preconditions and (condi-tional) effects;

• the service model: it specifies how the service works, i.e., the control flow anddata-flow involved in using the service;

• the service grounding: it gives information on how to use the service, i.e., itdescribes the transport-level messaging information associated with executionof the actual program that realizes the service.

Services are modelled as processes. Specifically, OWL-S defines a class processmodel as a subclass of the service model. The process model describes a service interms of inputs, outputs, preconditions, postconditions, and the subprocesses com-posing the service itself. Processes can be of three types:

• atomic, which have no subprocesses;

• simple, which are not directly invocable and are used as an abstraction elementfor either atomic or composite processes;

• composite, which consists of subprocesses.

An atomic process is characterized primarily in terms of its inputs, outputs, precon-ditions, and effects (IOPEs). The inputs specify the information the process requiresfor its execution. The result of the execution of the process is the generation of aset of outputs. The inputs and outputs of an atomic process are given types from the(class-hierarchical, description logic-based) typing system of OWL, which allows for

38 2. Web Services

the use of concepts defined and shared as part of the Semantic Web. Preconditionsspecify conditions that should be satisfied for a process to be executed correctly. Ef-fects describe the physical side-effects the execution of the process has on the world.Note that, there is a fundamental difference between effects and outputs. Effects de-scribes conditions on the world, while outputs describe information. Furthermore,OWL-S does not assume that outputs and effects are the same for every execution ofthe process. Rather, it allows to specify a set of conditions under which the outputsor the effects may result. Such kind of outputs and effects are referred to as condi-tional outputs and conditional effects, respectively. For expressing these conditions,OWL-S allows for the use of a more expressive language than OWL, such as RuleML[RuleML, The Rule Markup Initiative], DRS [McDermott & Dou, 2002], or the OWLRules Language [Horrocks et al., 2003].

A composite process is specified by using a set of flow control constructs suchas Sequence, Split, Split+Join Unordered, Choice, If-Then-Else, Iterate, and Repeat-Until. In addition, OWL-S specifies constructs that can be used for the description ofdata flow, i.e., it introduces the binding mechanism (InputBinding and OutputBindingclasses). Using this mechanism, it is possible to state the relation of a process inputsto its outputs, conditions and results, and the relation between the inputs and theoutputs of a composite process with the inputs and the outputs of another. Moreover,it is possible to state regarding a composite process, how the output of a sub-processis related to the input of another.

The benefits of the richer descriptions supported by OWL-S are multiple. In thearea of enactment7, OWL-S supports the specification of composite processes, andallows for flexible, robust invocation and interoperation between service clients andproviders. In the area of discovery, OWL-S allows service registries and matchmak-ing algorithms to take advantage of ontology-based characterization of services. Inthe area of service composition, a variety of approaches exist to reason about OWL-SIOPEs, in support of manual, semi-automated, and, under controlled conditions, au-tomated composition of both information-gathering and world-altering services. Inconclusion, OWL-S can help to enable full automation and dynamism in many as-pects of Web service provision and use, support the construction of powerful tools andmethodologies, and promote the use of semantically well-founded reasoning aboutservices.

2.5.2 OWL-S versus WSDL/BPEL

We now compare OWL-S with the dominant Web service standards WSDL andBPEL. WSDL allows for the specification of operations as the basic building blocksof Web services. Operations provide the organizational structure around which in-

7Enactment is the process by which a client applies a declarative description of a service to request

something of the service and interpret the response.

2.6. Example: A Stock Management System 39

put/output message syntax and patterns are specified. OWL-S provides an analogousbut somewhat more abstract construct known as the atomic process, which is charac-terized in terms of its inputs, outputs, preconditions, and effects (IOPEs). WSDL’slack of semantic descriptions of the meaning of inputs and outputs makes it impos-sible to develop software clients that can dynamically (without human assistance)find and successfully invoke a service. WSDL specifications of services must be in-terpreted by programmers, who interpret the names of keywords given for messageelements using other supporting documentation to integrate specific services withtheir client applications. On the other hand, inputs and outputs of OWL-S atomicprocesses are given types from the typing system of OWL, which allows for the useof concepts defined and shared as part of the Semantic Web.

The area of greatest overlap between BPEL and OWL-S is in the process model,but there are some crucial differences. OWL-S process notation includes precondi-tions and results, which enable automated tools to select and compose Web Services.The BPEL notation includes complex control structures and exception-recovery pro-tocols. The OWL-S process model and BPEL attempt to cover similar territory, butin complementary ways. The emphasis in OWL-S is on making process descriptionscomputer-interpretable, described with sufficient information to enable automationof a variety of tasks including Web Service discovery, invocation, and composition.BPEL provides a language primarily intended for manually constructing processesand protocols.

2.6 Example: A Stock Management System

In this section we provide an example of a composite Web service. For the sakeof comprehension, we choose a simple problem. Let us imagine that a chain ofsupermarkets (called local stores in the following) have to be supplied with goods (orproducts) every day (or as soon as needed, it depends on the local policy). All theneeded goods are centralized in a central store whose role is to supply all the localstores when they request something. This central store has to be supplied as well bysuppliers, particularly dedicated to a specific product (e.g., vegetables or fruits).

Our goal herein is to develop the Web service corresponding to the central storeassuming the existence of services describing local stores and suppliers. It is obvi-ous that many local stores and suppliers can interact with one central store (even ifafterwards several instances of central stores could be created). Local store and Sup-plier services are viewed through their public interfaces that we assume representedusing a simple behavioral description. It is out of scope here to introduce an adequatelanguage for interface description. In this section, we introduce the services usingtransition systems with parameterized actions. A Local Store service (see Figure 2.9)sends a request (an identifier id and a quantity qt) to acquire a certain amount of aproduct, and waits for an acceptance or a refusal. Similarly, a Supplier service re-

40 2. Web Services

ceives a request and replies depending on its ability to satisfy the request. A Central

okS

requestS?id?qt

nok

ok

request!id!qt

nokS

Local store Supplier

Figure 2.9: Behavioral Interfaces: Local Store and Supplier

Store may receive requests for a product from local stores, and replies depending onthe availability of that product in its stock. It also has to supply its stock and thenshould request possible missing products to a supplier which answers depending onits ability to satisfy the request. As a simplified version, stocks can be viewed assets of pairs, each pair containing a product identifier and a quantity. A pictorialrepresentation of all the interacting services is given in Figure 2.10.

Local Store 1

Local Store 3okS v nokS

Local Store 2 okS v nokS

Supplier 1

Supplier 3

Supplier 2request

okS v nokS

ok v nok

ok v nok

ok v nok

Central Store

requestS

requestS

request

request

requestS

Figure 2.10: Overview of the Service-to-be and its Mates

The Development of the Web service corresponding to the Central Store is carriedout by using Oracle BPEL Process Manager 2.0, BPEL Console, BPEL Designer[Oracle, BPEL Process Manager]. For experimentation purposes, some other services


are encoded (Local Store and Supplier) using the same tools. The process managerprovides an infrastructure for deploying, executing and managing BPEL processes.The console is useful to test the deployed BPEL services. The designer makes itpossible to build BPEL code from a developer-friendly visual tool, and to validateand create BPEL processes. Data are described using a Microsoft Access relationaldatabase (it is obvious that any DBMS could be used at this level). We employedthe package java.sql to access the database and the driver JDBC-ODBC to make theconnection between Java classes and the database. We use the Java exec activity toinsert Java code into BPEL code, so as to call the Java methods defined to access andupdate the database. In the following, we describe the WSDL and BPEL specificationof the Central Store Web service. For the sake of brevity we provide skeletons ofcode.

The Central Store receives a request for a product from the Local Store, character-ized by the identifier of the product and the quantity, and replies with an acceptance ora refusal, depending on the availability of the required quantity in the Central Storestock. In case of existence in the stock of a product whose quantity is less than athreshold, the Central Store sends a request to a Supplier to refill its stock. It thenreceives from the Supplier a response denoting whether its request can be fulfilled.

The first step is to specify the XML messages to be changed during the interac-tion. For this purpose, we define appropriate data types in the XML Schema, in theCentral Store WSDL specification.

<types>

<schema...>

<element name="ProductRequest">

<complexType>

<sequence>

<element name="productId" type="xsd:string" />

<element name="quantity" type="xsd:int" />

</sequence>

</complexType>

</element>

<element name="ProductResponse">

<complexType>

<sequence>

<element name="response" type="xsd:boolean"/>

</sequence>

</complexType>

</element>

42 2. Web Services

</schema>

</types>

The types tag encloses data type definitions that are relevant for the representationof a product request and a response. We define an element named ProductRequest.This element is considered as a complexType, and is described by a sequence tagthat defines an ordered sequence of sub-elements. A product request is composedby an identifier and a quantity. Thus, we can define productId and quantity assub-elements of ProductRequest. These elements are considered as simple typessince they can be described directly within a tag element. For representing a re-sponse we define the element ProductResponse, which is composed by a singlesub-element named response. The content of response is a boolean value. Ifresponse = true, the requested quantity of the product is available in the Cen-tral Store stock. If response = false, the request cannot be fulfilled. Data typesxsd:string, xsd:int, and xsd:boolean denote predefined XML Schema datatypes,respectively the string, int, and boolean built-in datatypes.

The XML messages to be exchanged during the interaction with the Local Storeand with the Supplier, are defined below. In particular, the ProductRequestMessage

is composed by two parts: order, which represents a request of a product; andDBName, which contains the name of the Database representing the stock of the in-voked store.

<message name="ProductRequestMessage">

<part name="order" element="tns:ProductRequest" />

<part name="DBName" type="xsd:string"/>

</message>

<message name="ProductResponseMessage">

<part name="response" element="tns:ProductResponse" />

</message>

The Central Store is invoked by the Local Store with a synchronous request-replyoperation. This operation is defined in the portType tag. The input message is therequest sent by the Local Store. The output message is the response that the CentralStore sends to the Local Store, after checking its stock.

<portType name="CentralStore">

...

<operation name="requestProduct">

<input message="tns:ProductRequestMessage"/>

<output message="tns:ProductResponseMessage"/>

</operation>

</portType>

The roles played by the Central Store in the conversations with the Local Store andthe Suppliers, are described in the partnerLinkType tags.

<plnk:partnerLinkType name="CentralStore">

<plnk:role name="CentralStoreProvider">

<plnk:portType name="tns:CentralStore"/>

</plnk:role>

<plnk:role name="CentralStoreRequester">


</plnk:role>


<plnk:partnerLinkType name="CentralStoreOrder">

<plnk:role name="orderProvider">


</plnk:role>

<plnk:role name="orderRequester">


</plnk:role>


The Central Store acts as a provider in the interaction with the Local Store, and asa client in the interaction with the Supplier. Its corresponding BPEL file defines thevariables that this process manipulate, as well as the partnerLinks identifying thepartner processes which it expects to interact with, and the orchestration logic madeup of all the activities it has to perform. Below, we provide the part of the BPEL codedescribing the interaction between the Central Store and the Local Store.

<sequence name="main">


<onMessage partnerLink="LocalStore"

portType="tns:CentralStore"

operation="requestProduct"

variable="productRequest">



<sequence>

...



<bpelx:exec language="java" version="1.4">

<![CDATA[

...

44 2. Web Services

//open the connection with the database

DBConnection cscDBC=new DBConnection("CentralStoreStock");

if(cscDBC.isAvailable((String) productId.getNodeValue()))

{

setVariableData("available", new Boolean("true"));

}

//close the connection with the database

cscDBC.close();

]]>

</bpelx:exec>

<switch>

<case condition="bpws:getVariableData(’available’)=true()">

<sequence>

<assign name="isAvailable">

<copy>

<from expression="true()">

</from>

<to variable="productResponse" part="response"

query="/tns:ProductResponse/tns:response"/>

</copy>

</assign>



<reply name="response"

partnerLink="LocalStore"

portType="tns:CentralStore"


variable="productResponse"/>



...

</sequence>

</case>

<otherwise>

<sequence>



...



<reply .../>

</sequence>

</otherwise>

</switch>

</sequence>

</onMessage>

...

</sequence>

An instance of the Central Store process is created on the arrival of a request from theLocal Store. The request is examined, and correspondingly the database represent-ing the Central Store stock, is queried for verifying the availability of the requestedquantity of the product. The interaction with the database is implemented by someJava code inserted in the BPEL code within the <exec> tag. Before terminating, theCentral Store builds an appropriate response and sends it back to the Local Store.

The BPEL code provided below specifies the interaction between the CentralStore and the Supplier. If the quantity of a product in the Central Store stock isunder a threshold, the Central Store invokes the Supplier, by sending a request for theproduct. This request is represented by an XML message of type productRequest.The database corresponding to the Central Store stock is updated only if the responseof the Supplier is an acceptance. Once again, we use some Java code embedded inthe XML to manage the interaction with the database.

...




<![CDATA[

//open the connection to the DB

DBConnection cscDBC=new DBConnection("CentralStoreStock");

...

]]>

</bpelx:exec>

<switch>

<case condition="bpws:getVariableData(’productRequest’,

’order’,’/tns:ProductRequest/tns:quantity’)!=0">

<sequence>



...

<invoke name="requestProduct"

partnerLink="Supplier"

portType="tns:Supplier"


inputVariable="productRequest"

46 2. Web Services

outputVariable="productResponse"/>

<switch>

<case condition="bpws:getVariableData(’productResponse’,

’response’, ’response’)=true()">

<sequence>


<![CDATA[

//we read the availability response

...

//the stock is updated only if the requested product

//is available

]]>

</bpelx:exec>

</sequence>

</case>

</switch>

...

2.7 Remarks

Implementing Web services in BPEL using all the necessary technologies (Java,databases, BPEL Process Manager) is not so simple. Nevertheless, with a minimumknowledge of such technologies, Web services can be implemented and deployedeasily, depending of course on the size of the application.

Chapter 3

Formal Approaches for WebServices

Web Service technology provides standard mechanisms and protocols for describing,locating and invoking services available all over the Web. Existing infrastructures al-ready enable providers to describe services in terms of their interface and to combinesimpler services into more structured and complex ones. However, research is stillneeded to move Web service technology from skilled handcrafting to well-engineeredpractice, supporting the management of interactions with stateful and long-runningservices, and quality of service delivery.

Formal approaches can play a fundamental role in the shaping of such innova-tions. For instance, they can help us define unambiguous semantics for the languagesand protocols that underpin existing Web service infrastructures, and provide a basisfor checking the conformance and compliance of bundled services. They can also em-power dynamic discovery and binding with compatibility checks against behavioralproperties and quality of service requirements. The theoretical investigation of Webservices cuts across many areas of computer science - Data Integration, ArtificialIntelligence (Knowledge Representation, Planning and Reasoning About Actions),Theoretical Computer Science (Program Synthesis and Verification), and SoftwareEngineering (Software Components) - and comes with numerous proposals. In thischapter we survey some of the relevant approaches that constitute the state of the arton services and that are somehow related to the results presented in this dissertation.

3.1 Labelled Transition Systems

Labelled transition systems or automata are a well-known model underlying formalspecifications of systems. An automaton consists of a set of states, a set of actions, a

47

48 3. Formal Approaches for Web Services

set of labelled transitions between states, and a set of initial states. Labels representactions and a transition label indicates the action causing the transition from one stateto another. The intuitive way in which an automaton can model a system behaviorhas lead to a variety of automata-based specification models such as, for instance,Input/Output (I/O) automata and their variants, as team automata and timed automata.

I/O automata [Lynch & Tuttle, 1989; Lynch, 2003; Kaynar et al., 2006] are usedto model distributed computations in asynchronous networks and as a means of con-structing correctness proofs of distributed algorithms. An I/O automaton is charac-terized by a set of actions partitioned into input, output, and internal actions. The dis-tinction between internal and external (input and output) actions is needed to modelthe communication with the environment, which may consist of other I/O automata.I/O automata can be composed using a synchronous product construction, yielding anew I/O automaton. Many variants of I/O automata can be considered. The model isalso widely used for describing reactive, distributed systems.

Team automata [Ellis, 1997; ter Beek et al., 2003] are an extension of I/O au-tomata, introduced to model components of groupware systems and their intercon-nections. They are also used as a formal model for the study of synchronizationmechanisms in automata models. Team automata allow a flexible modelling of vari-ous kinds of collaboration in groupware systems. They do not impose any restrictionson the role of the actions in the various components, and their composition is notbased on an a-priori fixed way of synchronizing actions. This allows the definition ofa wide variety of protocols for the interaction between a system and its environment.

Timed automata [Alur & Dill, 1994; Alur, 1999] are used to model the behaviorof real-time systems. They extend automata with timing constraints by using a fi-nite number of real-valued clocks, which can be reset and whose values increase uni-formly with time. At any moment in time, the value of a clock equals the time elapsedsince the last time it was reset. These clocks can be used to guard the transition fromone state to another: a transition is enabled iff the timing constraint associated withit, is satisfied by the current values of the clocks. One of the main attractions oftimed automata is the well-developed automatic tool support. Model checkers likeUPPAAL [UPPAL, 2007; Larsen, Pettersson, & Yi, 1997] and KRONOS [KRONOS,2002; Yovine, 2002], allow one to verify timed automata models.

Automata-based models are used to formally describe, compose, and verify Webservices. In [Fu, Bultan, & Su, 2004], the authors describe a framework to analyzeand verify properties of compositions of Web services represented as BPEL processesthat communicate via asynchronous XML messages. Their framework first translatesthe BPEL processes to guarded automata, in which every transition is equipped witha guard in the form of an XPath expression [W3C, 1999a]. Then, these automataare translated into PROMELA (PROcess Meta-LAnguage), the language accepted ininput by the SPIN model-checker [Holzmann, 2003] which is used to verify whethercomposite Web services satisfy certain properties expressed using Linear TemporalLogic (LTL) [Pnueli, 1977]. Since SPIN is a finite-state verification tool, the tool

3.1. Labelled Transition Systems 49

can only achieve partial verification by fixing the size of the input queues in thetranslation. Sufficient conditions for complete verification are also obtained.

Timed automata is the chosen formalism to analyze and verify Web services withtime aspects. The time properties of interests are those that are critical from the pointof the business logic, i.e., they refer to the time required by the participating actor tocarry out their tasks and take their decisions, and to the assumptions and constraintson these times that guarantee a successful execution of the business processes. Suchaspects are normally managed by current industrial solutions with elements such astime-outs and alignments. Time-outs allow each party to fix the available time foran action to occur, while alignments are synchronization between two peer-to-peerparties. Examples of formal frameworks based on timed automata for the analysisand verification of Web services with time constraints are [Dıaz et al., 2005] and[Kazhamiakin, Pandya, & Pistore, 2005]. The former discusses a translation of de-scriptions of Web services written in WSDL-BPEL/WS-CDL to timed automata. TheUPPAAL tool is then used to describe, simulate and analyze the obtained timed au-tomata. The latter proposes an encoding of BPEL processes into Web Services TimedTransition Systems (WSTTS), which are based on timed automata for capturing theaspects specific to the Web service domain. In WSTTS formalism, the fact that theoperation takes certain amount of time is represented by time increment in the state,followed by the immediate execution of the operation. In order to guarantee thatthe transition will take place at the right moment of time, the states and transitionsof timed automata are annotated with the invariants and guards of the special clockvariables. Furthermore, the authors discuss a framework to model-check timed as-sumptions expressed in the Duration Calculus [Chaochen, Hoare, & Ravn, 1991].The model checker used for the verification is NuSMV [NuSMV, 2008], which isan open source tool obtained by reimplementing and extending SMV (acronym ofSymbolic Model Verifier) the first model checker based on BDDs.

A general formal framework for representing e-services in terms of their behav-ioral description and for characterizing the automated composition of services, isdescribed in [Berardi et al., 2003a]. In particular, this framework is specialized to thecase where services are specified by means of finite state machines (automata com-posed of a finite number of states). The authors provide an algorithm that, given aspecification of a target service (i.e., specified by a client) and a set of available com-ponent services, synthesizes a composite service that uses only the available servicesand fully captures the target one. They also study the computational complexity ofthis algorithm, and show that it runs in exponential time with respect to the size of theinput state machines. This result is proved by using a transformation of the compo-sition problem into Propositional Dynamic Logic (PDL) [Kozen & Tiuryn, 1990], awell-known logic for reasoning about programs. These results have been further ex-tended in [Berardi et al., 2004] by allowing for synchronization and communicationbetween the component e-Services.

The approaches described so far focus mainly on the description of services in


terms of the sequencing of activities. Other approaches address the issue of describ-ing how services should interact. The notion of conversation has been formulated toaddress this need [Hanson, Nandi, & Kumaran, 2002b; Hanson, Nandi, & Kumaran,2002a; W3C, 2002b]. Preliminary theoretical work on conversations is reported in[Bultan et al., 2003; Fu, Bultan, & Su, 2003]. In [Hull et al., 2003], the authorspresent a framework for modelling and analyzing the global behavior of service com-positions. Services are modelled as Mealy machines (I/O automata composed of afinite number of states), that exchange messages with other services according to apredefined communication topology, expressed as a set of channels among services.A sequence of exchanged messages (as seen by an external virtual watcher) is re-ferred to as conversation. In this framework properties of conversations are studiedin order to characterize the behavior of services, and a formal model for compositionis developed in order tackle the problem of service composition synthesis.

The approach described in [Deutsch, Sui, & Vianu, 2004] considers a service asa data-driven entity characterized by a database and a set of Web pages. The clientof the service chooses one input among a set of input choices, and in response, theservice produces as output updates over the service database and/or performs someactions, and makes a state transition. Such transitions are seen by the client as transi-tions from a Web page to another. The structure of a service is completely specifiedin terms of a relational schema, constituted by a set of tuples that dynamically dependon the service database, the current state, the available actions and input choices. Theproposed model of services is based on Abstract State Machine (ASM) transducers(a.k.a. relation transducer) [Spielmann, 2000; Spielmann, 2003], which are specialkind of automata whose inputs, outputs and internal states are represented in terms ofrelational schemas, and not as an alphabet as in the case of traditional finite state au-tomata. A relational transducer reads its input as a set of tuples, updates accordinglythe state of the internal database (i.e., transaction), writes the output also as a set oftuples, and maintains a log of performed operations.

In [Foster et al., 2003], the authors discuss a model-based approach to verify Webservices composition for Web service implementation. This approach provides verifi-cation of properties created from design specification and implementation models toconfirm expected results from the viewpoints of both the designer and implementer.Specifications of the design are modelled in UML and compiled into the Finite StateProcess notation (FSP)1, to concisely describe and reason about the concurrent pro-grams. Implementations are mechanically translated to FSP to allow an equivalencetrace verification process to be performed. The approach is supported by a suite ofcooperating tools for specification, formal modelling and trace animation of the com-position workflow.

1A formalism used for modelling systems as Labelled Transition Systems.

3.2. Petri Nets 51

3.2 Petri Nets

Petri Nets (PNs) [Petri, 1962] are a well-founded process modelling techniques thathave formal semantics. A Petri Net (PN) is a directed, connected, and bipartite graphin which each node is either a place or a transition. Places are used to representstates of processes, while transitions model operations. Arcs run between placesand transitions, and never between places or between transitions. Places from whicharcs run to a transition, are called the input places of the transition; places to whicharcs run from a transition, are called the output places of the transition. Places maycontain any non-negative number of tokens. A distribution of tokens over the placesof a net is called a marking. A transition of a PN may fire whenever there is a token atthe end of all input arcs; when it fires, it consumes these tokens, and places tokens atthe end of all output arcs. A firing is atomic, i.e., a single non-interruptible step. For amore detailed introduction to PNs, we refer the reader to [Murata, 1989; Reisig, 1985;Peterson, 1981].

PNs are a tool well suited for describing and studying concurrent, asynchronous,distributed, parallel, nondeterministic, and/or stochastic systems. As a graphical tool,PNs can be used as a visual-communication aid similar to flow charts, block dia-grams, and networks. In addition, tokens are used to simulate the dynamic and con-current activities of systems. As a mathematical tool, it is possible to set up stateequations, algebraic equations, and other mathematical models governing the behav-ior of systems. Finally, there exists a number of algorithms to check formal propertiesof modelled systems, as well expected delivered performance.

PNs are adequate to model Web services and to analyze their properties. Refer-ring to the workflow modelling paradigm of van der Aals [1998], we can straightfor-wardly map a Web service behavior to a PN. In fact, Web services execution flowscan be seen as partially ordered sets of service states and service operations. Op-erations can be modelled as transitions, whereas service states can be modelled asplaces. The PN representing a Web service execution flow is called a service net.This net is assumed to be characterized by one input place, corresponding to the stateof the service at which it is ready to be started (the service initial state), and one out-put place, corresponding to the state at which the service is completed (the servicefinal state). The input and output places should always be connected, either directlyor indirectly through some transient states, to ensure that the service is structurallyaccomplishable. A service state is active when there is a token in its correspondingplace within a service net. The presence of a token in service input and output placesreflects the service initiation and completion, respectively. If the input place of atransition is occupied by a token, the transition is enabled and may fire. On firing,a transition removes a token from its input place and deposits it to its output place.This reflects the mechanism of service state changes.

In literature there are many approaches using PNs to model and verify Web ser-vices. A first proposal is presented in [Narayanan & McIlraith, 2003], where the


authors use the DAML-S2/DAML+OIL ontology for describing the capabilities ofWeb services. They define the semantics for a subset of DAML-S that is relevant toWeb services composition, in terms of a first-order logical language. Specifically, thelanguage chosen is the situation calculus [Reiter, 1992]. With this semantics in hand,they encode services descriptions in PN formalism and provide decision proceduresfor Web service simulation, verification and composition.

An opposite approach is taken in [Andonoff, Bouzguenda, & Hanachi, 2005],where the authors use the Petri Net with Objects (PNO) formalism to graphically andformally model Workflow Web services, and provide rules to automatically deriveOWL-S specifications from PNO specifications. Workflow Web services refer to ser-vices automating business processes, whose description and execution are accessiblethrough the Web. PNO [Sibertin-Blanc, 1986] is a formalism combining coherentlyPN technology and Object-Oriented (OO) approach. While PNs are suitable to ex-press the dynamic behavior of a system, OO approach enables the modelling andthe structuring of its active (actor) and passive (information) entities. The two mainadvantages of [Andonoff, Bouzguenda, & Hanachi, 2005] proposal are first, to easethe design, the simulation and the verification of a workflow service thanks to PNO,and second, to publish it thanks to OWL-S. Consequently, PNO can be seen as aformalism providing an operational semantics to OWL-S since it defines formal andexecutable specifications to analyze, simulate, check and validate OWL-S specifica-tions.

In [Hamadi & Benatallah, 2003], the authors define a PN-based algebra for com-posing Web services. The formal semantics of the composition operators is expressedin terms of PNs by providing a direct mapping from each operator to a PN construc-tion. Thus, any service expressed using the algebra constructs can be translated into aPN representation. By means of a set of algebra properties, it is possible to transformand optimize Web service expressions guaranteeing the same semantics as the ini-tial expressions. In addition, the use of a formal model allows for the verification ofproperties and the detection of inconsistencies both within and between services. Asimilar approach is presented in [Zhovtobryukh, 2007]. Composite services are builtfrom component services through PN-based service modelling. The framework uti-lizes a Web service algebra which is largely based on that of Hamadi and Benatallah[2003].

In [Martens, 2005] PNs are used for modelling and analyzing Web services busi-ness processes. Based on this formalism, a notion of usability is provided, on the topof which issues like compatibility and equivalence are addressed. Martens appliesthis method to real world examples by exploiting the PNS sematics of BPEL, definedin [Hinz, Schmidt, & Stahl, 2005]. These examples support his claim that the methodallows for the verification of usability of one Web service, the verification of com-

2The DARPA agent markup language for services (DAML-S) has been superseded by OWL-S[DMAL, 2006]. A brief description of OWL-S is given in Section 2.5.

3.3. Process Algebras 53

patibility of two Web services, the automatic generation of an abstract process modelfor a given Web service, and the verification of simulation and consistency.

In [Bonchi et al., 2008] PNs are used to address issues like service equivalenceand the related notion of substitutability (checking whether a service may replaceanother service without altering the behavior of the whole application). In doingso, a suitable notion of behavioral equivalence for OWL-S processes represented bymeans of Open-Consume-Produce-Read Nets (OCPRNs), is introduced. OCPRNs[Bonchi et al., 2007] are a simple variant of standard PNs, designed to address dataconsistency.

In [Yang et al., 2006], an approach for the composition, analysis and verificationof Web services, based on Colored Petri Nets (CPNs) is described. This proposal issimilar to [Martens, 2005]. CPNs [Jensen, 1996] are an extended version of PNs,which have a sound mathematical semantics and a number of existing analysis tools.Yang et al. provide some rules for translating a Web composition language intoCPNs, and a technique to analyze and verify effectively the net, and to investigateseveral behavioral properties. To show the effectiveness of their technique, they showhow to translate BPEL specifications into CPNs in a constructive way. These nets arethen analyzed and verified as prototypes of the given specifications. Even though theexamples are based on BPEL, the proposed translation technique is claimed to beindependent of the language chosen for the composition.

CPNs and Hierarchical Colored Petri Nets (HCPNs) (which include additionalfeatures w.r.t. CPNs) are at the basis of another proposal described in [Boukadi etal., 2007] that aims at specifying and verifying composite Web services. Comparedto the previous approach, the authors here introduce a new concept of view in orderto take into account the changes that occur in the user and Web service environment(that constitute the current context of the service), during the development of thecomposite Web service.

3.3 Process Algebras

Process algebras are formal languages to describe communication protocols amongconcurrently running processes and to verify their properties. Many process cal-culi have been defined: CCS [Milner, 1989], ACP [Baeten & Weijand, 1990], CSP[Hoare, 1984], and their extension π-calculus [Parrow, 2001], LOTOS [Bolognesi& Brinksma, 1989], Promela [Holzmann, 2003] and Timed CSP [Schneider et al.,1992]. Their underlying semantic foundation is based on labelled transition systems.Process algebras are precise and well-studied formalisms that allow the automaticverification of certain properties of systems behavior. They provide a rich theory onbisimulation analysis (i.e., one can establish whether two processes have equivalentbehaviors). The π-calculus has also inspired modern composition languages such asXLANG and, subsequently, BPEL.


In [Chaki, Rajamani, & Rehof, 2002], the π-calculus is employed to check for-mal LTL properties of cooperative programs using model checking techniques. Inparticular, the paper introduces and discusses a notion of sub-typing based on thepossibility of a process to simulate another one.

In [Koshkina & van Breugel, 2003], the authors introduce a language, called asBPEL-calculus, to capture dynamic features of the BPEL language using a suitablebehavioral type system. This type system has been encoded using a simple processalgebra that does not handle data in messages. This approach can verify safety andliveness properties expressed using LTL model checking. The process equivalence isbased on bisimulation.

Process algebra is the formalism that we have chosen for tackling several issuesrelated to Web services. Further considerations and a detailed discussion of our pro-posal and results are given Chapter 4.

3.4 AI Planning

The composition of Web services can be done either (i) manually or (ii) automati-cally. In the manual approach, human users select proper Web services and weavethem into a cohesive workflow by exploiting their cultural knowledge of what a Webservice does as well as the information provided on the service page. Although usersmay rely on some GUI-based software to facilitate the composition, in essence, itis a labor-intensive and error-prone task. Thus, this approach is not appropriate forlarge-scale Web service composition problems. On the contrary, in the automated ap-proach, given a set of Web services and some user-defined task or goal to be achieved,a computer agent automatically finds a composition of the available services to ac-complish the task [McIlraith & Son, 2002]. To that end, Web service descriptionsmust be enriched by information related to their functionalities. In fact, such kindof semantic descriptions provide software agents with a way to automatically reasonabout the service semantics, i.e., the preconditions and effects of its operations.

The automated composition of services is a hard problem and it is not entirelyclear which technique serves the problem best. Many research efforts tackle thisproblem via AI planning. In general, a planning problem can be described as a tuple〈S, S0, G, A,Γ〉, where S is the set of all possible states of the world, S0 ⊂ S denotesthe initial states of the world, G ⊂ S denotes the goal states of the world the planningsystem attempts to reach, A is the set of actions the planner can perform in attemptingto change one state to another state in the world, and the transition relation Γ ⊆S×A×S defines the preconditions and effects for the execution of each action. In thecontext of Web services, S0 and G are the initial states and the goal states specified inthe requirement of Web service requesters. A is a set of available services. Γ denotesthe state change function of each service. OWL-S [DMAL, 2006] is the only Webservice language that announces directly the connection with AI planning. The state

3.4. AI Planning 55

change produced by the execution of the service is specified through the preconditionand effect properties of the service profile. Preconditions present logical conditionsthat should be satisfied prior to the service being requested. Effects are the result ofthe successful execution of a service. The majority of the methods reported in thissection, use OWL-S as the external Web services description language.

In the remainder, we survey the most important planning techniques (withoutclaiming completeness) and discuss their suitability for dynamic composition of Webservices.

3.4.1 Hierarchical Task Networks

The Hierarchical Task Network (HTN) [Erol, Hendler, & Nau, 1994] is an approachto automated planning in which the dependency among actions can be given in theform of networks. Planning problems are specified by providing a set of tasks, thatcan be of three types:

• goal tasks, which are properties to be made true in the world;

• primitive tasks, which can be directly achieved by executing the correspondingaction;

• compound tasks, which denote complex changes in the world that involve sev-eral goal tasks and primitive tasks, and encode strategies for achieving goals.

A task network is a collection of tasks that need to be carried out, together withconstraints among them. A task network that contains only primitive tasks is called aprimitive task network. In the more general case a task network can contain non prim-itive tasks. HTN planners search for plans that accomplish task networks. They planby expanding non-primitive tasks and resolving conflicts iteratively, until a conflict-free plan is found that consists of only primitive tasks. Some well-known HTN plan-ners are UMCP [Erol, Hendler, & Nau, 1994] the first provably sound and completeHTN planning system, and SHOP2 [Nau et al., 2001] a HTN-planner developed atUniversity of Maryland.

As stated in [Sirin et al., 2004], HTN is a planning technique especially wellsuited for automated composition of Web services for several reasons. It encouragesmodularity and minimizes various sorts of failures or costs. Furthermore, it has greatscalability, provides natural places for human intervention, and supports complex pre-condition reasoning. Specifically, the authors describe how the HTN planning systemSHOP2 can be used with OWL-S Web Service descriptions. They provide a soundand complete algorithm to translate OWL-S service descriptions to a SHOP2 do-main, and OWL-S composition tasks to SHOP2 planning problems. The correctnessof the algorithm is proved by showing the correspondence to the situation calculussemantics of OWL-S [Narayanan & McIlraith, 2003]. Furthermore, they implement


a system that plans over sets of OWL-S descriptions by using SHOP2. The resultingplan that implements the required complex service is then executed over the Web.

In pure HTN planning, plans are generated only by successive action decom-position. But for certain recursive problems and conjunctive tasks, this approach isinadequate. In order to tackle these new issues, an enhanced HTN planning methodcombined with partial-order planning (POP) for service composition is presented in[Zhang et al., 2004]. Action decompositions are used as plan refinements in POP,in addition to the standard operations of establishing an open condition and resolv-ing conflicts by adding ordering constraints. The HTN planning method is used togenerate service independent plans automatically and improve the efficiency of ser-vice composition. A type matching algorithm is used to map Web services with planactions and generate an executable service-dependent plan.

Finally, in [Fernandez-Olivares et al., 2007], the HTN paradigm is employed toimplement a middleware able to both interpret OWL-S Web service descriptions,by translating them into an HTN domain and problem description, and carry out areasoning process based on HTN planning techniques in order to automatically com-pose a sequence of executable Web services. This sequence is obtained by followingthe workflow scheme defined in the OWL-S process model and satisfies a high-levelservice request. The cornerstone of this architecture is SIADEX, an HTN planner[Castillo et al., 2006; Fernandez-Olivares et al., 2006] that receives as input an HTNdomain automatically translated from an OWL-S process model, and a planning prob-lem representing both a goal extracted from a high-level service request and an initialstate extracted from the instances of the OWL-S underlying OWL [W3C, 2004a]data model. Specifically, OWL-S atomic processes are mapped as PDDL durativeactions and the workflow pattern of every OWL-S composite process is mapped intoa method-based task decomposition scheme that expresses the operational semanticsof the control structs found in that composite process. The translation is direct forworld-altering atomic process that don’t need to manage external information. Con-cerning information providing atomic processes, the translation is done by adding aninference rule that allows the planning system to get the information needed duringplanning by bounding a variable to the value coming from an external source, whichis seen as a service invoked for producing the information required.

3.4.2 Planning as Model Checking

In the last few years, Model Checking has been shown to be a very effective approachto Planning. In Model Checking [McCarthy & Hayes, 1969; Clarke & Wing, 1996],a formal model of a system is compared against a logical specification of its require-ments to discover inconsistencies. Very efficient techniques have been developed todeal with increasingly complex hardware and software. Symbolic Model Checking[McCarthy & Hayes, 1969; McMillan, 1993] is a particular form of Model Checkingthat allows one to analyze extremely large finite-state systems by means of symbolic

3.4. AI Planning 57

representation techniques (e.g., Binary Decision Diagrams (BDDs) and propositionalsatisfiability). The Planning as Model Checking approach [Cimatti et al., 1997;Cimatti, Roveri, & Traverso, 1998; Giunchiglia & Traverso, 1999] formulates a plan-ning problem in a logical context, while the symbolic representation techniques allowfor handling complex domains. In Planning as Model Checking, a planning domainis formalized as a specification of possible models for plans. Goals are formalizedas logical requirements about the desired behavior for plans. The planning problemis solved by searching through the state space, checking that there exists a plan thatsatisfies the goal. Several planning systems are based on different kinds of ModelChecking techniques for different purposes. Some of them use explicit-state ModelChecking to embed control strategies in the search (e.g., TLPlan [Bacchus & Ka-banza, 2000] and TALPlan [Kvarnstrom, Doherty, & Haslum, 2000]) or to allow fortemporally extended goals (e.g., SimPlan [Kabanza, Barbeau, & St.-Denis, 1997]).Other systems use Model Checking with timed automata to verify plans that shouldmeet timing constraints (e.g., CIRCA [Goldmam, Musliner, & Pelican, 2000]). Awide range of systems exploit Symbolic Model Checking techniques for obtainingan efficient search in large deterministic domains (e.g., MIPS [Edelkamp & Helmert,2000], Proplan [Fourman, 2000], BDDPlan [Holldobler & Storr, 2000]) or non-deterministic domains (e.g., MBP [Bertoli et al., 2001], UMOP [Jensen & Veloso,2000]). Symbolic representation techniques have been also applied to Markov Deci-sion Process-based planning (e.g., SPUDD [Hoey et al., 1999]).

As observed at the beginning of this section, the planning problem correspondingto the automated composition of services is far from trivial, since it poses strong re-quirements on the kind of planning techniques that can be used. Web services must bemodelled with nondeterministic and partially observable behaviors, and compositionrequirements must be expressed with extended goals. Planning as Model Checkingis a flexible approach which can take into account all of these aspects. A prelimi-nary proposal for using this approach is presented in [Pistore et al., 2004], where theauthors define, implement and experiment with a framework for planning the compo-sition and monitoring the interaction of Web services specified as BPEL processes.This framework is then extended in [Pistore, Traverso, & Bertoli, 2005] for dealingwith another crucial aspect of Web services, i.e., asynchronous interactions. Indeed,each BPEL process evolves independently with an unpredictable speed, and synchro-nizes with the other processes only through asynchronous exchange of messages. Theauthors address the problem of the automated composition of Web services by meansof planning in asynchronous domains. More precisely, given a set of BPEL abstractspecifications of published Web services, and given a composition requirement, theygenerate automatically a BPEL concrete process that interact asynchronously withthe published services. The generated BPEL process is then deployed and executedon an available execution engine.

In [Yu & Reiff-Marganiec, 2006], the Planning as Model Checking approach iscombined with the Semantic Web service concepts for defining a composition frame-


work. The planning task is exploited by using a strong planning algorithm3 modifiedby using a bounded on-the-fly depth-first search algorithm. The result allows forservice execution plans to be generated on-the-fly.

3.4.3 PDDL and Estimated Regression Planning

The Planning Domain Definition Language (PDDL) [McDermott et al., 1998] is awidely accepted language for expressing planning problems and domains. Estimated-regression planning is the name given to a family of planners including Unpop [Mc-Dermott, 1996; McDermott, 1999] and HSP [Bonet, Loerincs, & Geffner, 1997;Bonet & Geffner, 2001], in which situation-space search is guided by a heuristicestimator obtained by backward chaining in a “relaxed” problem space. Typicallythe relaxation neglects interactions, both constructive and destructive, between ac-tions that achieve goals, and in particular neglects deletions completely. The result-ing space is much smaller than situation space, and a planner can build a completerepresentation of it, called a regression graph. The regression graph reveals, for eachconjunct of a goal, the minimal sequence of actions that could achieve it.

The strong interest to Web service composition from AI planning community canbe explained roughly by similarity between OWL-S and PDDL representations. Webservice composition represents also a practical application of AI planning. Further-more, since OWL-S has been strongly influenced by the PDDL language, mappingfrom one representation to another is straightforward (as long as only declarativeinformation is considered). As other planning techniques, the estimated regressionplanning approach has been extensively employed to address many issues arising inWeb service area. For example, in [McDermott, 2002], the Web service composi-tion problem is translated into a planning problem and processed by a partial-orderplanner. The planner is employed to generate a collection of conditional action-plan relaxing the closed-world assumption. The problem is formalized through anaxiomatization of the message exchanges among agents, while sensing actions arerepresented using a reification of the modal operator K. In order to cope with contin-gent events, an on-line planner is also introduced to compute alternative schedulingwhen needed. The system has been prototyped by implementing a translator fromthe DAML-S (former version of OWL-S) specification of available and target ser-vices into a PDDL specification.

An alternative approach is discussed in [Peer, 2004]. The author presents a tool,called WSPlan, that transforms Web service composition problems into planningproblems and delegates them to the planners most suitable for the particular plan-

3There are three planning as model checking algorithms: strong cyclic planning, strong planning

and weak planning. The attribute refers to the solution: for a weak solution there is at least one path in

the plan reaching the goal; for strong solutions all paths reach the goal; the strong cyclic plans allow all

fair executions to reach a solution, which may imply stepping back to (a) previous state(s).

3.4. AI Planning 59

ning task. The tool uses PDDL as a transfer format. It can also cope with the prob-lems of incomplete information, various types of Web service indeterminism, statefulservices and structurally rich goal specifications.

Another proposal which uses a non-deterministic version of PDDL, is presentedin [Aiello et al., 2002]. In this case, the non-determinism is employed to defineaction-plans that are able to deal with erroneous events. The composite service is ex-pressed as a planning problem instance, annotated with additional constraints on theexecution, according to user preferences. The constraints are described in the formalplanning language EaGLe [Lago, Pistore, & Traverso, 2002], which is an extensionof the Computational tree logic (CTL) [Clarke, Emerson, & Sistla, 1986]. Giventhis specification, the planner computes some feasible scheduling where actions arebound to available service providers and filtered according to additional constraints.

Finally, in [Carman, Serafini, & Traverso, 2003] the service composition prob-lem is addressed as a planning application by assuming that available operators areonly partially instantiated (since they are specified in terms of a data domain andnot in terms of values) while the system state is described in terms of exchangedmessages. Accordingly, the composition goal is expressed in terms of achieving asuitable message flow w.r.t. a set of constraints. The problem instance is solved us-ing a backward-chaining planning algorithm enriched with type-checking operationsto enforce compatibility policies on exchanged messages.

3.4.4 Situation Calculus

The Situation Calculus is a logical formalism designed for representing and reason-ing about dynamical domains. It was first introduced in [McCarthy & Hayes, 1969].The version in use today is based on that introduced in [Reiter, 1992]. The SituationCalculus represents changing scenarios as a set of first-order logic formulas. A dy-namic world is modelled as progressing through a series of situations as a result ofvarious actions being performed within the world. A situation represents a history ofaction occurrences. Golog (alGOl in LOGic) [Levesque et al., 1997] is a high-levellogic programming language based on the Situation Calculus paradigm, developedat the University of Toronto. Its primary use is for robot programming and to sup-port high-level robot task planning, but it has also been used for agent-based pro-gramming. Golog provides a set of extralogical constructs for assembling primitiveactions defined in the Situation Calculus into macros that can be viewed as complexactions, and that assemble into a program. ConGolog [De Giacomo, Lesperance, &Levesque, 2000] is another programming language based on the Situation Calculusthat incorporates concurrency, interrupts, and exogenous actions into Golog.

The Situation Calculus and Golog have been used in [McIlraith & Son, 2002;Narayanan & McIlraith, 2003] to tackle the composition of Semantic Web services.The authors address the composition problem through the provision of high-levelgeneric procedures and customization constraints. Golog is adopted as a natural for-


malism for representing and reasoning about this problem. The method assumes thatsoftware agents could reason about Web services to perform automated Web servicediscovery, execution, composition and inter-operation. The user request (a genericprocedure) and constraints can be presented in the Situation Calculus. Each Webservice is seen as an action, either a primitive action or a complex action. Primitiveactions are in turn either world-altering actions that change the state of the world, orinformation-gathering actions that change the agent’s state of knowledge. Complexactions are compositions of individual actions. The agent knowledge base provides alogical encoding of the preconditions and effects of the Web service actions in the lan-guage of the Situation Calculus. The agents use procedural programming languageconstructs composed with concepts defined for the services and constraints using de-ductive machinery. The composition is done by finding an execution of the genericprocedure that satisfies the user constraints. A composite service is a set of atomicservices which are connected by procedural programming language constructs (if-then-else, while and so forth). The authors also propose a way to customize Gologprograms by incorporating service requester’s constraints. For example, the servicerequester can use the nondeterministic choice to present which action is selected ina given situation, or use the sequence construct to enforce the execution order be-tween two actions. The generation of the plan have to obey the predefined service’srequester constraints.

3.4.5 Event Calculus

The Event Calculus is a logic programming formalism for representing events andtheir effects [Kowalski & Sergot, 1986]. Several dialects have been proposed sincethe original paper [Geppert, Kradolfer, & Tombros, 1995; Kesim & Sergot, 1996;Shanahan, 2000]. As for the Situation Calculus, the Event Calculus is based onfirst-order logic, and it can represent a variety of phenomena, including actions withindirect effects, actions with non-deterministic effects, compound actions, concurrentactions, and continuous change.

The Event Calculus is a convenient language for the automated composition ofWeb services. There are several proposals that make use of this formalism in thiscontext. As an example, in [Chen & Yang, 2005] an Event Calculus based planneris used in an architecture for automatic workflow generation on the Web/Grid. In[Rouached, Perrin, & Godart, 2006] this formalism is used for verifying composedWeb services, which are coordinated by a composition process expressed in BPEL.Here the aim is to verify a composed service but not generating the composition itself.

Another proposal is [Stathis, Lekeas, & Kloukinas, 2006] which attempts to es-tablish a link between agent societies and Semantic Web services, but uses a versionof the Event Calculus which avoids abduction and sticks to normal logic programs.

In [Yolum & Singh, 2003], an approach for formally representing and reasoningabout commitments in the Event Calculus is developed. This approach is applied and

3.4. AI Planning 61

evaluated in the context of protocols, which represent the interactions allowed amongcommunicating agents.

Finally, in [Aydin, Cicekli, & Cicekli, 2007] the authors present a formal frame-work based on the Event Calculus to produce a user specific composition. Abductiveplanning of the Event Calculus [Shanahan, 2000] is exploited to show that whenatomic services are available, the composition of services that yield the desired effectis possible. They also propose a translation of OWL-S to the Event Calculus anddemonstrate how planning with complex actions is done within this framework.

3.4.6 Action Languages

Action languages are formal languages for describing the changes that are caused byperforming actions. The meaning of a set of propositions in an action language isrepresented by a transition diagram, which describes the possible transitions betweenstates of the world. States are represented as interpretations over some set of fluentsymbols.

Various action languages have been proposed in the literature, offering differ-ent capabilities and expressiveness. The action language A is the first one to havebeen defined. It is introduced in [Gelfond & Lifschitz, 1993] as a simple high-levellanguage for describing the effects of actions. It essentially represents the proposi-tional fragment of ADL [Pednault, 1989]. A has been extended in various ways, bothsyntactically and semantically. Popular descendants are AR [Giunchiglia, Kartha,& Lifschitz, 1997], B [Gelfond & Lifschitz, 1998], AS [Son & Baral, 2001] andAk [Lobo, Mendez, & Taylor, 2001]. The most recent and evolved languages arethe language C and its successor C+. Action language C, [Giunchiglia & Lifschitz,1998] applies the ideas of causal theories, (described in [McCain & Turner, 1997]and extended in [Lifschitz, 1997; Lifschitz & Turner, 1999]) in which the notion of“being true” and “being caused” are distinguished, for reasoning about the effectsof actions and the persistence (inertia) of facts. An implementation of C, called theCausal Calculator (CCALC) has been developed as a part of Norman McCain’s Ph.D.dissertation [1997]. The language C+ and its underlying formalism of nonmono-tonic causal theories are presented in [Giunchiglia et al., 2004]. C+ extends C byallowing multivalued fluents and generalizing the form of the rules in the language.Accordingly, the Causal Calculator (CCALC) has been redesigned and reimplemented.The new version of CCALC implements a fragment of the causal logic described in[Giunchiglia et al., 2004], and it has been developed as a part of Lee’s Ph.D. disser-tation [2005]. Now the system is maintained by Texas Action Group at Austin and isavailable at its Web site [TAG at Austin, CCALC].

The action language framework is employed in [Trajcevski, Baral, & Lobo, 2001]to address the problem of the validation of a workflow specification in case of incom-plete information. This is a typical scenario of intraorganization cooperation that isalso interesting in the case of Web services. It is impossible to analyze at design-


time every admissible execution scenarios, since some information can be accessedonly during the execution. To cope with these issues, the authors propose an actionlanguage derived from the language A, named AW which enables specifying the ef-fects that activities have on the environment and how they should be coordinated.The system state is described using a predicate alphabet. Actions are distinguishedinto ontic (world-altering) and knowledge producing actions. It is also possible tomodel asynchronous events and exceptions. A workflow specification is describedas a collection of rules, whereas a user goal as a collection of constraints on the sys-tem state. The language is provided with an entailment relation which allows one tocheck if the workflow is compatible with the goal being acheived. In order to dealwith incomplete information, a three-value logic is employed.

In the second part of this dissertation, we present an approach to Web servicecomposition based on action languages. Our approach is similar to [Trajcevski, Baral,& Lobo, 2001], but we focus on the action language C+. Further motivations and adetailed description of our proposal are given in Chapter 5.

3.5 Multi-Agent Systems

A multi-agent system (MAS) is an association of autonomous agents, which interactwith each other, typically by exchanging messages through some computer networkinfrastructure. In the most general case, the agents in a multiagent system will berepresenting or acting on behalf of users or owners with very different goals andmotivations. An Agent Communication Language (ACL) [Singh, 1998] defines thetypes and meaning of messages that agents can exchange (e.g, requests, etc.). Thereare two major ACLs: Knowledge Query and Manipulation Language (KQML) [Fininet al., 1994] and FIPA4 Agent Communication Language (FIPA-ACL) [FIPA, Foun-dation for Intelligent Physical Agents, 1999]. A comparative description of these twolanguages can be found in [Labrou, Finin, & Peng, 1999]. Although they both havedifferent origins, they are almost identical with respect to their basic concepts. Themain difference lies in their underlying semantic frameworks.

Web services are closely related to the agent programming paradigm. The defi-nition of the Web service architecture [W3C, 2004c] makes the assumption that theagents which provide the implementation of Web services are constructed as dis-tributed software components. This is a different kind of agent from the intelligentagents which form multi-agent systems. However, this assumption does not pre-clude Web services from being used to define MASs. The construction of MASsfrom Web services introduces a different kind of Web service architecture from the

4Foundation for Intelligent Physical Agents (FIPA) is an IEEE Computer Society standards organi-

zation for developing and setting computer software standards for heterogeneous and interacting agents

and agent-based systems.

3.5. Multi-Agent Systems 63

one presented in [W3C, 2004c]. In particular, the communication patterns betweenagents is more varied and complex. In a software component architecture, inter-agent communication appears as remote procedure calls between distributed objects,and exists simply to enable distributed computation. Communication in this modelconsists primarily of the passing of values to remote procedures, and the receipt ofmessages containing the results. On the contrary, in an intelligent agent architec-ture, communication exists for the exchange of knowledge between the agents, andthe communication can be viewed as a conversation between individual autonomousagents. Intelligent agents may engage in complex scenarios such as auctions andnegotiations. Thus, even though both approaches involve the exchange of messagesbetween agents, an intelligent agent architecture will clearly introduce an enhancedlevel of interaction between Web services.

[Gibbins, Harris, & Shadbolt, 2003] are probably the first ones who demon-strated, through an implementation, the usage of DAML-S Web service descriptionswithin agents. They separate the intentional meaning of messages (whether it isa request or an assertion, for instance) from the application domain specific con-tent within DAML-S. That conforms with MASs where intent of messages is giventhrough an agent communication language, and domain specific content by means ofdomain-specific ontologies.

Another proposal of incorporating Web services into agents is [Ardissono, Goy,& Petrone, 2003]. The main contribution is support for more rigorous service ex-ecution protocols compared to currently prevalent 2-step protocols, which mainlyconsider sending input data and then collecting results from services. However, ifwe consider MASs, we have to support also other aspects than simple remote execu-tion. One example is agent negotiation protocols, which have more refined structurethan the simple remote procedure call supported by WSDL. As noticed in the paper,WSDL has several shortcomings, like inability to describe interaction protocols andsequences of executions in complex services. To overcome these difficulties, it isproposed that the service provider guides the consumer by specifying at each step ofthe interaction the set of eligible turns customers may perform.

Some work tried to combine the paradigms of MAS and Web services for specificreasons, notably in the use of agents as proxies that assist in the selection of Web ser-vices according of some criteria [Maximilien & Singh, 2003], or even for reasoningabout semantic description, and the composition and use of Web services [Richardset al., 2003]. For example, in [Walton, 2004] a Multi-Agent Protocol (MAP) lan-guage is employed to specify the conversation among cooperative services adaptingthe model defined in [FIPA, Foundation for Intelligent Physical Agents, 1999]. Theverification of conversation protocols is performed by model checking. The authorsuse the SPIN model checker to perform a mechanical verification of dialogue proto-cols. Since SPIN accepts design specifications in its own language PROMELA, andverifies correctness claims specified as a LTL formula, a translation from MAP toPROMELA is also provided. In order to make the problem feasible in terms of com-


putational complexity, the input is simplified by ignoring the structure of exchangeddata.

The use of model checking techniques for the verification of formal propertiesof software agents implementing Web services is at the basis of another proposal de-scribed in [Pokorny & Ramakrishnan, 2004]. Agents are described as extended finitestate automata that allow for internal state variables and complex guard conditionson transitions. Desired properties are formalized in a generalized linear temporallogic (GLTL), that is able to predicate about both path and state characteristics. Thespecification of the composed process workflow is then encoded as a set of additionalconstraints that restricts the domain of admissible computations. The proposed ap-proach is also able to deal with multiple concurrent instances of modelled processesand to verify properties of an enactment set.

Finally, the multi-agent paradigm has been applied in [Maamar, Kouadri, &Yahyaoui, 2004], to define an architecture for the deployment of service-orientedapplications. It relies on three kinds of software agents: master service agent, whichis in charge of the management of available computing resources, the instantiationof required elements, and the control of accesses and authorizations; composite ser-vice agent, that coordinates orchestrations among different service agents served bythe master service agent; service agent, that implements capabilities involved in theprovisioning of a specific service.

3.6 Remarks

Although the work reviewed in this chapter covers a plethora of aspects related toWeb services, there is still a plenty of room for further research. For example, inthe field of automated Web service composition there is still no consensus on how todescribe composition problems. Moreover, it is not even clear how expressive lan-guages or formalisms must be for describing such problems. The same issue appliesto the Semantic Web, where in general, it is not clear which properties of objectsconstitute their semantics and how they should be expressed. Furthermore, it is un-clear which existing (logical) formalisms are sufficient to describe the semantics ofdata objects and Web services. There is also a need for understanding the character-istics of the search space of Web service composition tasks compared to AI planningtasks. While AI planning problems typically generate a deep search tree with smallbranching factor, Web service composition generates a shallow search tree with hugebranching factor. This in turn means that specialized heuristics are required for solv-ing Web service composition problems as AI planning problems. Moreover, due tothe constantly increasing number of published WSDL documents, there is a need forautomated annotation methods for supporting the automated Web service composi-tion. There are some efforts to automate Web service annotation, but no significantapproaches have been proposed in this direction.

Chapter 4

Representing and Reasoningabout Web Services with ProcessAlgebras

Web services are network-based software components deployed and accessed throughthe Internet using standard interface description languages and uniform communica-tion protocols. Each service solves a precise task, and may communicate with otherservices by exchanging messages. They are aimed at wide reusability and they aretypically designed to interact with other services in order to build larger applications.

From a software engineering point of view, the construction of new services bythe (static or dynamic) composition of existing services raises many theoretical andpractical issues which are part of the on-going research. In Chapter 2, we havebriefly discussed some well-known problems related to Web services, namely WebService Description (to specify them in an adequate formally defined and expres-sive enough language), Web Service Discovery (to discover them through the Web),Web Service Composition (to compose them in an appropriate way in order to per-form a specific task). Related to service composition, are the problems of devel-oping new services with available ones, and ensuring their correct interaction. Dueto the message-passing nature of Web service interactions, many subtle errors canoccur when we put several of them together. For example, messages may not be re-ceived, or the whole system composed by the interacting services may reach a dead-lock state. Compatibility of Web services is another critical issue, especially whenthe services to be composed are produced by different organizations. Intuitively,two services are compatible if they can interact properly [Bordeaux et al., 2004;Salaun, Bordeaux, & Schaerf, 2006]. In order to interact properly, services need to

65

66 4. Representing and Reasoning about Web Services with Process Algebras

match in some sense. As discussed in [Bordeaux et al., 2004], we can distinguishtwo types of compatibilities:

• static compatibility, which refers to the form of exchanged messages. In thiscase, we need to check that the messages sent and received by componentservices have syntactically compatible types (as declared in their WSDL inter-faces [W3C, 2001a]);

• dynamic compatibility, which refers to the possible sequences of messages ex-changed. In this case, we need to check that whatever scenario the interactiongoes through, undesired situations (e.g.. messages not received, impossibilityto terminate the interaction, etc.) will never occur. This kind of control re-quires reasoning on the behavioral features of Web services, i.e., to describeand examine all sequences of messages each component service can send orreceive.

All the problems discussed so far, are well-known and recurrent in distributed ap-plications, but they become even more critical in the open-endend world of Web ser-vices, where services are used more by other services than by human users, and whereservice interactions should (ideally) be as transparent and automated as possible. Asoutlined in Chapter 3, formal methods provide an adequate framework (many specifi-cation languages and reasoning tools) to address most of these issues. Some propos-als [Berardi et al., 2003a; Hull et al., 2003; Narayanan & McIlraith, 2003; Andonoff,Bouzguenda, & Hanachi, 2005; Hamadi & Benatallah, 2003; Zhovtobryukh, 2007;Lazovik, Aiello, & Papazoglou, 2003] address the problem of abstractly describingWeb services, most of which are based on transition system models (Labelled Tran-sition Systems, Mealy automata, Petri nets, etc). Some other proposals [Narayanan& McIlraith, 2003; Martens, 2005; Bonchi et al., 2007; Yang et al., 2006; Foster etal., 2003; Nakajima, 2002; Fu, Bultan, & Su, 2004] deal with the verification of Webservice descriptions to ensure some properties are satisfied by them. Finally, fewapproaches have been proposed to help the design and then development of Web ser-vices, especially from service abstract descriptions (as done in the classical softwareengineering life cycle to develop software systems).

In this dissertation, we advocate the use of process algebra [Bergstra, Ponse, &Smolka, 2001] as an abstract and formal description formalism to tackle several is-sues raised in the context of Web services. It has already been argued by other authors(e.g., [Meredith & Bjorg, 2003]) that Web services and their interactions are best de-scribed by using process description languages, and it is clear that the standards fordescribing and composing Web services, like BPEL[Curbera et al., 2002], are actu-ally such languages. Abstract processes can be used to describe services at differentlevel of expressiveness and to compose them in order to build more complicatedservices. A great interest in using process algebra is that formal reasoning is madepossible at any time and for many purposes thanks to the existence of state-of-the-art

67

tools. Abstract descriptions may also be used as a first step to develop certified Webservices following a well-defined method. Compared to automata-based approaches,the main benefit of process algebra is its expressiveness thanks to a large number ofexisting calculi enabling one to choose the most adequate formalism depending onthe final use. Compared to Petri nets, process algebra constructs make it possibleto specify composition due to their compositionality property which allows for thedefinition of more complex behaviors from simple ones. Finally, the textual notationis more adequate for describing and reasoning on real-size problems.

Central to the process algebra approach is the definition of a two-way mappingbetween abstract processes and executable services (implementations and their asso-ciated interfaces), as sketched in Figure 4.1. As claimed in [Salaun, Bordeaux, &

concrete levelabstract level

encoding

++

J2EE, .NET...)

(BPEL Process Manager,

Development environment

(BPEL, JAVA...)

Executable Code

(CWB−NC, CADP, SPIN...)

Editing and reasoning tools

Promela, Pi−calculus...)(CCS, CSP, LOTOS,

Process Algebra

mapping

reverse engineering inte

rfac

e

(WS

DL,

WS

−C

DL.

..)

Figure 4.1: Overview of the Process Algebras Approach

Schaerf, 2006; Chirichiello & Salaun, 2006], process algebra can be helpful to tackletwo classes of problems: Composition of Web services and Development on Webservices.

As discussed in Chapter 2, the (automated) composition of Web services is theproblem of finding the right way to put together a collection of Web services in orderto solve a precise task. There are two notions of composition: Choreography, thataims at finding a global model for services describing their interaction in a preciseway; and Orchestration, that aims at solving more complex tasks by building a newservice (the orchestrator) using existing services by exchanging messages with them.Process algebras can be used for either notion of composition, because they are com-positional languages (complex Web services can be built from basic ones easily byusing process algebra constructs). Concerning the choreography issue, process al-gebra can be used for representing the behavior of all interacting Web services, andconsequently it allows one to perform on-the-fly compatibility checks in order to en-sure that the component services can cooperate for solving the given tasks, and alsoto check that they do solve the desired tasks. Concerning the orchestration issue,process algebra is helpful to verify that the interaction between the orchestrator andeach of the selected partners works properly.


The (correct) development of Web services raises a number of problems whichare like those encountered in the development of distributed system. In this context,process algebra may be used for

• Encoding or Specification purposes during the design stage, i.e., for specifyingabstractly the new service and its interactions with the other participants, andthen translating it into an executable language. In this case, process algebrasare especially worthy as a first description step because they enable us to ana-lyze the problem at hand, to clarify some points, and to sketch a (first) solutionusing an abstract language (thus, dealing only with essential concerns). Fromsuch a formal description of one or more services-to-be, verification tools canbe used to validate their correct execution and, if necessary, to verify and en-sure relevant temporal properties such as safety and liveness [Manna & Pnueli,1995];

• Reverse Engineering purposes, i.e., for extracting an abstract representationfrom the service implementation (where the developer implements directly theservice using an executable language) to validate its behavior with respect toits mates.

Common to the development and composition problem is the assumption that theexisting Web services, developed by others or found on the Web, have behavioralinterfaces from which abstract descriptions can be obtained (prospective hypothe-sis particularly with regards to the current WSDL technology, see WS-CDL [W3C,2005] as an example of a proposal in this direction). The restriction of the servicevisibility to their public interfaces is a common situation in software engineering dueto the black-box feature of components.

The goal of this chapter is to illustrate the process algebras approach to Web ser-vices, and some of the results obtained in this context. We start with an overviewof process algebra, describing, in particular, the two languages used in our experi-mentation. Then, we discuss how process algebras and their tools may be used (i) todescribe and reason about Web services, (ii) to compose Web services, providing asolution to choreography and orchestration issues, and (iii) to develop Web servicesfollowing a well-defined process.

Our main contribution to this proposal, is in the definition of a methodology forencoding process algebraic description of Web services into executable code. Inparticular, starting from an initial proposal [Salaun, Bordeaux, & Schaerf, 2006;Salaun, Ferrara, & Chirichiello, 2004], we elaborated some systematic guidelinesto enable developers to develop and deploy running Web services from abstract andvalidated descriptions of services-to-be. Such an approach may be valuable for manyapplications in e-commerce: on-line sales, banking systems, trip organization, etc.Regarding the Web service(s) to be implemented (compared to the other ones whichare viewed as behavioral interfaces), we concentrated, at the concrete level, on WSDL

4.1. Introduction to Process Algebras 69

interfaces and BPEL services. We choose these technologies because they are well-known standards in widespread use and because BPEL is process-oriented thereforemaking the encoding tractable. Depending on the expressiveness of the process alge-bra used in the initial step, we can obtain either running BPEL code or just skeletonsof code to be complemented. We emphasize that a formal proof of semantics preser-vation between both levels is not achieved yet since BPEL does not have a widelyaccepted formal semantics. However, the correctness and completeness of the en-coding is discussed in more details in Section 4.6. Furthermore, our method hasbeen elaborated as a result of an experimentation phase, carried out using the BPELProcess Manager 2.0. Specifically, we have developed and deployed running Webservices. Consequently, our ideas have not remained at a conceptual level, as is mostof the time the case.

This work has been partially supported by Project ASTRO1 funded by the ItalianMinistry for Research under the FIRB framework (funds for basic research) coordi-nated in Rome by Prof. Marco Cadoli and Prof. Marco Schaerf. The results havealready been published during the Ph.D. studies, and are presented in [Salaun, Fer-rara, & Chirichiello, 2004; Chirichiello & Salaun, 2005; Chirichiello & Salaun, 2006;Chirichiello & Salaun, 2007].

4.1 Introduction to Process Algebras

Process algebras [Bergstra, Ponse, & Smolka, 2001] are abstract languages useful tospecify dynamic behaviors (sequentiality, concurrency, parallelism, etc). Processesdefined using them may communicate together by exchanging messages. Many pro-cess calculi exist: CCS [Milner, 1989], ACP [Baeten & Weijand, 1990], CSP [Hoare,1984], and their extensions the π-calculus [Parrow, 2001], LOTOS [Bolognesi &Brinksma, 1989], Promela [Holzmann, 2003] and Timed CSP [Schneider et al.,1992]. All of them are formalized either axiomatically with algebraic laws whichcan be used to verify term equivalences, operationally using a semantics based onLabelled Transition Systems, or denotationally defining the meaning of basic entities(and of their composition) using functions. These formalisms are most of the timetool-equipped, enabling one to simulate possible evolutions of processes, to generatetest sequences, to check properties (e.g., to ensure that a bad situation never happens),to minimize behaviors, to verify equivalences, etc.

1ASTRO is a research project in the field of Web services and service oriented applications, with

a focus on the integration of business processes that are distributed among the most disparate entities.

ASTRO addresses one of the major challenges for industry-wide adoption of Web services: the auto-

mated composition of distributed business processes, i.e., the development of technology, methods and

tools that support an effective, flexible, reliable, easy-to-use, low-cost, and time-efficient composition

of electronic distributed business processes.


In order to give a flavor of what a process algebra is made up of, we present thecommon constructs shared by most of them. Afterwards, we briefly introduce twoprocess algebras, namely CCS and LOTOS. CCS is the language used in the initialpresentation of our process algebras approach for Web services [Salaun, Bordeaux,& Schaerf, 2006]. Even though CCS is provided with a small set of operators, it isexpressive enough to describe and reason about Web services. LOTOS is the lan-guage we used in [Salaun, Ferrara, & Chirichiello, 2004] and then in [Chirichiello &Salaun, 2007; Chirichiello & Salaun, 2006], to extend the process algebras approachin order to cope with the data that normally services manage during their interactions.

4.1.1 Common Process Algebras Constructs

Actions and interactions. The basic concept to build dynamic behaviors (or pro-cesses) is the action (also called event, channel, gate or name in other formalisms).Actions correspond to local evolutions of processes, or express interactions betweentwo (or more) processes. They can be either emissions (output actions) or receptions(input actions). Two (or more) processes can evolve in parallel and synchronize them-selves when they are ready to evolve along the same action name. The basic matchingis one sender and one receiver. However, different communication models may beconsidered involving variants such as asynchronous vs synchronous communication,or binary vs n-ary communication.

Behavioral constructs. First, a termination indicates the end of a behavior. A hid-den or internal action may be used to abstract some possible pieces of behaviorscorresponding to internal evolutions. The hide operator is sometimes used to makeexplicit the hiding of some actions to the environment of the process. The usual threemain constructs are: the sequence proposing the execution of an action followed bya behavior; the nondeterministic choice between two behaviors (sometimes, internaland external choices are used to distinguish the source of the choice); and the parallelcomposition (and all its underlying variants like full synchronization or interleaving),meaning parallel evolution and synchronization of several processes. Many otherdynamic operators may be used and appear in existing calculi: interruption, sequen-tial composition of processes (in case of successful termination), or compensationand exception handling for constructs more related to specific Web services issues[Butler & Ferreira, 2004].

Data descriptions. Data are not always described within process algebra (this isnot the case in basic CCS, for instance). Different levels of representation exist. Forexample, in Promela basic datatypes (integers, boolean) may be handled and one ad-vanced construct (array) is available. A more expressive calculus is LOTOS whichallows the representation of expressive data types using algebraic specifications. Data


terms may appear at different places within dynamic behaviors. First, processes maybe parameterized with a list of formal parameters (local variable declaration). Ac-tions may exchange values: an emission may be parameterized with possible dataterms, whereas a reception may be parameterized with variables. A behavior may bepreceded by a guard, and is therefore executed only if the guard condition is true.

Processes. A process is composed of an identifier, a list of actions, a list of localparameters, and its behavior. The process body is built using the behavioral con-structs described previously. Observe that, since process algebras are compositionallanguages, complicated behaviors can be built from basic ones. The identifier of aprocess is useful to refer to the behavior of the process itself, and in particular to in-stantiate or call it recursively. Recursive calls may be used to update local variables.

4.1.2 CCS

CCS [Milner, 1989] is a simple process algebra adequate for the specification of (andreasoning about) dynamic behaviors. Defining processes in CCS requires to firstagree on a set of action names which represent the messages used in the system, forinstance {a, b, c} . The basic actions in CCS are: to receive a message, denoted bysimply writing its name (e.g., a); or to emit a message, written by its name prefixedby the quote symbol, (e.g., ′a).

Processes are constructed as follows. A terminated process that has finished itsexecution, is written as 0 (to be read as “do nothing”). A process can execute asequence of the form a.P (to be read as “execute a then P ”), where a is an action, . isthe sequence operator, and P is a process. A process can perform a nondeterministicchoice P + Q (to be read as “execute P or execute Q”), where P and Q are twoprocesses and + denotes the nondeterministic choice operator. The coexistence ofseveral processes P1, . . . , Pn whose execution is synchronized on complementaryactions is written as P1| . . . |Pn (to be read as “run P1, . . . , Pn in parallel”). The |symbol is the parallel composition operator. It is used to define a global processmade up of several subprocesses. The restriction operator \ is used for synchronizingprocesses. P\ns, where P is a process and ns is a set of names, imposes that anemission of ′a (a ∈ ns) by one subprocess of P can occur only if another subprocessdoes a reception a of the same message name. In practice, it is used to declare all thenames on which synchronization occurs in the whole system.

For illustration purposes, let us consider the following example of a CCS process(taken from [Salaun, Bordeaux, & Schaerf, 2006]):

procS = ((b.a.0 + c.a.0) | ′a.′c.0) \ {a}

This process is the parallel composition of two simple behaviors. The first subprocess(b.a.0 + c.a.0) can evolve either through the sequence of input messages b.a, or


through the sequence of inputs c.a. The second subprocess ′a.′c.0 can perform thesequence of output messages ′a.′c. The restriction \ {a} means that all exchanges ofmessage a must be internal to the system: message a cannot leave the system or bereceived from outside the system. On the contrary, messages b and c are not restricted,which means that other processes (that form the environment of the process) caninteract with the system by sending it or receiving from it any of these messages.

Hidden actions are denoted by the symbol τ . These actions allow some levelof abstraction in the description of the processes, since they can hide an arbitrarilycomplex sequence of actions whose details are kept private. A specification, or aninterface, typically describes part of the behavior of the concrete process, and mayspecify at some points that “here, some computation is done”, without further de-tails. The use of τ actions can in many cases be avoided, but they are needed whenone process exhibits “internal non-determinism”, i.e., when its state changes due tocomputations executed in a non-observable way. As another example, consider thefollowing process [Salaun, Bordeaux, & Schaerf, 2006]:

procS′ = request.(τ.′confirmation.0 + τ.′refusal.0)

This process first receives a request. Then, two different things can happen reflectingthe two possible outcomes of an operation (which can be, for example, a (hidden)query to a local database or a (hidden) communication with other processes) aimedat checking whether the request can be satisfied: (i) the request can be satisfied andthe process sends a confirmation, or (ii) the request cannot be satisfied and the pro-cess sends a refusal. With τ actions, we express the fact that the process internallyperforms a computation which can give different results, and this result determineswhich branch of the choice is effectively chosen.

CCS is formalized using axiomatic and operational semantics. The operationalsemantics describes the possible evolutions of a process, i.e., the execution steps thatthe process may engage in. This semantics is usually specified in the form of a ternaryrelation P

α→ P ′, meaning that behavior P can evolve into behavior P ′ in one stepthrough action α, which can be an emission, a reception, or a τ action. The relation→ is defined inductively using a collection of rules for each operator described sofar. For a complete presentation of these rules, as well as a detailed description ofthe semantics of CCS, we refer the reader to [Hoare, 1984] and to [Cleaveland &Smolka, 1999].

The Concurrency Workbench of New Century (CWB-NC) [Cleaveland, Li, &Sims, 2000] is the automated tool which supports the manipulation and analysis ofconcurrent systems expressed in CCS. In particular, the CWB-NC allows for differentverification methods, including equivalence checking, preorder checking and modelchecking, that are supported for several different process semantics.


4.1.3 LOTOS

LOTOS is an ISO specification language [ISO, 1989] which combines two specifi-cation models: one for static aspects (data and operations) that relies on the alge-braic specification language ACT ONE; and one for dynamic aspects (processes) thatdraws its inspiration from the CCS and CSP process algebras.

LOTOS allows the representation of data using algebraic abstract types. In ACTONE, each sort (or datatype) defines a set of operations with arity and typing (thewhole is called a signature). A subset of these operations, the constructors, are suf-ficient to create all the elements of the sort. Terms are obtained from all the correctoperation compositions. Axioms are first order logic formulas built on terms withvariables. They define the meaning of each operation appearing in the signature.

In LOTOS, a distributed, concurrent system is seen as a process, possibly con-sisting of several subprocesses. A subprocess is a process itself, so that in generala LOTOS specification describes a system via a hierarchy of process definitions. Aprocess is an entity able to perform internal, unobservable actions, and to interactwith other processes which form its environment. Complex interactions betweenprocesses are built up out of elementary units of synchronization which are calledevents, or (atomic) interactions, or simply actions. Events imply process synchro-nization, because the processes that interact in an event (they may be two or more)participate in its execution at the same moment in time. Such synchronizations mayinvolve the exchange of data. Events are atomic in the sense that they occur in-stantaneously, without consuming time. An event is thought of as occurring at aninteraction point, or gate, and in the case of synchronization without data exchange,the event name and the gate name coincide. Basic LOTOS is the subset of LOTOSthat allows the description of dynamic behaviors evolving in parallel and synchroniz-ing using rendez-vous (all the processes involved in the synchronization should beready to evolve simultaneously along the same gate). Full LOTOS is the extension ofbasic LOTOS that manages data expressions and value passing for synchronizations.

Basic LOTOS. A process P denotes a succession of actions which are basic enti-ties representing dynamic evolutions of processes. An action is called a gate. Thesymbol stop denotes an inactive behavior (it could be viewed as the end of a behav-ior) and the exit one depicts a normal termination. The specific i gate correspondsto an internal evolution. Now, we present the different LOTOS operators. The se-quence operator G;B proposes a rendez-vous on the gate G, or an independent firingof this gate (depending on the enclosing context), and then the behavior B is run.The nondeterministic choice between two behaviors is represented using []. LOTOShas at its disposal three parallel composition operators. The general case is givenby the expression B1 |[G1, . . . , Gn]| B2, expressing the parallel execution betweenbehaviors B1 and B2. It means that B1 and B2 evolve independently except on thegates G1, . . . , Gn on which they evolve at the same time firing the same gate (they


also synchronize on the termination exit). Two other operators are particular casesof the former one to write out interleaving B1|||B2, which means an independent in-terleaved evolution of composed processes B1 and B2 (empty list of gates), and fullsynchronization B1||B2, where composed processes synchronize on all actions (listcontaining all the gates used in each process). Moreover, the communication modelproposes a multi-way synchronization: n processes may participate to the rendez-vous.

The operator hide G1, . . . , Gn in B aims at hiding some internal actions for theenvironment within a behavior B. Consequently, the hidden gates cannot be used forthe synchronization between B and its environment. The sequential composition B1

À B2 denotes the behavior which executes B2 when B1 has successfully terminated(stop or exit). The interruption B1 [> B2 expresses that the B1 behavior can beinterrupted at any moment by the behavior B2. If B1 terminates correctly, B2 isnever executed.

Full LOTOS. A process may be parameterized by a list of formal gates Gi i ∈1, . . . , m, and a list of formal parameters Xj of sort Sj j ∈ 1, . . . , n. The full syntaxof a process is the following:

process P [G0, . . . , Gm] (X0:S0, . . . , Xn:Sn) : func := B endproc

where B is the behavior of the process P and func corresponds to the functionalityof the process: either the process loops endlessly (noexit), or it terminates (exit)possibly returning results of sort Sj j ∈ 1, . . . , n (exit(S0, . . . , Sn)). Gate identifiersare possibly enhanced with a set of parameters called offers. An offer of the formG!V corresponds to the emission of a value V , whereas an offer of the form G?X:Smeans the reception of a value of sort S in a variable X . A single rendez-vous cancontain several offers.

A behavior may depend on Boolean conditions. In this case, it is preceded by aguard [Boolean expression] → B, which means that the behavior B is executed onlyif the condition is true. Similarly, the guard can follow a gate accompanied with aset of offers. In this case, it expresses that the synchronization is effective only if theBoolean expression is true (e.g., G?X:Nat[X>3]). In the sequential composition,the left-hand side process can transmit some values (exit) to a process B (accept):

... exit(X0, ..., Xn) À accept Y0:S0, ..., Yn:Sn in B

For illustration purposes, we now provide an example of a simple LOTOS specifica-tion. To describe the process, we use the syntax accepted by CADP [VASY, CADP],the tool accompanying LOTOS. CADP is a toolbox for protocol engineering thatsupports development based on LOTOS specifications. It proposes a wide panel offunctionalities from interactive simulation to formal verification techniques (mini-mization, bisimulation, proofs of temporal properties, compositional verification).

4.2. Description of Web Services 75

A process Requester sends its local value to a process Adder and receives a newvalue that it compares to 5, and depending on the result of this test it continues orexits. The Adder receives a value and sends back this value incremented with itslocal variable.

specification MAIN [request, result]: exit

library BOOLEAN, NATURAL endlib

behavior

(* parallel composition of one requester and one adder *)

Requester[request, result](2)

|[request, result]|

Adder[request, result](1)

where

process Requester [request, result] (x: Nat): exit :=

request!x; result?y:Nat; (* emission of a request *)

(* and reception of a result *)

(

[y>5] -> exit (* termination *)

[]

[y<5] -> Requester[request, result](y) (* recursive call *)

)

endproc

process Adder [request, result] (z: Nat): exit :=

request?x:Nat; result!x+z; (* reception of a value *)

(* emission of the incremented *)

(* value *)

Adder[request, result](z)

[]

exit

endproc

endspec

4.2 Description of Web Services

As claimed in [Salaun, Bordeaux, & Schaerf, 2006], process algebras are adequate todescribe Web services since they focus on behavioral aspects. Due to the existence of


numerous process calculi, we can choose the most adequate formalism depending onthe aspects of services to be captured. Furthermore, process algebras constructs makeit possible to specify composition due to their compositionality property, which al-lows for the definition of more complex behaviors from simple ones. Finally, textualnotations are more adequate for describing real-size problems and are more adaptedto proof-writing and formal reasoning, w.r.t graphical notations. The latter are any-way complementary and can be used by user-friendly front-ends [Ng & Butler, 2002].Following the discussion of [Salaun, Bordeaux, & Schaerf, 2006], we mention howprocess algebras can be used to describe Web services.

Simple process algebras like CSS [Milner, 1989] can be used to represent servicesin all cases where messages and action names are enough for modelling dynamicbehaviors. For example, let us consider an hotel booking service, which is in chargeof booking an hotel room for a client. The behavior of this service may be differentdepending on, for example, whether there are free rooms still available at the time therequest arrives, whether the client provided all the needed information in the bookingform, and so on. Such kind of service is easily represented in CSS as follows (wedescribe the example using the syntax accepted by the CWB tool):

proc Hotel = request.InteractionLoop

proc InteractionLoop =

’askInfo.receiveInfo.InteractionLoop

+ ( ’refusal.Hotel

+

’acceptance.confirmation.Hotel))

In case there is a need to describe features of services regarding the values of mes-sages parameters, local data, or predicates guarding pieces of behavior, languages likeLOTOS [Bolognesi & Brinksma, 1989], and to some extent, Promela [Holzmann,2003] are useful. Promela is a calculus based on asynchronous communication. Ithas a C-like notation. As a modelling language is well-known since it is the inputlanguage of SPIN, the state-of-the-art tool for analyzing the logical consistency ofdistributed system based on LTL model checking. For example, let us consider againthe hotel booking service. We could realistically imagine that the client imposes alimit on the price of the room to be booked. This situation is modelled by using ex-pressions like p <= lp and p >lp, guarding the application of some of the actions,where p and lp denote the actual price of the room and the maximum price that clientcan accept, respectively.

In case there is the need to specify certain time constraints, like a waiting time fora specific event, or to verify that a service will never wait for an incoming messagefor longer than a specified duration of time, a good choice could be Timed CSP[Schneider et al., 1992], which is an extension of CSP that includes timing constructs.

4.3. Composition of Web Services 77

For example, considering again the hotel booking service, we could require that theconfirmation should be sent by the client within the successive 24 hours from therequest. This situation is modelled by using expressions like t <= 24h and t >24h

guarding the confirmation action and the refusal action, respectively.An important feature of mobile processes is the ability to send and receive ad-

dresses, and to send messages to these addresses in forthcoming communications. Inthe Web service world, for instance, a service may need to communicate with arbi-trary clients whose address is not specified at design time but are, on the contrary,discovered and constantly changing at runtime. As an example, consider a serverwhich receives requests from clients, as well as the address of the requester, andwhich then engages in an interaction by exchanging messages with the client in ques-tion. Depending, once again, on the level of details needed in the modelling, one may,or may not wish to reflect this address exchange in the process-algebraic description.In this case, it is recommended to use the π-calculus [Parrow, 2001], which is thebest-known algebra, based on CCS, for mobile processes.

Asynchronous communication is notoriously hard to reason about and debug.For this reason, Web service communication is often assumed to be synchronouscommunication, implementing explicit handshaking to force synchronization when-ever needed. In cases where asynchronicity cannot be avoided, the process algebraPromela and the SPIN model-checker can be used.

4.3 Composition of Web Services

In this section we show how process algebras can be useful for tackling the problemof Web services composition. Process algebras and their accompanying tools areeffective at verifying that compositions of services, obtained by orchestration andchoreography, conform the requirements and respect some desired properties.

4.3.1 Choreography

Choreography is the problem of guaranteeing that Web services, cooperating to solvea specific task, can interact properly, i.e., that they are compatible. This problem isespecially tricky when the component services have been developed by independentproviders. Web services are accessed through their public interfaces. As outlinedby the W3C [W3C-choreography-WG, 2004], for composition purposes these inter-faces should include also a description of the service observable behavior. Here wedo not refer to any specific interface description language. The only assumption tobe respected is that the behavior of the services can be described by Labelled Tran-sition System (LTS)-based model, from which process-algebraic descriptions can beextracted.


Process algebras allow us to describe each of the component service as an ab-stract process. Interactions are implicitly given by matching inputs and outputs ofprocesses. The global system is therefore represented as the parallel composition ofthe entities. Depending on the parallel composition operator used and its underlyingsemantics, many communication models can be expressed (binary in CCS, n-ary inCSP, with data exchange in LOTOS, etc). For illustration purposes, we consider anexample given in [Bordeaux & Salaun, 2004], which describes a communication be-tween requesters and providers. The typical interaction is that the requester sends arequest, the provider replies with a refusal or an acceptance. The requester keeps onsending requests till it receives an acceptance. In that case, it terminates its execution.This example has been written out in CCS (we use the syntax accepted by CWB-NC).The two processes corresponding to the requester and the provider, respectively, aredescribed as follows:

proc Requester =

( ’request.Requester *** emit a request and restart

+ refusal.Requester ) *** or get a refusal and restart

+ acceptance.nil *** or get an acceptance and terminate

proc Provider = *** recursively, receive a request and

*** send either refusal or acceptance

request. ( ’refusal.Provider

+ ’acceptance.Provider )

Parallel compositions and restriction sets are used to describe possible systems madeup of a requester and several providers, or several requesters and one provider. Forexample, consider a global system composed by one requester and three providers,depicted in Figure 4.2. The abstract description of the system is the following:

*** set of action names for synchronization:

set restrictionSet = {request,refusal,acceptance}

*** composition of 1 requester and 3 providers:

proc GlobalSystem =

(Requester | Provider | Provider | Provider) \

restrictionSet

4.3.2 Orchestration

Orchestration may be viewed as the problem of developing a new service, referred toas an orchestrator, that combines several Web services to work out a precise task, by

4.3. Composition of Web Services 79

Requester

Provider

Provider

Provider

` request

`refusal

`acceptance

Figure 4.2: An Example of Choreography

exchanging messages with them.In this context, process algebras may be used as an explicit orchestration lan-

guage, playing at the abstract level (see Figure 4.1) the same role as BPEL does atthe concrete level. Interactions are expressed as one or several orchestrator processesand then the whole system is given as the parallel composition of the entities andthe orchestrator(s). For illustration purposes, consider the following example, takenfrom [Bordeaux & Salaun, 2004]. Let us suppose that our system is composed by arequester and two providers. The requester sends a request and then waits for a reply,which can be an acceptance or a refusal. Each of the providers receives the requestand answers positively (acceptance) or negatively (refusal). The orchestrator con-trols the interactions between the requester and the provider: it reiterates the requestcoming from the requester until a provider answers positively. The process algebrachosen for this example is CCS. Descriptions are written using the syntax acceptedby CWB-NC. The requester and the provider are assumed to correspond to existingservices. They are described as follows:

proc Requester =

( ’request.Requester *** emit a request and restart

+ refusal.Requester ) *** or get a refusal and restart

+ acceptance.nil *** or get an acceptance and terminate


proc Provider = *** recursively, receive a request and

*** send either refusal or acceptance

request. ( ’refusal.Provider

+ ’acceptance.Provider )

The orchestrator is the service to be developed. We obtain the following representa-tion:

proc Orchestrator = *** Mutually recursive processes:

request. ( ’req1.Orch1 *** on request, send message to

+ ’req2.Orch2 ) *** either provider 1 or 2, and

*** call the corresponding process

proc Orch1 = nok1.’refusal.Orchestrator

+ ok1.’acceptance.nil

proc Orch2 = nok2.’refusal.Orchestrator

+ ok2.’acceptance.nil

The Orchestrator process is composed by two subprocesses, Orch1 and Orch2, whichare in charge of contacting one of the available provider. The sending of a request toa provider is reiterated until an acceptance comes. The whole system is composed byall these processes interacting together. It is modelled by using the parallel composi-tion operator. We also rename actions to distinguish the two transactions (with eachprovider instance), by using the notation [newname/oldname, ...] meaning that allthe occurrences of the action oldname in the behavior are replaced by newname. Theglobal system, depicted in Figure 4.3, is described as follows:

set restrictionSet =

{request,refusal,acceptance,req1,ok1,nok1,req2,ok2,nok2}

*** we rename channels of the two providers in the composition:

proc GlobalSystem =

(

Requester

| Provider[req1/request,ok1/acceptance,nok1/refusal]

| Provider[req2/request,ok2/acceptance,nok2/refusal]

| Orchestrator ) \ restrictionSet

4.4. Automated Reasoning on Web Services 81

Requester

Provider

Provider

` request

`refusal

`acceptance

Orchestrator

` req2` ok2` nok2

` req1

` ok1

` nok1Figure 4.3: An Example of Orchestration

4.4 Automated Reasoning on Web Services

The major interest of using abstract languages grounded in a clear semantics is thattools can be used to check that a system matches its requirements and works properly.Model checking [Clarke, Grumberg, & Peled, 2000] is the preferred technique atthis level (especially compared to the theorem proving alternative [Harrison, 2003])because it works with automata-based models (the underlying models of process-algebraic notations), and proofs are completely automated (press-button technology).Process algebras are equipped with state-of-the-art verification tools, and hence areadequate to any kind of press-button check.

As far as Web services specificities are concerned (components deployed on theWeb, composed to work out precise requests, and interacting as automatically aspossible), this kind of tools can help in three cases:

• checking that two processes are in some precise sense equivalent – one processis typically a very abstract one expressing the specification of the problem,while the other is closer to the implementation level;

• checking that a process verifies desirable properties – e.g. the property that thesystem will never reach some unexpected state;

• checking that interfaces of several services are compatible so that they caninteract together and end in a correct termination state.


Development and composition are also issues related to Web services which maybenefit from a reasoning step. As claimed in [Salaun, Bordeaux, & Schaerf, 2006;Chirichiello & Salaun, 2006], process algebra reasoning tools can help practitionersto reason about choreography and orchestration of Web services. Basic checks suchas syntactical parsing and type-checking of the file containing the processes defini-tions, allow one to obtain descriptions free of typing error and missing declarations.Other kind of checks can help to find deadlocks, missing synchronization and incom-plete behaviors. If a problem occurs, the tool gives an explanation of its diagnosticand provides helpful indications on the causes of the problem. Furthermore, thanksto their ability to perform exhaustive checking of all possible behaviors, verificationtools can also be used to certify given compatible services that their compositionwill work fine (unless, of course, some unpredictable technical mistake arises like anetwork problem or a system crash somewhere).

Verifying Equivalences. Intuitively, two processes or services are considered to beequivalent if they are indistinguishable from the viewpoint of an external observerinteracting with them. This notion has been formally defined in the process algebracommunity and several notions of equivalence have been proposed. In what followwe briefly discuss some of them. Details can be found in [Milner, 1989].

Trace equivalence stipulates that two processes are equivalent if the set of tracesthey can produce is the same. A trace is a sequence of actions that the process mayengage in. For example, let Process1 be a CCS process described as a.(b.0 + c.0),and Process2 a process described as (a.b.0 + a.c.0). Their possible executions aredepicted in Figure 4.4. Both processes produce a.b and a.c as possible traces. Theyeither receive the messages a then c, or a then c. Trace equivalence is not fully ad-equate for characterizing equivalent processes. To see why, consider again the twoCSS processes described so far. After receiving message a, Process1 accepts eithermessage b or message c. On the other hand, Process2 behaves differently: on re-ceiving message a, it either chooses to move to a state where it expects messageb, or to a state where it expects message c. Depending on the choice it makes, thesecond process will not accept one of the messages, whereas the first process leavesboth possibilities open (c might not be received if Process2 has chosen the left-handside branch). Let us move to the Web services world, and consider messages a, b,and c as requests for reservation, entering client data and cancellation, respectively.In this context, while the service represented by Process1, after receiving a requestfor a reservation, waits either for client data or for a cancellation, the service corre-sponding to Process2 does not guarantee that a request, followed, for example, by acancellation, is handled correctly. In fact, if this service evolves through the left-handbranch of the execution tree after a reservation, it will expect a message containingthe client data.

In order to take these differences into account, we could consider another notion


b b

aa a

c c

Process 1 Process 2

Figure 4.4: Example of Executions of CCS Processes: Process1 and Process2

of equivalence. Bisimulation equivalence is a refinement of trace equivalence that as-sociates systems that behave in the same way, i.e., one system simulates the other andvice-versa. Intuitively, two systems are bisimilar if they match each other’s moves. Inthis sense, each of the systems cannot be distinguished from the other by an observer.Therefore, considering the example above, we can certainly state that Process1 andProcess2 are not bisimilar, and so they are not equivalent in the bisimulation sense.

In certain contexts the notion of bisimulation is sometimes refined by adding ad-ditional requirements or constraints. For example, if the process engages in some hid-den actions τ , not visible by external observers, then bisimulation can be relaxed tobe weak bisimulation. Weak bisimulation (a.k.a. observational equivalence) closelyresemble regular bisimulation. The only difference lies in the fact that systems mayuse weak transitions (i.e, including an arbitrary number of τ transitions in betweenthe visible actions) to simulate normal transitions in the other system. For example,let us consider other two CCS processes, Process3 represented as b+c, and Process4represented as b + (τ.c). The possible executions of these processes are depicted inFigure 4.5. The two processes are not observationally equivalent. In fact, they bothcan receive b or c. But, whereas Process3 can receive any of the two messages, Pro-cess4 can choose to first execute some unobservable actions τ . These τ actions leadthe process to a state where it can only receive message c. When describing Web ser-vices, hidden actions may be needed for modelling partial knowledge of the behaviorof the service. For example, during the design stage, the specification of the service is


b

b

c

c

Process 3

Process 4

Figure 4.5: Example of Executions of CCS Processes: Process3 and Process4

still incomplete, or in case of reverse engineering, we may have access only to a par-tial description of the service, or to its interface. Considering the previous example,if Process3 and Process4 represent two services, message b represents a request forediting data, and message c a request for cancellation, it cannot be guaranteed that theservice corresponding to Process4 will accept editing data requests. This possibilitydepends on some decisions that the service takes secretly.

Other two notions of equivalence are: strong bisimulation, which requires a strictmatching of τ transitions; and branching equivalence [van Glabbeek & Weijland,1996] which strongly preserves the branching structure of processes, in the sense thatit preserves computations together with the potentials in all intermediate states thatare passed through, even if τ actions are involved. For a large class of processes itturns out that branching bisimulation and observation equivalence are the same. Forinstance, consider the practical applications where implementations are verified byproving them equal to some specification (after having abstracted from a set of un-observable actions of course). In many such cases, the specification does not involveany τ -steps at all: in fact, all τ -steps that occur in the verification process originatefrom the abstraction procedure that is carried out on the implementation. As it turnsout, in all such cases there is no difference between observation and branching bisim-ulation equivalence. For this reason, we may expect many verifications involvingobservation equivalence to be valid in the stronger setting of branching bisimulationas well. In particular, this is the case for all protocol verifications in weak bisimula-


tion semantics known to the authors.In our opinion, branching equivalence is the most relevant notion in the context

of Web services. Indeed, branching equivalence is the strongest of the weak equiva-lences, although, unlike strong equivalence, it does not require a strict matching of τtransitions.

Verifying Properties. The properties of interest in concurrent systems typicallyinvolve reasoning about the possible scenarios that the system can go through. Anestablished formalism for expressing such properties is given by temporal logics likeCTL? [Manna & Pnueli, 1995]. These logics offer constructs allowing to state in aformal way that, for instance, all scenarios will respect some property at every step,or that some particular event will eventually happen, and so on. The most notablekind of properties one may want to ensure are:

• safety properties, which state that an undesirable situation will never arise. Forinstance, the requirements can forbid that the system reserves a room withoutreceiving the credit information from the bank;

• liveness properties, which state that something good must happen (some ac-tions will always be followed by some reactions). A typical example is tocheck that every request for a room will be acknowledged.

The techniques used to check whether a system described in process-algebraic nota-tions respects temporal logic properties are referred to as model checking methods[Clarke, Grumberg, & Peled, 2000].

Reasoning abilities are strongly related to the visibility level. Normally, servicesare black-boxes, i.e. the internal details are hidden from users. Therefore, the ver-ification is restricted to reasoning about visible interfaces or execution results. Onthe other hand, in case of development of certified Web services (described furtheron in the chapter), reasoning steps can be carried further. Depending on the descrip-tion model chosen for Web services, on the level of abstraction, and on what kind ofchecking to be performed, a language and tool may be preferred. Last but not least,observe that a checking phase may be needed for several reasons and at differentlevels.

Checking Compatibilities. Compatibility between two Web services depends notonly on static properties like the correct typing of their message parameters, but alsoon their dynamic behavior. Providing a simple description of the service behaviorbased on process-algebraic or automata-based formalisms, can help detecting manysubtle incompatibilities in their interaction. Moreover, this compatibility checkingcan, to a large extent, be automated if we define the notion of compatibility in asufficiently formal way. In [Bordeaux et al., 2004], the authors propose and compare


three definitions of the compatibility notion of two services, and illustrate them onsimple examples:

• opposite behaviors: the emissions by one service match exactly the receptionsof the other service;

• unspecified receptions: each service is ready to receive at least all the messagesthat its mate can chose to send, and possibly more;

• deadlock freeness: there is at least one way for the two services to interact in asatisfactory way (the execution can successfully terminate).

4.5 Negotiation Among Web Services

To illustrate the interest of the process algebras approach to Web services, we focuson a specific Web services application, namely the negotiation. This problem is inter-esting since it deals with both data and dynamic aspects. As we will describe furtherin this section, process algebra languages are effective at, not only describing the ser-vices involved in the negotiation, but also describing how they should be coordinatedto enact different negotiation protocols in order to reach an agreement.

The perspective of intelligent Web services which are be able to automaticallyperform the necessary negotiation steps to satisfy their user’s request in the mostsatisfactory possible way, emerged from AI and MASs. Negotiation represents acoordination mechanism in which some agents allows cooperative and competitivesharing of information to determine an agreement. It involves at least two agents,with different goals that want to reach a joint decision. When referring to businesstransactions, negotiation is a phase required to obtain a contract that states the char-acteristics of the good or service traded between two entities, either final consumersor organizations. Since the mid ’90s the growth of network technologies and of theInternet has shifted the attention of the academic community towards automated ne-gotiation [Jennings et al., 2001]. In this research field, the goal is to develop softwareagents that can negotiate autonomously. In the last few years, many solutions havebeen proposed for software agents capable of participating autonomously in a negoti-ation process, like auctions [He, Leung, & Jennings, 2003], bilateral [Lin & Chang,2001] or multiparty negotiations [Faratin, Sierra, & Jennings, 1997]. In the WebService area, negotiation is considered primarily as the problem of trust negotiationbetween parties prior to the commitment of a business transaction and it is hard tofind frameworks that apply to service-oriented technologies the principles underlinedby multiagent research [Skogsrud, Benatallah, & Casati, 2003]. However, even in thecontext of Web services, the negotiation problem is a typical example of interactionamong services involving both data (prices, goods, stocks, etc) and behaviors.

4.5. Negotiation Among Web Services 87

In this context, we have experimented with the use of LOTOS and its tool CADP,to ensure trustworthy and automated negotiation steps. The results of this work havebeen published in the proceedings of an international conference [Salaun, Ferrara,& Chirichiello, 2004]. They are obtained via simulation experiments which allowedus to define a two-way mapping between LOTOS and WSDL/BPEL. The correspon-dence between LOTOS processes and BPEL code has been subsequently extended,by abstracting away from a specific process algebra. A deeper discussion about theseequivalences and the use of process algebras for development purposes, is providedin Section 4.6.

4.5.1 What Does Negotiation Involve?

When dealing with negotiation, we have to consider several aspects. Below, webriefly discuss some of them.

Variables. They represent entities on which processes should negotiate, e.g., aprice. Many variables may be involved in a negotiation at the same time (availabilityof different products, fees, maximum number of days for a delivery).

Constraints. They represent conditions to be respected (called invariants as well)while trying to reach an agreement. Such an invariant is actually a predicate whichcan be evaluated replacing free variables with actual values. For a requester who istrying to buy by auction a product, this kind of invariant could be that it is readyto pay e300,00 at most with a delivery within 10 days, or to accept a possible latedelivery if there is a price reduction of 10% at least.

Exchanged Information. To reach an agreement, both participants should sendvalues to the other. A simple case is a price, but they can also exchange more ad-vanced constructs (a record of values, a constraint on a value, etc).

Strategies. “An agent’s negotiation strategy is the specification of the sequence ofactions (usually offers or responses) the agent plans to make during the negotiation.”[Lomuscio, Wooldridge, & Jennings, 2003]. Strategies may take into account otherconsiderations. For instance, a participant can try to reach an agreement as soon aspossible, or to minimize a price. Therefore, strategies are related to minimizing ormaximizing objective functions.

In this proposal, we discard lots of possible variants which possibly appear in nego-tiations such as evolution of the constraints (a requester who is not finding a productless than e300,00 modifies its constraint to pay up to e320,00 from a certain pointin time) or the level of automation (complete automation or some intervention by


human people). Subsequently, all these variations may be combined and may endup to many possible scenarios of negotiation. No negotiation process is better thananother under all conditions. The right process should be selected depending on thebargaining context.

4.5.2 Negotiation Using LOTOS/CADP

We do not argue here, for a general approach to specifying any possible case ofnegotiation (even though many negotiation variants can be described in LOTOS). Ourgoal is to illustrate the use and interest of LOTOS/CADP for analyzing negotiatingservices. Consequently, we introduce our approach on a classical case of peer-to-peer sale/purchase negotiation involving one client (it works with more clients butwe explain with one) and many providers. The goal of a formal representation andhence of automated reasoning, is to prove properties so as to ensure a correct and safeautomated negotiation between the involved processes.

An assumption in this work is that we have a privileged view of all the partic-ipants and their possible behaviors (particularly in case of the reverse engineeringapproach). This means that, from our perspective, processes are glass boxes. Thishypothesis is essential in any situation where we want to reason on interacting pro-cesses. An alternative approach would be to consider processes as black boxes and toreason on visible traces. However, it is almost impossible given such inputs to ensurecritical properties, since they contain little information.

The aspects involved in negotiation described so far, may be encoded in LOTOSin different ways. Here is a sketch of the encoding we propose:

• datatypes are defined using ACT ONE algebraic specifications and are after-wards used to type variables locally defined as parameters of processes;

• a specific datatype (Inv) is defined to describe constraints to be respected byparticipants while negotiating;

• exchanged information is represented by variables. They can represent simplevalues (natural numbers) or more complex ones (a constraint on multi-typevalues). Values are exchanged between processes along gates. Strategies areencoded either in the dynamic processes (the way a participant proposes somevalues and more generally interacts with other participants) and in the localvariables managed by processes – initial value, computation of the next ones,constraints to be respected.

We now introduce the main ideas of the negotiation situation at hand and illustratethem with short pieces of specification.


Example: An On-line Auction Sale

We illustrate our proposal with an example of an on-line auction sale. A client in-teracts with book providers (one after the other) to purchase a book while respectingsome constraints. For the sake of simplicity, we consider a simplified scenario inwhich the client purchases of a single book, and the negotiation involves only theprice of the book. However, our approach works for more complex cases and manynegotiation variants (generalization of data management, handling of bigger sets ofbooks, negotiations on several values and, accordingly, encoding of more complexinvariants).

Data Descriptions. The ADT abilities of LOTOS are useful to represent the datavariables handled during the negotiation, as well as, the more complex data managedby processes. With regards to our negotiation problem, we need the datatypes gath-ered in Figure 4.6 with their import links (Nat and Bool are already defined in theCADP library). A book is represented using four values: an identifier, a price, the

BookStoreInvComp

BoolBookNat

Figure 4.6: Datatypes Dependence Graph

delivery time, the possibility to return the book or not. A bookstore is described as aset of books. Each entry in the bookstore also contains the number of available booksand the invariant to be respected when deciding on the offer’s acceptance or refusal.Several operations are defined to access, modify and update these datatypes.

Constraints are represented using a generic datatype. They are encoded using theInv sort which defines as many invariants as needed and a conform function evalu-ating invariants with actual values. In the example below, the invariant means thatthe maximum price to be paid is e3,00 (client condition), the corresponding mean-ing of the conform function is written out using the judicious comparison operatoron natural numbers. Another example shows how more complex invariants can beexpressed (the price has to be less than or equal to three, the delivery within 5 daysand the return possible).


pMax3 (*! constructor *) : -> Inv

conform : Nat, Inv -> Bool

...

eqns forall p: Nat, b: Book

ofsort Bool (* type of the result *)

conform(p, pMax3) = (p<=3);

conform(b, myInv) = (price(b)<=3) and

(days(b)<5) and returnok(b);

The computation of the initial value to be negotiated and of the next value to beproposed (e.g., adding up one to the price) are also encoded in a generic way using theComp sort. For example, it is done for the price by using some operations extendingthe Nat existing datatype.

Negotiating Processes. We define the processes involved in the negotiation steps.In the current negotiation example, we assume a fully delegated negotiation service(the user does not intervene into search for an agreement and negotiation rounds). InFigure 4.7, boxes correspond to nested processes and lines to interactions betweenprocesses (they hold the gates used by the processes to communicate). Nested pro-cesses mean that, at one moment, there is only one control flow: one parent processinstantiates another one and waits for the end of its fork before continuing its behav-ior. It is required in LOTOS because the use of an intermediate process is the onlyway to express a looping behavior inside a larger one.

NegotiateC

Controller

Requester

Provider

NegotiateP

request, reply

order, refusal, givingup

sendpriceP, sendpriceR

Figure 4.7: Process Involved in the Negotiation Steps

The Controller process is run by the client with specific parameters: the identi-fier of the book to purchase, an initial value to be proposed for the book while negoti-ating, an invariant to be respected during the negotiation steps, a function computingthe next proposal. Its exit statement is accompanied with a Boolean which indicatesan order or a failure of the negotiation rounds. On the other hand, each provider hasat its disposal a set of books, a function to compute a first value (to be proposed while


negotiating) from the actual price as stored in the book set, and a function to computethe price of the book for the next negotiation round.

Let us now sketch the behavior of the Controller. First, it initiates the interac-tion with a provider by sending the identifier of the book to be sought, then receivesan answer denoting the availability of the book: a false reply implies a recursive call;a true response induces the instantiation of the negotiation process NegotiateC andthe waiting for an answer accompanied with a status, which is true in case of an order(and then exit alerting the client of the success) and false in case of a failure (recursivecall to try another provider). At any moment, the Controller may give up and exitalerting the client that every negotiation attempt has failed. Each Provider has tobe willing to interact with such a controller, and then is made up of the symmetricalbehavior.

process Controller

[request,reply,order,refusal,sendpriceP,sendpriceR,givingup]

(ref: Nat, pi: Nat, inv: Inv, computfct: Comp): exit(Bool) :=

request!ref; reply?b:Bool;

(

([b] ->

NegotiateC[order,refusal,sendpriceP,sendpriceR,givingup]

(pi, inv, computfct) >> accept status: Bool in

(

[not(status)] -> (* case of a failure *)

Controller[request,reply,order,refusal,sendpriceP,...]

(ref, pi, inv, computfct)

[]

[status] -> exit(true) (* case of an order *)

))

[]

([not(b)] -> (* let us try another bookstore *)

Controller[request,...]

(ref, pi, inv, computfct))

)

[]

exit(false) (* the controller stops the negotiation *)

endproc

Below, we show the body of the NegotiateC process in charge of the negotiation onbehalf of the Controller. Negotiation steps are composed of classical information


exchanges. Each of the participants proposes a price to the other. The other par-ticipant accepts if this price satisfies its local constraints; otherwise, it refuses andcalls itself recursively. The caller updates its local value (price here) for the next pro-posal using the local function dedicated to such computations. At any moment, thenegotiation may be abandoned by one of the participants.

process NegotiateC [order,refusal,sendpriceP,sendpriceR,givingup]

(curp: Nat, inv: Inv, computfct: Comp): exit(Bool) :=

sendpriceP?p:Nat; (* the provider proposes a value *)

( [conform(p,inv)] -> order;exit(true) (* agreement *)

[]

[not(conform(p,inv))] -> refusal;


(curp, inv, computfct) )

[] (* proposal of a value to the provider *)

( [conform(curp,inv)] -> sendpriceR!curp;

(

order; exit(true) (* agreement *)

[]

refusal;


(compute(curp,computfct),inv,computfct)

) )

[] (* the client stops because results not satisfactory *)

givingup; exit(false)

endproc

And now we introduce an example of a concrete system in which one Requester

is seeking a book among three possible providers. First of all, the needed data aredescribed using appropriate algebraic terms. As a simple example, we show belowone bookstore containing eight books (we experimented our approach with storeshandling tens of books). For instance, the first book (identified by 0) has three copiesstill available and has to be sold for at least e3,00.

bs1: BookStore =

add2BS(book(0,2,6,true), 3, pMin3,

...

add2BS(book(7,3,2,false), 3, pMin5, emptyBS)...)

A lightweight view of the system is now given. This instance (and some variants ofit modifying the number of possible providers) is used later to assess the reasoning


capabilities. The Requester is seeking the book identified by 0, with 2 as initialnegotiating value, pMax3 as price constraint and a computation of the next valueobtained adding up one. Concerning the bookstore to be contacted, this informationis left unspecified.

Requester [request,reply,order,refusal,...] (0,2,pMax3,add1)

|[request,reply,order,refusal,sendpriceP,sendpriceR,givingup]|

(

Provider [request,reply,order,refusal,...] (bs1,times2,minus1)

||| Provider[...] (bs2,times2,minus1) ||| Provider[...] (...)

)

Reasoning. We focus now on the reasoning aspects. We want to validate our ne-gotiation system and verify some properties on it. All the steps we are going tointroduce have been very helpful to ensure a correct processing of the negotiationrounds. Several mistakes in the specification have been found out (in the design,in the interaction flows, in the data description and management). Simulation hasbeen carried out and proofs have been verified using EVALUATOR (a CADP on-the-fly model checker) and the prototype version CAESAR 6.3 [Garavel & Serwe, 2004]building smaller graphs than in the current distribution of CADP. Safety, liveness andfairness properties written in µ-calculus have been verified (examples are introducedbelow).

A first classical property is the absence of deadlocks (actually there is one dead-lock corresponding to the correct termination leading in a sink state). Another one(P1) ensures than an agreement is possible (because there exists one branch labelledby ORDER in the global graph). The property P2 expresses that the firing of everySENDPRICER gate (also checked with SENDPRICEP) is either followed by an order ora refusal. P3 verifies that after the firing of a REPLY!TRUE action, either SENDPRICEPand SENDPRICER are fireable.

< true* . "ORDER" > true (P1)

[true* . "SENDPRICER!*"] <("ORDER" or "REFUSAL")> true (P2)

[true* . "REPLY!TRUE"] <"SENDPRICEP" and "SENDPRICER"> true (P3)

We provide in Table 4.1 the results of some experimentations we carried out onthis system, illustrating the time and space limits of our approach (and of the useof CADP). We consider one user since the goal is to ensure properties for a givenuser even if proofs can be achieved with several as shown below (however in thiscase the existence of an agreement P1 is meaningless). We used a Sun Blade 100equipped with a processor Ultra Sparc II and 1.5 GB of RAM. Summing up theseresults, we can state that, though we can reason on rather realistic applications, ourapproach is limited by the state explosion problem due especially in our case to the

increase of: the number of processes (and underlying new negotiation possibilities),the number of values to be negotiated (if constraints are relaxed, negotiations can behold on more values), the size of data (above all the number of books managed byeach provider).

Number of processes Nb of states Nb of trans. P1 P2 P3

Example 1 (1 user & 1 provider) 32 47 3.84s 2.15s 2.21s

Example 2 (1 user & 5 providers) 2,485 5,124 4.88s 3.57s 3.57s




Example 6 (2 users & 4 providers) 300,764 944,394 5.31s 117.41s 117.79s

Table 4.1: Practical Assessment of the Approach

The Negotiation Case in BPEL. The negotiation example focused on in this sec-tion has been implemented in BPEL and the resulting services work correctly. Thedevelopment has been carried out by following systematic guidelines which make itpossible to translate such abstract processes into WSDL interfaces and BPEL pro-cesses. A detailed discussion of these guidelines is provided in the next section.Experimentations have been done using Oracle BPEL Process Manager 2.0, BPELConsole, BPEL Designer [Oracle, BPEL Process Manager]. For the sake of brevity,we show an excerpt of the BPEL code of the Controller process. An instance ofthe process is created upon invocation from the Requester, which is modeled by thefirst receive activity.

<process name="Controller" ...>

...

<sequence>

<receive name="receiveInputFromRequester"

partnerLink="Requester"

portType="tns:Controller"

operation="purchaseBook"

variable="input"




<assign>

<copy>

<from variable="input"

part="bookRequest"

query="/tns:ControllerRequest/tns:ref"/>

<to variable="bookRequest"

part="bookRequest"

query="/tns:ProviderRequest/tns:ref"/>

</copy>

</assign>



<invoke name="asksForBook"

partnerLink="Provider"

portType="tns:Provider"

operation="verifyAvailability"

inputVariable="bookRequest"

outputVariable="bookResponse"/>

<switch>

<case condition="bpws:getVariableData(’bookResponse’,

’response’, ’/tns:ProviderResponse/tns:response’)=true()">





<sequence>



<assign>

<copy>


part="bookRequest"

query="/tns:ControllerRequest/tns:pi"/>

<to variable="negotiationInputC"

part="negotiationParameters"

query="/tns:NegotiateCRequest/tns:initialPrice"/>

</copy>

</assign>

<assign>

<copy>


part="bookRequest"

query="/tns:ControllerRequest/tns:maxPrice"/>

<to variable="negotiationInputC"

part="negotiationParameters"

query="/tns:NegotiateCRequest/tns:maximumPrice"/>

</copy>

</assign>



<invoke name="startPriceNegotiation"

partnerLink="NegotiateC"

portType="tns:NegotiateC"

operation="negotiatePrice"

inputVariable="negotiationInputC"

outputVariable="negotiationOutputC"/>

<switch>

<case condition="bpws:getVariableData(’negotiationOutputC’,

’negotiationResponse’, ’/tns:NegotiateCResponse/tns:response’)

!= false()">



...

<otherwise>





...

</otherwise>



</switch>

</sequence>

</process>

4.6 Development of Web Services

Designing and developing certified2 and executable Web services is a promising di-rection and very few proposals are dealing with such a question in a formal way.However, a lot of work remains to be done to have at one’s disposal a smooth andformal process (known as refinement) enabling one to develop (correct) running Web

2The generated Web services do not violate certain conditions during their execution.

4.6. Development of Web Services 97

services from abstract and validated descriptions. At this level, we especially ex-perimented with the use of process algebras to develop executable and certified Webservices from such abstract descriptions. The link between the abstract level and theconcrete one is formalized through systematic guidelines which make it possible totranslate such abstract processes into WSDL interfaces and BPEL processes. De-pending on the process algebra (and particularly on its expressiveness) used in theinitial step, running BPEL services or just skeletons of code (to be complemented)may directly be obtained. We emphasize that our method has been used to developand deploy running Web services in BPEL. Consequently, it has not remained at theconceptual level as is often the case. The results of this work appeared in the pro-ceedings of an international conference and workshop [Chirichiello & Salaun, 2005;Chirichiello & Salaun, 2006], and in an international journal [Chirichiello & Salaun,2007].

4.6.1 From Process Algebras to BPEL

In this section, we define guidelines to enable developers to write out easily advancedskeletons of BPEL code from abstract and validated descriptions of services-to-be.The presentation of this section follows the structure of the introduction to processalgebras done in Section 4.1. For each process algebras concept (actions, interactions,dynamic operators, data descriptions, processes), we describe how it can be encodedinto BPEL and we illustrate with pieces of XML code. Here, we refer to processalgebra and its underlying constructs in a general way, even though we illustrate withpieces of LOTOS specification. We validated our approach on many examples of suchencodings. The BPEL code obtained after translation was developed and deployedusing the Oracle BPEL Process Manager 2.0 [Oracle, BPEL Process Manager]. Table4.2 summarises the main ideas of the translation from process algebras to BPEL. Theremainder of the section gives more details about it.

Actions and Interactions. The basic piece of behavior in process algebra, the so-called action, is translated into WSDL using messages which are completely charac-terized by the message, portType, operation and partnerLinkType tags.

As an example, these elements are set adequately below in order to encode ab-stract input and output actions. In particular, requestMessage defines the messageformat for input actions (request) whereas resultMessage defines the message for-mat for output actions (result). The operation requestResultOperation is definedin the portType tag, which in general contains the definition of several operations.The input and output tags specify the abstract message formats for the input andoutput actions, respectively. Finally, the partnerLinkType tag characterizes the con-versational relationship between the two interacting processes: it defines their rolesin the conversation and specifies the portType provided by each of them to receive


PA (LOTOS) BPEL

message, portType, operation,

gates + offers partnerLinkType (WSDL),

and receive, reply, invoke (BPEL)

termination ’exit’ end of the main sequence

sequence ’;’ sequence

guards case of switch

choice ’[]’ pick and switch

parallel composition ’|[..]|’ interacting Web services

recursive call new instantiation or while

datatypes and operations XML Schema, DBs, XPath, etc

Table 4.2: Correspondence Between Process Algebras (LOTOS) and BPEL Con-

structs

messages within the context of the conversation.

<message name="requestMessage">

<part name="request" type="xsd:int"/>

</message>

<message name="resultMessage">

<part name="result" type="xsd:int"/>

</message>

...

<portType name="requestResultPortType">

<operation name="requestResultOperation">

<input message="tns:requestMessage"/>

<output message="tns:resultMessage"/>

</operation>

</portType>

...

<plnk:partnerLinkType

name="requestResultPartnerLinkType">

<plnk:role name="requestResultAdder">

<plnk:portType



</plnk:role>

<plnk:role name="requestResultRequester">

<plnk:portType


</plnk:role>


An abstract reception is expressed in BPEL using the receive activity or the pick

activity with one onMessage tag. For example, the LOTOS code request?x:Nat

denotes the reception of an integer value, and the corresponding BPEL code is




variable="x"/>

The partnerLink tag in the receive activity refers to the partner process from whichit is expected to receive a value, the portType and operation tags denote the opera-tion that the partner process is invoking, and the variable tag defines the variable tobe used to store the message data received.

An abstract emission is written in BPEL using the asynchronous or one-wayinvoke activity. For example, the LOTOS code request!x denotes the emissionof a value, and the corresponding BPEL code is




inputVariable="x"/>

The inputVariable tag above refers to the input variable of the operation used tostore the message data to be emitted.

At the abstract level, an emission followed immediately by a reception maybe encoded using the BPEL synchronous or two-way invoke activity, performingtwo interactions (sending a request and receiving a response). On the other sideof the communication, the complementary reception/emission is written out using areceive activity (or a pick activity with one onMessage tag) followed by a reply

one. As an example, let us consider two interacting processes exchanging an integervalue. The emission and the following reception is written in LOTOS as request!x;result?y:Nat, and the corresponding BPEL code is




inputVariable="x"

outputVariable="y"/>


Since it is a synchronous invocation, it requires both an input variable and an outputvariable to store the exchanged messages, respectively denoted by the inputVariableand the outputVariable tags. While, on the other side of the communication, the re-ception followed by the emission request?x:Nat; result!x+z in LOTOS is trans-lated into BPEL as follows




variable="x"/>

...<reply partnerLink="Requester"



variable="y"/>

with the same name of port type and operation. The reply activity is used to senda response to the request previously accepted through the receive activity. Themessage data sent in reply is stored in the variable tag. We emphasize that theabstract term x+z does not appear in the BPEL code, because it is replaced by thevariable y denoting the result of the term, and which has to be assigned beforehandto y by using an assign activity.

As far as the number of participants to a communication is concerned, let usremark that binary interactions are encoded straightforwardly in BPEL (due to itspeer-to-peer interaction model) whereas multi-party communications are expressedin BPEL decomposing it in as many successive two-party communications as needed.

Behavioural Constructs. In this part, we explain respectively how sequence, ter-mination, hidden action, choice, parallel composition are encoded into BPEL.

The sequence matches the sequence activity. The abstract termination corre-sponds to the end of the main sequence in BPEL. For example, the following pieceof LOTOS specification request!x; result?y:Nat; exit corresponds in BPEL to

<sequence>

<invoke ... />

<sequence/>

In the example above, the sequence activity contains only one invoke activity defin-ing a synchronous request/response, but in general there could be more activities thatare to be performed sequentially. The sequence completes when the invoke activitycompletes.

An hidden action is translated into BPEL as a local evolution of a Web servicewhich is not visible from an external point of view. Accordingly, it corresponds to one(or more) assign statement. It may also correspond to a communication of the Web


service at hand with another party but not visible from outside. The hiding constructmaking hidden actions explicit in process algebra is mapped in BPEL as the hiding ofeach concerned action (these actions may be involved in a communication with otherpartners that is not visible from outside).

The choice is translated using either the switch activity, defining an ordered listof case, or the pick one, defining a set of activities fired by a message reception.Branches of a choice involve emissions and receptions, possibly preceded by guards.In case of a choice among emissions, nondeterminism existing at the abstract levelhas to be removed. We obtain a BPEL process whose behavior does not correspondto the abstract LOTOS behavior but which is able to perform any emission in thechoice at any time. In this case, the execution of a branch of the choice depends onan external intervention which may require an extra message exchange. If guardsare present, the encoding is straightforward using as many case tags as needed, andthe otherwise tag may be used to translate mutually exclusive conditions. With-out guards, determinism may be introduced in two ways: (i) adding a pick activityand then defining different messages whose arrival indicates the behavior to be fired,(ii) using a switch activity defining case conditions involving for instance valuesprovided beforehand, each condition firing a possible emission.

A choice among receptions without guards is straightforwardly translated with apick: whenever a message comes, it is received on the correct port. In presence ofguards, the translation is trickier because a pick activity cannot be introduced withina case tag (this is a BPEL limitation). However, it can be achieved reversing thereception and the guard evaluation. The result in BPEL for each branch is a pick

with an onMessage tag preceding a switch activity used to test the condition andthen to execute the behavior if the guard is true. Once again, the resulting BPELprocess behavior does not correspond to the abstract LOTOS behavior, even thoughthe process is still able to perform any reception in the choice at any time.

A choice involving emissions and receptions (without guards) is translated intoBPEL using a pick with one onMessage tag for each branch appearing at the abstractlevel. In case of an emission, it should be determined beforehand (as explained in thecase involving only emissions), and in case of reception it corresponds to a messagecoming from a partner. In presence of guards, we can reuse translation rules men-tioned before: first using a switch for an emission, then using a pick and finally aswitch for a reception.

Observe that the proposed encoding makes it possible to obtain running BPELprocesses from abstract specifications. Even if tricks and choice implementations areneeded, due to the limitations of BPEL as executable language (especially the wayinteractions among processes are managed, or activities combined), our guidelinesfacilitate the translation step. Further details on the translation of the choice can befound in Appendix A.

The parallel composition is used in two different cases: (i) it describes a compo-sition of interacting services; (ii) it may be used internally to a service to represent


two pieces of behavior which has to be carried out in different threads with possibleinteractions. In both cases, each operand of the parallel composition is encoded asone BPEL service meaning that for the case (ii), the architecture of the whole is notpreserved. However, it is not a problem because Web services are defined in a com-positional way, and such auxiliary services can be hidden from an external (or user)point of view, or not if one wants to make them reusable.

Finally, we note that many additional behavioral constructs exist among all of theexisting process algebras. Their translation is not always straightforward, althoughoften tractable. They are material for future research.

Data Descriptions. Three levels of data representation in process algebra have tobe encoded into BPEL: type and operation declarations, local variable declarations,data management in dynamic behaviors (guards and parameters of input/output ac-tions).

As far as datatype definitions are concerned, types are described using XMLSchema in the WSDL files. Elements in the Schema are either simple (many built-intypes are already defined, e.g., integer, string, boolean) or more complex (e.g., list,set, etc, built using the complexType tag). Considering LOTOS algebraic specifica-tions, correspondence is simple because such constructs are shared at both levels. Weintroduce below a simple datatype defining a product characterized by an identifierand a quantity in LOTOS.

type PRODUCTREQUEST is NATURAL, STRING

sorts ProductRequest

opns

conspr (*! constructor *): String, Nat -> ProductRequest

productId: ProductRequest -> String

quantity: ProductRequest -> Nat

...

endtype

The corresponding definition in XML Schema, as appearing in the WSDL file, isdescribed in the following.

<types>

<schema ...>

<element name="ProductRequest">

<complexType>

<sequence>

<element name="productId" type="xsd:string"/>


<element name="quantity" type="xsd:int"/>

</sequence>

</complexType>

</element>

...

</schema>

</types>

The types tag encloses data type definitions that are relevant for the representation ofa product. We define an element named ProductRequest. This element is consid-ered as a complexType, since the other datatype simpleType is reserved for datatypesholding only values. The use of the complexType tag allows us to represent a datatype specific for our application, which in turn can be used in the messageType defi-nition in the WSDL file to define messages that have to be exchanged by the businessprocess during its execution. The complex type ProductRequest is described by asequence tag (not to be confused with the <sequence> tag in BPEL code defining thesequence activity) that defines an ordered sequence of sub-elements. We know thata product is composed by an identifier and a quantity, thus we can define productId

and quantity as sub-elements of the ProductRequest. These elements are consid-ered as simple types since they can be described directly within a tag element. Datatypes xsd:string and xsd:int denote predefined XML Schema datatypes, respec-tively the string and int built-in datatypes.

Data definition allows us to define types but also operations on them. Such ab-stract operations may be encoded into BPEL following different ways. First, they canbe defined within XPath expressions. Several kinds of functions may be called at thislevel such as core XPath functions, BPEL XPath functions or custom ones. XPath ex-pressions appear in the assign activity. They simplify the extraction of informationfrom elements or the storage of a value into a variable. Complex data manipulationmay also be written using XSLT, XQuery or JAVA (e.g., JAVA exec tags enable oneto insert Java code into BPEL code). Another way to describe data operations is touse a database and adequate queries to access and manipulate stored information.

As regards data appearing in behaviors, we gather on one hand receptions andvariable declarations because they just involve variables, and on the other hand emis-sions and guards because they deal with data terms. First of all, we recall that actionparameters in process algebra for emissions and receptions are translated using themessage tag (in the WSDL file). Each part tag matches a parameter of an action.

BPEL variables are used to encode variables appearing in receptions and in localvariable declarations. They are defined using the variable tag (global when definedbefore the activity part) and their scope may be restricted (local declarations) using ascope tag. If necessary, local or global variables may be initialized using an assign

after their declaration.

<variables>

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


...

</variables>

...

<sequence>

...


<copy>


<to variable="y"/>

</copy>

<copy>


<to variable="z"/>

</copy>

</assign>

...

</sequence>

Now, regarding terms appearing in emissions and guards, an emission send(y) meansthat the data expression (e.g., x+z below) has to be built and assigned to variabley before sending using an assign tag, and more precisely the copy tag. Guardsare defined in BPEL using the case tag of the switch construct. For example, theLOTOS code [x<5] -> result!x+z; ... is translated into BPEL as

<switch> 

<case condition="bpws:getVariableData(’x’) < 5">

<assign name="result">

<copy>

<from expression="bpws:getVariableData(’x’) +

bpws:getVariableData(’z’)"/>

<to variable="y"/>

</copy>

</assign>

<reply ... variable="y"/>

</case>

</switch>

We emphasize that data are not available in every process algebra. Since they areessential in BPEL, it seems convenient to use a process algebra expressive enough


to specify data descriptions (like LOTOS). Otherwise, they are directly encoded atthe concrete level enhancing the BPEL skeletons obtained from the purely dynamicdescription.

Processes. As mentioned before, abstract processes are encoded as BPEL services.A global abstract system is described using a main behavior made up of instantiatedprocesses composed in parallel and synchronizing together (they are not obliged tosynchronize on all actions). Let us observe that the main specification (P1|P2|...|Pn),(| denoting a parallel composition) does not match a BPEL process. The correspon-dence is that each abstract instantiated process (Pi), belonging to the global systemmentioned previously, matches a BPEL Web service. However, the architecture ofthe specification is not always preserved. In specific cases (parallel behaviors withina process), it might be necessary to define additional services.

The set of messages is not defined explicitly in BPEL, but the correspondencebetween interacting services is made explicit using the partnerLink declaring onwhich partnerLinkType services interact, and their role in the communication (seebelow such an interaction definition between an Adder and a Requester).

<partnerLink

name="Adder"

partnerLinkType="tns:requestResultPartnerLinkType"

partnerRole="requestResultAdder"

myRole="requestResultRequester"/>

At a lower level, each abstract process is usually made up of three parts: action dec-larations, process parameters, and its behavior (body of the process). Action declara-tions are encoded using messages, operations, portTypes and partnerLinkTypes

tags in the WSDL file and variables in BPEL. Process parameters corresponds to vari-ables in BPEL and its behavior is encoded using BPEL activities. For instance, thedefinition of a process Adder using two actions request and result, parameterizedwith variable z is expressed in LOTOS as

process Adder [request, result] (z: Nat): exit :=

and it can be translated into BPEL as

<process name="Adder" ...>

...

<variables>

<variable name="request" messageType="tns:requestMessage"/>

...


</variables>


<sequence name="main">

...

</sequence>

</process>

Instantiations of processes are encoded into BPEL as an exchange of messages withthe new process to be instantiated. In BPEL, instantiations always occur through areception (a receive or a pick activity annotated with the createInstance attributeset to yes).

<receive ... createInstance="yes"/>

or


<onMessage ...> ...

In practical applications, such instantiations are often customers filling in forms on-line, and thus requesting some services on the Web.

The regular way to encode process algebra recursive process calls is related tothe notion of transaction. A transaction could be defined as a complete execution ofa group of interacting Web services working out a precise task. In this context, oneexecution of a process is enough, therefore abstract recursive behaviors are encodedas non recursive services (each transaction corresponds to a new invocation then in-stantiation of each involved service). Such an encoding is illustrated in Section 4.7.In the case of an abstract choice among different behaviors, some of which end withrecursive calls and some others ending with exits, the while activity may be used.The condition of the while is computed from guards of behaviors ending with exits(conjunction of guard negations).

4.6.2 On Correctness and Completeness of the Encoding

As discussed in the introduction of this chapter, we cannot prove formally that our en-coding preserves a particular semantics since BPEL does not have an accepted seman-tics. Even the language specification is not defined properly in official documents.The ambiguities and inconsistencies in the language are mainly due to the fact thatBPEL builds on IBM’s WSFL (Web Services Flow Language) [Leymann, 2001b] andMicrosoft’s XLANG (Web Services for Business Process Design) [Thatte, 2001] andcombines the (sometimes rather different) features of these two languages. However,we carried out many experiments with the Oracle BPEL Process Manager 2.0 and wecan claim to have acquired a good knowledge of the meaning of BPEL implementedin this tool. In this section, we focus on the semantics preservation between LO-TOS and the semantics of BPEL encoded in the Oracle BPEL Process Manager 2.0.


Correctness and completeness are discussed on the set of LOTOS behavioural con-structs, namely communications (emissions and receptions), sequence, choice andparallel composition.

Correcteness

Process algebra theory provides several notions of bisimulations or equivalences thatcan be used for different purposes. We rely on these equivalence notions to ensurecorrectness of our encoding. Therefore, the transition system model derived fromany LOTOS operator has to be equivalent (w.r.t. a certain equivalence relation) to thetransition system model of the BPEL code obtained by our translation guidelines.

In our context, strong equivalence [Milner, 1989] cannot be preserved becausethis notion imposes a strict matching of τ transitions, and it is not the case in ourapproach. For instance, several LOTOS processes involved in a parallel composi-tion terminate by a synchronization on a τ action which has no equivalent in BPEL.Another example are additional hidden communications that are taking into accountinto BPEL code to implement LOTOS multi-party communication. We claim that ourencoding preserves observational equivalence [Milner, 1989]. Observational equiva-lence is a weaker notion which does not enforce the matching of all τ transitions.

Let us give more details about each behavioral operator mentioned above. Re-ceptions and emissions are translated in the same way in BPEL, resulting in the sameunderlying model. It is also the case for sequence of events. As regards the choiceconstruct, the important point is that all the possible branches appearing in LOTOSare always present in the BPEL code after translation, independently of its encodingusing pick, switch or both of them. The model of a LOTOS parallel compositionis an interleaving of processes behaviors involved in the composition with synchro-nization points corresponding to communications between some of them. The corre-sponding BPEL code is made up of interleaved separate services which communicateon the same messages as those specified in LOTOS. Some τ transitions may appearwith no counterpart in LOTOS or BPEL for the parallel composition as mentionedpreviously in this section, but they are meaningless w.r.t. observational equivalence.

Completeness

Our encoding is complete since all the abstract LOTOS operators introduced in Sec-tion 4.1 can be translated into BPEL, following the guidelines presented previouslyin this chapter.


4.7 Example: A Stock Management System cont’d

Many services involved in e-business applications may be developed following ourapproach: on-line sales (books, CDs, DVDs, flowers, etc.), banking systems (ownaccount management for instance), trip organization, (car) renting, request engines,(hotel, show, etc) reservations, any kind of on-line payment, etc. A formal-baseddevelopment, like the one illustrated in previous section, is of interest to save time(and money), to respect deadlines, and to favor the correctness of the result.

In this section, we give an example that shows how following our approach wecan design and develop executable Web services. The example is about the prob-lem of designing and developing a Stock Management System, which has alreadybeen illustrated in Section 2.6. By following all the steps of our approach (analysis,specification, reasoning, encoding, running code) we are able to develop and deploy arunning Web service implementing the Central Store service (and the other additionalservices). In Section 2.6 we have discussed the first step (informal requirements andanalysis) and the last one (running code). Here we discuss the remaining ones (spec-ification, reasoning and encoding). LOTOS is the process algebra chosen for thisapplication. It is appropriate to describe abstractly the system, particularly thanksto its expressiveness (data and behaviors) and to its toolbox CADP that is helpful tovalidate specifications.

4.7.1 Specification and Validation

Services specifications are written in LOTOS. We start with the description of thedata part. We represent a stock as a set of pairs (id,qt) with two constructors (emptyand add) to build it. Some operations allow us to access and update a stock, such asthe increase operation which increments the quantity of a product.

type STOCK is NATURAL, BOOLEAN

sorts Stock

opns empty (*! constructor *) : -> Stock

add (*! constructor *) :

Nat, Nat, Stock -> Stock

increase : Nat, Nat, Stock -> Stock

...

From the Local Store and Supplier automata describing their public interfaces (seeFigure 2.9), LOTOS specifications are easily generated making the reasoning stepspossible. We illustrate with the process Supplier below:

4.7. Example: A Stock Management System cont’d 109

process Supplier [requestS, okS, nokS] : noexit :=

requestS?id:Nat?q:Nat; (* request reception *)

(

(* product available *)

okS; Supplier[requestS, okS, nokS]

[]

(* product not available *)

nokS; Supplier[requestS, okS, nokS]

)

endproc

Now, we focus on the Central Store process. This process has two possible behaviors:(i) it receives a request from a local store and it replies depending on the availabilityof the required quantity in the stock, (ii) in case of the existence in the stock of aproduct whose quantity is less than a threshold (to be defined arbitrarily), it sends arequest (identifier and a quantity, say, 5) to a supplier and receives a reply. The stockis updated in case of delivery or restocking, using adequate operations (decrease andincrease).

process CentralStore[request, ok, nok, requestS, okS, nokS]

(s:Stock): noexit :=

(

(* reception of a request from a local store *)

request?id:Nat?q:Nat;

(

(* product available *)

[isAvailable(id, q, s)] -> ok;

CentralStore[request, ok, nok, requestS, okS, nokS]

(decrease(id, q, s)) (* stock update *)

[]

(* product not available *)

[not(isAvailable(id, q, s))] -> nok;

CentralStore[...](s)

)

[]

(* emission of a request to a supplier *)

requestS!extract(s)!5;

(

(* restocking possible *)

okS; CentralStore[...] (increase(extract(s),5,s))


[]

(* restocking not possible *)

nokS; CentralStore[...](s)

)

)

endproc

To validate this new service, several verification steps can be performed using CADPto ensure a correct processing of the interacting processes. Accordingly, we show apossible closed system which can be built from the previous definitions. It containstwo local stores and two suppliers. Synchronization sets are explicitly declared, e.g.,the Central Store interacts with one Local Store along the request, ok and nok gates.

let

s1: Stock = (* a product identified by 1 *)

add(1, 6, (* and with 6 as quantity *)

add(2, 5,

add(3, 8, empty))),

...

in

( (* parallel execution of two Suppliers *)

Supplier[requestS, okS, nokS]

|||

Supplier[requestS, okS, nokS]

)

(* a Central Store interacting with two Suppliers *)

(* and two Local Stores *)

|[requestS, okS, nokS]|

CentralStore[request, ok, nok, requestS,

okS, nokS](s1)

|[request, ok, nok]|

( (* parallel execution of two Local Stores *)

LocalStore[request, ok, nok]

|||

LocalStore[request, ok, nok]

4.7. Example: A Stock Management System cont’d 111

)

We found several mistakes in the specification (in the design, interaction flows, datadescription and management). Thus, simulation has helped to clarify misunderstand-ings in the analysis of the problem at hand. Properties have been verified usingEVALUATOR [Mateescu & Sighireanu, 2003] (an on-the-fly model checker part ofCADP) which can be used to ensure safety, liveness and fairness properties writtenin µ-calculus. Due to the simplicity of the problem at hand, we particularly checkthe absence of deadlock, and liveness properties ensuring, for example, that everyrequest gate (also checked with requestS) is either followed by an acceptance or arefusal.

[true* . ’REQUEST !.* !.*’]

mu X. (<true> true and [not ("OK" or "NOK")]X)

and

< true* . ’REQUEST !.* !.*’ > true

4.7.2 Translation into BPEL

Our goal is to emphasize how previous guidelines are used to encode abstract pro-cesses written in LOTOS herein into BPEL. We explain this translation through asample of the BPEL code implemented for the Central Store service. So far, theBPEL code is obtained manually from the LOTOS specification. Automation of thetranslation may be part of future work.

Development Environment

The development environment has been described in Section 2.6.

Following the guidelines

Let us focus on the first half of the interaction of the Central Store with the LocalStore that we specified previously in LOTOS. We discuss how the constructs involvedin this behavior are expressed in BPEL.

First of all, LOTOS emissions and receptions (gates, variables and types) areencoded in the WSDL file. Observe that, the ok and nok actions have been encoded


into BPEL using the same name of message but both branches are distinguished bythe value of its Boolean parameter (true in case of availability, false otherwise).

Each stock is encoded as a simple table with two fields (identifier, quantity). AJava class has been developed, which contains methods to access and update correctlyeach database (using SQL queries), e.g., to test the availability of a product. Wehighlight that the Central Store handles one request after the other. It thus updatesthe database at the end of each transaction and concurrent accesses to the databaseare discarded.

The LOTOS sequence is directly translated using the sequence activity. Thereception and the emission in this part of the Central Store are translated as a pick

activity with one onMessage tag followed by a reply. The choice is composed of twobranches with guards and emissions (without parameters), consequently a switch ac-tivity is employed to translate this LOTOS behavior, and each branch is implementedusing a case tag with guards corresponding to queries on the database.

Recursive calls are encoded as normal terminations into the BPEL code. In thiscase, we introduce the transaction notion corresponding to a request posted by a localstore and a reply depending on the availability of the product in the database. Thus,such a transaction is instantiated every time a new request is received. In the LOTOSspecification, recursive calls are accompanied by stock updates. This is done in BPELupdating the database before the service completes.

Sample of BPEL

The skeleton of the BPEL code describing interactions between the Central Store andthe Local Store, and between the Central Store and the Supplier, has already been de-scribed in Section 2.6.

We conclude this section by observing how the implementation of Web services inBPEL using all the necessary technologies (Java, databases, BPEL Process Manager)is not so simple. Nevertheless, with a minimum knowledge of such technologies,Web services can be implemented and deployed easily and rather quickly (dependingof course on the size of the application) following our approach.

4.8 Comparison with Related Work

We compare our approach with four kinds of related work respectively aiming at: (i)specifying Web services at an abstract level using formal description techniques andreasoning about them, (ii) mapping abstract descriptions and executable languages(mainly BPEL), (iii) developing Web services from abstract specifications, and (iv)contribution w.r.t the negotiation issue. Note that Semantic Web services and existingframeworks for them, such as WSMF (Web Service Modeling Framework) or SWSF

4.8. Comparison with Related Work 113

(Semantic Web Service Framework), are out of the scope of our proposal since ourgoal is not to characterize Web service concepts, but to ensure a correct descriptionand development of services from an interaction point of view.

At this abstract level, there are lots of proposals that originally tended to de-scribe Web services using semi-formal notations, especially workflows [Leymann,2001a]. Some more formal proposals grounded for most of them on transition systemmodels (LTSs, Mealy automata, Petri nets) have been suggested, such as for exam-ple [Hull et al., 2003; Narayanan & McIlraith, 2003; Hamadi & Benatallah, 2003;Berardi et al., 2003a; Lazovik, Aiello, & Papazoglou, 2003]. With regards to the rea-soning issue, work has been dedicated to verifying Web service descriptions to ensuresome properties of systems [Fu, Bultan, & Su, 2004; Deutsch, Sui, & Vianu, 2004;Narayanan & McIlraith, 2003; Foster et al., 2003; Nakajima, 2002]. Summarizingthese, they use model checking to verify some properties of cooperating Web ser-vices described using XML-based languages (DAML-S, WSFL, BPEL, WSCI). Ac-cordingly, abstract representations are extracted from Web service implementations,and some properties are checked using ad-hoc or well-known tools (e.g. SPIN modelchecker, Labelled Transition System Analyzer - LTSA).

In comparison to these existing proposals, the strength of our alternative approachbased on process algebras, is to work out all these issues (description, composition,reasoning) at an abstract level, based on the use of expressive description techniquesand equipped with the state-of-the-art reasoning tools. Compared to the automata-based approaches, the main benefit of process algebra is its expressiveness, partic-ularly due to a large number of existing calculi enabling one to choose the mostadequate formalism depending on its final use. Additionally, another interest of pro-cess algebras is that their constructs are adequate to specify composition due to theircompositionality property (not the case of Petri nets or automata-based notations).Lastly, textual notations (even if sometimes criticized as less readable than transitionsystems) are more adequate to describe real-size problems, as well as to reason onthem.

The second group of related work deals with mappings between abstract andconcrete descriptions of Web services. Example of such proposals are [Fu, Bultan,& Su, 2004; Pistore, Roveri, & Busetta, 2004; Foster et al., 2003; Narayanan &McIlraith, 2003; Viroli, 2004]. Let us emphasize that in other attempts (especiallyours) [Salaun, Bordeaux, & Schaerf, 2006; Salaun, Ferrara, & Chirichiello, 2004;Ferrara, 2004], rough ideas have already been proposed to map process algebra andBPEL. Our initial proposal has been subsequently refined in [Chirichiello & Salaun,2007] and supported by a practical phase in which our ideas have been experimentedwith using the BPEL Process Manager 2.0. A relevant related paper is [Fu, Bultan,& Su, 2004] in which the authors present an approach to analyze BPEL compositeWeb services communicating through asynchronous messages. They use guarded au-tomata as an intermediate language from which different target languages (and tools)can potentially be employed. They especially illustrate with the formal language


Promela and the corresponding model checker SPIN.Compared to them, our attempt is slightly different while sharing some common

points. First, we do not argue for a reverse engineering direction for the mapping butwe propose a method to develop Web services. A judicious choice of our abstractlanguage (e.g., LOTOS) makes the specification of advanced data descriptions andoperations on them possible at the abstract level (more complex than in [Fu, Bultan,& Su, 2004] where operations cannot be modelled) as well as at the executable one.Our method has beenused to develop and deploy running Web services, consequentlyit has not remained at a conceptual level as is most of the time the case.

Furthermore, several approaches have been proposed to develop Web servicesstarting from abstract descriptions. Lau and Mylopoulos [2004] argues that TRO-POS (an agent-oriented methodology) may be used to design Web services, but thiswork does not take into account the formal part of the methodology [Fuxman et al.,2003]. A recent trend focuses on the use of UML to design Web services and onOMG’s model driven architecture (MDA) to generate executable specifications indifferent composition languages, see for instance [Mantell, 2003; Skogan, Grønmo,& Solheim, 2004; Baına et al., 2004]. However, semi-formality of UML is a greatlimit to the validation and verification stage which is one of our motivations in thiswork. On the industrial side, platforms like .NET [Microsoft, Net] and J2EE [SunMicrosystem, J2EE] make it possible to develop Web services, but they do not pro-pose methods (above all formal-oriented) to achieve this goal.

There are several proposals concerning negotiation from different research do-mains. The main issues in negotiation are to describe negotiating systems, to verifythe existence of an agreement (and possibly other properties) and to speed up reach-ing it. Most of the proposals belong to the MASs area. Some former work is ded-icated to describing and automating negotiations [Fatima, Wooldridge, & Jennings,2004; Wooldridge & Parsons, 2000; Zlotkin & Rosenschein, 1996]. As an example,in [Wooldridge & Parsons, 2000], the authors propose to use logic-based languagesfor multi-agent negotiation. They can verify from a given history that an agreementhas been reached and, for a given protocol that an agreement will be reached.

Other work proposes some description frameworks, for instance, to represent allthe concepts (profiles, policies, strategies, etc.) used in negotiations and to ensuretrust in negotiations. In [Bertino, Ferrari, & Squicciarini, 2003], the authors presentan XML-based framework for trust in negotiations. Their framework takes into ac-count most of the aspects involved in negotiation from the specification of participantprofiles and policies to the determination of the strategy to succeed in the negotiation.In [Skogsrud, Benatallah, & Casati, 2004], the authors propose a model-driven trustnegotiation framework for Web services. Their model is based on state machines ex-tended with security abstractions. Their approach allows dynamic policy evolution aswell. Another proposal related to Web services is [Chiu, Cheung, & Hung, 2003], inwhich the authors suggest a flexible meta-model based on contracts for e-negotiationservices. From this approach, negotiation plans can be derived and implementations

4.9. Remarks 115

can be performed in recent Web service platform like .NET. Chiu, Cheung, & Hungdescribe some experiments on automated negotiation systems using Web services.They also implement a RFQ-based simple negotiation protocol using the BPEL exe-cutable language.

Compared to these approaches, we first propose a formal representation of nego-tiation situations. The formality of our approach implies the ability to reason aboutit to ensure correctness of interacting processes (either developing concrete Web ser-vices or abstracting away from an executable one), and to prove the existence of anagreement. We also claim that, the use of Web services is adequate for negotiatingsystems due to many of their characteristics: interoperability, autonomy and automa-tion, expressiveness of description, deployment on the Web, etc.

4.9 Remarks

Web services are an emerging and promising area involving important technologicalchallenges. Some of the main challenges are to correctly describe Web services, tocompose them adequately and/or automatically, and to discover suitable Web servicessolving a given problem. In this chapter, we have illustrated a framework based onprocess algebras to develop and reason about Web services at an abstract level. Weemphasize that the results obtained so far, are at an early maturity stage and muchwork still needs to be done. A discussion of some future perspectives and possibleextensions is provided in Chapter 6.

The process algebras approach seems to be promising for tackling several issuesrelated to Web services. A beneficial aspect is that process algebras are very wellstudied and have formal foundation for investigating various aspects of interest forprocess-based systems, in general. While being based on a small core of usual oper-ators, process algebras offer a wide panel of languages and tools to deal with manyspecific aspects of Web services (data description, time, probability, mobility, etc)and involving different communication models. This characteristic makes the ap-proach quite general since we do not need to focus on a specific language but wehave at our disposal a whole family of formal description techniques. Additionally,process algebra constructs are adequate to specify Web services composition due totheir compositionality property. Finally, concerning the use of process algebra forWeb service development, the proposed giudelines makes it possible to obtain run-ning BPEL processes from abstract specifications.

However, the process algebras approach, like any other formal automata-basedapproach, has several drawbacks that limit its practical viability and wide-scale adop-tion. We conclude this section by illustrating some of these limitations. For speci-fying functional requirements, process algebras techniques for service compositionrequire the service developer to provide a specification of the desired behavior of thecomposite service in its entirety. Consequently, the developer has to deal with the


cognitive burden of handling the entire composition graph (comprising appropriatedata and control flows) which becomes hard to manage with the increasing complex-ity of the composite service. Instead, it would more practical to allow developers tobegin with an abstract, and possibly incomplete, specification that can be incremen-tally modified and updated until a feasible composition is realized. Moreover, if thecomposite service specification provided by the service developer cannot be realizedby the composition analyzer, using the set of available component services, the entirecomposition task fails. Observe that, in many cases the failure to realize a compositeservice using a set of component services, is due to incompleteness of the compositeservice specification. Therefore, it would of much help to have some approaches thatidentify the cause(s) for failure of composition and guide the developer in applyingthat information for appropriate reformulation of the composite service specificationin an iterative manner.

To overcome these limitations, we decide to adopt an alternative approach to Webservice composition based on reasoning about actions formalisms, and in particularon action languages. This work has been the focus of the second part of our Ph.D.studies and is described in detail in the next chapter. The rationale behind the choiceof action languages lies in their expressiveness and in the fact that they allow us todescribe services by disregarding details on how they are invoked and consumed,i.e., the effects of the activities of Web services are described without any specificknowledge about how they are implemented, and how they should be coordinated.As we will see, such a declarative approach is very flexible since it allows us to dealwith incomplete information and exceptional cases. What we describe are the normalruns of services and we do not need to know all the possible execution scenariosthat might occur. In this context, the composition problem can be formulated as aplanning task. Given an abstract and possibly incomplete specification of the targetservice, this specification is used to select a set of suitable component services suchthat their composition realizes the desired goal. In the event that such a composition isunrealizable, the cause for the failure of composition is determined, thereby enablingfurther reformulation of the goal specification.

Chapter 5

Representing and ReasoningAbout Web Services with ActionLanguages

Web services provide a standard means of interoperating between different softwareapplications running on a variety of platforms and/or frameworks. In a Web serviceapplication, if there is no single Web service that can achieve the client request, thereshould be a software agent which can automatically compose existing services to-gether (in a sequential or parallel order) in order to fulfill the request. Automatedservice composition has the potential to reduce development time and effort for newapplications. However, it is a hard problem and it is not clear which technique solvesthe problem best. The complexity, in general, depends on several aspects. First, thenumber of services available over the Web increases dramatically, and we cannot ex-pect to have a huge Web service repository to be searched. Moreover, Web servicescan be created and updated on the fly, thus the composition system needs to detect theupdating at runtime and decisions should be made based on up-to-date information.Finally, Web services can be developed by different organizations which use differentconcept models to describe the services, and there does not exist a unique languageto define and evaluate the Web services in a standard way.

Researchers have investigated the automated composition of Web services by ap-plying methods related to AI planning and automated theorem proving. The generalassumption of this kind of methods is that each Web service is an action that altersthe state of the world as a result of its execution. The input and the output parame-ters of Web services act as (knowledge and world) preconditions and (knowledge andworld) effects in the planning context. After a user has specified inputs and outputs

117

118 5. Representing and Reasoning About Web Services with Action Languages

required by the composite service (the goal), a process (plan) is generated automat-ically by AI planners or logical theorem provers. The plan represents the calls tothe component Web services needed for satisfying the client request. Such a plan issimilar to a workflow since it describes a set of steps towards a goal, but its function-ality is more limited than a workflow. In fact, plans are usually simple sequences ofactions whereas a workflow can contain while loops, if-then conditions, and so on.Observe that, the planning problems that will naturally arise in such contexts are notclassical, for the obvious reason that classical-planning domains assume completeinformation while many of the actions Web services perform are for the purpose ofgaining information.

The planning approaches are focused on the process-centric description of ser-vices as actions that are applicable in states. State transitions are defined based onpreconditions of actions and lead to new states where the effects of the actions aretrue. Therefore, they need a representation of state, actions, goals, events and op-tionally, an ontology of standard terms. In comparison with methods based on apredefined workflow model (see Chapter 1 and Chapter 2) which are focused on afunction-centric description of services, there is more flexibility in terms of consid-ering different choices of services (plans) based on goals, but the goals are explicitlygiven. OWL-S [DMAL, 2006] is the only Web service language that has a directconnection with AI planning. As discussed in Section 2.5, OWL-S views Web ser-vices as processes that have inputs, outputs, preconditions and (conditional) effects(IOPEs). Furthermore, it provides a family of constructs for building composite pro-cesses from atomic ones. These constructs are reminiscent of flowchart-style, but inOWL-S are viewed as declarative constraints in the specification of a Web service,rather than procedural.

Recently, several proposals have investigated the potential and boundaries of ex-ploiting AI planning techniques to derive Web service processes that achieve a desiredgoal. Some of these proposals have been described in Chapter 3. Further proposalsare reported in [Rao & Su, 2004; Peer, 2005]. Among the planning techniques, wemust mention the methods of reasoning about actions and planning for domains de-scribed in action formalisms. Action languages are high-level formalisms for repre-senting and reasoning about the effects of actions in the environment. They are at-tractive because they are concise and because their semantics is based on a theory ofcausality: the meaning of a domain description in such a language can be representedas a transition diagram, which is a directed graph with vertices corresponding to statesof the world and edges denoting the changes caused by the occurrence/nonoccurenceof actions. Action languages are more expressive than the “classical” planning lan-guages like STRIPS [Fikes & Nilsson, 1971] and ADL [Pednault, 1989]. Planning isconsidered as a reasoning task in an action domain. Translations of action languagesinto logic programming allow one to transform planning problems into satisfiabilityproblems (in the spirit of “Satisfiability Planning” [Kautz & Selman, 1992]), whichcan be solved by existing and efficient SAT checkers.

119

In this chapter, we discuss the use of action languages for representing and rea-soning about Web services. Our goal is to show how action languages can be ex-ploited to specify an abstract composite process model and produce a user specificcomposition. In our proposal we assume the existence of software agents that are incharge of reasoning about Web services to perform automated Web services compo-sition. We conceive each Web service as atomic or composite. Atomic services aremodelled as actions whose preconditions and effects are encoded in an action theory.The set of available atomic services is known in advance and is given once for all.Client requirements are specified by providing a set of conditions that the compositeservice must satisfy. Observe that, often these requirements involve complex condi-tions on the behavior of the composite service and not just on its final state. For thesake of simplicity, here we assume that these requirements are represented as simplegoals, i.e., they specify the properties that must hold in desired states of the world.Therefore, composite services are obtained as compositions of individual atomic ser-vices. They are seen as sequences of atomic services which must be executed in thegiven order, in order to satisfy the client goals.

Various action languages have been proposed in literature, offering different ca-pabilities and expressiveness. Here we focus on the action language C+ [Giunchigliaet al., 2004]. The rationale behind this choice lies in its expressiveness. In fact,C+ provides a framework for various reasoning problems (e.g., planning, predic-tion, postdiction) in presence of concurrency, nondeterminism, ramifications, etc.Furthermore, it is equipped with a tool CCALC [TAG at Austin, CCALC] whichanswers queries about action domains expressed in a fragment of C+. The lan-guage and its tool have been applied to several benchmark problems in common-sense knowledge (see, for instance, [Campbell & Lifschitz, 2003; Akman et al.,2004] and the examples provided on the CCALC Web site). Other applications arethe formalization of multiagent computational systems [Artikis, Sergot, & Pitt, 2002;Artikis, Sergot, & Pitt, 2003; Chopra & Singh, 2003; Chopra & Singh, 2006; Ser-got & Craven, 2006], and the specification of business protocols as choreographiesmodelled via commitments [Desai, Chopra, & Singh, 2007]. The contribution of ourstudy is twofold. First, we aim to show the use of the language C+ in a realistic ap-plication, namely the Web service composition. Second, the expressive power of thelanguage provides us with a framework for the formal description of Web servicesand the specification of Web service composition.

We begin by assuming that the software agent in charge of performing the com-position of services, has complete information about the environment in which com-ponent services have to be executed. Thus, we show how C+ propositions (actuallythe subset of C+ implemented in CCALC) can be used to describe the services andhow the composition problem can be formulated as a reasoning task. Such a charac-terization of the composition problem allows us to use CCALC for finding a solutionto the problem and synthesizing a composite service for the client request.

This basic approach can be seen as a first step towards a declarative method for


describing and reasoning about Web services. Although promising, however, it isbased on the simplified assumption of complete knowledge, which in the contextof the Web is unrealistic. In fact, as the set of available services grows very large(i.e., as we start using large repositories of heterogeneous services), and since eachservice node is designed, owned, or operated by different parties, it is likely thatthe composer agent has to acquire the information needed to solve the compositionproblem from external sources. Furthermore, many services are there simply foracquiring knowledge, e.g., getting options for booking travels, etc. These aspectssuggest that we should modify our framework in order to model not only the changesin the world but also in the mental state of the agent. As a first attempt to investigatecomplex scenarios involving incomplete information, we propose an extension of theaction language framework for dealing with actions that explicitly affect knowledge.Specifically, we describe a new action language, named KC+, which generalizes theaction language C+ by introducing epistemic modalities in the underlying logic todistinguish what is known about the world from what is unknown. Then, we suggesthow the expressive capabilities of the new language could be exploited for describingthe additional aspects of services related to information requirements and knowledgegain. Further discussions about future extensions are provided in Chapter 6.

5.1 The Action Language C+

The action language C+ is a formalism for specifying and reasoning about the ef-fects of actions and the persistence (inertia) of facts over time, building on a generalpurpose formalism called nonmonotonic causal theories (also referred to as causaltheories, or as the logic of causal explanation in [Lifschitz, 1997]). An action de-scription in C+ is a set of rules which define a labelled transition system of a certainkind. In this section, we provide a concise and necessarily rather dense summary ofC+, showing also how action descriptions can be translated into causal theories. Themain purpose of this section is to introduce the terminology and the notation whichwill be used and extended later on in the chapter. For a detailed description of C+ werefer the reader to [Giunchiglia et al., 2004].

5.1.1 Multivalued Propositional Formulas

A multivalued propositional signature σ is a set of symbols, called constants. Foreach constant c, there is a non-empty finite set Dom(c) of values, called the domainof c. A boolean constant c is such that Dom(c) = {true, false}. In this case, wewrite c for c = true, and ¬c for c = false. A boolean signature is one whoseconstants are boolean. An atom is an expression of the form c = v, where c ∈ σand v ∈ Dom(c). We write c 6= v as a shorthand for ¬(c = v). The language L ofmultivalued propositional formulas is

5.1. The Action Language C+ 121

φ ::= ⊥ | > | any atom c = v | ¬φ | φ ∧ φ | φ ∨ φ.

The material implication is defined as φ → ψdef= ¬φ ∨ ψ.

The signature σ is partitioned into a set σf of fluent constants and a set σa ofaction constants. Fluent constants are additionally partitioned into simple fluent con-stants and statically determined fluent constants. Intuitively, a fluent constant, orsimply a fluent, represents a parameter characterizing a state of the world and the el-ements of its domain are the possible values of that fluent. Similarly, action constantsdenote parameters characterizing an event occurring over a time interval between twosuccessive states. An atom c = v of L is called fluent atom if c ∈ σf , and actionatom if c ∈ σa. A fluent formula is a formula such that all constants occurring init are fluent constants, and an action formula is a formula that contains at least oneaction constant and no fluent constants.

An interpretation I of σ is a function that maps every constant of σ to an elementof its domain. I(σ) denotes the set of interpretations of σ. An interpretation I satisfiesan atom c = v, written as I |= c = v, if I(c) = v. The satisfaction relation |= iseasily extended from atoms to formulas of L, according to the truth tables for thepropositional connectives. Since σf and σa are disjoint, it makes sense to state thefollowing.

• I(σ) = I(σf ) ∪ I(σa), where I(σf ) is the set of interpretations of σf , andI(σa) the set of interpretations of σa;

• I = If ∪ Ia, where If is the restriction of I to σf , and Ia the restriction of Ito σa;

• for any fluent formula φ, I |= φ iff If |= φ;

• for any action formula α, I |= α iff Ia |= α.

As usual, if X is a set of formulas, I |= X stands for I |= φ for all φ ∈ X . Wecall I a model of X . X is said to be consistent or satisfiable if it has a model. Wewrite X |= φ to denote that I |= φ, for all models I of X . In this case we say thatthe formula φ is entailed by the set X . When X ′ is a set of formulas of L, we writeX |= X ′ as a shorthand for X |= φ for all formulas φ ∈ X ′.

5.1.2 Syntax of C+

Consider a multivalued propositional signature σ and the language L built on it. Anaction description D is a finite set of causal laws which can be of three types: staticlaws, fluent dynamic laws and action dynamic laws. A static law is an expression ofthe form

caused φ if ϕ (1)


where φ and ϕ are fluent formulas of L; φ is the head of the rule and ϕ is the body.Static laws are used to specify domain constraints, exogenous fluents and staticallydetermined fluents. Domain constraints express static background knowledge aboutthe world. Exogenous fluents are fluents whose value can vary from one state toanother, but not under the effects of actions in the action description. Statically deter-mined fluents differ from simple fluents, since their value in a state is related to thevalue of other fluents in the same state. A fluent dynamic law is an expression of theform

caused φ if ϕ after ψ (2)

where φ and ϕ are fluent formulas of L, φ does not contain statically determinedfluent constants, and ψ is a formula of L; φ is the head of the rule and ϕ after ψ isthe body. Fluent dynamic laws are used to specify how the value of simple fluentschanges after an event, and to specify inertial fluents. Such fluents are simple fluentswhose value persists by default from one state to the next. An action dynamic law isan expression of the form

caused α if ψ (3)

where α is an action formula of L and ψ is a formula of L; α is the head of therule and ψ is the body. If combined appropriately, action dynamic laws can be usedto specify certain constraints on action constants, or to describe exogenous actionconstants. Such constants correspond to atoms like a = v and are used to nameelementary actions. Their execution has an external cause not described in the actiondescription (they can be executed or not executed at will). Causal laws can be writtenusing some abbreviations. The full list is presented in [Giunchiglia et al., 2004] andprovided in Appendix B for future reference.

Definite Action Descriptions. Of a particular interest are definite action descrip-tions. An action description D is definite if for all static laws, fluent dynamic lawsand action dynamic laws in D

• the head of every laws is either a fluent atom (respectively, an action atom) orthe symbol ⊥, and

• no atom is the head of infinitely many laws of D.

5.1.3 Nonmonotonic Causal Theories

The formalism of nonmonotonic causal theories, presented in [Giunchiglia et al.,2004], is a general-purpose language for knowledge representation and nonmono-tonic reasoning. The main idea is to distinguish between the claim that a propositionis true and the stronger claim that there is a cause for it. Causal dependencies aredescribed by causal rules which are expressions of the form


φ ⇐ ψ

(to be read as “φ is caused if ψ holds”), where φ and ψ are formulas of the languageL built on a given multivalued propositional signature σ. The formula φ is the headof the rule, and ψ is the body. Rules with head ⊥ are called constraints. A causaltheory is a set of causal rules.

We now extend the concept of a model defined for formulas of L to causal rules.Let Γ be a causal theory based on a signature σ, and I be an interpretation of σ. Thereduct of Γ, denoted as ΓI , is the set of heads of rules of Γ whose bodies are satisfiedby the interpretation I . Formally,

ΓI def= {φ | φ ⇐ ψ is a rule in Γ, I |= ψ}.

Intuitively, ΓI is the set of formulas of L that are caused according to the rules of Γunder the interpretation I . We say that I is a model of Γ iff I is the unique interpreta-tion of σ that satisfies all formulas of ΓI . Observe that, based on this definition if ΓI

has no models, or more than one model, or a unique model different from I , then Iis not considered to be a model of the theory Γ. Γ is consistent or satisfiable if it hasa model. We say that Γ entails the formula φ if every model of Γ satisfies φ. In thiscase we write Γ |= φ.

As an example, consider the following theory Γ1 based on the boolean signatureσ1 = {p, q}

p ⇐ qq ⇐ q¬q ⇐ ¬q

In order to find out if Γ1 is satisfiable, we need to consider all possible interpretationsof σ1:

• I1 = {p = false, q = false}: ΓI11 = {¬q}. Since ΓI1

1 has two models({p = false, q = false} and {p = true, q = false}), then I1 is not a modelof Γ1.

• I2 = {p = false, q = true}: ΓI21 = {p, q}. Since I2 is not a model of ΓI2

1 ,then I2 is not a model of Γ1.

• I3 = {p = true, q = false}: ΓI31 = {¬q}. Since ΓI3

1 has has two models({p = false, q = false} and {p = true, q = false}), then I3 is not a modelof Γ1.

• I4 = {p = true, q = true}: ΓI41 = {p, q}. Since I4 is the unique model of

ΓI41 , then I4 is a model of Γ1.


The formalism of causal theories is nonmonotonic. This means that, adding new rulesto a causal theory may change its conclusions. For instance, consider the signatureσ2 = {c}, where Dom(c) = {1, . . . , n} for some positive integer n. Γ2 is a causaltheory based on σ2 that consists of the rule

c = 1 ⇐ c = 1

Γ3 is another causal theory based on σ2, obtained by extending Γ2 with a new rule

c = 1 ⇐ c = 1c = 2 ⇐ >

Observe that, the only model of Γ2 is I(c) = 1, whereas the only model of Γ3 isI(c) = 2. Therefore, although Γ2 |= c = 1, we have for the extended theory Γ3 thatΓ3 6|= c = 1 but Γ3 |= c = 2. This example shows that the logic introduced above isnonmonotonic.

The models of a causal theory Γ based on a multivalued propositional signatureσ, can be used to described the “histories” (sequences of states) of length is m ≥ 0of a system. To do that, we can create for all i ∈ {0, . . . , m} a copy of every fluentof σf , and for all i ∈ {0, . . . ,m − 1} a copy of every action constant in σa. For aparticular i, the interpretation of fluents represents a state si of the system, and theinterpretation of action constants represents the transition from state si to state si+1.

Definite Causal Theories. A causal theory Γ is definite if

• the head of every rule of Γ is an atom or ⊥, and

• no atom is the head of infinitely many rules of Γ.

Definite causal theory are of a particular interest since their models can be describedin terms of literal completion [McCain & Turner, 1997], which is a process for trans-lating a set of causal rules into a set of propositional formulas. This process is anal-ogous to Clark’s completion that provides the semantics for negation by failure inlogic programs. Literal completion is used in [McCain & Turner, 1998] to apply sat-isfiability planning [Kautz & Selman, 1992] to action domains described by causaltheories.

Consider a definite causal theory Γ based on signature σ. For each atom c = v,the completion formula for c = v is the formula

c = v ≡ ψ1 ∨ · · · ∨ ψn

where ψ1, . . . , ψn (n ≥ 0) are the bodies of the rules of Γ with head c = v. Incase n = 0, c = v is the head of no rule. Therefore, its completion formula isc = v ≡ ⊥. The completion of Γ, denoted as Comp(Γ), is obtained by takingthe completion formulas for every atom of σ along with the formula ¬ψ for eachconstraint ⊥ ⇐ ψ in Γ. The relationship between causal logic and completion isdescribed in [Giunchiglia et al., 2004], where the authors demonstrate that


the models of a definite causal theory are precisely the models of its completion.

This result is important since it shows that the satisfiability problem for definite causaltheories belongs to class NP, and it is clearly NP-complete.

For illustration purpose, consider the causal theory Γ1 described above. Γ1 isobviously definite. Its completion consists of the following formulas

p ≡ q¬p ≡ ⊥q ≡ q¬q ≡ ¬q

It is easy to verify that the only model of Comp(Γ1) is {p, q}, which is exactly themodel found before using the definition of causal logic.

5.1.4 Semantics of C+

Consider a multivalued propositional signature σ = σf ∪ σa. A state of the worldis defined as an interpretation of σf , and represented by the set of fluent atoms thatit satisfies. Similarly, an event is defined as an interpretation of σa, and representedby the set of action atoms that it satisfies. Events describe the execution of actionsduring a time interval between two successive states. The event {a1 = v1, a2 =v2, . . . , an = vn} denotes a composite action in which the elementary actions a1 =v1, a2 = v2, . . . , an = vn are performed concurrently. If a is a boolean actionconstant, then ¬a indicates that action a is not performed. If all action constants areboolean, {¬a1,¬a2, . . . ,¬an} is the null event. Therefore, given a fluent formula φ,we say that φ holds in s if s |= φ. Given an action formula α, we say that the event εis of type α if ε |= α.

Every action description D of C+ defines a labelled transition system. This sys-tem can be represented as a directed graph where nodes correspond to states andedges encode the transitions between states due to actions execution. A transition isdenoted as a triple 〈s, ε, s′〉, where s is the initial state of the transition and s′ theresulting state when the actions in event ε are executed. Giunchiglia et al. give a for-mal characterization of the transition systems defined by action descriptions of C+in terms of causal theories. Specifically, in their paper they show how an action de-scription D can be turned into a causal theory ΓD

m for a given integer m ≥ 0 (whichrepresents the length of the histories of the system that we want to describe), suchthat the model of ΓD

0 are the nodes of the transition system described by D, and themodels of ΓD

1 are its edges. In what follows, we briefly describe how this translationis carried out.

If σ is the signature of D, ΓDm is based on a signature σm which is obtained

from σ by time-stamping every fluent with a non negative integer 0 ≤ i ≤ m, andevery action constant with 0 ≤ i ≤ m − 1. That is, σm = σf

m ∪ σam−1, where


σfm = σf

0 ∪ σf1 ∪ . . . ∪ σf

m−1 and σam−1 = σa

0 ∪ σa1 ∪ . . . ∪ σa

m−2. The signature σm

contains constants i : c such that

• i ∈ {0, . . . , m} and c is a fluent of σf ;

• i ∈ {0, . . . , m− 1} and c is an action constant of σa;

and the domain of such constants is kept identical to those of their constituent. Sincean interpretation I of σ is represented by the set of atom that it satisfies, and states andevent are interpretations of σf and σa, respectively, we represent any interpretationof the signature σm as

(0 : s0) ∪ (0 : ε0) ∪ (1 : s1) ∪ (1 : ε1) ∪ · · · ∪ (m− 1 : εm−1) ∪ (m : sm)

where s0, . . . , sm ∈ I(σf ) and ε0, . . . , εm−1 ∈ I(σa) .The rules of ΓD

m are obtained by translating the laws of D. The details of thistranslations are provided in Table 5.1. In this table f is a fluent,a is an action constant,φ and ϕ are fluent formulas, α is an action formulas, and ψ is a formula. Let us nowcomment on the contents of table 5.1. The first four lines show how (statically andsimple) fluent constants are translated. Statically determined fluents can be used inthe head of static laws only. Simple fluents can be inertial and the third line showshow they can be declared. The corresponding causal rules make the inertial fluentsexogenous in the initial state, meaning that the value of a fluent in the initial stateis determined by means external to the theory, and express the inertiality by statingthat, by default, the value of an inertial fluent is preserved while transitioning tothe next state. All of these rules act as frame axioms. In general, simple fluentscan be declared as exogenous not only in the initial state, but in every state. Thefourth line shows how to do that, along with the corresponding causal rules. Thefifth and sixth lines show how action constants are translated. In particular, the sixthline shows how to declare exogenous action constants. The corresponding causalrules express that the principle of universal causation1 is disabled for the action.Intuitively, it means that the cause for this action is external to the theory. The seventhline shows how to translate static laws: formulas φ and ϕ must be evaluated in thesame current state. The following line shows the translation of fluent dynamic laws:φ and ϕ are evaluated in the following state, while ψ is evaluated in the current state.Finally, the last line shows the translation of action dynamic laws. In particular,the corresponding causal rules express constraints on the execution of actions. Theformula ψ expresses some conditions that have to be tested against the state of theworld before actions execution.

The semantics of C+ is defined in terms of causal theories. We summarize theresults presented in [Giunchiglia et al., 2004]. Given an action description D basedon a multivalued propositional signature σ

1The principle of universal causation expresses that in very possible world history every fact that

obtains is caused.


C+ Causal Theories

1. f f is a statically determined fluent

2. f f is a simple fluent

3. inertial f f is an inertial fluent

(0 : f = v) ⇐ (0 : f = v)

(i + 1 : f = v) ⇐ (i + 1 : f = v)

for every v ∈ Dom(f)

and for every i ∈ {0, . . . , m}

4. exogenous f f is an exogenous fluent

(i : f = v) ⇐ (i : f = v)

for every v ∈ Dom(f)

and for every i ∈ {0, . . . , m}

5. a a is an action constant

6. exogenous a a is an exogenous action constant

(i : a = v) ⇐ (i : a = v)

for every v ∈ Dom(a)

and for every i ∈ {0, . . . , m− 1}

7. caused φ if ϕ (i : φ) ⇐ (i : ϕ)

for every i ∈ {0, . . . , m}

8. caused φ if ϕ after ψ (i + 1 : φ) ⇐ (i + 1 : ϕ) ∧ (i : ψ)

for every i ∈ {0, . . . , m− 1}

9. caused α if ψ (i : α) ⇐ (i : ψ)

for every i ∈ {0, . . . , m− 1}

Table 5.1: Translation of C+ to Causal Theories


• an interpretation s of σf is a state of D iff (0 : s) is a model of ΓD0 ;

• a triple 〈s, ε, s′〉, where s and s′ are interpretations of σf and ε is an inter-pretation of σa, is a transition of D (causally explained according to D) iff(0 : s) ∪ (0 : ε) ∪ (1 : s′) is a model of ΓD

1 ;

• for any m ≥ 0, each triple 〈si, εi, s′i+1〉 from a sequence of transitions is a

transition of D (causally explained according to D) iff the interpretation ofσm (0 : s0) ∪ (0 : ε0) ∪ (1 : s1) ∪ (1 : ε1) ∪ · · · ∪ (m− 1 : εm−1) ∪ (m : sm)is a model of ΓD

m;

• for any transition 〈s, ε, s′〉 of D, s and s′ are states of D.

Example: A Simple Action Description in C+

As an illustration of the definitions given before, we provide a simple example of anaction description, taken from [Giunchiglia et al., 2004]. Let σ = σf ∪ σa = {p} ∪{ao} be a boolean signature. The action description AD consists of the propositions

ao causes pinertial pexogenous ao

In action description AD, abbreviations are used. According to the definition of theseabbreviations (see Appendix B), the propositions above are shorthand for

caused p if > after ao

caused p if p after pcaused ¬p if ¬p after ¬pcaused ao if ao

caused ¬ao if ¬ao

Since σf = {p} and σa = {ao}, there are two states of the world s1 = {p = false}and s2 = {p = true} (corresponding to the possible interpretations of fluent σf )and two events ε1 = {ao = true} and ε2 = {ao = false} (corresponding to thepossible interpretations of σa). The transition diagram defined by AD is depicted inFigure 5.1. Two edges are labelled ao (action ao is executed); the other two edgesare labelled ¬ao (action ao is not executed). The presence of loops in the diagram isdue to the fact that p is inertial. Given an integer m ≥ 0, the causal theory ADm

generated from AD is


Figure 5.1: Transition Diagram for C+ Action Description AD

(i + 1 : p) ⇐ (i : ao)(i + 1 : p) ⇐ (i : p) ∧ (i + 1 : p)(i + 1 : ¬p) ⇐ (i : ¬p) ∧ (i + 1 : ¬p)(0 : p) ⇐ (0 : p)(0 : ¬p) ⇐ (0 : ¬p)(i : ao) ⇐ (i : ao)(i : ¬ao) ⇐ (i : ¬ao)

for i = 0, . . . , m − 1. It is easy to verify that the vertices of the transition system inFigure 5.1

s1 = {p = false}s2 = {p = true}

are the models of causal theory AD0

0 : {p = false}0 : {p = true}

and that the transitions of AD

〈{p = false}, {ao = false}, {p = false}〉〈{p = false}, {ao = true}, {p = true}〉〈{p = true}, {ao = false}, {p = true}〉〈{p = true}, {ao = true}, {p = true}〉

correspond to interpretations of σ1

0 : {p = false} ∪ 0 : {ao = false} ∪ 1 : {p = false}0 : {p = false} ∪ 0 : {ao = true} ∪ 1 : {p = true}0 : {p = true} ∪ 0 : {ao = false} ∪ 1 : {p = true}0 : {p = true} ∪ 0 : {ao = true} ∪ 1 : {p = true}

which are the models of causal theory AD1.


5.1.5 Transition Systems, Paths, Plans and Goals

The material provided in this section is quite standard and its definition is based on[Lifschitz & Ren, 2004]. The transition system defined by an action description Dbased on a multivalued propositional signature σ, is formally represented as ΣD =〈S, E, Tr〉, where:

• S is the set of states of D;

• E = I(σa) is a set of transitions labels (called events);

• Tr ⊆ S × E × S is the set of transitions of D.

We say that an event ε is

• executable in state s if there is at least one tuple 〈s, ε, s′〉 ∈ Tr;

• deterministic in state s if there at most a state s′ such that 〈s, ε, s′〉 ∈ Tr.

A path π of length n ≥ 0 is a sequence

〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉such that s0, s1, . . . , sn−1, sn ∈ S, ε0, . . . , εn−1 ∈ E, and 〈si, εi, si+1〉 ∈ Tr fori = 0, . . . , n − 1. Sometimes there is a distinguished set S0 ⊆ S of initial states,which we can think to be specified by a fluent formula φI of the language L built onσ. Thus, all paths are defined so that their first state s0 ∈ S0. If there is a single initialstate, i.e., S0 = {s0}, then the set of all paths in ΣD is seen as a tree rooted in s0.

A plan is a finite sequence of events

〈ε0, . . . , εn〉where n ≥ 0, labelling the edges of ΣD. The length of of the plan is n+1. An emptyplan, denoted as 〈〉, is characterized by a length equal to 0, i.e., it does not containany event. We now provide the definition of executability of a plan in a given state.The definition is given recursively on the length of the plan.

• The empty plan 〈〉 is executable in any state;

• A non empty plan 〈ε0, . . . , εn〉 n ≥ 0, is executable in state s0 if

(i) 〈ε0, . . . , εn−1〉 is executable in s0, and

(ii) for any states s1, . . . , sn such that 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉 is apath in ΣD, there exists a state sn+1 such that 〈sn, εn, sn+1〉 ∈ Tr.

A goal is (partially) described by a fluent formula φG of the language L built on σ.φG specifies a set SG ⊆ S of goal states. We say that a plan 〈ε0, . . . , εn−1〉 is


• sufficient for achieving the goal φG in a state s0, if for any states s1, . . . , sn

such that 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉 is a path in ΣD, we have sn |= φG;

• valid for achieving the goal φG in state s0, if it is executable and sufficient forachieving φG in s0.

We now show how some problems of reasoning about actions, namely prediction,postdiction, and planning, can be formulated. Let φI , φG be two fluent formulas, andα0, . . . , αn−1 n action formulas.

Prediction. φI holds initially; a sequence of events of type α0, . . . , αn−1 happen.For any path of length n ≥ 0 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉 in ΣD such that s0 |=φI , εi |= αi for i = 0, . . . , n− 1, verify if sn |= φG.

Postdiction. A sequence of events of type α0, . . . , αn−1 happens; φG holds cur-rently. For any path of length n ≥ 0 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉 in ΣD such thatsn |= φG, εi |= αi for i = 0, . . . , n− 1, verify if s0 |= φI .

Planning. s0 |= φI . Find a valid plan for achieving φG in s0.

5.1.6 Reasoning about Actions

Action languages define labelled transition systems, whereas query languages stateassertions about these transition systems. Queries are evaluated by means of an en-tailment relation that characterizes the action language. This relation can be used toformulate various kinds of reasoning tasks.

With regards to C+, we introduce two types of queries: queries on states whichare used to verify whether a given formula holds in a state of the labelled transitionssystem; and time-stamped queries which are used to verify whether a formula holdson paths of the labelled transition system. Consider an action description D basedon a multivalued propositional signature σ = σf ∪ σa. Let ΣD = 〈S,E, Tr〉 be thelabelled transition system defined by D. In the following, we define the entailmentrelation for both kinds of queries discussed so far. This relation is denoted as |=D

in order to distinguish it from the satisfaction relation |= defined for the language Lbuilt on σ.

Queries on States. They are expressions of the form [α]φ, where α is an actionformula of L and φ is a fluent formula of L. [α]φ is intended to express that φ holdsin every state resulting from a transition induced by an event of type α. For such kindof queries, we define the entailment relation as follows.

ΣD, s |=D [α]φ iff s′ |= φ for every s′ such that 〈s, ε, s′〉 ∈ Tr and ε |= α.


We can generalize the form of these queries by allowing expressions of the form[α0, . . . , αn−1]φ, where α0, . . . , αn−1 are action formulas. Thus,

ΣD, s |=D [α0, . . . , αn−1]φ iff for every path 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉of ΣD such that s0 = s and εi |= αi for i = 0, .., n− 1, we have that sn |= φ.

Time-stamped Queries. These kind of queries are expressions of the query lan-guage supported by the tool CCALC. They are used to express properties of paths ofsome specified length m ≥ 0 of ΣD. The query language of CCALC is obtained fromthe language L of signature σ, and consists of the following type of formulas

• time-stamped fluent atoms (i : f = v), where i = 0, . . . , m and f = v is afluent atom of L;

• time-stamped action atoms (i : a = v), where i = 0, . . . , m − 1 and a = v isan action atom of L;

• time-stamped formulas (i : ψ), obtained from the formula ψ of L by replacingevery constant c in ψ with (i : c).

Consider a path π = 〈s0, ε0, s1, ε1, . . . , sm−1, εm−1, sm〉 of length m in ΣD. Wedenote the ith component of π as π[i] = si ∪ εi. Clearly, π[i] is an interpretation ofσ when π is a path of ΣD. Observe that, π[i] |= φ iff si |= φ for all fluent formulasφ; π[i] |= α iff εi |= α for all action formulas α. Thus, given a formula ψ of L, let(i : ψ) be the query obtained by time-stamping every constant in ψ with i. For suchkind of queries, we define the entailment relation as follows. For any path π of lengthm ≥ of ΣD

ΣD, π |=D (i : ψ) iff π[i] |= ψ for 0 ≤ i ≤ m.

Definite Action Descriptions.

Time-stamped queries are formulas of signature σm, which is also the signatureof the causal theory ΓD

m. This fact suggests that, for a definite action descriptionD, a formula µ of the query language can be evaluated by finding the models ofComp(ΓD

m) ∪ {µ}. This is the basic operation that CCALC does: the action de-scription D is first translated into the causal theory ΓD

m by using a macro expansionmechanism based on the rules of table 5.1, and then into the set of propositional for-mulas Comp(ΓD

m) by using the literal completion procedure. The models of formulasComp(ΓD

m) ∪ {µ} which correspond to paths of the transition system described byD that satisfy the property µ, are found by running SAT solvers.

We can now formulate the problems prediction, postdiction, and planning, fordefinite action descriptions. Let ΣD be the transition system defined by a definiteaction description D based on the signature σ, φI , φG two fluent formulas of L, andα0, . . . , αn−1 action formulas of L.


Prediction. We have to verify that

ΣD, π |=D (n : φG)

for any path π = 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉 in ΣD such that π[0] |= φI , π[i] |=αi for i = 0, . . . , n− 1. That is, we want to know whether

Comp(ΓDn ) |= (0 : φI) ∧ (0 : α0) ∧ . . . ∧ (n− 1 : αn−1) → (n : φG)

Hence, we need to check whether

Comp(ΓDn ) ∪ [(0 : φI) ∧ (0 : α0) ∧ . . . ∧ (n− 1 : αn−1) ∧ ¬(n : φG)]

is unsatisfiable.

Postdiction. We have to verify that

ΣD, π |=D (0 : φI)

for any path π = 〈s0, ε0, s1, . . . , sn−1, εn−1, sn〉 in ΣD such that π[n] |= φG, π[i] |=αi for i = 0, . . . , n− 1. That is, we want to know whether

Comp(ΓDn ) |= (0 : α0) ∧ . . . ∧ (n− 1 : αn−1) ∧ (n : φG) → (0 : φI)

Hence, we need to check whether

Comp(ΓDn ) ∪ [(0 : α0) ∧ . . . ∧ (n− 1 : αn−1) ∧ (n : φG) ∧ ¬(0 : φI)]

is unsatisfiable.

Planning. For j = 0, 1, . . . up to some specified maximum value n, we have toverify if there exists a plan 〈ε0, . . . , εj〉 such that

ΣD, π |=D (j + 1) : φG

for every path π = 〈s0, ε0, s1, ε1, . . . , εj , sj+1〉 of ΣD such that π[0] |= φI . That is,for j = 0, 1, . . . up to some specified maximum value n, we verify whether

Comp(ΓDj+1) ∪ [(0 : φI) ∧ (j + 1 : φG)]

is satisfiable. If satisfiable, a SAT solver will return all models. These models containa representation of the plan 〈ε0, . . . , εj〉.


5.1.7 The Causal Calculator (CCALC)

The Causal Calculator (CCALC) is a system that answers queries about actiondomains described in the “definite” fragment of the action language C+. The originalversion of this tool has been written by McCain as part of his Ph.D. dissertation.The system has been extended by Lee as part of his Ph.D dissertation, and now ismaintained by the Texas Action Group at Austin. It can be downloaded from itshome page [TAG at Austin, CCALC].

A CCALC input file consists of declarations, action laws in the sense of C+ (ormore often, schemas with metavariables whose instances are causal laws), queriesspecifying reasoning problems (e.g, planning problems) and comments. Computa-tionally, to answer such queries CCALC turns definite action descriptions first intodefinite causal theories and then into a propositional theory by literal completion.Afterwords, it call SAT solvers to find the models of the propositional theory, whichin turn correspond to the models of the causal theory, and so to paths in the transi-tion system. The tool has been implemented so that it can use several SAT solvers:GRASP, mChaff, relsat, SATO, Satz, Satz-rand, WalkSAT, zChaff. By default, it callsmChaff and instructs it to stop as soon as one solution has been computed. By theway, it is always possible to change this option and chose a different solver, amongthe ones available.

5.2 Describing and Reasoning About Web Services with C+

In this section, we present our basic approach for describing and reasoning aboutWeb services with the action language C+.

We consider a Web service as a “black-box” software artifact with an input in-terface and an output interface, that interacts with its clients (which can be in turnother Web services). An interaction consists of a client invoking a service and wait-ing for the fulfillment of the invoked task along with its output. We are interested inthe description of the changes in the world induced by the invocation of a service.To this purpose, we distinguish between atomic and composite services. Atomic ser-vices are described as actions that have preconditions and effects. The preconditionsspecify under which conditions the service is applicable, and the effects describe theresults of its execution. We assume that composite services are sequences of atomicservices. Observe that, our vision of services resembles OWL-S process model. Infact, atomic services in our approach correspond to atomic processes in OWL-S,which are directly invokable and executable in a single-step (from the perspective ofthe service requester), whereas our composite services correspond to composite pro-cesses in OWL-S. The set of all atomic services constitutes the service community.Services in the community are available to the client and are defined once for all.

Web service composition addresses the situation when a client request cannot be

5.2. Describing and Reasoning About Web Services with C+ 135

satisfied by a single atomic service, but can be satisfied by suitably combining atomicservices of the community. Therefore, we assume that the client request is processedby a composer agent which is in charge of determining how to compose the availableservices in order to fulfill the request. In such a context, the composer agent has tosolve a planning task: given the client request and a description of the community ofavailable atomic services, it has to build a plan representing the sequence of atomicservices whose execution in the given order satisfies the client request.

We start by assuming that the composer agent has complete knowledge about theenvironment in which atomic services have to be executed. We exploit the expres-siveness of C+ to represent several aspects of service execution and interaction. Inparticular, the service community is described by a definite action description thatspecifies the possible behaviors of each atomic service in the community. Hence, thecomposition problem is described as a planning tasks, and so it is formally specifiedby means of the entailment relation that characterizes the action language C+. Thecomposition problem is then solved by using the tool CCALC, which synthesizes thecomposite service.

Observe that, due to the nature of Web services the assumption of completeknowledge is unrealistic. In fact, the composer agent has to deal with incompleteinformation and acquire the needed information to solve the composition problem.Incomplete information may be in the description of the initial situation, or in thedescription of the service community (e.g., not all possible execution scenarios areknown). These aspects suggest that we should modify our framework in order tomodel not only the changes in the world but also in the mental state of the composeragent. As a first attempt to investigate complex scenarios involving incomplete in-formation, in Section 5.4 we discuss how the action language framework should beextended for dealing with actions that explicitly affect knowledge. Specifically, wepropose a new action language KC+, which generalizes the action language C+ byintroducing epistemic modalities in the underlying logic to distinguish what is knownabout the world from what is unknown. By combining epistemic logic and the ac-tion language C+, we create a simple tool which could be used for describing theadditional aspects of Web services concerning information providing and gathering.Perspectives on future research directions are further discussed in Chapter 6.

5.2.1 Description of Web Services

For simplicity, we concentrate on ground atomic services, i.e., atomic services wherethe input parameters have already been instantiated by individual names. Parametricatomic services, which contains variables in place of individual names, are to beconsidered a compact representation of all their ground instances. Parametric atomicservices are referred henceforth as simply atomic services.

We start by choosing a multivalued propositional signature σ, composed by twodisjoint sets of symbols called fluents and action constants, respectively. Fluents


represent all relevant aspects of the application domain and describe the state of theworld. They are not necessarily boolean. Instead, we restrict our attention on booleanaction constants which represent atomic services. Services are characterized by pa-rameters. The reader familiar with C+ knows that action constants can be parame-terized by introducing variables. Variables range over finite sets of objects of somesorts. In a step called “grounding”, the tool CCALC replaces each variable with ev-ery object in the range of the corresponding sort. Therefore, we describe an atomicservice as a boolean action constant a(

→x), where

→x are variables denoting the ser-

vice parameters. Actually, a(→x) has to be treated as representing a parametric atomic

service. Ground atomic services are obtained by replacing each variable with everyobject of the corresponding sort. As an example, consider an on-line Bookstore ap-plication. Clients accessing the bookstore can buy books, which are chosen from agiven catalogue. Books in the catalogue are identified by their titles. We may imaginethat the on-line Bookstore application provides several services to its customers. Oneof these services is the atomic service buyBook which allows to buy a book chosenfrom the catalogue. In our framework, this service is represented as

buyBook(bookT itle)

where buyBook is a boolean action constant of a certain signature σ, and bookT itleis a variable name denoting an object of a sort of possible books to purchase (allbooks listed in the catalogue).

In general we deal with many atomic services Wi (i = 1, . . . , n). For eachWi, we are given its description Di which is a set of propositions of C+ describ-ing the preconditions and the effects of the service. Recall that, in C+ propositionscontaining variables are treated as schemas describing finite set of propositions thatare formed according to the same pattern. As before, the grounding of the propo-sitions of Di has to be considered a description of ground instances of the atomicservice Wi. Furthermore, the service descriptions Di are assumed to be definite ac-tion descriptions. We focus on definite action descriptions because they are widelyapplicable, but more importantly because we want to use the tool CCALC to test ourformalizations. In fact, even though non definite action descriptions would yield tomore natural formalizations, they have not yet been implemented in CCALC. The setof available atomic services C = {W1, . . . ,Wn} forms a community which can bedescribed by the definite action description DC obtained by taking the union of theservice descriptions Di, i.e., DC = D1 ∪ · · · ∪Dn.

The language C+ is very expressive and allows us to specify in an elaborationtolerant2 manner several aspects of services behavior and interaction (actually, the

2McCharty [1998] called elaboration tolerance the quality that human-level AI should require. He

said: “A formalism is elaboration tolerant to the extent that it is convenient to modify a set of facts

expressed in the formalism to take into account new phenomena or changed circumstances. [..] Human-


subset of C+ implemented in CCALC). In what follows we detail our approach. Ob-serve that causal laws are written by making use of the abbreviations provided forC+. Such abbreviations are only syntactic sugar that make the description of actiontheories more compact. The detailed list of abbreviations along with their generalform is given in Appendix B.

Preconditions. Atomic service preconditions are described by fluent dynamic lawsof this form

nonexecutable a(→x) if ϕ

where ϕ is a fluent formula, eventually containing the variables→x within its ar-

guments. This proposition expresses the fact that the atomic service a cannot beexecuted in a state satisfying ϕ. For example, consider again the atomic servicebuyBook(bookT itle). A book can be purchased if it is in the catalogue. Hence, thepreconditions of the buyBook(bookT itle) service are described as follows

nonexecutable buyBook(bookT itle) if ¬inCatalogue(bookT itle)

where inCatalogue(bookT itle) is a boolean fluent descrbing whether a book is inthe catalogue.

Effects. Non-conditional atomic service effects can be described by laws of thistype

a(→x) causes φ

where φ is a fluent formula that may contain the variables→x within its arguments.

The formula φ characterizes the conditions that must result after the execution of theatomic service a. For instance, an effect of the atomic service buyBook(bookT itle)is to have the book. This can be be expressed as

buyBook(bookT itle) causes ownBook(bookT itle)

where ownBook(bookT itle) is a boolean fluent which states whether we possess thebook, after buying it.

level AI will require representations with much more elaboration tolerance than those used by present

AI programs, because human-level AI needs to be able to take new phenomena into account.” Mc-

Charty illustrated this idea by defining 19 variants of the Missionaries and Cannibals problem. When

humans are told about these elaborations, they understand the changes using their background knowl-

edge expressed in natural language without having to start from scratch. The input language of CCALC

is elaboration tolerant. Liftschitz [2000] has formalized 10 of the 19 variants of the Missionaries and

Cannibals proposed by McCharty, by factoring out the common part and by adding for each variant a

few propositions that express the changes, without starting from scratch.


Conditional Effects. An atomic service may have different effects on the envi-ronment, depending on the state in which is executed. In this case, we talk aboutconditional effects. Such effects can be expressed by laws like the following

a(→x) causes φ if ϕ

where φ and ϕ are fluent formulas, eventually containing the variables→x within their

arguments. These laws state that φ characterizes the effect of executing the atomicservice a in a state satisfying ϕ. As an example, suppose that in our bookstore domainpurchasable books are those that are listed in the catalogue, but the shipping can beexecuted only if there are copies available in the stock of the bookstore. Otherwise,the book can be ordered and the shipping is delayed until the stock is refilled. Thereservation of the book when it is not in the stock, can be considered as a conditionaleffect of the atomic service buyBook(bookT itle). It is therefore expressed by thefollowing proposition

buyBook(bookT itle) causes reservedBook(bookT itle) if ¬inStock(bookT itle)

where reservedBook(bookT itle) is a boolean fluent denoting the reservation of thebook, and inStock(bookT itle) is a boolean fluent stating whether there are availablecopies of the book in the stock.

Nondeterministic Effects. In a general setting, atomic services may have nonde-terministic effects. These are easily represented in C+ by means of laws of type

a(→x) may cause φ if ϕ

where φ and ϕ are two fluent formulas that may contain the variables→x . In this

way we state that φ characterizes a possible effect of the atomic service a. Consideragain the on-line Bookstore. From time to time, the owners of the bookstore organizespecial promotions for new books of an author. If the promotion is active, to all thosecustomers that buy a book, it may send for free a copy of the new latest book writtenby the same author. We can model this situation by considering the effect of sending anew book to costumers whenever there is a promotion, as a nondeterministic effect ofthe atomic service buyBook(bookT itle). Such effect is expressed by the followingproposition

buyBook(bookT itle) may cause ownBookForFree(bookT itle1) ifbookT itle1 6= bookT itle ∧ author(bookT itle1) = author(bookT itle) ∧newBook(bookT itle1, author(bookT itle)) ∧ promotion(author(bookT itle))

where bookT itle1 is a variable that denotes an object of a sort of available booksin the catalogue, ownBookForFree(bookT itle1) is a boolean fluent which stateswhether we are given a book for free, author(b) is fluent constant whose domain


is the set of author names registered in the catalogue (its value is the name of theauthor of the book b), newBook(n, b) is a boolean fluent describing whether thebook b is the latest new book written by author n, and promotion(n) is a booleanfluent constant stating whether the promotion is active for the author n. Observe that,the proposition above has been written by making use of a feature of the languageaccepted by CCALC. In fact, the argument of constants are supposed to be eitherobjects or variables. When a constant appears as an argument of another constant,the former is understood as the value of the constant. For instance

newBook(bookT itle1, author(bookT itle)) ∧ promotion(author(bookT itle))

has the same meaning as

newBook(bookT itle1, authorName) ∧ author(bookT itle) = authorName∧promotion(authorName)

Ramifications. The causal laws used so far allow us to describe the direct effectsof an atomic service execution in a given state. However, the execution may haveindirect effects in a particular state. Ramification effects are usually derived from theset of fluents, and they can be used to specify which are the valid states of the domain,as well as the valid transitions among those states. Ramifications in C+ can be easilyexpressed by means of static laws

caused φ if ϕ

where φ and ϕ are fluent formulas. The intuitive meaning is that is any state in whichϕ holds, we can infer that φ holds too. Observe that, if ϕ appears in the head of fluentdynamic laws as characterizing a direct effect of an atomic service, then φ has to beseen as characterizing an indirect effect of the service execution. Consider for ex-ample, the atomic service buyBook(bookT itle). As we have seen before, one of itsdirect effects is to make the client to have the book (ownBook(bookT itle) = true).However, having the book implies also that the client has payed for it an amount ofmoney corresponding to its price. Such an indirect effect is easily represented by thefollowing proposition

caused payed(price(bookT itle)) if ownBook(bookT itle)

where payed(p) is a boolean fluent denoting the payment of an amount of money pand price(bookT itle) is a fluent whose domain is a set of positive numbers repre-senting prices. As before, we have used the fluent price(bookT itle) as an argumentof payed(p) to denote the price of the book identified by bookT itle.


Defeasibility and Exceptions. In real scenarios, it is often the case that exceptionalsituations happen during the execution of a service. Some of these situations are un-expected, some others are expected. The former correspond to executional scenariosto which the service is unable to react. The latter correspond to executional scenar-ios which are not desirable but may happen. The action language C+ cannot dealwith unexpected exceptions but it allows, to a certain extent, to manage expectedexceptions by means of defeasible causal laws. In particular, we can model situa-tions in which the execution of an atomic service is unsuccessful by using laws of thefollowing type

a(→x) causes φ if ψ unless b(

→y )

which is obtained by appending to the laws describing the effects of the atomic ser-vice a, the expression unless b(

→y ), where b is a boolean action constant and

→y are its

parameters that may/may not include the parameters→x . The boolean action constant

b is used to specify when the execution of service a is unsuccessful. Then, excep-tional situations are described by enhancing the domain description with action lawsof the following type

caused b(→y ) if ζ

where ζ is a fluent formula characterizing the exceptional situation that make theservice a unsuccessful. Observe that, the action constant b cannot be declared asexogenous, i.e., the cause for its execution is described in the action description bymeans of the action dynamic laws above. To clarify these concepts, consider again theexample of the on-line Bookstore. It may happen that the purchase of a book cannotbe processed because the connection reaches a time-out. Such situations occur whenthe client waits too much before choosing a book from the catalogue. Therefore, wemodify the description of the service buyBook(bookT itle) in the follwoing way

buyBook(bookT itle) causes ownBook(bookT itle) unless abortcaused abort if connectionT imedOut

where abort is a boolean action constant and connectionT imedOut is a booleanfluent stating whether a time-out occurs. The second law above describes whenthe atomic service buyBook(bookT itle) is unsuccessful, i.e., when the connectionreaches a time-out. The boolean fluent connectionT imedOut may be a direct or anindirect effect of another atomic service in the community. Therefore, its cause isdescribed by means of static/dynamic fluent laws.

Coordination and Concurrency. The set of causal laws discussed above specifiesthe effects of executing a particular atomic service in any particular state. In somedomains, we may need to impose some restrictions on the concurrent execution of


atomic services, and we may need to specify the control flow among service execu-tion, i.e., how atomic services are to be sequenced and coordinated in order to achievea desired goal. Restrictions on the concurrent executions of some atomic services areeasily expressed by means of laws of this type

nonexecutable a1(→x1) ∧ . . . ∧ ak(

→xk)

where ai(→xi) i = 1, .., k are boolean action constants representing some atomic ser-

vices in the community. The above propositions are meant to prevent the concurrentexecution of all services ai for i = 1, .., k in any state. Control flows rules can beexpressed by means of action laws of this type

caused a(→x) if ϕ

where a(→x) is a boolean action constant describing an atomic service and ϕ is a

fluent formula, that may contain the variables→x within its parameters. Such laws

specify some conditions on the atomic service a that have to be tested against thestate of the environment, i.e., the atomic service a is executed in all those states inwhich ϕ holds. The action constant a cannot be declared exogenous. The causefor its execution is specified by the law above. For example, consider again theon-line Bookstore application. Suppose that the application offers another serviceselectBook that allows a client to select a book from the catalogue. The descriptionof this service is given below, where for simplicity we have assumed that this servicehas no preconditions and only one effect, e.g., the selection of the book.

selectBook(bookT itle) causes selectedBook(bookT itle)

It obvious that clients cannot select and buy books concurrently. This means that weneed to impose some restrictions on the concurrent execution of the service buyBook

and service selectBook. Moreover, clients can buy books only after selecting themfrom the catalogue. This implies that the service buyBook can be executed after theselection has been done by means of the service selectBook. All these constraintscan be represented by the following rules

nonexecutable selectBook(bookT itle) ∧ buyBook(bookT itle)caused buyBook(bookT itle) if selectedBook(bookT itle)

Client Request. The client request imposes some requirements on the composition.Often it involves complex conditions on the behavior of the composite service andnot only on its final state. For the sake of simplicity, here we assume that these re-quirements are represented as simple goals, i.e., they specify the properties that musthold in desired states of the world (goal states). We denote as φG the specificationof the client request. Such a specification is given in terms of a fluent formula whichis a conjunction of fluent atoms of the signature σ that (partially) describe desired


states of the world. For example, let us consider the on-line Bookstore application.Suppose that a client access the bookstore web site because it wants to buy a bookentitled I Love Shopping. This simple goal can be represented as follows.

ownBook(ILoveShopping)

Initial State. We denote as φI the specification of the initial state in our formaliza-tion. Such a specification is given in terms of a fluent formula which is a conjunctionof fluent atoms of the signature σ. Since we have assumed to have complete knowl-edge, φI specifies the value for each fluent of σ in the initial situation. For example,in our on-line Bookstore the initial state may be described as follows.

inCatalogue(TheDaV inciCode) ∧ auhtor(TheDaV inciCode) = DanBrown∧inCatalogue(ILoveShopping) ∧ inCatalogue(ILoveShoppingForBaby)∧author(ILoveShopping) = Kinsella ∧ author(ILoveShoppingForBaby) =Kinsella ∧ newBook(ILoveShoppingForBaby, Kinsella)∧promotion(Kinsella) ∧ · · ·

5.2.2 Composition of Web Services

Given a multivalued signature σ and the language L built on it, let DC be a defi-nite action description based on σ describing a community of atomic services C ={W1, . . . , Wn}, φI and φG be two fluent formulas of L expressed as conjunctions offluent atoms. The Web service composition problem can be formulated as follows.

Given the description of the service community DC , the specification φI of the initialstate and the specification of the client request φG, there exists a composite serviceW that fulfill the client request φG iff there is a sequence of atomic services from thecommunity such that its execution leads to a desired state in which φG holds.

Let ΣDCbe the transition system defined by the action description DC . In our frame-

work, the Web service composition problem is captured by the following reasoningproblem.

For j = 0, 1, . . . up to some specified value m ≥ 0, verify if there exists a plan

〈a0, . . . , aj〉 such that

ΣDC, π |=DC

(j + 1) : φG

for every path π = 〈s0, a0, s1, a1, . . . , aj , sj+1〉 of ΣDCsuch that π[0] |= φI . The

action constants ai in the plan are representative of the atomic services that constitutethe composite service.

5.3. Example: The On-line Municipal Agency 143

Note that, the description of the service community in terms of a definite action de-scription and the above characterization of the composition problem in terms of areasoning task in C+, allow us to reduce the composition problem to the problem ofsatisfying a set of propositional formulas. This set of formulas is obtained by exploit-ing the translation of definite action descriptions to definite causal theories and thecompletion procedure described in [Giunchiglia et al., 2004]. This implies also thatwe can to use the tool CCALC for finding the solution to the problem and synthesizinga composite service for the client request. The composition problem can have mul-tiple solutions, which are thought as different branches of a more general plan. Allthese solutions can be obtained by instructing CCALC with appropriate parameters.In the next section we illustrate our approach with a simple example.

5.3 Example: The On-line Municipal Agency

The example reported here is an elaboration of the example given in [Baader et al.,2005], where the same Web service scenario has been analyzed but with DescriptionLogics [Baader et al., 2003]. The purpose of this section is to exemplify our ideasand clarify additional aspects of service description in C+.

Let us suppose that the local administration of a small town has developed an ap-plication that provides several services for people moving to live in town, through theWeb. New citizens can, for example, get a contract with an electricity provider, opena bank account, and apply for child benefit. For simplicity, suppose that these are theonly services available within the application. Each of them is deployed on the Webas an atomic service: getElectricityContract(c,e), openBankAccount(c,a),askChildBenefit(p,c). Moreover, let us suppose that: obtaining an electricity con-tract with an electricity provider does not involve any preconditions; opening a bankaccount is possible if the customer is eligible for a bank account and posses a proofof address; citizen can apply for child benefits only if they have a bank account. Sup-pose now that John is Mary’s father. He moves to live in town. He wants to get thechild benefits for Mary. Our goal is to show how this domain can be formalized in ourframework, and that given John’s request, it is possible to compose the three servicesof the application in order to fulfill his request in an automated fashion.

Domain

We provide and comment a sketch of the domain description for the example underconsideration. We use the syntax accepted by the tool CCALC. The domain descrip-tion begins with a set of declaration for sorts, objects, variables and (fluent and action)constants. Since CCALC is written in Prolog, the syntax follows the Prolog traditionof capitalizing the variables. Sorts are names for finite sets. Variables take values


from the set of the corresponding sort. Constant declarations define fluent and actionsymbols, along with the values to which symbols can be mapped. The set of values isspecified in parentheses. If nothing is specified the constant is declared as boolean.

:- sorts

citizens; eContracts; bAccounts.

:- objects

john, mary, lucy, mark, jack, kate :: citizens;

ec1, ec2, ec3 :: eContracts;

b1,b2, b3 :: bAccounts.

:- variables

C,P :: citizens;

E :: eContracts;

A :: bAccounts.

:- constants

holdEContract(citizens,eContracts),

holdBAccount(citizens,bAccounts),

resident(citizens),

receiveCBenefit(citizens,citizens) :: inertialFluents;

parent(citizens) :: inertialFluents(citizens);

holdAddress(citizens),

eligibleForBank(citizens) :: sdFluent;

getEContract(citizens,eContracts),

openBAccount(citizen,bAccounts),

askCBenefit(citizens,citizens) :: exogenousAction;

In our example, all constants in the signature are boolean except for parent whosedomain is the set of citizens. The symbol inertialFluent is used to declare inertialfluents: the identifier instructs CCALC to declare the fluent and to postulate that thisfluent is inertial (i.e., the declaration has the same meaning as the declaration f ::

simpleFluent accompanied by the static law inertial f); sdFluent is used todeclare statically determined fluents; exogenousAction is used to declare an actionconstant exogenous: the identifier instructs CCALC to declare the action constant andto postulate that this action constant is exogenous (i.e., the declaration has the samemeaning as the declaration a :: action accompanied by the action dynamic lawexogenous a).

5.3. Example: The On-line Municipal Agency 145

Domain constraints are specified by static laws and express background knowledgeabout the domain. For example, the following domain constraints are on the relationbetween parents and children (which is irreflexive and not symmetric), where thesymbol \= stands for 6=, and ->> for →. The symbol % precedes comments.

% parent relation irreflexive and not symmetric.

constraint parent(C) \= C.

constraint parent(C)=C1 ->> parent(C1) \= C.

...

The formalization of the example also includes the description of a specific smalltown. This description is given by using static laws whose if part is >. In this casethe laws are abbreviated by simply writing the caused part. For example, in thefollowing we sketch a description of our small town.

% the resident citizens of our small town.

caused resident(lucy).

caused resident(mark).

caused resident(jack).

caused resident(kate).

....

% John is Mary’s father

caused parent(mary)=john.

Here is the description of the service community. In the following, the symbol -stands for ¬, and ++ stands for ∨.

% obtaining an electricity contract with an electricity provider

% does not involve any preconditions.

getEContract(C,E) causes holdEContract(C,E).

% opening a bank account is possible if the customer is eligible for

% a bank account and posses a proof of address.

openBAccount(C,A) causes holdsBAccount(C,A).

nonexecutable openBAccount(C,A)


if -eligibleForBank(C) ++ -holdsAddress(C).

% resident citizens are eligible for a bank account.

caused eligibleForBank(C) if resident(C).

default -eligibleForBank(C).

% a citizen holds an address if it has an electricity contract.

caused holdsAddress(C) if holdsEContract(C,E).

% citizen can apply for child benefits only if they have

% a bank account.

askCBenefit(P,C) causes receiveCBenefit(P,C).

nonexecutable askCBenefit(P,C)

if parent(C)\= P ++ -holdsBAccount(P,A).

% concurrent execution of services is not allowed.

noconcurrency.

Observe that fluent eligibleForBank(C) is defined in terms of other fluents. Specif-ically, we specify that eligibleForBank(C) ≡ resident(c) by making the fluenteligibleForBank(C) statically determined and by including two static laws contain-ing eligibleForBank(C) in the head.

caused eligibleForBank(C) if resident(C).

default -eligibleForBank(C).

Also the fluent holdsAddress(C) is declared as statically determined fluent. It isrelated to the fluent holdsEContract(C,E) by the following static law which statesthat holdsAddress(C) is an indirect effect of getEContract(C,E).

caused holdsAddress(C) if holdsEContract(C,E).

default -holdsAddress(C).

We assume that all the atomic services must not be executed concurrently. The lan-guage of CCALC allows us to express this assumption concisely, simply by writingnoconcurrency.

5.4. Dealing with Incomplete Information 147

Composition Problem

We now specify in the language accepted by CCALC the composition problem. Weneed to describe the initial state (John moves to live in town with his family) and thegoal (John wants to receive the child benefits for his daughter Mary).

:- query

maxstep :: 1..100;

0: resident(john),

.....

maxstep: receiveCBenefit(john,mary).

Symbols 0: and 1..100: are time stamps: 0: describes the initial state; 1..100 inthe maxstep section instructs CCALC to first try to find a plan of length 1, then 2, 3,and so on until it finds a solution or fails after trying length 100. The goal is describedby the final symbol maxstep.

Testing with CCALC

To test our formalization, we run CCALC by giving in input the domain descriptionand the query specifying the planning problem, and we check if the result returned bythe tool match our expectations. In this case, CCALC has determined that the lengthof the shortest solution is 3. One of the possible output is

getEContract(john,ec1), openBAccount(john,b1), askCBenefit(john,mary)

By executing this sequence of atomic services, we reach a state in which fluentreceiveCBenefit(john,mary) is true.

5.4 Dealing with Incomplete Information

The approach described in previous sections assumes that the composer agent hascomplete knowledge about the world. However, in the context of the Web this sim-plifying assumption is unrealistic. In fact, as the set of available services grows verylarge (i.e., as we start using large repositories of heterogeneous services), and sinceeach service node is designed, owned, or operated by different parties, it is likely thatthe composer agent has to deal with incomplete information. By incomplete infor-mation we mean that the initial situation may not be completely specified and thatthe description of the service community may not be complete (e.g., not all possibleexecution scenarios are known). Therefore, the composer agent has to acquire the


information needed to solve the composition problem from external sources. In thissection, we discuss how we should modify our approach and we outline the exten-sions in order to deal with incomplete information. However, we emphasize that thiswork is preliminary. It represents a first step towards the definition of a more generaldeclarative method for describing and reasoning about Web services which will bematerial for future research.

Incompleteness in the initial state specification is straightforwardly representedby means of fluent formulas φI that specify an initial value for only some of thefluents in the signature σ. This means that, instead of dealing with a single initialstate we have to consider a set of possible initial states. As an extreme situation,the composer agent may not know anything about the initial state: the set of initialstates is represented by all possible combinations of values for every fluent of thesignature. From a theoretical point of view, composition problems involving partialspecification of the initial state can still be solved with our approach without mak-ing significant modifications. In fact, in this case it is required to reason about allpossible paths π in the transition systems ΣDC

defined by the service communitydescription DC that start in any possible initial state (π[0] |= φI ) and ends in anypossible goal state (π[j + 1] |= φG). The action sequences corresponding to thesepaths are representative of all possible compositions of atomic services in the com-munity that achieve the client request in any possible initial situation. Concerning theuse of CCALC, as stated in [Lee, 2005], although the current version of the tool cansolve prediction and postdiction problems with incomplete information, it does nothandle “conformant planning”, i.e., generating plans that are guaranteed to succeedwith incomplete conditions. Hence, as a practical contribution, we need to enhancethe tool with the ability to solve such problems.

Dealing with the second source of incompleteness, requires to be able to modelnot only the changes in the world but also the changes in the mental state of thecomposer agent. To that end, we need to extend our approach by allowing atomicservices to have knowledge preconditions and knowledge effects. Knowledge pre-conditions represent the information that the composer agent must know before itcan execute the atomic service. Knowledge effects represent the information that thecomposer agent is being told by the execution of the atomic service. Observe that,these additional features of services make our vision of Web service more coherentwith the OWL-S process model. In fact, knowledge preconditions and knowledgeeffects may be seen as corresponding to inputs and outputs properties of OWL-Satomic processes. However, these new aspects cannot be captured by the approachwe have proposed in the previous section. Although very expressive, the action lan-guage C+ cannot describe actions that affect the knowledge of an agent (see, again,[Lee, 2005]). Hence, we try to extend the representational capabilities of C+, w.r.tthis issue. The simplest and best known way of representing knowledge is to use anepistemic logic. Specifically, to distinguish what is known about the world from whatis unknown, we extend the action language C+ by introducing epistemic modalities


in the underlying logic. We obtain a new action language, called KC+, that could beused to represent and reason about Web service composition in scenarios involvingincomplete information. Concerning this last issue, we can only suggest some pos-sible research directions since this work is still in an early stage. The new languageand a discussion on how it can be exploited to extend our approach are the subject ofthe remaining sections of this chapter. Future perspectives and other improvementsof our proposal are discussed in Chapter 6.

5.4.1 Towards an Epistemic Extension of the Action Language C+

Action languages are high-level formalisms defined for reasoning about actions thatchange the state of the world. When dealing with incomplete information we mustconsider how the perception of the reasoning agent about the world, is changed by ac-tions execution. The epistemic capabilities of an agent are expressed through the no-tion of epistemic state, represented either explicitly as a set of states of the world con-sidered possible in a given situation, or implicitly by a modal operator K and formulasKφ. There are a number of proposals that extend existing action languages to dealwith incomplete information [Lobo, Mendez, & Taylor, 2001; Son & Baral, 2001;Eiter et al., 2003; Lukasiewicz, Nardi, & Rosati, 2004], most of which characterizethe agent’s epistemic state explicitly.

In this subsection, we discuss for proposal of an extension of the action lan-guage framework to handle incomplete information based on a modal approach. Weare interested in formalizing domains in which actions affect the agent’s knowledge,eventually without changing the state of the world. The main contribution of ourwork is the introduction of a new action language, called KC+, which generalizesthe language C+. Specifically, we extend the syntax of C+ with a modal operator Kand formulas of S5 epistemic logic. In defining the semantics of KC+, we rely ona model of dynamic system discussed in [Fagin et al., 2003]. Our global system iscomposed by a single reasoning agent and the world in which the agent acts and withwhich it interacts. At any point in time, the system is in a global state, described bya pair consisting of the state of the world and the agent’s epistemic state. The pro-gression of the global system by actions execution is specified in terms of transitionsbetween global states.

In the following, we briefly repeat the formal notions and notation of epistemiclogic. Then, we describe the language KC+, by extending the material provided inSection 5.1. Once more we emphasize that, while from the representation stand pointour formalism provides a rather rich framework, a number of issues still deservefurther investigation.


Epistemic Logic

We now provide a short introduction to epistemic logic (see [Balckburn, Rijek, &Venema, 2001; Hendricks, 2003], for details). Syntactically, the language of proposi-tional epistemic logic is obtained by augmenting the propositional logic with a unaryepistemic operator K. Kφ is read as the agent knows φ.

The semantic interpretation of the epistemic operator K, provided by Hintikka[1962], is known as the possible wold semantics: Kφ is interpreted as in all possibleworlds compatible with what the agent knows, it is the case that φ. The basic as-sumption is that the knowledge of the agent can be characterized in terms of a set ofpossible worlds. Each world represents one state of affairs considered possible, givenwhat the agent knows. To express the idea that for an agent a world is compatiblewith its information state (or is accessible from the situation in which the agent iscurrently in), we introduce a relation of accessibility on the set of possible worlds,denoted by R. If R holds between worlds w and w′, written as Rww′, we say thatw′ is accessible from w, and w′ is considered an epistemic alternative to w. Giventhe above semantical interpretation, if a proposition φ is true in all worlds which theagent considers possible, then the agent knows φ.

A possible world semantics for a propositional epistemic logic with a singleagent, consists of a frame F = 〈W,R〉, where W is a non-empty set of possi-ble worlds and R is a binary accessibility relation on W . A model M is a struc-ture 〈F , π〉: F = 〈W,R〉 is a frame; and π is a truth assignment function of typeπ : W → (F→ {true, false}) where F denotes a set of propositional constantswhich stand for basic facts about the world. Given a model M = 〈F , π〉,

• a propositional formula φ is said to be true in a world w (in M ), written as(M, w) |= φ, iff π(w)(φ) = true;

• the formula Kφ is true in a world w, written as (M,w) |= Kφ, iff ∀w′ ∈ W :if Rww′, then (M, w′) |= φ

• a formula φ is valid in M , written as M |= φ, if ∀w ∈ W : (M,w) |= φ.

We list in Table 5.2 some axioms usually considered interesting for epistemic logicwith their names (the nomenclature was first due to Lemmon [1977], and later refinedby Bull and Serberg [1994]). Combining them in a proper way, we obtain epistemicsystems of varying strength. Observe that, many important epistemic systems cor-respond to certain algebraic properties of the accessibility relation R in the frameF = 〈W,R〉. For instance, systems KT, KD, and K4 are determined by classesof structures in which the accessibility relation is reflexive, serial, and transitive, re-spectively. The S5 epistemic system, described in detail below, is characterized by anequivalence (reflexive, symmetric and transitive) accessibility relation. The intuitionis that two worlds are related by the accessibility relation if they are indistinguishableto the underlying agent.


Table 5.2: Common Epistemic Axioms

K K(φ → φ′) → (Kφ → Kφ′)

D Kφ → ¬K¬φ

T Kφ → φ

4 Kφ → KKφ

5 ¬Kφ → K¬Kφ

.2 ¬K¬Kφ → K¬Kφ

.3 K(Kφ → Kφ′) ∨K(Kφ′ → Kφ)

.4 φ → (¬K¬Kφ → Kφ)

S5 Epistemic System. The logic S5 consists of the following axioms and deriva-tion rules:

(A1) All propositional tautologies(A2) (Kφ ∧K(φ → ψ)) → Kψ knowledge is closed under logical consequence(A3) Kφ → φ known facts are true(A4) Kφ → KKφ an agent knows that it knows something(A5) ¬Kφ → K¬Kφ an agent knows that it does not know something(R1) ` φ, ` φ → ψ ⇒` ψ modus pones(R2) ` φ ⇒` Kφ necessitation

An S5-model is a structure M = 〈W,π〉 where W is a non-empty set, π is a truthassignment function of type W → (F→ {true, false}), such that for all m1,m2 ∈W : π(m1) = π(m2) ⇒ m1 = m2. We describe the knowledge of an agentusing the notion of epistemic state, which is represented as an S5-model. The setW is called the set of epistemic alternatives, all of which are considered as equallypossible by the agent.

Given M = 〈W,π〉, we define the relation M = 〈W,π〉 |= ϕ by induction onthe structure of the epistemic formula ϕ (assuming that |= has been defined for allsubformulas of ϕ. The π component of the structure gives us the information weneed to deal with the base case, where ϕ is a primitive proposition.

• (M, w) |= p, iff π(w)(p) = true for p ∈ F;

• (M, w) |= ¬φ iff (M, w) 6|= φ;

• (M, w) |= φ ∧ ψ iff (M,w) |= φ and (M, w) |= ψ;

• (M, w) |= φ ∨ ψ iff (M,w) |= φ or (M, w) |= ψ;


• (M, w) |= φ → ψ iff (M, w) 6|= φ or (M,w) |= ψ;

• (M, w) |= Kφ iff (M, w′) |= φ for all w ∈ W .

The Action Language KC+In what follows we extend the terminology and notation presented in Section 5.1.

Multivalued Epistemic Formulas. Consider a multivalued propositional signatureσ, the languageL built on it, and a unary modal operator K that satisfies S5 epistemiclogic. Our language LK of multivalued epistemic formulas is

γ ::= any formula ψ of L |Kγ | ¬γ | γ ∧ γ | γ ∨ γ | γ → γ.

We refer to formulas and atoms of L as objective formulas and objective atoms, re-spectively. For the sake of simplicity, we do not allow nested application of epistemicmodalities. Hence, in the scope of operator K there is an objective formula φ. For-mulas like Kφ are called epistemic atoms. By an epistemic formula we mean anypropositional combination of epistemic atoms: for instance K(φ1 ∧ φ2)∨¬K(¬φ3)is an epistemic formula, while φ1 ∧ Kφ2 is not. For convenience, we introduce anew modal operator S defined as

Sφdef= Kφ ∨ K¬φ.

Consequently,

¬Sφdef= ¬Kφ ∧ ¬K¬φ.

For objective atoms like c = v, we write S(c)def=

∨v∈Dom(c) K(c = v) and

¬S(c)def=

∧v∈Dom(c) ¬K(c = v). If c is a boolean constant, we write Sc =

Kc ∨K¬c, and ¬Sc = ¬Kc ∧ ¬K¬c.The signature σ is partitioned into a set σf of fluents and a set σa of action con-

stants. As for C+, by a fluent formula we mean a formula such that all constantsoccurring in it are fluents. An action formula is a formula that contains at least oneaction constant and no fluents. As a further restriction on the form of multivaluedepistemic formulas, we allow only objective fluent formulas in the scope of opera-tor K. This means that, in LK fluent formulas are either objective, epistemic, or acombination of both, whereas action formulas are necessarily objective formulas. Werefer to objective atoms like f = v where f ∈ σf , v ∈ Dom(f), as objective fluentatoms; objective atoms like a = v where a ∈ σa, v ∈ Dom(a) as objective actionatoms.

We now provide our language LK with a satisfaction relation. As far as objectiveformulas are concerned, we use the satisfaction relation defined for L. Concerning


epistemic formulas, we define a semantics based on possible world models. Sincewe rely on S5 epistemic logic, a structure M is a non-empty set of interpretations ofσ, M ⊆ I(σ). Intuitively, M contains the interpretations of σ considered as equallypossible by the reasoning agent in a given situation. The satisfaction of a formula ofLK by a structure M , for an interpretation of σ I ∈ M , is defined as follows:

• for ψ objective formula, (I,M) |= ϕ iff I |= ϕ;

• for φ objective fluent formula, (I, M) |= Kφ iff I ′ |= φ for all (I ′,M) ∈ M ;

• (I, M) |= ¬γ iff (I, M) 6|= γ;

• (I, M) |= γ ∧ δ iff (I,M) |= γ and (I, M) |= δ;

• (I, M) |= γ ∨ δ iff (I,M) |= γ or (I, M) |= δ.

• (I, M) |= γ → δ iff (I,M) 6|= γ or (I,M) |= δ.

If X is a set of formulas, (I, M) |= X stands for (I,M) |= γ for all γ ∈ X . We call(I,M) a model of X . Moreover, we write X |= γ to denote that (I, M) |= γ, forall models (I, M) of X . In this case, we say that the formula γ is entailed by the setX . When X ′ is a set of formulas of LK , X |= X ′ is a shorthand for X |= γ for allformulas γ ∈ X ′. Furthermore, since σ = σf ∪ σa and I = If ∪ Ia, it makes senseto state the following

• for any objective fluent formula φ, (I, M) |= φ iff (If ,M) |= φ iff If |= φ;

• for any objective action formula α, (I, M) |= α iff (Ia,M) |= α iff Ia |= α;

• for any objective fluent formula φ, (I, M) |= Kφ iff (If , M) |= Kφ.

Syntax of KC+. Consider a multivalued propositional signature σ and the corre-sponding language LK . An action description in KC+ is a set of causal laws, whichare of the same form as in C+, but with formulas of LK as their arguments. Specifi-cally, formulas appearing in the head of static causal laws (1) can be either objectivefluent formulas or epistemic formulas. In the first case, formulas appearing in thebody must be objective fluent formulas (this restriction is to avoid situations in whichknowing something could cause a real change in the world). In the latter case, for-mulas in the body can be of any type and the resulting rules can be used to expressindirect knowledge effects of actions. For example, a law like caused Kφ if Kϕ1∧ϕ2,where φ, ϕ1 and ϕ2 are objective fluent formulas, states that knowing that ϕ1 is truewhenever ϕ2 is true, implies knowing that φ is true.

Fluent dynamic laws (2) are used to express how the value of fluents and/or theagent’s knowledge are affected by actions. Formulas appearing both in the head andthe body of the rule can be either objective, or epistemic, or a combination of both.


Actions effects are specified through the formulas in the head of the rule. Onticeffects (affecting the environment’s state) are described by objective fluent formulas.Epistemic effects (affecting the agent’s epistemic state) are described by epistemicfluent formulas. We distinguish four types of epistemic effects:

• Kφ - gaining knowledge effects: the agent learns the truth value of φ;

• ¬Kφ - ignorance effects: the agent ignores the truth value of φ;

• Kφ ∨ K¬φ - sensing effects: the agent knows whether φ holds or not;

• ¬Kφ ∧ ¬K¬φ - forgetting effects: the agent forgets what it knows about φ.

Sensing and forgetting effects can be represented in a compact way using the operatorS introduced so far, as Sφ and ¬Sφ, respectively.

Finally, concerning action dynamic laws (3), formulas appearing in the head areobjective formulas, since action formulas are objective, and formulas in the body canbe of any type. Causal laws can be written using the abbreviations provided for C+,whose definition is extended here to KC+.

Definite Action Descriptions. As in the case of C+, action descriptions of pri-mary interest are those that are definite. They are defined by further restricting theunderlying language of multivalued epistemic formulas. Specifically, we allow epis-temic modalities to be used only in front of objective fluent atoms f = v. Hence,epistemic atoms are of the form K(f = v) or ¬K(f = v), and concerning the op-

erator S, we only admit epistemic formulas like S(f)def=

∨v∈Dom(f) K(f = v) or

¬S(f)def=

∧v∈Dom(f) ¬K(f = v).

An action description D of KC+ based on a signature σ, is definite if the follow-ing conditions hold (where f ∈ σf and v ∈ Dom(f)):

• the head of all static and fluent dynamic laws is either⊥, or an objective fluentatom, or an epistemic atom K(f = v) or ¬K(f = v), or an epistemic fluentformula S(f) or ¬S(f);

• the head of all action dynamic laws is either ⊥, or an objective action atom;

• no objective fluent/action atom, and no epistemic atom K(f = v) or ¬K(f =v), and no epistemic fluent formula S(f) or ¬S(f), is the head of infinitelymany laws of D.

Semantics of KC+. In our formalization, a dynamic system, also referred to asglobal system [Fagin et al., 2003], is composed by an agent and the world in whichthe agent acts and with which it interacts. At any instant of time, the global system is


in a global state, represented as a pair s = (senv, sk), where senv is the state of theworld (henceforth called environment state) and sk is the agent’s epistemic state.

The meaning of environment states and events have been discussed in Subsection5.1.1. Here they are represented in the same way. Since we rely on S5 epistemiclogic, an epistemic state is represented as the set of environment states that the agentconsiders as equally possible in a given situation. We assume that the knowledge ofthe agent is captured by its epistemic state sk. This knowledge can be incomplete (theagent may not know which world in sk is the real environment state), but is correct(the actual environment state is in sk). Thus, if Senv denotes the set of environmentstates, we define the set of global states as

S = {(senv, sk)| senv ∈ Senv, sk ⊆ Senv, senv ∈ sk} ⊆ Senv × 2Senv .

An action description D in KC+ consists of a set of propositions encoding how theglobal state of a global system changes through actions execution. Global state up-dates by action effects are characterized in terms of a uniqueness condition on envi-ronment components (as a direct application of the condition mentioned in [Giunchigliaet al., 2004]) and a minimal change criterion on epistemic components (which isbased on the theory of knowledge updates of [Baral & Zhang, 2005]).

In order to specify the transition function, we need to provide KC+ with a pos-sible world semantics, and with a notion of epistemic closeness between globalstates. Our formalization is based on S5 epistemic logic with a single agent. Apossible world semantics is defined straightforwardly. Consider two global statess = (senv, sk) and s′ = (s′env, s

′k). We say that s and s′ are indistinguishable to the

agent, and we write s ∼ s′, if sk = s′k. Intuitively, since the agent’s knowledge isdetermined by its epistemic state, the agent cannot distinguish between global stateswhich have different environment components. It is easy to verify that the relation∼is an equivalence on global states.

Recalling that environment states and events are interpretations of fluents andaction constants of the signature σ, respectively, and an epistemic state is a set ofenvironment’s states, we use the relation∼ to define an equivalence relation on I(σ),which is the set of interpretations of σ, and to provide an interpretation for formulas ofLK in global states. The structure M corresponds to the equivalence class generatedby an interpretation I of σ.

Definition 5.1 Consider two global states s = (senv, sk), s′ = (s′env, s′k), and an

event ε. The interpretations senv ∪ ε and s′env ∪ ε of σ, are equivalent if s ∼ s′. The

equivalence class generated by senv ∪ ε is [senv ∪ε] = {senv ∪ ε|senv ∈ sk} ⊆ I(σ).

Given ε, the set [senv∪ε] is uniquely identified by sk. Thus, without loss of generality

we write sk instead of [senv ∪ ε].


By Definition 5.1 and based on the observations given at the end of Subsection 5.1.1,it makes sense to state the following:

• for every objective formula ψ, (senv ∪ ε, sk) |= ψ iff senv ∪ ε |= ψ; if φ isan objective fluent formula, we write (senv, sk) |= φ, and if α is an actionformula, we write (ε, sk) |= α (event ε is said to be of type α);

• for every objective fluent formula φ, (senv, sk) |= Kφ iff senv |= φ for allsenv ∈ sk.

We now give a definition of epistemic closeness between global states.

Definition 5.2 Let s = (senv, sk), s1 = (senv1 , sk1), and s2 = (senv2 , sk2) be three

global states. We say that s1 is epistemically closer, or as epistemically close to s as

s2, denoted as s1 ¹ks s2 if one of the following conditions holds:

1. sk1 = sk2;

2. sk1 6= sk2 , and if sk ⊂ sk1 then (i) there exist some objective fluent formulas

φ and ϕ such that the following hold: (senv, sk) |= Kφ, (senv2 , sk2) 6|= Kφ,

(senv, sk) 6|= Kϕ, (senv2 , sk2) |= Kϕ; or (ii) for any objective fluent formula

φ if (senv, sk) |= Kφ and (senv1 , sk1) 6|= Kφ, then (senv2 , sk2) 6|= Kφ;

3. sk1 6= sk2 , and if sk1 ⊂ sk, then condition (i) above is satisfied, or (iii) for any

objective fluent formula φ if (senv, sk) 6|= Kφ and (senv1 , sk1) |= Kφ, then

(senv2 , sk2) |= Kφ;

4. sk1 6= sk2 , and if sk 6⊂ sk1 and sk1 6⊂ sk, then conditions (ii) and (iii) above

are satisfied;

5. sk1 6= sk2 and sk1 = sk.

We denote s1 ≺ks s2 if s1 ¹k

s s2 and s2 6¹ks s1.

A transition is denoted as a triple 〈s, ε, s′〉, where s = 〈senv, sk〉 is the initial global

state, and s′ = 〈s′env, s′k〉 the resulting global state when event ε occurs. Before

characterizing the semantics of an action description D in terms of transitions be-

tween global states, we need to provide some other definitions. Such definitions are

a natural extension of the notions given in Section 5.1 for C+.


Definition 5.3 A fluent formula γ is caused in a global state (senv, sk) if it is the

head of a static law caused γ if δ from D, such that (senv, sk) |= δ.

Definition 5.4 A fluent formula γ is caused in a transition 〈s, ε, s′〉, if it is either (i)

the head of a static law caused γ if δ from D, such that (s′env, s′k) |= δ, or (ii) the

head of a dynamic law caused γ if δ after η from D, such that (s′env, s′k) |= δ and

(senv ∪ ε, sk) |= η.

Definition 5.5 An action formula α is caused in a transition 〈s, ε, s′〉, if it is the head

of an action dynamic law caused α if γ from D, such that (senv ∪ ε, sk) |= γ.

Definition 5.6 A global state (senv, sk) is a global state of D if for all fluent formulas

γi caused in (senv, sk), (senv, sk) |=∧

i γi, and there does not exist another global

state s′ = (s′env, s′k) such that (s′env, s

′k) |=

∧i γi, and such that either (i) s′env 6=

senv or (ii) if s′env = senv then s′k ⊂ sk.

Definition 5.7 A transition 〈s, ε, s′〉 is causally explained according to D, if

• for all objective action formulas αi caused in 〈s, ε, s′〉, ε |= ∧i αi, and there

does not exist another ε′ 6= ε such that ε′ |= ∧i αi; and

• for all fluent formulas γi caused in 〈s, ε, s′〉, (s′env, s′k) |=

∧i γi, and there does

not exist another global state s′′ = (s′′env, s′′k) such that (s′′env, s

′′k) |=

∧i γi, and

such that either (i) s′′env 6= s′env or (ii) if s′′env = s′env then s′′ ≺ks s′.

As for C+, any action description D in KC+ defines a labelled transitions system.

Its characterization is given in terms of the definitions provided above.

Definition 5.8 The transition system defined by the action description D is the di-

rected graph which has the global states of D as nodes, and includes an edge from s

to s′ labelled ε, for every transition 〈s, ε, s′〉 causally explained according to D.

Definite Action Descriptions. For definite action descriptions, the characteri-zation of the resulting global state in a causally explained transition can be simplifiedconsiderably. In fact, fluent formulas caused in a transition are either ⊥, objectivefluent atoms, epistemic atoms like K(f = v) or ¬K(f = v), or epistemic fluentformulas like S(f) or ¬S(f), where f ∈ σf and v ∈ Dom(f). Consider a transition


〈s, ε, s′〉, where s = 〈senv, sk〉 and s′ = 〈s′env, s′k〉, and a fluent formula γ caused in

it. Depending on the form of γ, we have several kinds of global state updates.

Ontic Effects: γ = (f = v). The agent’s epistemic state is not changed. Thus,

• s′k = sk

• s′env = (senv − {f = w | f = w ∈ senv, w 6= v}) ∪ {f = v}.

Gaining Knowledge Effects: γ = K(f = v). The agent’s knowledge is in-creased. Worlds not consistent with the knowledge gained with this operation arepurged from the epistemic state. Since operator K satisfies S5 epistemic logic, nec-essarily f = v ∈ senv. Thus,

• s′env = senv

• s′k = sk − {senv | senv ∈ sk, f = v 6∈ senv}.

Ignorance Effects: γ = ¬K(f = v). They introduce uncertainty about thefluent f . The number of worlds in the epistemic state may increase. Since the agentignores the value of f , it needs to consider all possible alternatives about its value.Thus,

• s′env = senv

• if (senv, sk) |= K(f = v) then s′k = sk ∪ {s′env| s′env = (senv − {f =v}) ∪ {f = w}, for each senv ∈ sk, f = v ∈ senv, and for each w ∈Dom(f), w 6= v}

• otherwise s′k = sk.

Sensing Effects: γ = S(f). The agent’s knowledge is increased. Worlds thatare not consistent with the result of the sensing operation are purged from the epis-temic state. Thus,

• s′env = senv

• if f = v ∈ senv then s′k = sk − {senv | senv ∈ sk, f = v 6∈ senv}

• if f = v 6∈ senv then s′k = sk − {senv| senv ∈ sk, f = v ∈ senv}.


Forgetting Effects: γ = ¬S(f). They introduce uncertainty about the fluent f .The number of worlds in the epistemic state may increase, since the agent needs toconsider alternatives about its value. Thus,

• s′env = senv

• if (senv, sk) |= K(f = v) then s′k = sk ∪ {s′env| s′env = (senv − {f =v}) ∪ {f = w}, for each senv ∈ sk, f = v ∈ senv, and for each w ∈Dom(f), w 6= v}

• if (senv, sk) |= K¬(f = v) then s′k = sk ∪ {s′env | s′env = senv ∪ {f =v}, for each senv ∈ sk, f = v 6∈ senv}

• otherwise s′k = sk.

Example: A Simple Action Description in KC+

To illustrate the new language, we provide an example of aKC+ action description3.It is deliberately simple so that the transition system can be shown in its entirety.

Let σ = {p}∪{ao, as} be a boolean signature, where p is a fluent, ao and as twoaction constants. The action description ADk consists of the propositions

ao causes pao causes ¬Sp if K¬pas causes Spnonexecutable ao ∧ as

inertial p, Kp, K¬p,exogenous ao, as.

ao makes p true (ontic effect - first rule), and makes the agent forgetting what it knowsabout p, whenever the agent knows that p is false (forgetting effect - second rule); as

makes the agent determining the value of p (sensing effect - third rule); a0 and as

cannot be executed concurrently (fourth rule). The fluent p is assumed to be inertialand exogenous in the initial state, and similarly for the knowledge of the agent aboutthe fluent p (fifth rule). Action constants ao and as are exogenous (sixth rule). Thepropositions above are shorthands for

3We tested a slightly different version of this example with CCALC 2.0, using tricks to overcome its

inability to deal with epistemic formulas.


caused p if > after ao

caused ¬Sp if > after ao ∧K¬pcaused Sp if > after as

caused ⊥ if > after ao ∧ as

caused p if p after pcaused ¬p if ¬p after ¬pcaused Kp if Kp after Kpcaused ¬Kp if ¬Kp after ¬Kpcaused K¬p if K¬p after K¬pcaused ¬K¬p if ¬K¬p after ¬K¬pcaused ao if ao

caused ¬ao if ¬ao

caused as if as

caused ¬as if ¬as

Observe that, the action description ADk is definite. In fact, p, ¬p are objectivefluent atoms; ao, ¬ao, as, ¬as are objective action atoms; Kp and K¬p are epistemicatoms; Sp, ¬Sp are epistemic fluent formulas. Since p is a boolean fluent, there areonly two possible environment’s states: senv1 = {p = false}, senv2 = {p = true}.The possible epistemic states are:

• sk1 = {{p = false}, {p = true}} = {senv1 , senv2}, corresponding to thefact that the agent does not know the truth value of p (complete ignorance);

• sk2 = {{p = false}} = {senv1}, corresponding to the fact the agent knowsthat p is false;

• sk3 = {{p = true}} = {senv2}, corresponding to the fact that the agentknows that p is true.

Therefore, the set of global states is S = {s1, s2, s3, s4}, where s1 = (senv1 , sk1),s2 = (senv1 , sk2), s3 = (senv2 , sk1), s4 = (senv2 , sk3). It can be trivially verifiedthat the following equivalences hold: s1 ∼ s1, s1 ∼ s3, s2 ∼ s2, s3 ∼ s1, s3 ∼ s3,and s4 ∼ s4.

All global states of S are global states of ADk. Out of the 4 × 4 × 4 = 64transitions, only 12 are causally explained. The transition diagram is depicted inFigure 5.2. As an example, consider the transition 〈s1, {ao,¬as}, s3〉. This transitionis causally explained. The only fluent formula caused in it, is p. Global state s3

results from the update of s1 by the effect p: sk1 is not affected and senv2 is the onlyenvironment’s state such that senv2 |= p. As another example, consider the transition〈s2, {ao,¬as}, s4〉. This transition is not causally explained. Fluent formulas causedin it, are p, ¬Sp, but senv2 |= p and (senv2 , sk3) 6|= ¬Sp.


s1

s4s2

{ao,¬ as }

{ ao,¬ as }

{¬ ao, as }

{ ¬ao, ¬ as } { ¬ao,¬ as }

{¬ ao,¬ as }

{ ¬ao,¬as }

s3

{ ao,¬ as }

{ ¬ao, as }

{ ¬ao, as }

{a o,¬a s

}{¬ ao, as }

Figure 5.2: Transition Diagram for KC+ Action Description ADk

5.4.2 Using KC+ for Web Services

We now discuss how the expressive capabilities of KC+ could be used to describethe additional aspects of Web services in presence of incomplete information.

As discussed so far, in order to deal with incomplete information we allow atomicservices to have knowledge preconditions and knowledge effects. The former repre-sent the information that the composer agent must know before invoking the atomicservice, whereas the latter represent the information that is told to the composer agentas a result of the execution of the atomic service. Knowledge preconditions andknowledge effects are treated as normal preconditions and direct/indirect effects ofservices executions. Therefore, they can be easily represented by means of laws ofKC+, which have the same form of the laws used in Section 5.2, but with epistemicformulas in the head and the body for modelling the information requirements andknowledge gain. Furthermore, epistemic formulas can also appear in control flowrules in order to impose some restrictions on the execution of the atomic servicesbased on the information that the composer agent has at its disposal.

For illustration purpose, let us consider an example which is a slightly modifiedversion of the scenario presented in [Trajcevski, Baral, & Lobo, 2001]. Suppose thatwe want to automate the course registration process of a graduate student in a Univer-sity. In this process, the student sends an authorization request to the advisor. It’s the


advisor’s responsibility to check if the student is eligible to register, i.e., if it has theprerequisites to attend the course and if the class of the course is not full of students.If both these conditions are met, the registration is made by the secretary which givesthe student a password to access the course. If the student does not have the prerequi-sites, the student needs to contact the instructor of the course and get its permission,in which case the registration is processed by the secretary. If the class of the courseis full, the student needs to get the permission not only from the instructor of thecourse but also from the chair of the department that has to allow over-subscriptionto that course. If both permissions are obtained, the secretary can proceed with theregistration. The whole process could be automated by building an application thatwhenever a student request arrives, allows or disallows the registration of the studentto the course. Suppose that such an application makes use of some atomic servicesbelonging to a given community

C = {advisorWS(s, c), instructorWS(s, c), chairWS(s, c),secretaryWS(s, c)}

where advisorWS(s, c) is in charge of verifying if the student s is eligible to registerto the course c; instructorWS(s, c) is in charge of contacting the instructor of thecourse c and obtain the permission for the student s either in case the student does nothave the prerequisites or the class is full of students; chairWS(s, c) is in charge ofcontacting the chair of the department and obtain the permission for over-subscribingthe student s to the course c when the class is full; and secretaryWS(s, c) is theservice that should grant the registration password of the course c for the student s.

Let us try to formalize this domain by exploiting the expressive capabilities ofKC+. As the informal description of the example suggests, the composer agent doesnot have complete knowledge about the domain. In order to fulfill the student re-quest, it has to acquire the required information for the registration concerning thestudent situation (if the student has the prerequisites) and the course organization (ifthe course is full an if it is possible to obtain an authorization for an exceptional sub-scription to the course). As illustrated below, knowledge preconditions and knowl-edge effects are straightforwardly represented by means of multivalued epistemicformulas appearing in the head and the body of causal laws composing the KC+action description for the example. Consider the signature σ = σf ∪ σa, where

σf = {requested(s, c), hasPrereq(s, c), prereqWaived(s, c), classFull(c),spaceWaived(s, c), spaceWaivedInstr(s, c),spaceWaivedChair(s, c), pwdGranted(s, c), instructor(c),chair(d), dept(s), consulted(s)}

σa = {advisorWS(s, c), instructorWS(s, c), chairWS(s, c),secretaryWS(s, c)}


Variable c takes values in a set of course names given in the university. Variable dtakes values in a set of department names in the university. Variables s takes valuesin a set of names of persons. This set is the domain of the fluents instructor(c)denoting the instructor of the course c, and chair(d) denoting the chair of the depart-ment d. Fluent dept(s) denotes the department to which the student s belongs. Itsdomain is the set of department names. The rest of fluent symbols in the signature areboolean. All action constants are boolean. The description of the service communityis composed by the following laws.

advisorWS(s, c) causes S(hasPrereq(s, c))advisorWS(s, c) causes S(classFull(c))

instructorWS(s, c) causes S(prereqWaived(s, c)) if ¬hasPrereq(s, c)instructorWS(s, c) causes S(spaceWaivedInstr(s, c)) if classFull(c)instructorWS(s, c) causes consulted(instructor(c))

chairWS(s, c) causes S(spaceWaivedChair(s, c)) if classFull(c)chairWS(s, c) causes consulted(chair(d)) ∧ d = dept(s)

caused spaceWaived(s, c) if spaceWaivedInstr(s, c)∧spaceWaivedChair(s, c)default ¬spaceWaived(s, c)

secretaryWS(s, c) causes pwdGranted(s, c) if hasPrereq(s, c)∧¬classFull(c)secretaryWS(s, c) causes pwdGranted(s, c)if ¬hasPrereq(s, c) ∧ classFull(c) ∧ prereqWaived(s, c) ∧ spaceWaived(s, c)

secretaryWS(s, c) causes pwdGranted(s, c)if hasPrereq(s, c) ∧ classFull(c) ∧ spaceWaived(s, c)

secretaryWS(s, c) causes pwdGranted(s, c)if ¬hasPrereq(s, c) ∧ ¬classFull(c) ∧ prereqWaived(s, c)

secretaryWS(s, c) causes ¬pwdGranted(s, c)if ¬hasPrereq(s, c) ∧ ¬prereqWaived(s, c)

secretaryWS(s, c) causes ¬pwdGranted(s, c)if classFull(c) ∧ ¬spaceWaived(s, c)

Restrictions on the concurrent execution of the atomic services, and control flow rulesare expressed by the following laws.

nonexecutable advisorWS(s, c) ∧ secretaryWS(s, c)nonexecutable advisorWS(s, c) ∧ instructorWS(s, c)nonexecutable advisorWS(s, c) ∧ chairWS(s, c)nonexecutable secretaryWS(s, c) ∧ instructorWS(s, c)


nonexecutable secretaryWS(s, c) ∧ chairWS(s, c)

caused advisorWS(s, c)if requested(s, c) ∧ ¬S(hasPrereq(s, c)) ∧ ¬S(¬classFull(c))

caused instructorWS(s, c) if ¬hasPrereq(s, c) ∧ ¬S(prereqWaived(s, c))caused instructorWS(s, c) if classFull(c) ∧ ¬S(spaceWaived(s, c))

caused chairWS(s, c) if classFull(c) ∧ ¬S(spaceWaived(s, c))

caused secretaryWS(s, c) if hasPrereq(s, c) ∧ ¬classFull(c)caused secretaryWS(s, c)

if ¬hasPrereq(s, c) ∧ ¬classFull(c) ∧ consulted(instructor(c))

caused secretaryWS(s, c) if classFull(c)∧consulted(instructor(c)) ∧ consulted(chair(d)) ∧ d = dept(s)

5.5 Comparison with Related Work

In this section, we compare our approach to related work. In particular we compareour work with research concerning (i) automated Web service composition basedon symbolic reasoning and AI planning techniques, (ii) action languages and theirextensions to handle incomplete information.

Different planning approaches have been proposed for the composition of Webservices, from HTN planning [Sirin et al., 2004; Zhang et al., 2004; Fernandez-Olivares et al., 2007] to regression planning based on extensions of PDDL [Mc-Dermott, 2002] and to planning as model checking [Pistore et al., 2004; Pistore,Traverso, & Bertoli, 2005]. Other planning techniques, like CSP [Lazovik, Aiello, &Papazoglou, 2003], have been applied to related but somehow orthogonal problemsin the field of Web services. Our approach, in this chapter, has been to use reasoningabout action formalisms (in particular the action language C+) to describe Web ser-vices and to use logical reasoning (mainly satisfiability) to solve the problem of Webservices composition. This approach gives us the ability to deal with Web servicesusing a compact and high-level representation.

The idea of using reasoning about action formalisms in the context of Web ser-vices is not new. In [McIlraith & Son, 2002; Narayanan & McIlraith, 2003] theSituation Calculus [McCarthy & Hayes, 1969; Reiter, 1992] and GOLOG [Levesqueet al., 1997] are used to formalize the dynamic aspects of Web services and to de-scribe their composition. Specifically, composite services are represented as GOLOGprograms while the client request is specified in terms of constraints. The synthesis

5.5. Comparison with Related Work 165

of a composition is based on using such constraints for pruning the tree of possibleexecutions of the available services. With this work, we share the same semanticvision of atomic services as actions that have preconditions and effects, even thoughwe do not explicitly refer to OWL-S properties. In our proposal, preconditions andeffects are expressed with the help of C+ causal laws. In [Berardi et al., 2003b] theauthors propose the general framework of execution trees, for synthesizing compositeservices from a set of available component services. The client request is expressedas a (possibly incomplete) specification of a target service (a sequence of atomic ac-tions). They use the Situation Calculus for representing services and exploit its corre-spondence to PDL [Kozen & Tiuryn, 1990] for computing the composite service bymeans of logical reasoning: the problem of checking the existence of a compositionis reduced to the problem of checking the satisfiability of a PDL formula. With thisproposal, we share the same idea of a service community whose description is givenin terms of an action theory. In particular, we allow the service community to bedescribed by a definite action description in C+. Thus, by exploiting the translationof definite action descriptions to definite causal theories and the completion proce-dure described in [Giunchiglia et al., 2004], we are able to reduce the compositionproblem to the problem of satisfying a set of propositional formulas. Concerning theclient request, we simply specify it by providing a set of conditions that the targetcomposite service must satisfy as simple goals.

In Section 5.4, we have discussed the need to extend our approach in order todeal with incomplete information. In particular, we have shown that by combin-ing epistemic logic with the action language C+ we obtain a framework for rea-soning about action with increased expressive capabilities which can be used totackle the composition of Web services in more complex scenarios involving in-formation requirements and knowledge gain. In literature, the usual way to facesuch contexts is to distinguish between world altering Web services and informa-tion providing Web services [McIlraith & Son, 2002; Narayanan & McIlraith, 2003;Sirin et al., 2004]. The composition problem is therefore solved by combining on-line execution of necessary information providing Web services, with offline sim-ulation of world altering services. On the contrary, by using KC+ for describingWeb services, we would not need to adopt such kind of distinction. In fact, dueto the form of the rules in KC+, we are able to describe atomic services charac-terized by preconditions and effects not only on the world but also on the knowl-edge of the reasoning agent. Moreover, with suitable notions of conditional planswe could reformulate the composition problem by interleaving information gather-ing and world altering activities. Similar “knowledge-based” approaches to auto-mated Web services composition are described in [Martınez & Lesperance, 2004;Pistore et al., 2005]. Specifically in [Martınez & Lesperance, 2004] the authors showhow to use the PKS planner [Petrick & Bacchus, 2002] to solve the Web service com-position problem. PKS allows one to plan under conditions of incomplete knowledgeand sensing. It generalizes the STRIPS approach by representing a state as a set of


databases that models the agent’s knowledge, and action effects as updates to thesedatabases. In [Pistore et al., 2005] the authors present an approach which extends aprevious proposal [Pistore, Traverso, & Bertoli, 2005] with knowledge level descrip-tion of services. They start with a set of services described in BPEL. Such services arethen translated into a knowledge level planning domain. The composition problem issolved by using of the MBP planner [Bertoli et al., 2001].

The closest approach to ours is maybe that of [Trajcevski, Baral, & Lobo, 2001]where the authors use an action language derived from the language A, named AW ,to specify and reason about workflows. Activities in the workflow are seen as per-formed by cooperative agents that interact in order to fulfill the task. Actions canhave effects on the world and on the agent’s knowledge. It is also possible to modelasynchronous events and exceptions. A workflow specification is described as a col-lection of rules, and a user goal as a collection of constraints on the system state. Thelanguage is also provided with an entailment relation which allows one to check ifthe workflow is compatible with achieving the goal. In order to deal with incompleteinformation, a three-value logic is employed. The main improvement of our proposalw.r.t. this one, is in focusing on the action language C+ which is without doubt moreexpressive than its predecessor A. As we have already pointed out, the approachbased on C+ provides a framework where different aspects of services execution andcomposition can be described in a uniform way by means of causal laws. Moreover,in an extended framework based on KC+, thanks to the use of epistemic modalities,we would not need to employ a three valued logic to distinguish what is known fromwhat is unknown.

The second area of related work concerns action languages and their extensionsto handle knowledge and partial observability. The literature contains several pro-posals. For example, AS and Ak are two such languages, described in [Son & Baral,2001] and in [Lobo, Mendez, & Taylor, 2001], respectively, that are obtained by ex-tending the action language A [Gelfond & Lifschitz, 1993] with special propositionsfor representing sensing action effects. In comparison with these works, the main dif-ference of our proposal is in focusing on the action language C+ [Giunchiglia et al.,2004]. C+ is an expressive language that has several desirable features, but cannotexpress actions effects on the knowledge. We extend the representational capabili-ties of C+, w.r.t this last issue, without changing the language itself but modifyingits underlying logic. We add a modal operator K and use formulas of S5 epistemiclogic for representing the epistemic capabilities of an agent. We obtain a new actionlanguage, named KC+. In defining the semantics, we adopt the approach of [Son &Baral, 2001], by separating the state of the world from the agent’s epistemic state,and introduce the notion of global state [Fagin et al., 2003]. We generalize the ap-proach of [Lobo, Mendez, & Taylor, 2001], by identifying actions epistemic effectsas a mean of modifying the agent’s knowledge. In particular, we distinguish fourtypes of epistemic effects (not only sensing effects, but also knowledge gain effects,ignorance effects, and forgetting effects), each of which is represented naturally by

5.6. Remarks 167

epistemic formulas.Our proposal builds on [Hunter, 2004], where the author presents an extension

of the action language A with a unary modal operator K, called A[LK]. We applythe same idea of describing actions epistemic effects as transitions between Kripkestructures, to the action language C+. We provide our language with a relationalsemantics to interpret actions effects, based on standard Kripke semantics, thus en-suring the preservation of the equivalence properties of the accessibility relation ofS5 logic. Furthermore, we model the evolution of global states by actions effects,referring to the notion of knowledge updates developed in [Baral & Zhang, 2005]:the k-models correspond to global states in our framework, whereas the formula µresponsible for the k-models updates, is seen as the conjunction of all fluent formulascaused in a given transition. However, in our case, we have applied a minimal changecriterion only on the epistemic components of global states, whereas we have used auniqueness condition on the environment components, as it is done for C+.

Two other action languages for reasoning about action with incomplete informa-tion, are E+ [Lukasiewicz, Nardi, & Rosati, 2004], and K [Eiter et al., 2003]. E+is syntactically similar to A and C+, but has a semantics based on autoepistemic de-scription logic ALCKNF [Donini, Nardi, & Rosati, 2002], that allows for represent-ing incomplete knowledge, persistence properties and sensing actions. In comparisonwith E+, the strength of KC+ is a semantics based on S5 epistemic logic which al-lows for a natural representation of action effects as global state transitions. On thecontrary, the language K is based on logic programming and allows for modellingincomplete information and nondeterminism. A distinguishing feature w.r.t. KC+, isthat inK knowledge states are incomplete states where the truth value of some fluentsis unknown (those that are not represented in the state).

5.6 Remarks

The work described in this chapter has been carried out during the last year of ourPh.D. studies, and is still in an early stage. Doubtless, it constitutes a contributiontowards the definition of a theoretical framework for Web service composition.

Chapter 6

Discussion and Conclusions

We conclude our presentation by evaluating how process algebras and action lan-guages differ w.r.t. the research issues, and by summarizing the main contributionsof our investigation. Finally, we discuss some possible directions for furure researchby considering the extensions and improvements that can be devised for both ap-proaches.

6.1 Critical Evaluation of the Two Proposed Approaches

In this section, we discuss the benefits and limitations of the two proposed for-malisms, namely process algebras and action languages, in the context of Web ser-vices.

Process Algebras. Process algebras appeared to us as a natural formalism for pro-viding solutions to a number of challenges raised by the Web service paradigm. Ourinterest in using process algebras is motivated by the fact that they are very wellstudied and have a formal foundation. Generally speaking, process calculi providea simple and expressive framework in which to represent and reason about Web ser-vices. While being based on a small core of usual operators, they offer a wide panel oflanguages and tools to deal with many specific aspects of Web services (data descrip-tion, time, probability, mobility, etc) and involving different communication models.This characteristic makes the approach quite general since we do not need to focuson a specific language but we have at our disposal a whole family of formal de-scription techniques. Additionally, process algebra constructs are adequate to specifyWeb service composition due to their compositionality property which allows for thedefinition of more complex behaviors from simple ones. Furthermore, the textual no-tation is more adequate for describing and reasoning on real-size problems, and are

169

170 6. Discussion and Conclusions

more adapted to proof-writing and formal reasoning compared to graphical notations.But, more importantly, the greatest interest in using process algebras is that for-

mal reasoning is made possible at any time and for many purposes thanks to theexistence of state-of-the-art tools. Basic checks such as syntactical parsing and type-checking of the file containing the processes definitions, allow one to obtain descrip-tions free of typing errors and missing declarations. Other kinds of checks concern(i) verification of equivalences by exploiting several formal notions of equivalences,(ii) verification of properties, typically safety and liveness properties, and (iii) verifi-cation of compatibilities to certify that the composition of services (through choreog-raphy and orchestration) conform their requirements and respect desired properties.Specifically, concerning the choreography issue, process algebra can be used for rep-resenting the behavior of all interacting Web services, and consequently it allows oneto perform on-the-fly compatibility checks in order to ensure that the component ser-vices can cooperate for solving the given tasks; concerning the orchestration issue,process algebra is helpful to verify that the interaction between the orchestrator andeach of the selected partners works properly.

Finally, process algebras can be used to support the correct development of Webservices. In particular, on one hand they can be exploited for encoding purposes dur-ing the design stage, i.e., for specifying abstractly the new service and its interactionswith the other participants, and then translating it into an executable language. Inthis case, process algebras are especially worthy as a first description step becausethey enable us to analyze the problem at hand, to clarify some points, and to sketch a(first) solution using an abstract language (thus dealing only with essential concerns).From such a formal description of one or more services-to-be, verification tools canbe used to validate their correct execution and, if necessary, to verify and ensure rel-evant temporal properties. On the other hand, process algebras can be exploited forreverse engineering purposes, i.e., for extracting an abstract representation from theservice implementation (accordingly, the developer implements directly the serviceusing an executable language) to validate its behavior with respect to its mates.

Summarizing the results of our investigation, we can claim that the Web servicecommunity can benefit from the sophisticated languages developed in the process al-gebra area. However, this approach, like any other formal automata-based approach,has several drawbacks that limit its practical viability and wide-scale adoption. Whilebeing powerful languages, process algebras are of a procedural nature. Process al-gebra techniques for service composition require the developer to provide a speci-fication of the desired behavior of the composite service in its entirety. In fact, thedeveloper has to specify the steps and the order in which these steps have to be ex-ecuted. Consequently, it has to deal with the cognitive burden of handling the entirecomposition graph (comprising appropriate data and control flows) which becomeshard to manage with the increasing complexity of the composite service. Further-more, although these techniques allow for some flexibility by considering alternativepaths in the composite service behavior, any of which could be taken depending on

6.1. Critical Evaluation of the Two Proposed Approaches 171

some a-priori available data, they require to model all possible scenarios, includingeven exceptional situations. These situations may arise at any point in time, and sospecifying them explicitly increases more the complexity of the composite servicemodel since it makes difficult or even impossible to oversee what activity should beperformed next. Furthermore, if the composite service specification cannot be real-ized using the set of available component services, the entire composition task fails.Observe that, in many cases the failure is due to the incompleteness of the compositeservice specification.

Action Languages. To overcome the limitations of process algebras, i.e., to re-duce the complexity of the composite service model, and allow for more flexibilityin selecting an execution path, we have experimented with a declarative approachto Web service composition based on reasoning about actions formalisms, and inparticular on action languages. The idea of using reasoning about action formalisms,mainly the Situation Calculus [McIlraith & Son, 2002; Narayanan & McIlraith, 2003;Berardi et al., 2003b], in the context of Web services is not new. Very few proposals(for instance [Trajcevski, Baral, & Lobo, 2001]) exploit the expressiveness capabil-ities of action languages. Action languages are attractive because they are concise,simple and characterized by an English-like syntax which makes it easier to describethe ontology and basic relations needed for modeling the agent’s domain. More-over, their semantics is based on a theory of causality: the meaning of a domaindescription is represented as a transition diagram, that is a directed graph with ver-tices corresponding to states of the world and edges denoting the changes caused bythe occurrence/nonoccurence of actions. Finally, action languages are more expres-sive than the “classical” planning languages like STRIPS [Fikes & Nilsson, 1971]and ADL [Pednault, 1989]. Planning is considered as a reasoning task in an actiondomain. Translations of action languages into logic programming allow one to trans-form planning problems into satisfiability problems (in the spirit of “SatisfiabilityPlanning” [Kautz & Selman, 1992]), which can be solved by existing and efficientSAT checkers.

Unlike the imperative process algebras approach, a declarative approach basedon action languages allows one to specify the effects of the activities of Web ser-vices without any specific knowledge about how they are implemented, and how theyshould be coordinated. Such an approach is very flexible since it allows one to dealwith incomplete information and exceptional cases. We describe the normal runs ofservices and we do not need to know all the possible execution scenarios that mightoccur. In this context, the composition problem can be formulated as a planningproblem. The entailment relation that characterizes the action language chosen as thespecification language, enables us to reason about the correctness of the specificationof a composite service in terms of achieving a client request. Given an abstract andpossibly incomplete specification of the client request, this specification is used to se-


lect a set of suitable component services such that their composition realizes it. In theevent that such a composition is unrealizable, the cause for the failure is determined,thereby enabling further reformulation of the goal specification.

Among all possible action languages available in literature, we have focused onthe action language C+ [Giunchiglia et al., 2004]. The rationale behind this choicelies in the expressiveness of the language. In particular, C+ is a non-monotonicformalism that allows for reasoning about concurrent actions and for expressing per-sistence of properties, state constraints and indirect effects. As a specification for-malism, its salient feature is its modularity: new rules can be added independent ofthe rest of the domain description. Moreover, the language is provided with a rea-soning tool, called CCALC [TAG at Austin, CCALC], which answers queries aboutaction domains expressed in its definite fragment. C+ and its tool have been success-fully applied to several benchmark problems of commonsense knowledge (see, for in-stance, [Campbell & Lifschitz, 2003; Akman et al., 2004] and the examples providedon the CCALC Web site), to the formalization of multiagent computational systems[Artikis, Sergot, & Pitt, 2002; Artikis, Sergot, & Pitt, 2003; Chopra & Singh, 2003;Chopra & Singh, 2006; Sergot & Craven, 2006], and the specification of businessprotocols as choreographies modelled via commitments [Desai, Chopra, & Singh,2007].

Our investigation has shown another application of C+ to a realistic domain,namely the Web service composition. The expressive power of the language providesus with a framework for the formal description of Web services and the specificationof their composition. More importantly, the characterization of service descriptions interms of definite action descriptions and the specification of the composition problemin terms of a reasoning task, make possible a reduction of the composition problemto a satisfiability problem of a set of propositional formulas. This set of formulas isobtained by exploiting the translation procedure for definite action theories discussedin [Giunchiglia et al., 2004]. Furthermore, a practical advantage of such a character-ization is the ability to use the tool CCALC for finding a solution to the problem andautomatically synthesizing a composite service for the client request.

The action languages approach is currently based on the simplifying assumptionof complete knowledge, which in the context of the Web is unrealistic and thereforehas to be removed. Incompleteness can be in the initial situation specification or inthe description of the service community (e.g., not all possible execution scenariosare known). The subset of C+ implemented in CCALC, which we exploited in ourapproach, cannot deal with the first source of incompleteness. In fact, as stated in[Lee, 2005], although the current version of CCALC can solve prediction and post-diction problems with incomplete information, it does not handle “conformant plan-ning”, i.e., generating plans that are guaranteed to succeed with incomplete initialconditions. But more importantly, dealing with the second source of incompleteness,requires to be able to model not only the changes in the world but also the changes inthe mental state of the composer agent. These new aspects cannot be captured by the

6.2. Summary 173

language C+, which although very expressive, cannot describe actions that affect theagent’s knowledge. To overcome these limitations we need a more expressive actionlanguage which allows one to represent actions that explicitly affect knowledge. Apossible candidate is the languageKC+ that we obtained by introducing in the under-lying logic of C+ epistemic modalities. Epistemic logic appeared to us the simplestand best known way of representing knowledge. However, although KC+ seems toprovide a rich framework for reasoning about actions in presence of incomplete in-formation, its definition is still in a preliminary stage and much work remains to bedone.

Another restriction of our approach concerns the use of definite action descrip-tions for modelling the service community. We have focused on such kind of actiondescriptions in order to have at our disposal the ability of testing our formalizationswith the tool CCALC and verify if the results match our expectations. As outlined in[Lee, 2005], although definite causal theories are widely applicable, there are caseswhere nondefinite causal theories yield to more natural formalizations. In his PhD.dissertation, Lee shows how to turn arbitrary causal theories into propositional for-mulas. This process includes completion as a special case, and allows to turn anynondefinite theory into an equivalent definite theory. Such translation is at the basisof a possible extension of CCALC to handle nondefinite action descriptions, but it hasnot been proposed yet.

Finally, our approach shares with any other AI planning technology applicableto the service composition problem, the same drawbacks. First of all, plans needto contain complex control structures involving loops, nondeterminism, and choice.Furthermore, in contrast to classical planning, where all objects are available in theinitial state and the actions change the state of objects, Web services create new ob-jects at runtime, i.e., they produce message objects during their execution that thencan be further processed by other services. It is still an open problem whether this be-havior can be adequately modelled with the currently available planning techniques.

6.2 Summary

In this dissertation we have focused on several aspects of Web service compositionincluding Web service description, simulation, verification and development. In-spired by the Web service initiatives proposed both in industry (WSDL/BPEL) andin academia (OWL-S/AI Planning), and motivated by the need for semantically well-founded and algorithmically manageable formalisms for tackling several issues ofWeb services, we have proposed two formal approaches for describing and reasoningabout Web services, namely process algebras and action languages. In particular, thepresentation of our work has been organized has follows.

• In Chapter 1, we have introduced the problems addressed by this dissertation


and the approaches followed.

• In Chapter 2, we have provided a thorough survey of previous work on Webservices. The chapter outlines and discusses the main existing languages forspecifying Web services (WSDL [W3C, 2001a], BPEL [Curbera et al., 2002],and OWL-S [DMAL, 2006]). A detailed example specification in WSDL andBPEL involving a stock management application is also given.

• In Chapter 3, we have described some previous formal approaches to Webservices and discussed how they compare.

• In Chapter 4, we have advocated the use of process algebras for describingthe essential facets of Web Services, and especially, those useful to understandtheir interaction. Process algebras are simple, abstract and formally-definednotations that allow one to describe the exchange of messages between Webservices, and to reason about the specified system. Along with their accom-panying tools, they are effective at verifying that composition of services, ob-tained by orchestration and choreography, conform the requirements and re-spect some desired properties. To illustrate the interest of the process algebrasapproach to Web services, we have considered an application to the problemof negotiation. This problem is a typical example of service interaction in-volving both data (prices, goods, stocks, etc) and behaviors. Negotiation is-sues appear when several participants (clients and providers) have to interactto reach an agreement that is beneficial to all of them. In this context, we haveexperimented with the use of LOTOS [Bolognesi & Brinksma, 1989] and itstool CADP [VASY, CADP], to ensure trustworthy and automated negotiationsteps in Web services. Abstract descriptions have also been used as a first stepto developing certified Web services following a well-defined method. Thelink between the abstract level and the concrete one is formalized through sys-tematic guidelines which make it possible to translate abstract processes intoWSDL interfaces and BPEL processes. Depending on the process algebra (andparticularly on its expressiveness) used in the initial step, running BPEL ser-vices or just skeletons of code (to be complemented) may be obtained directly.Our method has been used to develop and deploy running Web services inBPEL. Consequently, it has not remained at the conceptual level as is often thecase. Concerning the correctness of our encoding, if we focus on the version ofBPEL implemented in the Oracle BPEL Process Manager 2.0 [Oracle, BPELProcess Manager] that has been used to run all the examples, we can claim thatthe transition system model derived from any LOTOS operator introduced inin Section 4.1, is observationally equivalent to the transition system model ofthe BPEL code obtained using our translation guidelines. Concerning the com-pleteness, we have shown that all the abstract LOTOS operators considered inSection 4.1 can be translated into BPEL.

6.3. Future Perspectives 175

• In Chapter 5, we have advocated the use of action languages for reasoningabout Web services and their composition. Action languages are high-levelformalisms for representing and reasoning about the effects of actions in theenvironment. Various action languages have been proposed in literature, of-fering different capabilities and expressiveness. Here, we have focused on thelanguage C+ [Giunchiglia et al., 2004]. The approach based on C+ providesus with a framework where different aspects of services execution and compo-sition can be described in a uniform way by means of causal laws. The frame-work refers to the OWL-S process model that distinguishes between atomic andcomposite services. Atomic services are described by specifying their precon-ditions and effects in a definite action theory. Composite services are sequencesof atomic services. The composition problem is described as a planning task,and so is formally specified by means of the entailment relation that charac-terizes the action language C+. This basic approach is currently based on thesimplifying assumption of complete knowledge, which in the context of theWeb is unrealistic. As a first attempt to investigate complex scenarios involv-ing incomplete information, we have discussed some possible extensions. Theaim is to be able to represent additional aspects of services related to informa-tion requirements and knowledge gain. These new aspects cannot be capturedby the action language C+, which although very expressive, cannot describeactions that affect the agent’s knowledge. To that end, we have proposed anextension of the action language framework for dealing with actions that ex-plicitly affect knowledge. Specifically, to distinguish what is known about theworld from what is unknown, we have introduced in the underlying logic of C+epistemic modalities. We have obtained a new action language, called KC+,that could be used to represent and reason about Web services composition inscenarios involving incomplete information. However, about this last concern,we could only suggest some possible research directions since this work is stillpreliminary. In fact, there are several issues that remain to be solved and manyaspects to be investigated both from a practical and a theoretical point of view.The next section provides more insights on these improvements.

6.3 Future Perspectives

There are several different research directions which can improve and extend thework of our Ph.D. studies. We conclude our presentation with an outlook on futurework for each of the two approaches discussed in this dissertation.

Process Algebras. The results illustrated in Chapter 4 are at an early maturity stageand much work remains to be done before they are widely applicable to large-scaleapplications. Many perspectives can be considered.


Although the presented approach is general since it does not focus on a specificlanguage, we have experimented in particular with the use of CCS [Milner, 1989] andLOTOS. A first continuation could be to experiment with the use of other process al-gebras involving more advanced constructs such as, for example, the π-calculus [Par-row, 2001]. π-calculus is a process algebra dedicated to mobility and reconfiguration.Notions as name passing and dynamic instantiations are definitely of interest in thecontext of Web services (e.g., a new client arrives and has to tell the address where an-swers should be sent, the server forks and dynamically creates a sub-process param-eterized with a new address, etc.). Thus, it is worth trying to extend our approach inthis direction. Furthermore, we could study a possible adjustment of existing equiv-alence checking algorithms so as to propose efficient automated composition of Webservices. Currently, the notion of composition is based on bisimulations. Loosernotions might be envisaged and need to be studied.

Another perspective concerns the use of process algebras for Web service devel-opment. Although it is promising due to the similar foundation of process algebraicdescriptions and the executable language BPEL, some work remains to be carried outto have at one’s disposal a formal refinement method by allowing a correct encodingfrom one level to the other one. In this direction, the implementation of a prototypeaccepting abstract specifications written using a process algebra (LOTOS in a firstattempt), and generating as output the BPEL skeletons corresponding to the inputdescriptions should be investigated as well. This will induce a practical validation ofthe mapping that we propose, and will be a great opportunity to find out possible defi-ciencies in our guideline definitions. It could be implemented for example, using theLOTOS NT compiler construction technologies [Garavel, Lang, & Mateescu, 2002].The LOTOS NT language is a variant of E-LOTOS (Enhanced-LOTOS, Iso/Iec stan-dard 15437:2001) elaborated by the Vasy project-team [INRIA, Validation de sys-temes Validation of systems], which is in turn a deep revision of LOTOS that aimsto provide a greater expressiveness (for instance, by introducing quantitative time todescribe systems with real-time constraints) together with a better user friendliness.The LOTOS NT technology is an interesting approach for compiler developmentwhich has been used to build some compilers like TRAIAN, that is actually availableon several platforms (Windows, Linux, Solaris) and can be downloaded on the Inter-net. Another direction of future work in this context, is to study how to generalizethe mapping to deal with other front-end languages such as LTS-based ones and withother back-end languages. Whereas the use of automata in place of process algebrasand their mapping to BPEL seems obvious, the encoding of abstract descriptions intoother XML-based technologies or programming languages to deploy Web servicesremains to be studied. The interest in considering other languages lies in the fol-lowing considerations. BPEL, like many other Web service programming languages,facilitates the development of services that engage in concurrent interactions. But,as pointed out in [Cooney, Dumas, & Roe, 2006], it fails to address more complexscenarios that go beyond simple sequences of requests and responses or that involve

6.3. Future Perspectives 177

many participants. In particular, BPEL cannot deal with one-to-many interactionswith partial synchronization among the partner services, especially when these ser-vices are not known in advance. Concerning these BPEL limitations, we could try todefine a correspondence with other target languages at the concrete level such as, forinstance, Gardens Point Service Language (GPSL) [Cooney, Dumas, & Roe, 2006]which seems more suitable to the implementation of complex services.

Action Languages. The work described in Chapter 5 is still preliminary but it con-stitutes a contribution towards the definition of a theoretical framework for Web ser-vice composition. Several issues deserve further investigation and many possibleextensions can be devised, both practically and theoretically.

In Section 5.2, we have exploited the expressive capabilities of C+ to describeseveral aspects of Web services. We have referred mainly to the presentation of thelanguage given in [Giunchiglia et al., 2004]. However, in [Lee, 2005], additionalconstructs have been presented which allow one to capture more sophisticated as-pects of domains. For example, a first continuation is to consider how the constructincrements could be used in the context of Web services. This construct has beenintroduced to describe the effects of actions on additive fluents. Such kind of fluentshave as domains finite sets of numbers. Numbers are understood as elements of a setwith an associative and commutative binary operation + that has a neutral elements0. In planning, fluents with numerical values are referred to as “resources” [Koehler,1998]. Incremental laws, i.e. laws based on the construct increments, are used todescribe how these resources are affected by actions. In the context of Web services,the word resources could resemble several things, for example money, quantity ofobjects in stock etc. Therefore, a natural way to exploit this new type of laws is fordescribing services that makes operations on such resources.

The framework for representing and reasoning about Web services with actionlanguages is based on the OWL-S process model that distinguishes between atomicand composite services. Actually, this the only relation with OWL-S, since through-out the chapter we do not make any explicit reference to OWL-S constructs. As apractical contribution, it could be interesting to define a translation from OWL-S de-scriptions into C+ planning domain. Whereas the translation of atomic processesproperties seems obvious, the translation of flows constructs requires to study howthey can be represented by set of causal laws. Similar translations, from OWL-S toSHOP2 [Sirin et al., 2004] and from OWL-S to the Event Calculus [Aydin, Cicekli,& Cicekli, 2007], have already been investigated, and may inspire the definition ofour own method.

The last perspective concerns the new action language KC+ and its use in theWeb service area. KC+ seems to provide a rich framework for representing actions inpresence of incomplete information, but several issues deserve further investigation.In particular, we have to define algorithms for reasoning about actions in domains


expressed in KC+. Suitable notions of conditional plans could be used to extendthe approach presented in Chapter 5 to more complex scenarios in Web service in-teraction involving incomplete information. Furthermore, with the aim at extendingthe tool CCALC with the new features of KC+, we may first define an epistemic ex-tension of the formalism of causal theories, and consequently propose a reductionof KC+ definite action descriptions to such theories. We may also be interested inenhancing the action language framework to multiagent systems. This kind of exten-sion could be achieved in a straightforward way, for both C+ and KC+. In fact, asdiscussed in [Giunchiglia et al., 2004], the use of the action language C+ in multia-gent systems is made possible by adding an argument to action constants that takesvalues over a finite set of symbols representing a set of agents in the system. Therole of this argument is to represent the agent that executes the corresponding action.Concerning KC+, we note that the origins of our proposal are in [Fagin et al., 2003],where the authors analyze knowledge in distributed systems using epistemic logicS5m. Nested epistemic operators are a natural way to represent and reason aboutknowledge in a multiagent system. However, the introduction of nested epistemicoperators in KC+ requires to modify in a significant way both the syntax and thesemantics of the language.

Appendix A

Translation of the LOTOS ChoiceOperator into BPEL

We explain how the LOTOS choice operator can be translated into BPEL. The trans-lation has been defined by considering some basic LOTOS examples which are rep-resentative of possible cases of interaction at the process algebra level (combinationsof emissions and receptions, possibly preceded by guard expressions defining condi-tional behaviors). For each of them, we realize a corresponding BPEL implementa-tion. The skeletons of BPEL code obtained for all possible cases of interaction areprovided in Tables A.1, A.2, and A.3.

A.1 Preliminaries

In LOTOS, the choice between two behaviors is represented using the construct [].If B1 and B2 are two expressions, then B1[]B2 denotes a process that behaves eitherlike B1 or like B2. The choice offered is resolved in the interaction of the processwith the environment.

In BPEL, to express a choice between two or more different behaviors it is pos-sible to use either the switch activity or the pick one, which are included in the setof structured activities of BPEL. The switch activity consists of an ordered list ofone or more conditional branches defined by the case tags (the condition is built on aboolean expression), followed by an optional otherwise branch. The case branchesare considered in the order in which they appear. The first branch whose conditionholds true is taken and provides the activity performed for the switch. If no branchwith a condition is taken, then the otherwise branch is taken. If the otherwise branchis not explicitly specified, then an otherwise branch with a empty activity is deemedto present. The switch activity completes when the activity of the selected branch

179

180 A. Translation of the LOTOS Choice Operator into BPEL

completes. The pick activity provides the possibility to make a non deterministicchoice based on external events. It awaits the occurrence of one of a set of eventsand then performs the activity associated with the event that occurred. The occur-rence of the events is often mutually exclusive. If more than one event occurs, thenthe selection of the activity to perform depends on which events occurred first. Thepossible events are the arrival of a message (<onMessage...>) in the form of theinvocation of an inbound one-way or request-response operation, or an alarm basedon a timer. Each pick activity must have at least one onMessage event. It completeswhen one of the branches is triggered by the occurrence of its associated event andthe corresponding activity completes.

The translation from LOTOS to BPEL is not always straightforward. There aremany aspects to be considered, such as how the life cycle of a business process ismodelled in BPEL, and how processes interact and communicate during an interac-tion. First of all, in an interaction we must decide which process starts the com-munication. There is always a “client” process that invokes operations provided byanother process (service). Services are deployed on a server and are ready to be in-voked at any time, unless they do not get undeployed. When a process is invoked forthe first time, an instance of the process itself is created on the server and registered as“alive”. Every instance created on the server is identified by a key, which is a numberused for the delivering of messages to the process itself. Therefore, the interactionis between the client and the instance of the process created on invocation. If thereare multiple invocations for the same process, multiple instances are created. Eachof them identifies a communication with the corresponding client. To be instantiated,each process must contain at least one start activity, i.e., a pick or a receive withthe attribute createInstance="yes". This start activity must be an initial activity,in the sense that there is no basic activity that logically precedes it in the behaviorof the process. The instance of the process terminates when the activities that definethe behavior of the process as a whole complete, or when the instance is explicitlyterminated by the terminate activity (in this case we have an abnormal termination).

Observe that, key numbers associated to process instances are managed by theserver, and cannot be accessed by the client. This means that a client can interactwith a process instance only within a communication started with an invocation. Thisimplies that in the BPEL code describing the process behavior, a receive activity canappear either as a start activity, or following an invoke modelling an asynchronousrequest/response as a part of an interaction previously established with a client.

A.2 Basic Interactions

The first problem to be solved is how to treat nondeterminism. BPEL processes doshow an external nondeterminism, i.e., the behavior of a business process depends onsome external events, coming from the environment with which the process interacts

A.2. Basic Interactions 181

(e.g. the arrival of a message from a partner process). Moreover, all interactions arebinary interactions in which there is a client invoking some operations and a processthat provides the client with these operations. Therefore, to model the nondetermin-ism, we must decide who starts the interaction and which action has to be performedfirst.

Emissions

In case of only emissions, with or without guard expressions, the nondeterminism ex-isting at the abstract level has to be removed. We need to introduce an external clientthat decides which behavior to perform, either providing the value to be checked inthe guards conditions, or choosing directly the message to be emitted. It may be seenas a situation in which a client fills in some forms, providing enough information toswitch among possible behaviors.

If guard conditions are present, the encoding is straightforward using a switch,with as many case tags as needed and the otherwise tag to implement mutuallyexclusive conditions. The external client provides the value for the parameter in guardexpressions. This means that, in the corresponding BPEL code, before the switch

there must be a first receive annotated with createInstance="yes", correspondingto the reception of the first message from the client. We provide an example oftranslation. Consider the following LOTOS code

[x<3] -> port1!x;exit

[]

[x>=3] -> port2!x+1;exit

The corresponding BPEL code is





<receive name="receiveInput"

partnerLink="client"

portType="tns:P1PortType"

operation="initiate"

variable="x"


<switch>

<case condition="bpws:getVariableData(’x’, ’number’,

’/value’)< number(3)">





<sequence>

<invoke partnerLink="P2"


operation="port1"

inputVariable="x"/>

</sequence>

</case>

<otherwise>




<sequence>





operation="port2"

inputVariable="y"/>

...

</sequence>

</otherwise>

</switch>

Observe that, this BPEL process can always perform one of the two possible emis-sions, but it is not known in advance which value is to be emitted. This decisionis taken by the client on invocation. The result is the creation of an instance of theprocess that effectively performs the emissions, based on the evaluation of the guardcondition.

Without guard conditions, determinism may be introduced in two ways: (i) addinga pick activity and then defining different messages whose arrival indicates the be-havior to be fired (the type of the incoming message determines the emission to bedone), (ii) using a switch activity defining case conditions involving, for instance,values provided beforehand, each condition firing a possible emission. In both cases,the choice of the message to be emitted is totally demanded to the client, that caneither choose directly the operation to perform, or provide a number to be used toswitch among possible emissions. As an example, consider the following LOTOSexample code

port1!x; exit

[]

port2!1; exit

If we adopt the first idea, then the corresponding BPEL code is

<onMessage partnerLink="client"


operation="port1Operation"

variable="input1">



<sequence>





operation="port1"

inputVariable="x"/>

</sequence>

</onMessage>



operation="port2Operation"

variable="input2">



<sequence>

...





operation="port2"

inputVariable="x2"/>

</sequence>

</onMessage>

</pick>

If we adopt the second idea, then the corresponding BPEL code is





<receive name="receiveInput"

partnerLink="client"



variable="input"


<switch>

<case condition="bpws:getVariableData(’input’, ’number’,

’/value’)=number(1)">


<sequence>

...



operation="port1"


</sequence>

</case>


’/value’)=number(2)">


<sequence>

...



operation="port2"


</sequence>

</case>

Observe that, both implementations define a BPEL process which is able to performtwo emissions, at any time. The emission to be fired depends on the choice madeduring instantiation by the client.

Receptions

In case of receptions with no guard conditions, the nondeterminism is easily mod-elled by using the BPEL pick activity, and this is a straightforward correspondence.There is no need to decide which value should be received first. Whenever a messagecomes, it is received on the correct port. The pick activity is either the start activ-ity, annotated with createInstance="yes", or follows an invoke, as a part of aninteraction established with a client that provoked the creation of the instance itself.Consider, for example, the following piece of LOTOS code

port1?y:Nat; exit

[]

port2?z:Nat; exit

The corresponding BPEL code is




operation="port1"

variable="y">



<sequence>

...

</sequence>

</onMessage>



operation="port2"

variable="z">


<sequence>

...

</sequence>

</onMessage>

</pick>

The partnerLink="client" identifies a possible interaction with a client that in-vokes the performance of either action port1, or action port2.

A guard expression before a reception makes the process receive a message onlyif the guard condition is satisfied. This condition may be expressed in terms of thevalue of a local parameter that is provided to the process during instantiation, or itcan be the result of a local computation. In all these cases, we can still provide aBPEL implementation but the result is slightly different from what it is describedin the abstract specification. The guard condition before the reception may be seenas a sort of “conditional receive”. But, as we noticed previously, a process cannotdiscriminate among all possible messages it receives during an interaction. Its WSDLfile describes the type of messages that can be received through its interface. As longas the process is ready to be invoked on the server, it receives messages anyway andat anytime. This means that it is impossible to implement a “conditional receive”.On the contrary, it is possible to check if some conditions are met, after receivingthe message, and then to decide whether to perform the activities associated with theevent corresponding to the reception of that message. If the conditions are false, theprocess can then send a message back to the invoking client to communicate this fact.For example, consider the following piece of LOTOS code

[x<3] -> port1?y:Nat;exit

[]

port2?y:Nat; exit

The corresponding BPEL implementation is the following:




operation="port1"

variable="y">


<sequence>

<switch>




<sequence>

...

<sequence>

<otherwise>



...

</otherwise>

</switch>

</sequence>

</onMessage>



operation="port2"

variable="y">


<sequence>

...

</sequence>

</onMessage>

</pick>

Observe that, the behavior of the BPEL process is not exactly the same of the LOTOSprocess. We still have the possibility to perform two receptions, but in the first casethe reception of a message port1 is performed before checking the guard condition.

Therefore, what becomes conditional is the execution of the actions that follow thereception port1.

Emissions and Receptions

A choice involving emissions and receptions without guard conditions, can be trans-lated in BPEL using a pick activity with one onMessage tag for each branch appear-ing at the abstract level, distinguishing between messages coming from the clientto fire the emission and messages coming from partner processes to implement re-ceptions. Observe that the pick must be annotated with createInstance="yes",meaning that whenever a message arrives (from the client or from a process partnerin the interaction) an instance of the process is created.

The presence of guard conditions, both in receptions and emissions, does notmodify the use of a pick. If the guard expression controls the emission, the param-eter to be checked is provided by the client and controlled with a switch. On thecontrary, if the guard condition controls a reception, since we cannot model a “con-ditional reception”, we may first receive the value to be checked with the pick, andthen decide what actions to perform after the reception with a switch. For example,the next LOTOS code corresponds to the case of an emission controlled by a guardexpression

[x<3] -> port1!x;exit

[]

port2?y:Nat; exit

The BPEL code is:





variable="input">



<sequence>

<switch>





<sequence>

operation="port2"

inputVariable="x"/>

</sequence>

</case>

</switch>

</sequence>

</onMessage>

<onMessage partnerLink="clientPort1"


operation="port1" variable="y">



<sequence>

...

</sequence>

</onMessage>

</pick>

Observe that, the translation defines a BPEL process which is capable of performingan emission or a reception, whenever it gets instantiated. The following is an exampleof a reception controlled by a guard expression plus an emission.

[x<3] -> port1?y:Nat;exit

[]

port2!2; exit

In this case, the corresponding BPEL code is




operation="port1"

variable="y">


<sequence>

<switch>




<sequence>

...

<sequence>

A.3. Conclusion 189

</sequence>

</onMessage>




variable="input">



<sequence>


...





operation="port2"

inputVariable="x"/>

</sequence>

</onMessage>

</pick>

Observe that, this translation defines a BPEL process whose behavior does not corre-spond exactly to the abstract LOTOS behavior. However, the process is still capableto perform both receptions and emissions, at any time.

A.3 Conclusion

The translation proposed for the LOTOS choice operator allows us to obtain runningBPEL processes from LOTOS abstract specifications. As we have seen, sometimeswe are forced to use some tricks to cope with the limits and constraints imposed bythe development environment and by the BPEL language, but we are able anyway toobtain running executable BPEL processes. The ideas of our proposal are summa-rized in the following tables, where O stands for emission, GO for emission precededby a guard condition, I for reception, and GI stands for reception preceded by a guardcondition.

Case LOTOS BPEL

O+O act1!x:t;...

[]

act2!y:t;...

<pick...createInstance="yes">

<onMessage...variable=...>



<invoke...inputVariable=.../>

</onMessage>

<onMessage...>




</onMessage>

</pick>

OR

<receive...createInstance="yes">

<sequence>

<switch>

<case condition=...>



</case>

<otherwise



</sequence>

</switch

</sequence>

I+I act1?x:t;...

[]

act2?y:t;...





...

</onMessage>



<onMessage...>

...

</sequence>

</onMessage>

</pick>

O+I act1!x:t; ...

[]

act2?y:t; ...






</onMessage>



<onMessage...>

...

</onMessage>

</pick>

Table A.1: Encoding the LOTOS Choice into BPEL

A.3. Conclusion 191

GO+GO [V1]->act1!x:t;...

[]

[V2]->act2!y:t;...

<receive...createInstance="yes">

<sequence>



<switch>




</case>

<otherwise>



</switch

</sequence>

GI+GI [V1]->act1?!x:t;...

[]

[V2]->act2?y:t;...





<switch>


...

</case>

</switch

</onMessage>




<switch>


...

</case>

</switch

</onMessage>

</pick>

GO+GI [V1]->act1!x:t;...

[]

[V2]->act2?y:t;...




<switch>





</case>

</switch

</onMessage>





<switch>


...

</case>

</switch

</onMessage>

</pick>

Table A.2: Encoding the LOTOS Choice into BPEL (cont’d)

GO+O [V]->act1!x:t;...

[]

act2!y:t;...




<switch>




</case>

</switch

</onMessage>

<onMessage...>



</onMessage>

</pick>

GO+I [V]->act1!x:t;...

[]

act2?y:t;...




<switch>





</case>

</switch

</onMessage>




...

</onMessage>

</pick>

GI+I [V]->act1?!x:t;...

[]

act2?y:t;...





<switch>


...

</case>

</switch

</onMessage>



...

</onMessage>

</pick>

GI+O [V]->act1?x:t;...

[]

act2!y:t;...






<switch>


...

</case>

</switch

</onMessage>

<onMessage...>




</onMessage>

</pick>

Table A.3: Encoding the LOTOS Choice into BPEL (cont’d)

Appendix B

Abbreviations for C+ Causal Laws

Causal laws of C+ can be abbreviated in several ways. The comprehensive list ofsuch abbreviations is given in the following tables, where φ and ϕ are fluent formulas,α and α′ are action formulas, ψ is a formula, f is a fluent constant and a is an actionconstant. Laws in lines 28, 29 and 30 can be used if f denotes a statically determinedboolean fluent constant and a is a boolean action constant.

193

194 B. Abbreviations for C+ Causal Laws

Causal Laws Abbreviations

1. caused φ if > caused φ

2. caused φ if > after ψ caused φ after ψ

3. caused φ if φ default φ

4. caused φ if φ ∧ ϕ default φ if ϕ

5. caused φ if φ ∧ ϕ after ψ default φ if ϕ after ψ

6. default φ if > after ψ default φ after ψ

7. caused f = v if f = v after f = v, for all v ∈ dom(f) inertial f

8. caused f = v if f = v after f = v ∧ ψ, for all v ∈ dom(f) inertial f if ψ

9. default f = v, for all v ∈ dom(f) exogenous f

10. default f = v if ϕ, for all v ∈ dom(f) exogenous f if ϕ

11. caused ⊥ if ¬φ constraint φ

12. caused ⊥ if ¬φ after ψ constraint φ after ψ

13. constraint f = v after f = v, for all v ∈ dom(f) rigid f

14. caused ⊥ after ¬ψ always ψ

15. caused α if > caused α

Table B.1: Abbreviations for Causal Laws in C+

195

Causal Laws Abbreviations

16. caused φ if > after α α causes φ

17. caused φ if > after α ∧ ψ α causes φ if ψ

18. α causes ⊥ nonexecutable α

19. α causes ⊥ if ψ nonexecutable α if ψ

20. caused φ if φ after α α may cause φ

21. caused φ if φ after α ∧ ψ α may cause φ if ψ

22. caused α′ if α ∧ ψ α causes α′ if ψ

23. caused α′ if α′ ∧ α ∧ ψ α may cause α′ if ψ

24. caused α if α default α

25. caused α if α ∧ ψ default α if ψ

26. default a = v, for all v ∈ dom(a) exogenous a

27. default a = v if ψ, for all v ∈ dom(a) exogenous a if ψ

28. caused φ if ϕ ∧ ¬f caused φ if ϕ unless f

default ¬f

29. caused φ if ϕ after ψ ∧ ¬a caused φ if ϕ after ψ unless a

default ¬a

30. caused α if ψ ∧ ¬a caused α if ψ unless a

default ¬a

Table B.2: Abbreviations for Causal Laws in C+ cont’nd

196 B. Abbreviations for C+ Causal Laws

Bibliography

[Aalst, 1998] Aalst, W. 1998. The Application of Petri Nets to Workflow Manage-ment. The Journal of Circuits, Systems and Computers 8(1):21–66.

[Aiello et al., 2002] Aiello, M.; Papazoglou, M. P.; Yang, J.; Carman, M.; Pistore,M.; Serafini, L.; and Traverso, P. 2002. A Request Language for Web-ServicesBased on Planning and Constraint Satisfaction. In Proc. of TES’02, volume 2444of LNCS, 76–85. Springer.

[Akman et al., 2004] Akman, V.; Erdogan, S. T.; Lee, J.; Lifschitz, V.; and Turner,H. 2004. Representing the Zoo World and the Traffic World in the Language ofthe Causal Calculator. Artif. Intell. 153(1-2):105–140.

[Alonso et al., 2004] Alonso, G.; Casati, F.; Kuno, H.; and Machiraju, V. 2004. WebServices. Concepts, Architectures, and Applications. Springer-Verlag.

[Alur & Dill, 1994] Alur, R., and Dill, D. L. 1994. A Theory of Timed Automata.Theor. Comput. Sci. 126(2):183–235.

[Alur, 1999] Alur, R. 1999. Timed Automata. In Proc. of CAV’99, volume 1633 ofLNCS, 8–22. Springer.

[Andonoff, Bouzguenda, & Hanachi, 2005] Andonoff, E.; Bouzguenda, L.; andHanachi, C. 2005. Specifying Workflow Web Services Using Petri Nets withObjects and Generating of Their OWL-S Specifications. In Proc. of EC-Web’05,volume 3590 of LNCS, 41–52. Springer.

[Ardissono, Goy, & Petrone, 2003] Ardissono, L.; Goy, A.; and Petrone, G. 2003.Enabling Conversations with Web Services. In Proc. of AAMAS’03, 819–826.

[Artikis, Sergot, & Pitt, 2002] Artikis, A.; Sergot, M. J.; and Pitt, J. 2002. Specify-ing Electronic Societies with the Causal Calculator. In Proc. of AOSE’02, volume2585 of LNCS, 1–15. Springer.

[Artikis, Sergot, & Pitt, 2003] Artikis, A.; Sergot, M. J.; and Pitt, J. 2003. An Exe-cutable Specification of an Argumentation Protocol. In Proc. of ICAIL’03, 1–11.

197

198 BIBLIOGRAPHY

[Aydin, Cicekli, & Cicekli, 2007] Aydin, O.; Cicekli, N.; and Cicekli, I. 2007. Auto-mated Web Services Composition with the Event Calculus. In Proc. of ESAW’07,volume 4995 of LNCS. Springer.

[Baader et al., 2003] Baader, F.; Calvanese, D.; McGuiness, D.; and Nardi, D., eds.2003. The Description Logics Handbook: Theory, Implementation, and Applica-tions. Cambridge University Press.

[Baader et al., 2005] Baader, F.; Lutz, C.; Milicic, M.; Sattler, U.; and Wolter, F.2005. A Description Logic Based Approach to Reasoning about Web Services. InProc. of WSS’05.

[Bacchus & Kabanza, 2000] Bacchus, F., and Kabanza, F. 2000. Using TemporalLogics to Express Search Control Knowledge for Planning. Artif. Intell. 116(1-2):123–191.

[Baeten & Weijand, 1990] Baeten, J. C. M., and Weijand, W. P. 1990. Process Alge-bra, volume 18 of Cambridge Tracts in Theoretical Computer Science. CambridgeUniversity Press.

[Baına et al., 2004] Baına, K.; Benatallah, B.; Casati, F.; and Toumani, F. 2004.Model-Driven Web Service Development. In Proc. of CAiSE’04, volume 3084 ofLecture Notes in Computer Science, 290–306. Springer.

[Balckburn, Rijek, & Venema, 2001] Balckburn, P.; Rijek, M. D.; and Venema, Y.2001. Modal Logic. Cambridge Tracts in Theoretical Computer Science 53.

[Ballinger et al., 2001] Ballinger, K.; Brittenham, P.; Malhotra, A.; Nagy, W. A.; andPharies, S. 2001. Web Services Inspection Language: Specification. http://www-128.ibm.com/developerworks/library/specification/ws-wsilspec/.

[Baral & Zhang, 2005] Baral, C., and Zhang, Y. 2005. Knowledge Updates: Seman-tics and Complexity Issues. Artif. Intell. 164:209–243.

[Berardi et al., 2003a] Berardi, D.; Calvanese, D.; De Giacomo, G.; Lenzerini, M.;and Mecella, M. 2003a. Automatic Composition of e-services that Export theirBehavior. In Proc. of ICSOC’03, volume 2910 of LNCS, 43–58. Springer.

[Berardi et al., 2003b] Berardi, D.; Calvanese, D.; De Giacomo, G.; and Mecella, M.2003b. Reasoning about Actions for e-Service Composition. In Proc. of ICAPS2003 Workshop on Planning for Web Services.

[Berardi et al., 2004] Berardi, D.; De Giacomo, G.; Lenzerini, M.; Mecella, M.; andCalvanese, D. 2004. Synthesis of Underspecified Composite e-Services based onAutomated Reasoning. In Proc. of ICSOC’04, 105–114. ACM.

BIBLIOGRAPHY 199

[Bergstra, Ponse, & Smolka, 2001] Bergstra, J. A.; Ponse, A.; and Smolka, S. A.,eds. 2001. Handbook of Process Algebra. Elsevier Science Inc.

[Berners-Lee, Hendler, & Lassila, 2001] Berners-Lee, T.; Hendler, J.; and Lassila,O. 2001. The Semantic Web. Scientific American 284(5):34–433.

[Bertino, Ferrari, & Squicciarini, 2003] Bertino, E.; Ferrari, E.; and Squicciarini,A. C. 2003. Trust-Chi: An XML Framework for Trust Negotiations. In Poc.of CMS’03, volume 2828 of LNCS, 146–157. Springer.

[Bertoli et al., 2001] Bertoli, P.; Cimatti, A.; Pistore, M.; Roveri, M.; and Traverso,P. 2001. MBP: a Model Based Planner. In Proc. IJCAI’01 Workshop on Planningunder Uncertainty and Incomplete Information.

[Bolognesi & Brinksma, 1989] Bolognesi, T., and Brinksma, E. 1989. Introductionto the ISO Specification Language LOTOS. In van Eijk, P. H. J.; Vissers, C. A.;and Diaz, M., eds., The Formal Description Technique LOTOS. Elsevier SciencePublishers North-Holland. 23–73.

[Bonchi et al., 2007] Bonchi, F.; Brogi, A.; Corfini, S.; and Gadducci, F. 2007. ABehavioural Congruence for Web Services. In Proc. of FSEN’07, volume 4767 ofLNCS, 240–256. Springer.

[Bonchi et al., 2008] Bonchi, F.; Brogi, A.; Corfini, S.; and Gadducci, F. 2008. Com-positional Specification of Web Services Via Behavioural Equivalence of Nets: ACase Study. In Proc. of Petri Nets’08, volume 5062 of LNCS, 52–71. Springer.

[Bonet & Geffner, 2001] Bonet, B., and Geffner, H. 2001. Heuristic Search Planner2.0. AI Magazine 22(23):77–80.

[Bonet, Loerincs, & Geffner, 1997] Bonet, B.; Loerincs, G.; and Geffner, H. 1997.A Robust and Fast Action Selection Mechanism for Planning. In Proc. ofAAAI/IAAI’97, 714–719.

[Bordeaux & Salaun, 2004] Bordeaux, L., and Salaun, G. 2004. Using Process Al-gebra for Web Services: Early Results and Perspectives. In Proc. of TES’04,volume 3324 of LNCS, 54–68. Springer.

[Bordeaux et al., 2004] Bordeaux, L.; Salaun, G.; Berardi, D.; and Mecella, M.2004. When are Two Web Services Compatible? In Proc. of TES’04, volume3324 of LNCS, 15–28. Springer.

[Boukadi et al., 2007] Boukadi, K.; Ghedira, C.; Maamar, Z.; and Benslimane, D.2007. Specification and Verification of Views over Composite Web Services UsingHigh Level Petri-Nets. In Proc. of ICEIS’07, 107–112.

200 BIBLIOGRAPHY

[Bull & Segerberg, 1994] Bull, R., and Segerberg, K. 1994. Basic Modal Logic. InHandbook of Philosofical Logic, vol. II: Extensions of Classical Logic. Dordretch:D. Rediel Publishing Company. 1–88.

[Bultan et al., 2003] Bultan, T.; Fu, X.; Hull, R.; and Su, J. 2003. ConversationSpecification: A New Approach to Design and Analysis of eE-Service Composi-tion. In Proc. of WWW’03, 403–410.

[Butler & Ferreira, 2004] Butler, M., and Ferreira, C. 2004. An Operational Seman-tics for StAC, a Language for Modelling Long-Running Business Transactions. InProc. of COORDINATION’04, volume 2949 of LNCS, 87–104. Springer.

[Campbell & Lifschitz, 2003] Campbell, J., and Lifschitz, V. 2003. Reinforcing aClaim in Commonsense Reasoning. In Working Notes of the AAAI Spring Sympo-sium on Logical Formalizations of Commonsense Reasoning.

[Carman, Serafini, & Traverso, 2003] Carman, M.; Serafini, L.; and Traverso, P.2003. Web Service Composition as Planning. In Proc. of ICAPS’03 Workshopon Planning for Web Services.

[Carpineti, Laneve, & Padovani, 2008] Carpineti, S.; Laneve, C.; and Padovani,L. 2008. PiDuce a Project for Experimenting Web Services Technologies.http://www.cs.unibo.it/PiDuce/.

[Castillo et al., 2006] Castillo, L. A.; Fernandez-Olivares, J.; Garcıa-Perez, O.; andPalao, F. 2006. Efficiently Handling Temporal Knowledge in an HTN Planner. InProc. of ICAPS’06, 63–72. AAAI.

[Chaki, Rajamani, & Rehof, 2002] Chaki, S.; Rajamani, S. K.; and Rehof, J. 2002.Types as models: model checking message-passing programs. In Proc. ofPOPL’02, 45–57.

[Chaochen, Hoare, & Ravn, 1991] Chaochen, Z.; Hoare, C. A. R.; and Ravn, A. P.1991. A Calculus of Durations. Inf. Process. Lett. 40(5):269–276.

[Chen & Yang, 2005] Chen, L., and Yang, X. 2005. Applying AI Planning to Se-mantic Web Services for Workflow Generation. In Proc. of SKG ’05. IEEE Com-puter Society.

[Chirichiello & Salaun, 2005] Chirichiello, A., and Salaun, G. 2005. Encoding Ab-stract Descriptions into Executable Web Services: Towards a Formal Develop-ment. In Proc. of WI’05, 457–463. IEEE Computer Society.

[Chirichiello & Salaun, 2006] Chirichiello, A., and Salaun, G. 2006. Formal De-velopment of Web Services. In Proc. of ECAI’06 Workshop on AI for ServiceComposition.

BIBLIOGRAPHY 201

[Chirichiello & Salaun, 2007] Chirichiello, A., and Salaun, G. 2007. Encoding Pro-cess Algebraic Descriptions of Web Services into BPEL. WIAS 5(4):419–434.

[Chiu, Cheung, & Hung, 2003] Chiu, D. K. W.; Cheung, S.-C.; and Hung, P. C. K.2003. Developing e-Negotiation Process Support by Web Services. In Proc. ofICWS’03, 97–103. CSREA Press.

[Chopra & Singh, 2003] Chopra, A. K., and Singh, M. P. 2003. NonmonotonicCommitment Machines. In Proc. of ACL’03, volume 2922 of LNCS, 183–200.Springer.

[Chopra & Singh, 2006] Chopra, A. K., and Singh, M. P. 2006. ContextualizingCommitment Protocol. In Proc. of AAMAS’06, 1345–1352. ACM.

[Cimatti et al., 1997] Cimatti, A.; Giunchiglia, F.; Giunchiglia, E.; and Traverso, P.1997. Planning via Model Checking: A Decision Procedure for AR. In Proc. ofECP’97, volume 1348 of LNCS, 130–142. Springer.

[Cimatti, Roveri, & Traverso, 1998] Cimatti, A.; Roveri, M.; and Traverso, P. 1998.Automatic OBDD-Based Generation of Universal Plans in Non-Deterministic Do-mains. In Proc. of AAAI/IAAI’98, 875–881.

[Clarke & Wing, 1996] Clarke, E. M., and Wing, J. M. 1996. Formal Methods: Stateof the Art and Future Directions. ACM Comput. Surv. 28(4):626–643.

[Clarke, Emerson, & Sistla, 1986] Clarke, E. M.; Emerson, E. A.; and Sistla, A. P.1986. Automatic Verification of Finite-State Concurrent Systems Using TemporalLogic Specifications. ACM Trans. Program. Lang. Syst. 8(2):244–263.

[Clarke, Grumberg, & Peled, 2000] Clarke, E. M.; Grumberg, O.; and Peled, D.2000. Model Checking. The MIT Press.

[Cleaveland & Smolka, 1999] Cleaveland, R., and Smolka, S. 1999. Encyclopediaof Electrical Engineering. John Wiley & Sons. chapter Process Algebra.

[Cleaveland, Li, & Sims, 2000] Cleaveland, R.; Li, T.; and Sims, S. 2000. The Con-currency Workbench of the New Century (Version 1.2). Department of ComputerScience, North Carolina State University.

[Cooney, Dumas, & Roe, 2006] Cooney, D.; Dumas, M.; and Roe, P. 2006. GPSL:A Programming Language for Service Implementation. In FASE’06, volume 3922of LNCS, 3–17. Springer.

[Curbera et al., 2002] Curbera, F.; Goland, Y.; Klein, J.; Leyman, F.; Roller, D.;Thatte, S.; and Weerawarana, S. 2002. Business Process Execution Language forWeb Services (BPEL4WS 1.0).

202 BIBLIOGRAPHY

[De Giacomo, Lesperance, & Levesque, 2000] De Giacomo, G.; Lesperance, Y.;and Levesque, H. J. 2000. ConGolog, a Concurrent Programming LanguageBased on the Situation Calculus. Artif. Intell. 121(1-2):109–169.

[Desai, Chopra, & Singh, 2007] Desai, N.; Chopra, A. K.; and Singh, M. P. 2007.Representing and Reasoning about Commitments in Business Processes. In Proc.of AAAI’07, 1328–1333. AAAI Press.

[Deutsch, Sui, & Vianu, 2004] Deutsch, A.; Sui, L.; and Vianu, V. 2004. Specifica-tion and Verification of Data-driven Web Services. In Proc. of PODS’04, 71–82.ACM.

[Dıaz et al., 2005] Dıaz, G.; Pardo, J. J.; Cambronero, M.-E.; Valero, V.; and Cuar-tero, F. 2005. Automatic Translation of WS-CDL Choreographies to Timed Au-tomata. In Proc. of EPEW/WS-FM’05, volume 3670 of LNCS, 230–242. Springer.

[DMAL, 2006] DMAL. 2006. OWL-S 1.2 Pre-Release.http://www.daml.org/services/owl-s/.

[Donini, Nardi, & Rosati, 2002] Donini, F. M.; Nardi, D.; and Rosati, R. 2002. De-scription Logics of Minimal Knowledge and Negation as Failure. ACM Trans. onComput. Log. 3:1–49.

[Edelkamp & Helmert, 2000] Edelkamp, S., and Helmert, M. 2000. On the Im-plementation of MIPS. In Proc. of AIPS’00 Workshop on Model-Theoretic Ap-proaches to Planning.

[Eiter et al., 2003] Eiter, T.; Faber, W.; Leone, N.; Pfeifer, G.; and Polleres, A. 2003.A Logic Programming Approach to Knowledge-state Planning, II: The DLVK

System. Artif. Intell. 144:157–211.

[Ellis, 1997] Ellis, C. A. 1997. Team Automata for Groupware Systems. In Proc. ofGROUP’97, 415–424. ACM.

[Erol, Hendler, & Nau, 1994] Erol, K.; Hendler, J. A.; and Nau, D. S. 1994. UMCP:A Sound and Complete Procedure for Hierarchical Task-network Planning. InProc. of AIPS’94, 249–254. Morgan Kaufmann.

[Fagin et al., 2003] Fagin, R.; Halpern, J. Y.; Moses, Y.; and Vardi, M. Y. 2003.Reasoning about Knowledge. MIT Press.

[Faratin, Sierra, & Jennings, 1997] Faratin, P.; Sierra, C.; and Jennings, N. R. 1997.Negotiation Decision Functions for Autonomous Agents. Int. J. of Robotics andAutonomous Systems 23(3-4):159–182.

BIBLIOGRAPHY 203

[Fatima, Wooldridge, & Jennings, 2004] Fatima, S. S.; Wooldridge, M.; and Jen-nings, N. R. 2004. An Agenda-based Framework for Multi-issue Negotiation.Artif. Intell. 152(1):1–45.

[Fernandez-Olivares et al., 2006] Fernandez-Olivares, J.; Castillo, L. A.; Garcıa-Perez, O.; and Palao, F. 2006. Bringing Users and Planning Technology Together.Experiences in SIADEX. In Proc. of ICAPS’06, 11–20. AAAI.

[Fernandez-Olivares et al., 2007] Fernandez-Olivares, J.; Garzon, T.; Castillo, L. A.;Garcıa-Perez, O.; and Palao, F. 2007. A Middle-Ware for the Automated Compo-sition and Invocation of Semantic Web Services Based on Temporal HTN PlanningTechniques. In Proc. of CAEPIA’07, volume 4788 of LNCS, 70–79. Springer.

[Ferrara, 2004] Ferrara, A. 2004. Web Services: A Process Algebra Approach. InProc. of ICSOC’04.

[Fikes & Nilsson, 1971] Fikes, R., and Nilsson, N. J. 1971. STRIPS: A New Ap-proach to the Application of Theorem Proving to Problem Solving. Artif. Intell.22(3/4):189–208.

[Finin et al., 1994] Finin, T. W.; Fritzson, R.; McKay, D. P.; and McEntire, R. 1994.KQML As An Agent Communication Language. In Proc. of CIKM’94, 456–463.ACM.

[FIPA, Foundation for Intelligent Physical Agents, 1999] FIPA, Foundation for In-telligent Physical Agents. 1999. FIPA Specification Part 2 - Agent Communi-cation Language. Available at http://www.fipa.org.

[Foster et al., 2003] Foster, H.; Uchitel, S.; Magee, J.; and Kramer, J. 2003. Model-based Verification of Web Service Compositions. In Proc. of ASE’03, 152–163.IEEE Computer Society.

[Fourman, 2000] Fourman, M. P. 2000. Propositional Planning. In Proc. of AIPS’00Workshop on Model-Theoretic Approaches to Planning.

[Fu, Bultan, & Su, 2003] Fu, X.; Bultan, T.; and Su, J. 2003. Conversation Proto-cols: A Formalism for Specification and Verification of Reactive Electronic Ser-vices. In Proc. of CIAA’03, volume 2759 of LNCS, 188–200. Springer.

[Fu, Bultan, & Su, 2004] Fu, X.; Bultan, T.; and Su, J. 2004. Analysis of InteractingBPEL Web Services. In Proc. of WWW’04, volume 3299 of LNCS. Springer.

[Fuxman et al., 2003] Fuxman, A.; Liu, L.; Pistore, M.; Roveri, M.; and Mylopou-los, J. 2003. Specifying and Analyzing Early Requirements: Some ExperimentalResults. In Proc. of RE’03, 105–114. IEEE Computer Society.

204 BIBLIOGRAPHY

[Garavel & Serwe, 2004] Garavel, H., and Serwe, W. 2004. State Space Reductionfor Process ALgebra Specifications. In Proc. of AMAST’04, volume 31162 ofLNCS. Springer.

[Garavel, Lang, & Mateescu, 2002] Garavel, H.; Lang, F.; and Mateescu, R. 2002.Compiler Construction Using LOTOS NT. In Proc. of CC’02, volume 2304 ofLNCS, 9–13. Springer.

[Gelfond & Lifschitz, 1993] Gelfond, M., and Lifschitz, V. 1993. Representing Ac-tion and Change by Logic Programs. J. of Logic Programming 17(2/3&42):301–321.

[Gelfond & Lifschitz, 1998] Gelfond, G., and Lifschitz, V. 1998. Action Languages.Electron. Trans. Artif. Intell. 2:193–210.

[Geppert, Kradolfer, & Tombros, 1995] Geppert, A.; Kradolfer, M.; and Tombros,D. 1995. Realization of Cooperative Agents using an Active Object-OrientedDatabase System. In Proc. of RRIDS’95, volume 985 of LNCS, 327–341.

[Gibbins, Harris, & Shadbolt, 2003] Gibbins, N.; Harris, S.; and Shadbolt, N. 2003.Agent-based Semantic Web Services. In Proc. of WWW’03, 710–717.

[Giunchiglia & Lifschitz, 1998] Giunchiglia, E., and Lifschitz, V. 1998. An Ac-tion Language Based on Causal Explanation: Preliminary Report. In Proc. ofAAAI/IAAI’98, 623–630.

[Giunchiglia & Traverso, 1999] Giunchiglia, F., and Traverso, P. 1999. Planning asModel Checking. In Proc. of ECP’99, volume 1809 of LNCS, 1–20. Springer.

[Giunchiglia et al., 2004] Giunchiglia, E.; Lee, J.; Lifschitz, V.; McCain, N.; andTurner, H. 2004. Nonmonotonic Causal Theories. Artif. Intell. 153(1-2):49–104.

[Giunchiglia, Kartha, & Lifschitz, 1997] Giunchiglia, E.; Kartha, G. N.; and Lifs-chitz, V. 1997. Representing Action: Indeterminacy and Ramifications. Artif.Intell. 95(2):409–438.

[Goldmam, Musliner, & Pelican, 2000] Goldmam, R. P.; Musliner, D. J.; and Peli-can, M. J. 2000. Using Model Checking to Plan Hard Real-Time Controllers. InProc. of AIPS’00 Workshop on Model-Theoretic Approaches to Planning.

[Hamadi & Benatallah, 2003] Hamadi, R., and Benatallah, B. 2003. A Petri Net-based Model for Web Service Composition. In Proc. of ADC’03, volume 17 ofCRPIT. Australian Computer Society.

[Hanson, Nandi, & Kumaran, 2002a] Hanson, J. E.; Nandi, P.; and Kumaran, S.2002a. Conversation-enabled Web Services for Agents and e-Business. In Proc.of IC’02, 791–796.

BIBLIOGRAPHY 205

[Hanson, Nandi, & Kumaran, 2002b] Hanson, J. E.; Nandi, P.; and Kumaran, S.2002b. Conversation Support for Business Process Integration. In Proc. ofEDOC’02, 65–74. IEEE Computer Society.

[Harrison, 2003] Harrison, J. 2003. Verification: Industrial Applications. Lecture at2003 Marktoberdorf Summer School, USA.

[He, Leung, & Jennings, 2003] He, M.; Leung, H.; and Jennings, N. R. 2003. AFuzzy-Logic Based Bidding Strategy for Autonomous Agents in Continuous Dou-ble Auctions. IEEE Trans. Knowl. Data Eng. 15(6):1345–1363.

[Hendricks, 2003] Hendricks, V. F. 2003. Epistemology Axiomatized. UNESCO.Paris.

[Hintikka, 1962] Hintikka, J. 1962. Knowledge and Belief: An Introduction to theLogic of the Two Notions. Corneli University Press.

[Hinz, Schmidt, & Stahl, 2005] Hinz, S.; Schmidt, K.; and Stahl, C. 2005. Trans-forming BPEL to Petri Nets. In Proc. of BPM’05, volume 3649, 220–235.

[Hoare, 1984] Hoare, C. A. R. 1984. Communicating Sequential Processes.Prentice-Hall.

[Hoey et al., 1999] Hoey, J.; St-Aubin, R.; Hu, A.; and Boutilier, C. 1999. SPUDD:Stochastic Planning using Decision Diagrams. In Proc. of UAI’99. Morgan Kauf-mann.

[Holldobler & Storr, 2000] Holldobler, S., and Storr, H.-P. 2000. Solving the Entail-ment Problem in the Fluent Calculus using Binary Decision Diagrams. In Proc. ofAIPS’00 Workshop on Model-Theoretic Approaches to Planning.

[Holzmann, 2003] Holzmann, G. 2003. The SPIN Model-Checker: Primer andReference Manual. Addison-Wesley.

[Horrocks et al., 2003] Horrocks, I.; Patel-Schneider, P. F.; Boley, H.; and Tabet, S.2003. OWL Rules Language. Technical report, Draft version.

[Hull et al., 2003] Hull, R.; Benedikt, M.; Christophides, V.; and Su, J. 2003. E-Services: a Look Behind the Curtain. In Proc. of PODS’03, 1–14. ACM.

[Hunter, 2004] Hunter, A. 2004. Adding Modal Operators to the Action LanguageA. In Proc. of NMR’04, 219–226.

[IBM, International Business Machines Corporation] International Business Ma-chines Corporation. http://www.ibm.com/.

[IBM, WebSphere] WebSphere. Available at http://www.ibm.com/websphere/.

206 BIBLIOGRAPHY

[INRIA, Validation de systemes Validation of systems] INRIA. Validation desystemes - Validation of systems. VASY. http://www.inrialpes.fr/vasy/.

[ISO, 1989] ISO. 1989. LOTOS: a Formal Description Technique Based on the Tem-poral Ordering of Observational Behaviour. Technical Report 8807, InternationalStandards Organisation.

[Jennings et al., 2001] Jennings, N. R.; Faratin, P.; Lomuscio, A.; Parsons, S.;Sierra, C.; and Wooldridge, M. 2001. Automated Negotiation: Prospects, Methodsand Challenges. Int. J. of Group Decision and Negotiation 10(2):199210.

[Jensen & Veloso, 2000] Jensen, R. M., and Veloso, M. M. 2000. OBDD-basedUniversal Planning for Synchronized Agents in Non-Deterministic Domains. J.Artif. Intell. Res. 13:189–226.

[Jensen, 1996] Jensen, K. 1996. Colored Petri Nets Basic Comcepts, Analysis Meth-ods and Practical Use. Volume 1,2, and 3, second edition edition.

[Kabanza, Barbeau, & St.-Denis, 1997] Kabanza, F.; Barbeau, M.; and St.-Denis, R.1997. Planning Control Rules for Reactive Agents. Artif. Intell. 95(1):67–11.

[Kautz & Selman, 1992] Kautz, H., and Selman, B. 1992. Planning as Satisfiability.In Proc. of ECAI’92, 359–363.

[Kaynar et al., 2006] Kaynar, D. K.; Lynch, N. A.; Segala, R.; and Vaandrager, F.2006. The Theory of Timed I/O Automata. Synthesis Lectures on ComputerScience.

[Kazhamiakin, Pandya, & Pistore, 2005] Kazhamiakin, R.; Pandya, P. K.; and Pis-tore, M. 2005. Timed Modelling and Analysis in Web Service Compositions. InProc. of WESC’05. IEEE.

[Kesim & Sergot, 1996] Kesim, F. N., and Sergot, M. J. 1996. Implementing anObject-oriented Deductive Database Using Temporal Reasoning. J. of DatabaseManagement 7(4):21–34.

[Koehler, 1998] Koehler, J. 1998. Planning under Resource Constraints. In Proc. ofECAI’98, 489–493.

[Koshkina & van Breugel, 2003] Koshkina, M., and van Breugel, F. 2003. Verifica-tion of Business Processes for Web Services. Report CS-2003-11, York University.

[Kowalski & Sergot, 1986] Kowalski, R. A., and Sergot, M. J. 1986. A Logic-basedCalculus of Events. New Generation Comput. 4(1):67–95.

BIBLIOGRAPHY 207

[Kozen & Tiuryn, 1990] Kozen, D., and Tiuryn, J. 1990. Logics of Programs. InLeeuwen, J. V., ed., Handbook of Theoretical Computer Science. Elsevier. chapterFormal Methods and Semantics, 789–840.

[KRONOS, 2002] 2002. Kronos. Available at http://www-verimag.imag.fr/TEMPORISE/kronos/.

[Kvarnstrom, Doherty, & Haslum, 2000] Kvarnstrom, J.; Doherty, P.; and Haslum,P. 2000. Extending TALplanner with Concurrency and Resources. In Proc. ofECAI’00, 501–505. IOS Press.

[Labrou, Finin, & Peng, 1999] Labrou, Y.; Finin, T.; and Peng, Y. 1999. The currentlandscape of Agent Communication Languages. Intelligent Systems 14(2).

[Lago, Pistore, & Traverso, 2002] Lago, U. D.; Pistore, M.; and Traverso, P. 2002.Planning with a Language for Extended Goals. In Proc. of AAAI/IAAI’02, 447–454.

[Larsen, Pettersson, & Yi, 1997] Larsen, K. G.; Pettersson, P.; and Yi, W. 1997.UPPAAL in a Nutshell. Int. J. on Software Tools for Technology Transfer 1(1-2):134–152.

[Lau & Mylopoulos, 2004] Lau, D., and Mylopoulos, J. 2004. Designing Web Ser-vices with Tropos. In Proc. of ICWS’04, 306–314. IEEE Computer Society.

[Lazovik, Aiello, & Papazoglou, 2003] Lazovik, A.; Aiello, M.; and Papazoglou,M. P. 2003. Planning and Monitoring the Execution of Web Service Requests.In Proc. of ICSOC’03, volume 2910 of LNCS, 335–350. Springer.

[Lee, 2005] Lee, J. 2005. Automated Reasoning About Actions. Ph.D. Dissertation,University of Texas.

[Lemmon & Scott, 1977] Lemmon, E. J., and Scott, D. 1977. An Introduction toModal Logic. Oxford: Basil Blackwell Publishers.

[Levesque et al., 1997] Levesque, H. J.; Reiter, R.; Lesperance, Y.; Lin, F.; andScherl, R. B. 1997. GOLOG: A Logic Programming Language for DynamicDomains. J. of Log. Program. 31(1-3):59–83.

[Leymann, 2001a] Leymann, F. 2001a. Managing Business Processes via WorkflowTechnology. Tutorial at VLDB’01, Italy.

[Leymann, 2001b] Leymann, F. 2001b. Web Service Flow Language Version 1.0.Technical report, International Business Machines Corporation (IBM).

[Lifschitz & Ren, 2004] Lifschitz, V., and Ren, W. 2004. Irrelevant Actions in PlanGeneration. In Proc. of IBERAMIA’04, 71–78.

208 BIBLIOGRAPHY

[Lifschitz & Turner, 1999] Lifschitz, V., and Turner, H. 1999. Representing Tran-sition Systems by Logic Programs. In Proc. of LPNR’99, volume 1730 of LNCS,92–106. Springer.

[Lifschitz, 1997] Lifschitz, V. 1997. On the Logic of Causal Explanation (ResearchNote). Artif. Intell. 96(2):451–465.

[Lifschitz, 2000] Lifschitz, V. 2000. Missionaries and Cannibals in the Causal Cal-culator. In Proc. of KR’00, 85–96.

[Lin & Chang, 2001] Lin, F., and Chang, K. 2001. A Multiagent Framework forAutomated Online Bargaining. IEEE Intelligent Systems 16(4):41–47.

[Lobo, Mendez, & Taylor, 2001] Lobo, J.; Mendez, G.; and Taylor, S. R. 2001.Knowledge and the Action Description Language A. TPLP 1:129–184.

[Lomuscio, Wooldridge, & Jennings, 2003] Lomuscio, A. R.; Wooldridge, M.; andJennings, N. R. 2003. A Classification Scheme for Negotiation in ElectronicCommerce. Int. J. of Group Decision and Negotiation 12(1):31–56.

[Lukasiewicz, Nardi, & Rosati, 2004] Lukasiewicz, L. I. T.; Nardi, D.; and Rosati,R. 2004. Reasoning about Actions with Sensing under Qualitative and Probabilis-tic Uncertainty. In Proc. ECAI’04, 818–822. IOS Press.

[Lynch & Tuttle, 1989] Lynch, N. A., and Tuttle, M. R. 1989. An Intorduction toInput/Output Automata. CWI Quartely 2(3):219–246.

[Lynch, 2003] Lynch, N. A. 2003. Input/Output Automata: Basic, Timed, Hybrid,Probabilistic, Dynamic, .. In Proc of CONCUR’03, volume 2761 of LNCS, 187–188. Springer.

[Maamar, Kouadri, & Yahyaoui, 2004] Maamar, Z.; Kouadri, S.; and Yahyaoui, H.2004. A Web Services Composition Approach Based on Software Agents andContext. In Proc. of SAC ’04, 1619–1623. ACM.

[Manna & Pnueli, 1995] Manna, Z., and Pnueli, A. 1995. Temporal Verification ofReactive Systems: Safety. Springer.

[Mantell, 2003] Mantell, K. 2003. From UML to BPEL. IBM DeveloperWorksReport.

[Martens, 2005] Martens, A. 2005. Analyzing Web Service based Business Pro-cesses. In Proc. of FASE’05, volume 3442 of LNCS. Springer.

[Martınez & Lesperance, 2004] Martınez, E., and Lesperance, Y. 2004. Web ServiceComposition as a Planning Task: Experiments using Knowledge-Based Planning.

BIBLIOGRAPHY 209

In Proc. of ICAPS’04 Workshop on Planning and Scheduling for Web and GridServices.

[Mateescu & Sighireanu, 2003] Mateescu, R., and Sighireanu, M. 2003. EfficientOn-the-Fly Model-Checking for Regular Alternation-Free Mu-Calculus. Scienceof Computer Programming 46(3):255–281.

[Maximilien & Singh, 2003] Maximilien, E. M., and Singh, M. P. 2003. Agent-based Architecture for Automatic Web Service Selection. In Proc. of WSABE’03.

[McCain & Turner, 1997] McCain, N., and Turner, H. 1997. Causal Theories ofAction and Change. In Proc. of AAAI/IAAI’97, 460–465.

[McCain & Turner, 1998] McCain, N., and Turner, H. 1998. Satisfiability Planningwith Causal Theories. In Proc. of KR’98, 212–223.

[McCain, 1997] McCain, N. 1997. Causality in Commonsense Reasoning AboutActions. Ph.D. Dissertation, University of Texas.

[McCarthy & Hayes, 1969] McCarthy, J., and Hayes, P. J. 1969. Some Philosophi-cal Problems from the Standpoint of Artificial Intelligence. Machine Intelligence4:463–502.

[McCharty, 1998] McCharty, J. 1998. Elaboration Tolerance. http://www-formal.stanford.edu/jmc/elaboration/elaboration.html. In progress.

[McDermott & Dou, 2002] McDermott, D. V., and Dou, D. 2002. RepresentingDisjunction and Quantifiers in RDF. In Proc. of ISWC’02, volume 2342 of LNCS,250–263. Springer.

[McDermott et al., 1998] McDermott, D.; Ghallab, M.; Howe, A.; Knoblock, C.;Ram, A.; Veloso, M.; Weld, D.; and Wilkins, D. 1998. PDDL – The PlanningDomain Definition Langage. Technical Report CVC TR-98-003/DCS TR-1165,Yale Center for Computational Vision and Control.

[McDermott, 1996] McDermott, D. V. 1996. A Heuristic Estimator for Means-EndsAnalysis in Planning. In Proc. of AIPS’96, 142–149.

[McDermott, 1999] McDermott, D. V. 1999. Using Regression-Match Graphs toControl Search in Planning. Artif. Intell. 109(1-2):111–159.

[McDermott, 2002] McDermott, D. V. 2002. Estimated-Regression Planning forInteractions with Web Services. In Proc. of AIPS’02, 204–211. AAAI.

[McIlraith & Son, 2002] McIlraith, S. A., and Son, T. C. 2002. Adapting Golog forComposition of Semantic Web Services. In Proc. of KR’02, 482–496. MorganKaufmann.

210 BIBLIOGRAPHY

[McIlraith, Son, & Zeng, 2001] McIlraith, S. A.; Son, T. C.; and Zeng, H. 2001.Semantic Web Services. IEEE Intelligent Systems 16(2):46–53.

[McMillan, 1993] McMillan, K. 1993. Symbolic Model Checking. Kluwer Aca-demic Publ.

[Meredith & Bjorg, 2003] Meredith, G., and Bjorg, S. 2003. Contracts and Types.CACM 46(10):41–47.

[Microsoft, Microsoft Corporation] Microsoft Corporation.http://www.microsoft.com/.

[Microsoft, Net] .Net. Available at http://www.microsoft.com/net/.

[Milner, 1989] Milner, R. 1989. Communication and Concurrency. InternationalSeries in Computer Science. Prentice Hall.

[Murata, 1989] Murata, T. 1989. Petri Nets: Properties, Analysis and Applications.In Proc. of IEEE’89, 541–580.

[Nakajima, 2002] Nakajima, S. 2002. Model-checking Verification for Reliable WebService. In Proc. of OOWS’02.

[Narayanan & McIlraith, 2003] Narayanan, S., and McIlraith, S. 2003. Analysis andSimulation of Web Services. Computer Networks 42(5):675–693.

[Nau et al., 2001] Nau, D. S.; Munoz-Avila, H.; Cao, Y.; Lotem, A.; and Mitchell, S.2001. Total-Order Planning with Partially Ordered Subtasks. In Proc. of IJCAI’01,425–430.

[Ng & Butler, 2002] Ng, M. Y., and Butler, M. 2002. Tool Support for VisualizingCSP in UML. In Proc. ICFEM’02, volume 2495 of LNCS, 287–298. Springer.

[NuSMV, 2008] 2008. NuSMV: A New Symbolic Model Checker. Available athttp://nusmv.irst.itc.it/.

[OASIS, 2002] OASIS. 2002. UDDI Version 2.04 API Specification.http://uddi.org/pubs/ProgrammersAPI v2.htm.

[OASIS, 2007] OASIS. 2007. Web Service Business Process Execution LanguageVersion 2.0. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html.

[OASIS, Organization for the Advancement of Structured Information Standards]Organization for the Advancement of Structured Information Standards.http://www.oasis-open.org/.

[Oracle, BPEL Process Manager] Oracle. BPEL Process Manager. Available athttp://www.oracle.com/technology/products/ias/bpel/.

BIBLIOGRAPHY 211

[Ort, 2005] Ort, E. 2005. Service-Oriented Architecture and Web Services: Con-cepts, Technologies, and Tools. Technical Articles and Tips, Sun Developer Net-work (SDN).

[Papazoglou et al., 2007] Papazoglou, M. P.; Traverso, P.; Dustdar, S.; and Ley-mann, F. 2007. Service-Oriented Computing: State of the Art and ResearchChallenges. IEEE Computer 40(11):38–45.

[Parrow, 2001] Parrow, J. 2001. An Introduction to the π-Calculus. In Bergstra, J.;Ponse, A.; and Smolka, S., eds., Handbook of Process Algebra. Elsevier. chapter 8,479–543.

[Pednault, 1989] Pednault, E. P. D. 1989. ADL: Exploring the Middle Ground Be-tween STRIPS and the Situation Calculus. In Proc. of KR’89, 324–332.

[Peer, 2004] Peer, J. 2004. A PDDL Based Tool for Automatic Web Service Compo-sition. In Proc. of PPSWR’04, volume 3208 of Lecture Notes in Computer Science,149–163. Springer.

[Peer, 2005] Peer, J. 2005. Web Service Composition as AI Planning - a Survey.Technical report, Univ. of St. Gallen, Switzerland.

[Peltz, 2003] Peltz, C. 2003. Web Services Orchestration and Choreography. IEEEComputer 36(10):46–52.

[Peterson, 1981] Peterson, J. L. 1981. Petri Net Theory and the Modeling of Systems.Englewood Cliffs: Prentice-Hall, Inc.

[Petri, 1962] Petri, C. A. 1962. Kommunikation mit Automaten. Schriften des IIMNr. 2, Bonn: Institut fur Instrumentelle Mathematik. Second Edition:, New York:Griffiss Air Force Base, Technical Report RADC-TR-65377, Vol.1, 1966, Pages:Suppl. 1, English translation. 2.2.1.

[Petrick & Bacchus, 2002] Petrick, R. P. A., and Bacchus, F. 2002. A Knowledge-Based Approach to Planning with Incomplete Information and Sensing. In Proc.of AIPS’02, 212–222.

[Pistore et al., 2004] Pistore, M.; Barbon, F.; Bertoli, P.; Shaparau, D.; and Traverso,P. 2004. Planning and Monitoring Web Service Composition. In Proc. ofAIMSA’04, volume 3192 of LNCS, 106–115. Springer.

[Pistore et al., 2005] Pistore, M.; Marconi, A.; Bertoli, P.; and Traverso, P. 2005.Automated Composition of Web Services by Planning at the Knowledge Level. InProc. of IJCAI’05, 1252–1259.

212 BIBLIOGRAPHY

[Pistore, Roveri, & Busetta, 2004] Pistore, M.; Roveri, M.; and Busetta, P. 2004.Requirements-Driven Verification of Web Services. In Proc. of WS-FM’04, vol-ume 105, 95–108.

[Pistore, Traverso, & Bertoli, 2005] Pistore, M.; Traverso, P.; and Bertoli, P. 2005.Automated Composition of Web Services by Planning in Asynchronous Domains.In Proc. of ICAPS’05, 2–11. AAAI.

[Pnueli, 1977] Pnueli, A. 1977. The Temporal Logic of Programs. In Proc ofFOCS’77, 46–57. IEEE.

[Pokorny & Ramakrishnan, 2004] Pokorny, L. R., and Ramakrishnan, C. R. 2004.Modeling and Verification of Distributed Autonomous Agents Using Logic Pro-gramming. In DALT’04, volume 3476 of LNCS, 148–165. Springer.

[Rao & Su, 2004] Rao, J., and Su, X. 2004. A Survey of Automated Web ServiceComposition Methods. In Proc. of SWSWPC’04, volume 3387 of LNCS, 43–54.Springer.

[Reisig, 1985] Reisig, W. 1985. Petri Nets: An Introduction. Springer-Verlag.

[Reiter, 1992] Reiter, R. 1992. Formalizing Database Evolution in the SituationCalculus. In Proc. of FGCS’92, 600–609.

[Richards et al., 2003] Richards, D.; Splunter, S. V.; Brazier, F.; and Sabou, M.2003. Composing Web Services using an Agent Factory. In Proc. of WSABE’03.

[Rouached, Perrin, & Godart, 2006] Rouached, M.; Perrin, O.; and Godart, C. 2006.Towards Formal Verification of Web Service Composition. In Proc. of BPM’06,volume 4102 of LNCS, 257–273. Springer.

[RuleML, The Rule Markup Initiative] The Rule Markup Initiative.http://www.dfki.uni-kl.de/ruleml/.

[Salaun, Bordeaux, & Schaerf, 2006] Salaun, G.; Bordeaux, L.; and Schaerf, M.2006. Describing and Reasoning on Web Services using Process Algebra. IJBPIM1(2):116–128.

[Salaun, Ferrara, & Chirichiello, 2004] Salaun, G.; Ferrara, A.; and Chirichiello,A. 2004. Negotiation among Web Services using LOTOS/CADP. In Proc. ofECOWS’04, volume 3250 of LNCS, 198–212. Springer.

[Schneider et al., 1992] Schneider, S.; Davies, J.; Jackson, D. M.; Reed, G. M.;Reed, J. N.; and Roscoe, A. W. 1992. Timed CSP: Theory and Practice. InProc. of REX Workshop on Real-Time: Theory in Practice, 640–675.

BIBLIOGRAPHY 213

[Sergot & Craven, 2006] Sergot, M. J., and Craven, R. 2006. The Deontic Com-ponent of Action Language nC+. In Proc. of DEON’06, volume 4048 of LNCS,222–237. Springer.

[Shanahan, 2000] Shanahan, M. 2000. An Abductive Event Calculus Planner. J.Log. Program. 44(1-3):207–240.

[Sibertin-Blanc, 1986] Sibertin-Blanc, C. 1986. High level Petri Nets with DataStructure. In Proc. of the 6th Workshop on Petri Nets.

[Singh, 1998] Singh, M. P. 1998. Agent Communication Languages: Rethinking thePrinciples. IEEE Computer 31(12):40–47.

[Sirin et al., 2004] Sirin, E.; Parsia, B.; Wu, D.; Hendler, J. A.; and Nau, D. S. 2004.HTN planning for Web Service composition using SHOP2. J. Web Sem. 1(4):377–396.

[Skogan, Grønmo, & Solheim, 2004] Skogan, D.; Grønmo, R.; and Solheim, I.2004. Web Service Composition in UML. In Proc. of EDOC’04, 47–57. IEEEComputer Society.

[Skogsrud, Benatallah, & Casati, 2003] Skogsrud, H.; Benatallah, B.; and Casati, F.2003. Model-Driven Trust Negotiation for Web Services. IEEE Internet Comput-ing 7(6):45–52.

[Skogsrud, Benatallah, & Casati, 2004] Skogsrud, H.; Benatallah, B.; and Casati, F.2004. Trust-Serv: Model-driven Lifecycle Management of Trust Negotiation Poli-cies for Web Services. In Proc. of WWW’04, 53–62. ACM.

[Son & Baral, 2001] Son, T. C., and Baral, C. 2001. Formalizing Sensing Actions:a Transition Function Based Approach. Artif. Intell. 125:19–91.

[Spielmann, 2000] Spielmann, M. 2000. Abstract State Machines: VerificationProblems and Complexity. Ph.D. Dissertation, RWTH Aachen.

[Spielmann, 2003] Spielmann, M. 2003. Verification of Relational Transducers forElectronic Commerce. J. Comput. Syst. Sci. 66(1):40–65.

[Stathis, Lekeas, & Kloukinas, 2006] Stathis, K.; Lekeas, G.; and Kloukinas, C.2006. Competence Checking for the Global E-Service Society Using Games. InProc. of ESAW’06, volume 4457 of LNCS, 384–400. Springer.

[Sun Microsystem, J2EE] J2EE. Available at http://java.sun.com/javaee/.

[Sun Microsystem, ONE] ONE. Available athttp://www.sun.com/aboutsun/media/presskits/sunone/.

214 BIBLIOGRAPHY

[TAG at Austin, CCALC] CCALC. Available athttp://www.cs.utexas.edu/users/tag/cc/.

[ter Beek et al., 2003] ter Beek, M. H.; Ellis, C. A.; Kleijn, J.; and Rozenberg, G.2003. Synchronizations in Team Automata for Groupware Systems. ComputerSupported Cooperative Work 12(1):21–69.

[Thatte, 2001] Thatte, S. 2001. XLANG: Web Services for Business Process Design.Technical report, Microsoft Corporation.

[Trajcevski, Baral, & Lobo, 2001] Trajcevski, G.; Baral, C.; and Lobo, J. 2001. For-malizing and Reasoning About the Requirements Specifications of Workflow Sys-tems. Int. J. Cooperative Inf. Syst. 10(4):483–507.

[Turner, Budgen, & Brereton, 2003] Turner, M.; Budgen, D.; and Brereton, P. 2003.Turning Software into a Service. IEEE Computer 36(10):38–44.

[UPPAL, 2007] 2007. Uppal. Available at http://www.uppaal.com/.

[van Glabbeek & Weijland, 1996] van Glabbeek, R. J., and Weijland, W. P. 1996.Branching Time and Abstraction in Bisimulation Semantics. J. of the ACM43(3):555–600.

[VASY, CADP] CADP. Available at http://www.inrialpes.fr/vasy/cadp/.

[Viroli, 2004] Viroli, M. 2004. Towards a Formal Foundation to Orchestration Lan-guages. In Proc. of WS-FM’04, volume 105, 51–71.

[W3C-choreography-WG, 2004] W3C-choreography-WG. 2004. Web ServicesChoreography Requirements. http://www.w3.org/TR/ws-chor-reqs/.

[W3C, 1999a] W3C. 1999a. XML Path Language (XPath) Version 1.0.http://www.w3.org/TR/xpath/.

[W3C, 1999b] W3C. 1999b. XSL Transformations (XSLT) Version 1.0.http://www.w3.org/TR/xslt/.

[W3C, 2000] W3C. 2000. Extensible Markup Language (XML) 1.0 (Fourth Edi-tion). http://www.w3.org/TR/xml/.

[W3C, 2001a] W3C. 2001a. Web Services Description Language (WSDL) 1.1.http://www.w3.org/TR/wsdl/.

[W3C, 2001b] W3C. 2001b. XML Schema part 0: Primer Second Edition.http://www.w3.org/TR/xmlschema-0/.

[W3C, 2002a] W3C. 2002a. Web Service Choreography Interface (WSCI) 1.0.http://www.w3.org/TR/wsci/.

BIBLIOGRAPHY 215

[W3C, 2002b] W3C. 2002b. Web Services Conversation Language (WSCL) 1.0.http://www.w3.org/TR/wscl10/.

[W3C, 2004a] W3C. 2004a. OWL - Ontology Web Language.http://www.w3.org/TR/owl-features/.

[W3C, 2004b] W3C. 2004b. RDF Vocabulary Description Language 1.0: RDFSchema. http://www.w3.org/TR/rdf-schema/.

[W3C, 2004c] W3C. 2004c. Web Services Architecture. http://www.w3.org/TR/ws-arch/.

[W3C, 2005] W3C. 2005. Web Services Choreography Description Language Ver-sion 1.0. http://www.w3.org/TR/ws-cdl-10/.

[W3C, 2007a] W3C. 2007a. SOAP Version 1.2 Part 1: Messaging Framework (Sec-ond Edition). http://www.w3.org/TR/soap12-part1/.

[W3C, 2007b] W3C. 2007b. Web Services Description Language (WSDL) Version2.0 Part 0: Primer. http://www.w3.org/TR/wsdl20-primer/.

[W3C, 2007c] W3C. 2007c. Web Services Description Language (WSDL) Version2.0 Part 1: Core Language. http://www.w3.org/TR/wsdl20/.

[W3C, 2007d] W3C. 2007d. Web Services Description Language (WSDL) Version2.0 Part 2: Adjuncts. http://www.w3.org/TR/wsdl20-adjuncts/.

[W3C, 2007e] W3C. 2007e. XQuery 1.0: An XML Query Language.http://www.w3.org/TR/xquery/.

[W3C, World Wide Web Consortium] World Wide Web Consortium.http://www.w3.org/.

[Walton, 2004] Walton, C. D. 2004. Model Checking Multi-Agent Web Services. InProc. of the AAI Spring Symposium on Semantic Web Services.

[Webber & Parastatidis, 2005] Webber, J., and Parastatidis, S. 2005. The SOAPService Description Language. http://www.ssdl.org/.

[Wooldridge & Parsons, 2000] Wooldridge, M., and Parsons, S. 2000. Languagesfor Negotiation. In Proc. of ECAI’00, 393–400. IOS Press.

[Yang et al., 2006] Yang, Y.; Tan, Q.; Xiao, Y.; Liu, F.; and Yu, J. 2006. TransformBPEL Workflow into Hierarchical CP-Nets to Make Tool Support for Verification.In Poc. of APWeb’06, volume 3841 of LNCS, 275–284. Springer.

216 BIBLIOGRAPHY

[Yolum & Singh, 2003] Yolum, P., and Singh, M. P. 2003. Reasoning about Com-mitments in the Event Calculus: An Approach for Specifying and Executing Pro-tocols. Ann. Math. Artif. Intell. 42(1-3):227–253.

[Yovine, 2002] Yovine, S. 2002. Kronos: A Verification Tool for Real-Time Sys-tems. (Kronos User’s Manual Release 2.2).

[Yu & Reiff-Marganiec, 2006] Yu, H., and Reiff-Marganiec, S. 2006. Semantic WebServices Composition via Planning as Model Checking. Technical Report CS-06-003, University of Leicester.

[Zhang et al., 2004] Zhang, J.; Zhang, S.; Cao, J.; and Mou, Y. 2004. ImprovedHTN Planning Approach for Service Composition. In Proc. of IEEE SCC’04,609–612. IEEE Computer Society.

[Zhovtobryukh, 2007] Zhovtobryukh, D. 2007. A Petri Net-based Approach forAutomated Goal-Driven Web Service Composition. Simulation 83(1):33–63.

[Zlotkin & Rosenschein, 1996] Zlotkin, G., and Rosenschein, J. S. 1996. Mecha-nisms for Automated Negotiation in State Oriented Domains. J. Artif. Intell. Res.(JAIR) 5:163–238.

two formal approaches for web services: process algebras & action

Documents