AI for Service Composition

In the last years, there has been increasing interest in service composition.The key idea is that existing distributed services can be selected and combinedinto suitable workflows of tasks, in order to provide new functionalities or appli-cations. Service composition has the potentiality to revolutionize the classicalapproaches to data integration and business process integration, reducing devel-opment time and effort. Standards and platforms based on service models andsupporting service composition have been developed in different frameworks,including web services, grid services, and agent services.

AI techniques have been used to support different key aspects of the man-agement of service compositions, including tasks such as their generation, allo-cation of resources, execution, monitoring and repair. For instance, knowledgerepresentation techniques have been exploited to provide suitable semantic an-notations of services; planning has been applied to an automatic generation ofthe workflows composing the services; scheduling has been applied to resourceallocation and workflow optimization; and agent techniques have been appliedto support a dynamic adaptation of the workflows.

However, many issues remain to be resolved. These include (1) forming pre-cise, clean and general characterizations of service compositions, and identifyingthe most appropriate ways to formalize the critical steps in their life cycle; (2)determining suitable languages to represent service compositions in all their rel-evant aspects and finding ways of bridging the gap between service compositionlanguages used in the industry and languages exploited in AI; (3) highlight-ing important challenges for AI to be effective in practical, industrial contexts,proposing techniques and tools able to address these challenges in realistic sce-narios, and finding architectures for integrating such techniques in a robust,integrated environment. The 8 full papers and 4 short papers appearing in thisproceedings address these and other relevant problems in service composition.

This workshop has been organized under the MIUR-FIRB projectRBNE0195K5 ”Knowledge Level Automated Software Engineering”. It is thecontinuation of three successful workshops at ICAPS 2003, ICAPS 2004, andAAAI 2005, and aims at becoming a regular meeting place for researcher andpractitioners working in the field of AI and in the area of service composition.

Marco Pistore

Jose Luis Ambite

Jim Blythe

Jana Koehler

Sheila McIlraith

Biplav Srivastava

August 28, 2006

i

Organization

Program Chair

Marco Pistore, University of Trento, Italy

Organizing Committee

Jose Luis Ambite, USC Information Sciences Institute, USAJim Blythe, USC Information Sciences Institute, USAJana Koehler, IBM Research Laboratory, SwitzerlandSheila McIlraith, University of Toronto, CanadaBiplav Srivastava, IBM Research Laboratory, India

Local Organization

Annapaola Marconi, ITC-irst, Trento, Italy

ii

Table of Contents

A Logic For Decidable Reasoning About ServicesY. Gu, M. Soutchanski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

A Service Selection Model to Improve Composition ReliabilityN. Kokash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Abduction for Specifying and Verifying Web Service and ChoreographiesF. Chesani, P. Mello, M. Montali, M. Alberti, M. Gavanelli, E. Lamma, S.

Storari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

An Immune System-Inspired Approach for Composite Web Services ReuseR. Bova, S. Hassas, S. Benbernou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Designing Security Requirements Models through PlanningV. Bryl, F. Massacci, J. Mylopoulos, N. Zannone . . . . . . . . . . . . . . . . . . . . . . . . . .28

Formal Development of Web ServicesA. Chirichiello, G. Salaun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Implicit vs. Explicit Data-flow Requirements in Web Service Composition GoalsA. Marconi, M. Pistore, P. Traverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Web Service Composition in a Temporal Action LogicL. Giordano, A. Martelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

A Composition oriented proposal to describe functionalities of devicesS. Tandabany, M. Rousset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Automatic Web Service Composition: Service-tailored vs. Client-tailored Ap-proachesD. Berardi, G. De Giacomo, M. Mecella, D. Calvanese . . . . . . . . . . . . . . . . . . . . 63

Causal link matrix and AI planning: a model for Web service compositionF. Lecue, A. Leger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Using Quantified Boolean Logics to Verify Web Service Composition Require-mentsE. Giunchiglia, M. Narizzano, M. Pistore, M. Roveri, P. Traverso . . . . . . . . . 69

iii

iv

1

A Logic For Decidable Reasoning About ServicesYilan Gu1 and Mikhail Soutchanski2

Abstract. We consider a modified version of the situation calculusbuilt using a two-variable fragment of the first-order logic extendedwith counting quantifiers. We mention several additional groups ofaxioms that need to be introduced to capture taxonomic reasoning.We show that the regression operator in this framework can be de-fined similarly to regression in the Reiter’s version of the situationcalculus. Using this new regression operator, we show that the pro-jection problem (that is the main reasoning task in the situation cal-culus) is decidable in the modified version. Wemention possible ap-plications of this result to formalization of Semantic Web services.

1 IntroductionTheSemantic Web community makessignificant efforts toward inte-gration of Semantic Web technology with the ongoing work on webservices. These efforts include use of semantics in the discovery,composition, and other aspects of web services. Web service com-position is related to the task of designing a suitable combination ofavailable component services into a composite service to satisfy aclient request when there is no single service that can satisfy this re-quest [16]. Thisproblem attracted significant attention of researchersboth in academiaand in industry. A major step in thisdirection iscre-ation of ontologies for web services, in particular, OWL-Sthat mod-els web services as atomic or complex actions with preconditionsand effects. An emerging industry standard BPEL4WS (BusinessProcess Execution Language for Web Services) provides the basisfor manually specifying composite web services using a procedu-ral language. However, in comparison to error-prone manual servicecompositions, (semi)automated servicecomposition promisessignif-icant flexibility in dealing with availableservicesand also accommo-dates naturally thedynamics and openness of service-oriented archi-tectures. The problem of theautomated composition of web servicesis often formulated in terms similar to a planning problem in AI:given a description of a client goal and a set of component services(that can be atomic or complex), find a composition of services thatachieves the goal [20, 21, 26, 24]. Despite that several approachesto solving this problem have already been proposed, many issues re-main to be resolved, e.g., how to give well-defined and general char-acterizationsof servicecompositions, how to computeall effectsandside-effects on the world of every action included in composite ser-vice, and other issues. Other reasoning problems, well-known in AI,that can be relevant to service composition and discovery are exe-cutability and projection problems. Executability problem requiresdetermining whether preconditions of all actions included in a com-posite service can be satisfied given incomplete information aboutthe world. Projection problem requires determining whether a cer-tain goal condition is satisfied after the execution of all componentservices given an incomplete information about the current state. Inthis paper we would like to concentrate on the last problem because

1 Dept. of Computer Science, University of Toronto, Canada, email: yi-lan@cs.toronto.edu

2 Department of Computer Science, Ryerson University, Canada, email:mes@scs.ryerson.ca

it is an important prerequisite for planning and execution monitor-ing tasks, and for simplicity we start with sequential compositionsof the atomic actions (services) only (we mention complex actionsin the last section). More specifically, following several previous ap-proaches [20, 21, 5, 26, 16], we choose the situation calculus as anexpressive formal language for specification of actions. However, weacknowledge openness of the world and represent incomplete infor-mation about an initial state of the world by assuming that it is char-acterized by a predicate logic theory in the general syntactic form.

The situation calculus is a popular and well understood predicatelogic language for reasoning about actions and their effects [25]. Itserves as a foundation for the Process Specification Language (PSL)that axiomatizes a set of primitives adequate for describing the fun-damental concepts of manufacturing processes (PSL has been ac-cepted as an international standard) [13, 12]. It is used to provide awell-defined semantics for Web servicesand afoundation for ahigh-level programming language Golog [5, 20, 21]. However, becausethe situation calculus is formulated in a general predicate logic, rea-soning about effects of sequences of actions is undecidable (unlesssome restrictions are imposed on the theory that axiomatizes the ini-tial state of the world). The first motivation for our paper is inten-tion to overcome this difficulty. We propose to use a two-variablefragment FO2 of the first-order logic (FOL) as a foundation for amodified situation calculus. Because thesatisfiability problem in thisfragment is known to be decidable (it is in NEXPTIME), we demon-strate that by reducing reasoning about effects of actions to reason-ing in this fragment, one can guarantee decidability no matter whatis the syntactic form of the theory representing the initial state ofthe world. The second motivation for our paper comes from descrip-tion logics. Description Logics (DLs) [2] are a well-known familyof knowledge representation formalisms, which play an importantrole in providing the formal foundations of several widely used Webontology languages including OWL [15] in the area of the Seman-tic Web [3]. DLs may be viewed as syntactic fragments of FOL andoffer considerable expressive power going far beyond propositionallogic, while ensuring that reasoning is decidable [6]. DLs have beenmostly used to describe static knowledge-base systems. Moreover,several research groups consider formalization of actions using DLsor extensions of DLs. Following the key idea of [8], that reasoningabout complex actions can be carried in a fragment of the propo-sitional situation calculus, De Giacomo et al. [9] give an epistemicextension of DLs to provide a framework for the representation ofdynamic systems. However, the representation and reasoning aboutactions in this framework are strictly propositional, which reducesthe representation power of this framework. In [4], Baader et al.provide another proposal for integrating description logics and ac-tion formalisms. They takeas foundation thewell known descriptionlogic ALCQIO (and itssub-languages) and show that the complexityof executability and projection problemscoincideswith thecomplex-ity of standard DL reasoning. However, actions (services) are repre-sented in their paper meta-theoretically, not asfirst-order (FO) terms.This can potentially lead to some complications when specificationsof other reasoning tasks(e.g., planning) will beconsidered because it

2

payTuit(x,y)

student(x)~student(x)

drop(x,y)

enroll(x,y)

enrolled(x,y)~enrolled(x,y)

reset

Figure1. Examples of transition diagrams for simpleservices.

admit(PSN1);payTuit(PSN1,5100);enroll(PSN1,CS1)

enrolled(PSN1,CS1)student(PSN1)incoming(PSN1)

~student(PSN1)~incoming(PSN1)

~ y.enrolled(PSN1,y)

Figure2. A transition diagram for acomposite web service.

isnot possible to quantify over actions in their framework. In our pa-per, we take a different approach and represent actions as FO terms,but achieve integration of taxonomic reasoning and reasoning aboutactions by restricting the syntax of the situation calculus. Our papercan be considered as a direct extension of the well-known result ofBorgida [6] who proves that many expressive description logics canbe translated to two-variable fragment FO2 of FOL. However, to thebest of our knowledge, nobody proposed this extension before.

The main contribution of our paper to the area of service compo-sition and discovery is thefollowing. Weshow that by using servicesthat are composed from atomic services with no more than two pa-rameters and by using only those properties of the world which haveno more than two parameters (to express a goal condition), one canguarantee that the executability and projection problems for theseservices can always be solved even if information about the currentstate of the world is incomplete.

Our paper isstructured as follows. In Section 3, we briefly reviewthe Reiter’s situation calculus. In Section 4 we review a few popu-lar description logics. In the following section 5 we discuss detailsof our proposal: a modified situation calculus and an extension ofregression (themain reasoning mechanism in thesituation calculus).Finally, in Section 6 we provide a simple example and in Section 7we discuss briefly other related approaches to reasoning about ac-tions.

2 MotivationsConsider online web services provided by an university. Imaginethat a system automates the department administrators by doing stu-dent management work online, for instance, admitting new students,accepting payments of tuition fees and doing course enrollmentsfor students, etc. Unlike previously proposed e-services (e.g.,the e-services described in [5] or in BPEL4WS) which allow only ser-vices without parameters, we use functional symbols to represent aclassof services. For example, variables, say x and y, can be used torepresent any objects; the service of enrolling any student x in anycoursey can bespecified by using afunctional symbol enroll(x, y);and, the service of admitting any student x can be represented asa functional symbol admit(x), etc. The composite web servicescan be considered as sequences of instantiated services. For exam-ple, a sequence admit(P1); payTuit(P1, 5100); enroll(P1, CS1)represents the following composite web service for person P1: ad-mit her as a student, take the tuition fee $5100 and enroll her in acourseCS1. Thesystem properties arespecified by using predicateswith parameters. For example, the predicate enrolled(x, y) repre-sentsthat astudent x isenrolled in acoursey. Thisproperty becomestruewhen serviceenroll(x, y) isperformed and becomesfalsewhenservice drop(x, y) is performed for a student x and a course y (seeFigure 1). A composite web service corresponds to the compositionof these instantiated transition diagrams (see Figure 2). When onedescribes thepreconditions of theservices, theeffectsof theserviceson the world, i.e., when one characterizes which properties of the

world are true before and after the execution of the services, givenincomplete information about the current state of the world, the useof FO language, such asthesituation calculus [25], can providemoreexpressivepower than propositional languages. For example, assumethat a student is considered as a qualified full time student if the tu-ition fee she paid is more than 5000 dollars and she enrolls in atleast four different courses in the school. Such property can be eas-ily described using the FO logic, and checking whether or not suchproperty can be satisfied after execution of certain sequence of webservices isequivalent to solving a projection problem. Because FOLis compact way of representing information about states and tran-sitions between states, we want to take advantage of the expressivepower of the FO logic as much as possible to reason about web ser-vices.

On the other hand, as we mentioned in the introduction, we wantto avoid the undecidability of the entailment problem in the generalFOL. Inspired by the decidability of reasoning in many DLs (whicharesub-languagesof asyntactic fragment of theFOL with therestric-tion on the number of variables), we restrict the number of variablesto at most two in the specifications of the web services to ensure thedecidability of the executability and projection problems.techniquesAt the sametime, wecan take theadvantage of theexpressive powerof quantifiers to specify compactly realistic web services (such asmentioned above). Moreover, FOL with limited number of variables,in contrast to the propositional logic, still allows us to represent andreason about properties with infinite domains (such as weight andtime, etc) or with large finite domains (such as money, person,etc) in a very compact way. Two examples are given in the last sec-tion to illustrate the expressive power and reasoning about the webservices.

3 TheSituation Calculus

The situation calculus (SC) Lsc is a FO language for axiomatizingdynamic systems. In recent years, it has been extended to includeprocedures, concurrency, time, stochastic actions, etc [25]. Neverthe-less, all dialects of the SC Lsc include three disjoint sorts: actions,situations and objects. Actions are FO terms consisting of an ac-tion function symbol and its arguments. Actions change the world.Situations are FO terms which denote possible world histories. Adistinguished constant S0 is used to denote the initial situation, andfunction do(a, s) denotes the situation that results from performingaction a in situation s. Every situation corresponds uniquely to a se-quence of actions. Moreover, notation s′ � s means that either situ-ation s′ is a subsequence of situation s or s = s′.3 Objects are FOterms other than actions and situations that depend on the domainof application. Fluents are relations or functions whose values mayvary from onesituation to thenext. Normally, afluent isdenoted by apredicate or function symbol whose last argument has the sort situa-tion. For example,F (~x, do([α1, · · · , αn], S0) representsarelationalfluent in thesituationdo(αn, do(· · · , do(α1, S0) · · · ) resulting fromexecution of ground action termsα1, · · · , αn inS0.4

TheSC includesthedistinguished predicatePoss(a, s) to charac-terizeactionsa that are possible to execute in s. For any SC formulaφ and a term s of sort situation, we say φ is a formula uniform in siff it does not mention the predicates Poss or ≺, it does not quan-tify over variables of sort situation, it does not mention equality on

3 Reiter [25] uses the notation s′ v s, but we use s′ � s to avoid confusionwith the inclusion relation < that is commonly used in description logicliterature. In this paper, we use< to denote the inclusion relation betweenconcepts or roles.

4 Wedo not consider functional fluents in this paper.

3

situations, and whenever it mentions a term of sort situation in thesituation argument position of a fluent, then that term iss (see [25]).If φ(s) isauniform formulaand thesituation argument isclear fromthecontext, sometimeswesuppress thesituation argument and writethis formulasimply asφ, and also introduceanotationφ[s] to repre-sent the SC formula obtained by restoring situation s back to all thefluents and/or Poss predicates (if any) inφ. It is obvious that φ[s] isuniform in s.

A basic action theory (BAT) D in theSC isaset of axiomswrittenin Lsc with the following five classes of axioms to model actionsand their effects [25].

Action precondition axioms Dap: For each action function A(~x),there isan axiom of the formPoss(A(~x), s) ≡ ΠA(~x, s). ΠA(~x, s)is a formula uniform in s with free variables among ~x and s, whichcharacterizes the preconditions of actionA.

Successor state axioms Dss: For each relational fluent F (~x, s),there is an axiom of the form F (~x, do(a, s)) ≡ ΦF (~x, a, s), whereΦF (~x, a, s) is a formula uniform in s with free variables among~x, a and s. The successor state axiom (SSA) for F (~x) completelycharacterizes the value of F (~x) in the next situation do(a, s) interms of the current situation s. The syntactic form of ΦF (~x, a, s) isas follows:F (~x, do(a, s)) ≡

Wm

i=1(∃~yi)(a = PosActi(~ti) ∧ φ+i (~x, ~yi, s))∨

F (~x, s) ∧ ¬Wk

j=1(∃~zj)(a = NegActj(~t′j) ∧ φ−j (~x, ~zj , s)),

where for i = 1..m (j = 1..k, respectively), each ~ti (~t′j , respec-tively) isvector of terms including variables among ~x and quantifiednew variables~yi (~zj , respectively) if thereare any, each φ+

i (~x, ~yi, s)(φ−

j (~x, ~zj , s), respectively) is a SC formula uniform in s who hasfree variables among ~x and ~yi (~zj , respectively) if there are any,and each PosAct(~ti) (NegAct(~t′j), respectively) is an action termthat makes F (~x, do(a, s)) true (false, respectively) if the conditionφ+

i (~x, ~yi, s) (φ−j (~x, ~zj , s), respectively) issatisfied.

Initial theory DS0: It is a set of FO formulas whose only situation

term isS0. It specifies the values of all fluents in the initial state. Italso describes all the facts that are not changeable by any actions inthe domain.

Unique name axioms for actions Duna: Includes axioms specify-ing that two actions are different if their names are different, andidentical actions have identical arguments.

Fundamental axioms for situations Σ: The axioms for situationswhich characterize the basic properties of situations. These axiomsare domain independent. They are included in the axiomatization ofany dynamic systems in the SC (see [25] for details).

Suppose that D = Duna ∪ DS0∪ Dap ∪ Dss ∪ Σ is a

BAT, α1, · · · , αn is a sequence of ground action terms, and G(s)is a uniform formula with one free variable s. One of the mostimportant reasoning tasks in the SC is the projection problem,that is, to determine whether D |= G(do([α1, · · · , αn], S0)).Another basic reasoning task is the executability problem. Letexecutable(do([α1, · · · , αn], S0)) be an abbreviation of the for-mula Poss(α1, S0) ∧

Wn

i=2 Poss(αi, do([α1, · · · , αi−1], S0)).Then, the executability problem is to determine whether D |=executable(do([α1, · · · , αn], S0)). Planning and high-level pro-gram execution are two important settings where the executabilityand projection problems arise naturally. Regression isa central com-putational mechanism that forms the basis for automated solutionto the executability and projection tasks in the SC [23, 25]. A re-cursive definition of the regression operator R on any regressableformula φ is given in [25]; we use notation R[φ] to denote the for-

mula that results from eliminating Poss atoms in favor of their def-initions as given by action precondition axioms and replacing fluentatoms about do(α, s) by logically equivalent expressions about s asgiven by SSAs of sort situation in W is starting from S0 and hasthe syntactic form do([α1, · · · , αn], S0) where each αi is of sortaction; (2) for every atom of the form Poss(α, σ) in W , α hasthe syntactic form A(t1, · · · , tn) for some n-ary function symbolA of Lsc; and (3) W does not quantify over situations, and doesnot mention the relation symbols “≺” or “=” between terms of sit-uation sort. The formulaG(do([α1, · · · , αn], S0)) is a particularlysimple example of a regressable formula because it is uniform indo([α1, · · · , αn], S0)), but generally, regressable formulascan men-tion several different ground situation terms. Roughly speaking, theregression of a regressable formula φ through an action a is a for-mula φ′ that holds prior to a being performed iff φ holds after a.Both precondition and SSAs support regression in a natural wayand are no longer needed when regression terminates. The regres-sion theorem proved in [23] shows that one can reduce the eval-uation of a regressable formula W to a FO theorem proving taskin the initial theory together with unique names axioms for actions:

D |= W iff DS0∪ Duna |= R[W ].

This fact is the key result for our paper. It demonstrates that an ex-ecutability or a projection task can be reduced to a theorem prov-ing task that does not use precondition, successor state, and foun-dational axioms. This is one of the reasons why the SC providesa natural and easy way to representation and reasoning about dy-namic systems. However, because DS0

is an arbitrary FO theory,this type of reasoning in the SC is undecidable. One of the com-mon waysto overcomethisdifficulty isto introduce theclosed worldassumption that amounts to assuming that DS0

is a relational the-ory (i.e., it has no occurrences of the formulas having the syntacticformF1( ~x1, S0)∨F2( ~x2, S0) or ∃xF (x,S0), etc) and all statementsthat are not known to be true explicitly, are assumed to be false. Inmany application domains this assumption is unrealistic. Therefore,weconsider aversion of the SC formulated in FO2, asyntactic frag-ment of the FO logic that is known to be decidable, or in C2 an ex-tension of FO2 (see below), where the satisfiability problem is stilldecidable.

4 Descr iption Logics and Two-var iable First-orderLogics

In thissection wereview a few popular expressive description logicsand related fragments of the FO logic. We start with logic ALCHQI.Let NC = {C1, C2, . . .} be a set of atomic concept names andNR = {R1, R2, . . .} be a set of atomic role names. A ALCHQIrole is either some R ∈ NR or an inverse role R− for R ∈ NR.A ALCHQI role hierarchy (RBox ) RH is a finite set of role in-clusion axioms R1 v R2, where R1, R2 are ALCHQI roles. ForR ∈ NR, we define Inv(R) = R− and Inv(R−) = R, and assumethat R1 v R2 ∈ RH implies Inv(R1) v Inv(R2) ∈ RH.

The set of ALCHQI concepts is the minimal set built inductivelyfromNC and ALCHQI roles using the following rules: all A ∈ NC

are concepts, and, if C, C1, and C2 are ALCHQI concepts, R is asimple role and n ∈ N, then also ¬C, C1 u C2, and (∃>nR.C) areALCHQI concepts. We use also some abbreviations for concepts:

C1 t C2def= ¬(¬C1 u ¬C2) ∃R.C

def= ∃≥1R.C

C1 ⊃ C2def= ¬C1 t C2 ∀R.C

def= ∃<1R.¬C

(∃6nR.C)def= ¬(∃>(n+1)R.C) ⊥

def= A u ¬A for some A ∈ NC

(∃n R.C)def= (∃6n R.C) u (∃>n R.C) >

def= ¬⊥

Concepts that are not concept names are called complex. A literal

4

concept isapossibly negated concept name. A TBox T isafinitesetof equality axiomsC1 ≡ C2 (sometimes, general inclusion axiomsof the form C1 v C2 are also allowed, whereC1, C2 are complexconcepts). An equality with an atomic concept in theleft-hand sideisaconcept definition. In thesequel, wealways consider TBox axiomsset T that isa terminology, afiniteset of concept definition formulaswith unique left-hand sides, i.e., no atomic concept occurs morethan once as a left-hand side. We say that a defined concept nameC1 directly uses a concept name C2 with respect to T if C1 isdefined by a concept definition axiom in T withC2 occurring in theright-hand side of the axiom. Let uses be the transitive closure ofdirectly uses, and aTBox axiomsset T isacyclic if no concept nameuses itself with respect to T . An ABox A is a finite set of axiomsC(a),R(a, b), and (in)equalitiesa ≈ b and a 6≈ b.

The logic ALCQI is obtained by disallowing RBox . A more ex-pressive logic ALCQI(t,u,¬, |, id) is obtained from ALCQI by in-troducing identity role id (relating each individual with itself) andallowing complex role expressions: if R1, R2 areALCQI(t,u,¬, |, id) roles and C is a concept, then R1 t R2, R1 u R2, ¬R1, R−

1

andR1|C areALCQI(t,u,¬, |, id) roles too.5 These complex rolescan be used in TBox (in the right-hand sides of definitions). Subse-quently, we call a role R primitive if it is either R ∈ NR or it isan inverse roleR− for R ∈ NR. Two-variable FO logic FO2 is the

τx(A)def= A(x) for A ∈ NC

τx(>)def= x = x τx(⊥)

def= ¬(x = x)

τx(¬C)def= ¬τx(C) τy(C)

def= τx(C)[x/y, y/x]

τx(C1 u C2)def= τx(C1) ∧ τx(C2)

τx(∃./nR.C)def= ∃./ny.( τx,y(R) ∧ τy(C) )

τx(∀R.C)def= ∀y.( τx,y(R) ⊃ τy(C) )

τx,y(id)def= x = y τx,y(¬R)

def= ¬τx,y(R)

τx,y(R|C)def= τx,y(R) ∧ τy(C) τx,y(R−)

def= τy,x(R)

τx,y(R1 uR2)def= τx,y(R1) ∧ τx,y(R2)

τx,y(R1 tR2)def= τx,y(R1) ∨ τx,y(R2)

τx,y(R)def= R(x, y) for R ∈ NR

τy,x(R)def= R(y, x) for R ∈ NR

fragment of ordinary FO logic (with equality), whose formulas onlyuseno morethan two variablesymbolsx and y (freeor bound). Two-variable FO logic with counting C2 extends FO2 by allowing FOcounting quantifiers∃≥m and ∃≤m for all m ≥ 1. Borgida in [6] de-fines an expressive description logic B and shows that each sentencein the language B without transitive roles and role-composition op-erator can be translated to a sentence in C2 with the same meaning,and vice versa, i.e., these two languages are equally expressive. Aknowledge baseKB is a triple (R, T ,A). The semantics of KB isgiven by translating it into FO logic with countingC2 by theoperatorτ (seethetableabove, in which ./ ∈ {>,6} andx/y meansreplacex with y). Borgida’s logic B includes all concept and role construc-tors in ALCQI(t,u,¬, |, id) and, in addition, it includes a specialpurpose constructor product that allows to build the role C1 × C2

from two conceptsC1 andC2. Thisconstruct hasasimplesemantics

τx,y(C1 × C2)def= τx(C1) ∧ τy(C2) , and makes the translation

fromC2 intoB rather straightforward. Although constructor productis not a standard role constructor, we can use restriction constructor| in addition witht,u,¬ and inverse role to represent it. That is, forany conceptsC1 andC2,

5 Thesestandard roles constructors and their semantics can be found in [3].

C1 ×C2 = (R t ¬R)|C2u ((R t ¬R)|C1

)−,

whereR can be any role name. Consequently, product can be elimi-nated. Therefore, the following statement isa direct consequence ofthe theorems proved in [6].

Theorem 1 Thedescription logicALCQI(t,u,¬, |, id) andC2 areequally expressive (i.e., each sentence in languageALCQI(t,u,¬, |, id) can be translated to a sentence in C2, and vice versa). In ad-dition, translation in both directions leads to no more than linearincrease of the sizeof the translated formula.

This statement has an important consequence. Gradel et. al.[11]and Pacholski et al [22] show that satisfiability problem for C2

is decidable. Hence, the satisfiability and/or subsumption problemsof concepts w.r.t. an acyclic or empty TBox in description logicALCQI(t,u,¬, |, id) is also decidable.6 In Section 5, we take ad-vantage of thisand useC2 as a foundation for a modified SC.

5 Modeling Dynamic Systems in a ModifiedSituation Calculus

In this section, we consider dynamic systems formulated in a minormodification of the languageof theSC so that it can beconsidered asan extension toC2 language (with situation argument for unary andbinary fluents). The key idea is to consider a syntactic modificationof the SC such that the executability and projection problems areguaranteed to be decidable as a consequence of theC2 property ofbeing decidable.7 Moreover, since themodified SC hasa very strongconnectionswith description logics, which will beexplained in detailbelow, we will denote this language asLDL

sc .First of all, the three sorts in LDL

sc (i.e., actions, situations andobjects) are the same as those in Lsc, except that they obey the fol-lowing restrictions: (1) all terms of sort object are variables (x andy) or constants, i.e., functional symbols are not allowed; (2) all ac-tion functions include no more than two arguments. Each argumentof any term of sort action iseither aconstant or an object variable (xor y); (3) variable symbol a of sort action and variable symbol s ofsort situation are the only additional variable symbols being allowedinLDL

sc in addition to variable symbolsx and y.Second, any fluent in LDL

sc is a predicate either with two or withthree arguments including the one of sort situation. We call fluentswith two arguments, one is of sort object and the other is of sortsituation, (dynamic) concepts, and call fluents with three arguments,first two of sort object and the last of sort situation, (dynamic) roles.Intuitively, each (dynamic) concept in LDL

sc , say F (x, s) with vari-ablesx and s only, can be considered as a changeable concept F inadynamic system specified inLDL

sc ; the truth valueof F (x, s) couldvary from one situation to another. Similarly, each (dynamic) role inLDL

sc , say R(x, y, s) with variablesx, y and s, can be considered asachangeable roleR in adynamic system specified inLDL

sc ; the truthvalueof R(x, y, s) could vary from onesituation to another. InLDL

sc ,(static) concepts (i.e., unary predicates with no situation argument)and (static) roles (i.e., binary predicates with no situation argument),if any, are considered as eternal facts and their truth values neverchange. If they are present, they represent unchangeable taxonomic

6 In [3] it is shown that the satisfiability problems of concepts and subsump-tion problems of concepts can be reduced to each other; moreover, if aTBox T is acyclic, the reasoning problems w.r.t. T can always be reducedto problems w.r.t. the empty TBox.

7 The reason that we call it a ”modified” SC rather than a ”restricted” SC isthat we not only restrict the number of variables that can be mentioned inthe SC during the formalizations of dynamic systems, but we also extendthe SC with other features, such as introducing counting quantifiers andadding acyclic TBox axioms to basic action theories.

5

propertiesand unchangeable classesof an application domain. More-over, each concept (static or dynamic) can be either primitive or de-fined. For each primitive dynamic concept, a SSA must be providedin the basic action theory formalized for the given system. Becausedefined dynamic concepts are expressed in terms of primitive con-cepts by axioms similar to TBox , SSAs for them are not provided.In addition, SSAsare provided for dynamic primitive roles.

Third, apart from standard FO logical symbols –∧, ∨ and ∃, withthe usual definition of a full set of connectives and quantifiers, LDL

sc

also includes counting quantifiers∃≥m and ∃≤m for all m ≥ 1.The dynamic systems we are dealing with here satisfy the open

world assumption (OWA): what is not stated explicitly is currentlyunknown rather than false. In this paper, the dynamic systemswe are interested in can be formalized as a basic action theory(BAT) D using the following seven groups of axioms in LDL

sc :D = Σ ∪ Dap ∪ Dss ∪ DT ∪ DR ∪ Duna ∪ DS0

. Five of them(Σ,Dap,Dss,Duna,DS0

) are similar to those groups in a BATin Lsc, and the other two (DT ,DR) are introduced to axiomatizedescription logic related facts and properties (see below). However,because LDL

sc allows only two object variables, all axioms mustconform to the following additional requirements.

Action precondition axioms Dap: For each action A in LDLsc ,

there is one axiom of the form Poss(A, s) ≡ ΠA[s] (orPoss(A(x), s) ≡ ΠA(x)[s], or Poss(A(x, y), s) ≡ ΠA(x, y)[s],respectively), if A is an action constant (or unary, or binary actionterm, respectively), whereΠA (or ΠA(x), or ΠA(x, y), respectively)is aC2 formula with no free variables ( or with at most x, or with atmost x, y as theonly freevariables, respectively). Thisset of axiomscharacterize thepreconditions of all actions.

Successor state axioms Dss: For each primitive dynamic conceptF (x, s) in LDL

sc , a SSA is specified for F (x, do(a, s)). Accordingto the general syntactic form of the SSAs provided in [25], withoutloss of generality, we can assume that the axiom has the form

F (x, do(a, s)) ≡ ψF (x, a, s), (1)where the general structure of ψF (x, a, s) is as follows.

ψF (x, a, s) ≡ (Wm0

i=1[∃x][∃y](a=A+i (~x(i,0,+)) ∧ φ

+i (~x(i,1,+))[s])) ∨

F (x, s) ∧ ¬((Wm1

j=1[∃x][∃y](a=A−j (~x(j,0,−)) ∧ φ

−j (~x(j,1,−))[s]))),

where each variable vector ~x(i,n,b) (or ~x(j,n,b) respectively)(i = 1..m0, j = 1..m1, n ∈ {0, 1}, b ∈ {+,−}) representsa vector of object variables, which can be empty, x, y, 〈x, y〉or 〈y, x〉. Moreover, [∃x] or [∃y] represents that the quantifierincluded in [ ] is optional; and each φ+

i (~x(i,1,+)), i = 1..m0

(φ−i (~x(j,1,−)), j = 1..m1, respectively), is a C2 formula with

variables (both free and quantified) among x and y.Similarly, a SSA for a dynamic primitive role R(x, y, s) is

provided as a formula of the formR(x, y, do(a, s)) ≡ ψR(x, y, a, s), (2)

Moreover, without loss of generality, the general structure ofψR(x, y, a, s) isas follows.

ψR(x, y, a, s) ≡ (Wm2

i=1[∃x][∃y](a=A+i (~x(i,0,+)) ∧ φ

+i (~x(i,1,+))[s]))∨

R(x, y, s) ∧ ¬((Wm3

j=1[∃x][∃y](a=A−j (~x(j,0,−)) ∧ φ

−j (~x(j,1,−))[s]))),

where each variable vector ~x(i,n,b) (or ~x(j,n,b) respectively)(i = 1..m2, j = 1..m3, n ∈ {0, 1}, b ∈ {+,−}) represents avector of free variables, which can be either empty, x, y, 〈x, y〉or 〈y, x〉. Moreover, [∃x] or [∃y] represents that the quantifierincluded in [ ] is optional; and each φ+

i (~x(i,1,+)), i = 1..m2

(φ−j (~x(j,1,−)), j = 1..m3, respectively), is a C2 formula with

variables (both free and quantified) among x and y.8

8 Notice that when m0 (or m1, m2, m3, respectively) is equal to 0, the cor-

Acyclic TBox axioms DT : Similar to the TBox axioms in DL, wemay also introduce a group of axioms DT to define new concepts,which are later called TBox axioms. Any group of TBox axiomsDT may include two sub-classes: static TBox DT,st and dynamicTBox DT,dyn. Every formula in static TBox is a concept definitionformula of the form G(x) ≡ φG(x),whereG is a unary predicate symbol and φG(x) is aC2 formula inthe domain with free variablex, and there is no dynamic concept ordynamic role in it. Every formula in dynamic TBox isaconcept def-inition formula of the form G(x, s) ≡ φG(x)[s],where φG(x) is a C2 formula with free variable x, and there is atleast one dynamic concept or dynamic role in it. All theconcepts ap-peared in the left-hand side of TBox axioms are called defined con-cepts. During reasoning, weuse lazy unfolding technique (see[2]) toexpand a given sentence whenever we regress defined dynamic con-cepts. In this paper, we require that the set of TBox axioms must beacyclic to ensure the lazy unfolding approach terminates in thefinitenumber of steps (acyclicity in DT is defined exactly as it is definedfor TBox ).RBox axiomsDR: Similar to the idea of RBox in DL, we may alsospecify a group of axioms, called RBox axioms below, to support arole taxonomy. Each role inclusion axiom R1 v R2, if any, whereR1 and R2 are primitive roles (either static or dynamic) is repre-sented asR1(x, y)[s] ⊃ R2(x, y)[s]. If these axioms and includedin the BAT D, then it is assumed that D is specified correctly in thesense that the meaning of any RBox axiom included in the theoryis correctly compiled into SSAs. This means that one can prove byinduction that D |= ∀s.R1(x, y)[s] ⊃ R2(x, y)[s]. Although RBoxaxiomsarenot used by theregression operator, they areused for tax-onomic reasoning in the initial theory.Initial theory DS0

: It is a finite set of C2 sentences (assuming thatwe suppress the only situation term S0 in all fluents). It specifiesthe incomplete information about the initial problem state and alsodescribesall thefactsthat arenot changeableover timein thedomainof an application. In particular, it includes static TBox axiomsDT,st

as well as RBox axioms in the initial situation S0 (if any).Theremaining two classes ( Σ andDuna) are thesameas those in

the usual SC.After giving the definition of what the BAT in LDL

sc is, we turnour attention to the reasoning tasks. Given a formulaW of LDL

sc inthedomainD, thedefinition of W being regressable(calledLDL

sc re-gressable below) is slightly different from the definition of W beingregressable inLsc (seeSection 3) by adding thefollowing additionalconditions: (4) any variable (free or bounded) inW is either x or y;(5) every term of sort situation inW is ground. Moreover, to avoidusing new variables and assuredefined dynamic concepts being han-dled, we modify the regression operator (which later is still denotedas R) for each LDL

sc regressable formula using the following ideas:(1) whenever the operator meets a defined dynamic concept, it willreplace the concept with the corresponding definition, i.e., with theright hand-sideof theTBox axiom for thisconcept; (2) whenever theoperator meets a atomic sentence whose the positions of variable xand y are different from the positions of the left hand-side of theaxiom given in the basic action theory, wewill switch all the appear-ances of x and y (both free and quantified) at the right hand-side ofthe axiom when replacing the atomic sentence with the right hand-sideof theaxiom in thebasic actionstheorem. Thedetailed definitioncan be found in [14].

Weproved that using such regression operator onLDLsc regressable

responding disjunctive subformula is equivalent to false.

6

formulas, regression terminatesinafinitenumber of steps. Moreover,wealso proved the following key property indicating that theprojec-tion problemsand executability problems aredecidable for any LDL

sc

regressable formulas in the modified situation calculusLDLsc .

Theorem 2 (see [14] for details) SupposeW is a LDLsc regressable

formula with the background basic action theory D. Then, the prob-lem whether D |= W is decidable.

6 An ExampleIn this section, we give an example to illustrate the basic ideas de-scribed above.

Example 1 Consider some university that provides on the Webstudent administration and management services, such as admittingstudents, paying tuition fees, enrolling or dropping courses and en-tering grades.

Although the number of object arguments in the predicates canbe at most two, sometimes, we are still able to handle those fea-tures of the systems that require more than two arguments. For ex-ample, the grade z of a student x in a course y may be representedas a predicate grade(x, y, z) in the general FOL (i.e., with threeobject arguments). Because the number of distinct grades is finiteand they can be easily enumerated as ”A” , ”B” , ”C” or ”D” , wecan handle grade(x, y, z) by replacing it with a finite number ofextra predicates, say gradeA(x,y), gradeB(x, y), gradeC(x, y)and gradeD(x, y) such that they all have two variables only. How-ever, the restriction on the number of variables limits the expressivepower of the language if more than two arguments vary over infinitedomains (such as energy, weight, time, etc). Despite this limitation,weconjecture that many web servicesstill can berepresented with atmost two variableseither by introducing extrapredicates(just likewedid for the predicate grade) or by grounding some of the argumentsif their domains are finite and relatively small. Intuitively, it seemsthat most of the dynamic systems can be specified by using prop-erties and actions with small arities, hence the techniques for arityreductions mentioned above and below require no more than poly-nomial increase in the number of axioms. The high-level features ofour example are specified as the following concepts and roles.

• Static primitive concepts: person(x) (x is a person); course(x)(x is acourse provided by the university).• Dynamic primitive concepts: incoming(x, s) (x is an incom-ing student in the situation s, it is true when x was admitted);student(x, s) (x is an eligible student in the situation s, it is truewhen an incoming student x pays the tuition fee).• Dynamic defined concepts: eligFull(x, s) (x is eligible to bea full-time student by paying more than 5000 dollars tuition fee);eligPart(x, s) (x is eligible to be a part-time student by paying nomorethan 5000 dollarstuition); qualFull(x, s) (x isaqualified full-timestudent if heor shepays full timetuition feeand takesat least 4courses); qualPart(x, s) (x is a part-time student if he or she payspart-time tuition and takes 2 or 3 courses).• Static role: preReq(x, y) (coursex isaprerequisite of coursey).• Dynamic roles: tuitPaid(x, y, s) (x pays tuition fee y in thesituation s); enrolled(x, y, s) (x is enrolled in course y in the sit-uation s); completed(x, y, s) (x completes course y in the situ-ation s); hadGrade(x, y, s) (x had a grade for course y in thesituation s); gradeA(x,y, s); gradeB(x, y, s); gradeC(x, y, s);gradeD(x, y, s).

Web services are specified as actions:

reset (at the beginning of each academic year, the system is being

reset so that students need to pay tuition fee again to become eli-gible); admit(x) (the university admits student x); payTuit(x, y)(x pays tuition fee with the amount of y); enroll(x, y) (x enrollsin course y); drop(x, y) (x drops course y); enterA(x, y) (entergrade ”A” for student x in course y); enterB(x, y); enterC(x, y);enterD(x, y).

Thebasic action theory isas follows (most of the axioms are self-explanatory).Precondition Axioms:Poss(reset, s) ≡ true,Poss(admit(x), s) ≡ person(x) ∧ ¬incoming(x, s),P oss(payTuit(x,y), s) ≡ incoming(x, s) ∧ ¬student(x, s),P oss(drop(x, y), s) ≡ enrolled(x, y, s) ∧ ¬completed(x, y, s),P oss(enterA(x, y), s) ≡ enrolled(x, y, s) ∧ ¬completed(x, y, s),

and similar to enterA(x, y), the precondition for enterB(x, y)(enterC(x, y) and enterD(x, y) respectively) at any situations is also enrolled(x, y, s). Moreover, in the traditional SC, theprecondition for action enroll(x, y) would be equivalent to

(∀z)(preReq(z,y)∧completed(x, z, s)∧¬gradeD(x, z, s))∧student(x)∧ course(y).

However, in the modified SC, we only allow at most two variables(including free or quantified) other than the situation variable s andaction variable a. Fortunately, the number of the courses offeredin a university is limited (finite and relatively small) and relativelystable over years (if we manage the students in a college-wise rangeor department-wise range, the number of courses may be evensmaller). Therefore, we can specify the precondition for the actionenroll(x, y) for each instance of y. That is, assume that the setof courses is {CS1, · · · , CSn}, the precondition axiom for eachCSi (i = 1..n) is Poss(enroll(x,CSi), s) ≡ student(x) ∧(∀y)(preReq(y,CSi) ∧ completed(x, y, s) ∧ ¬gradeD(x, y, s)).

On the other hand, when we do this transformation, we can omitthe statements course(x) for each course available at the universityin the initial theory.Successor StateAxioms: TheSSAsfor thefluentsgradeB(x, y, s),gradeC(x, y, s) and gradeD(x, y, s) are very similar to the onefor fluent gradeA(x,y, s) (therefore are not repeated here), whichensures that for each student and each course there is no more thanone grade assigned.

incoming(x, do(a, s)) ≡ a = admit(x)∨ incoming(x, s),student(x, do(a, s)) ≡ (∃y)(a = payTuit(x, y))∨

student(x) ∧ a 6= reset,tuitPaid(x, y, do(a, s)) ≡ a = payTuit(x, y)∨

tuitPaid(x, y, s) ∧ a 6= reset,enrolled(x, y, do(a, s)) ≡ a = enroll(x, y) ∨ enrolled(x, y, s)

∧¬(a = drop(x, y) ∨ a = enterA(x, y) ∨ a = enterB(x, y)∨a = enterC(x, y) ∨ a = enterD(x, y)),

completed(x, y, do(a, s)) ≡ a=enterA(x,y) ∨ a=enterB(x,y)∨a=enterC(x, y) ∨ a=enterD(x,y)∨completed(x, y, s) ∧ a 6= enroll(x, y),

gradeA(x, y, do(a, s)) ≡ a=enterA(x,y) ∨ gradeA(x, y, s)∧¬(a=enterB(x,y) ∨ a=enterC(x,y) ∨ a=enterD(x,y)),

Acyclic TBox Axioms: (no static TBox axioms in this example)

eligFull(x, s) ≡ (∃y)(tuitPaid(x, y, s) ∧ y > 5000),eligPart(x, s) ≡ (∃y)(tuitPaid(x, y, s) ∧ y ≤ 5000),

qualFull(x, s) ≡ eligFull(x, s) ∧ (∃≥4y)enrolled(x, y, s),

qualPart(x, s) ≡ eligPart(x, s) ∧ (∃≥2y)enrolled(x, y, s)

∧(∃≤3enrolled(x, y, s)).An example of the initial theory DS0

could be the conjunctions ofthe following sentences:

7

person(P1), person(P2),· · · , person(Pm),(∀x)incoming(x,S0) ⊃ x = P2 ∨ x = P3,preReq(CS1, CS4) ∨ preReq(CS3, CS4),(∀x)x 6= CS4 ⊃ ¬(∃y).prePeq(y,x), (∀x)¬student(x,S0).Wemay also introduce some RBox axioms as follows:

gradeA(x,y, s) ⊃ hadGrade(x, y, s),gradeB(x, y, s) ⊃ hadGrade(x, y, s),gradeC(x, y, s) ⊃ hadGrade(x, y, s),gradeD(x, y, s) ⊃ hadGrade(x, y, s).

The RBox axioms are not used in the regression steps of reasoningabout executability problems and projection problems. However,they are useful for terminological reasonings when necessary. Forinstance, we may reason about

∀x.∀s.((∃≤1y)(hadGrade(x, y, s) ∧ course(y)) ⊃

((∃≤1y)(gradeA(x,y, s) ∧ course(y))∨

(∃≤1y)(gradeB(x,y, s) ∧ course(y)))).

Since the truth value of such statement in fact has nothing to dowith the situation argument, it is the same as the following formularepresented in Description Logics.

∃≤1 hadGrade.course v

(∃≤1 gradeA.course t ∃≤1 gradeB.course).

Finally, we give an example of regression of a LDLsc regressable

formula.

R[(∃x).qualFull(x, do([admit(P1), payTuit(P1, 6000)], S0))]

= R[(∃x).eligFull(x, do([admit(P1), payTuit(P1, 6000)], S0))∧

(∃≥4y)enrolled(x, y, do([admit(P1), payTuit(P1, 6000)], S0))]

= · · ·

= (∃x).(∃≥4y)enrolled(x, y, S0) ∧ ((∃y)R[y > 5000∧tuitPaid(x, y, do([admit(P1), payTuit(P1, 6000)], S0))])

= · · ·

= (∃x).(∃≥4y)enrolled(x, y, S0) ∧ ((∃y).tuitPaid(x, y, S0)∧y > 5000 ∨ (x = P1 ∧ y = 6000 ∧ y > 5000))

which is false given the above initial theory.Suppose we denote the above basic action theory as D.

Given goal G, for example ∃x.qualFull(x), and a compos-ite web service starting from the initial situation, for exampledo([admit(P1), payTuit(P1, 6000)], S0) (we denote the corre-sponding resulting situation as Sr), we can check if the goal is sat-isfied after the execution of this composite web service by solv-ing the projection problem whether D |= G[Sr]. In our example,this corresponds to solving whether D |= ∃x.qualFull(x,Sr).We may also check if a given (ground) composite web serviceA1;A2; · · · ;An is possible to execute starting from the initialstate by solving the executability problem whether D |=executable(do([A1, A2, · · · , An], S0)). For example, wecan checkif thecompositewebserviceadmit(P1); payTuit(P1, 6000) ispos-sible to be executed from the starting state by solving whether D |=executable(Sr).

7 Discussion and FutureWork

The major consequence of the results proved above for the problemof service composition is the following. If both atomic services andpropertiesof theworld that can beaffected by theseserviceshavenomore than two parameters, then we are guaranteed that even in thestate of incomplete information about the world, one can always de-termine whether a sequentially composed service is executable andwhether thiscompositeservicewill achieveadesired effect. Thepre-viously proposed approaches made different assumptions: [20] as-

sumes that the complete information is available about the worldwhen effects of a composite service are computed, and [5] consid-ers the propositional fragment of the SC.

As we mentioned in Introduction, [20, 21] propose to use Gologfor composition of Semantic Web services. Because our primitiveactions correspond to elementary services, it is desirable to defineGolog in our modified SC too. It is surprisingly straightforward todefinealmost all Golog operatorsstarting from ourC2 based SC. Theonly restriction in comparison with theoriginal Golog [18, 25] isthatwe cannot define the operator (πx)δ(x), non-deterministic choiceof an action argument, because LDL

sc regressable formulas cannothave occurrences of non-ground action terms in situation terms. Inthe original Golog this is allowed, because the regression operator isdefined for a larger class of regressable formulas. However, every-thing else from the original Golog specifications remain in force, nomodifications are required. In addition to providing a well-definedsemantics for Web services, our approach also guarantees that eval-uation of tests in Golog programs is decidable (with respect to arbi-trary theory DS0

) that ismissing in other approaches (unlessonecanmake the closed world assumption or impose another restriction toregain decidability).

The most important direction for future research is an efficientimplementation of a decision procedure for solving the executabil-ity and projection problems. This procedure should handle the mod-ified LDL

sc regression and do efficient reasoning in DS0. It should

bestraightforward to modify existing implementations of the regres-sion operator for our purposes, but it is less obvious which reasonerwill work efficiently on practical problems. There are several dif-ferent directions that we are going to explore. First, according to[6] and Theorem 1,there exists an efficient algorithm for translat-ing C2 formulas to ALCQI(t,u,¬, |, id) formulas. Consequently,we can use any resolution-based description logic reasoners that canhandle ALCQI(t,u,¬, |, id) (e.g., MSPASS [17]). Alternatively,we can try to use appropriately adapted tableaux-based descriptionlogic reasoners, such as FaCT++, for (un)satisfiability checking inALCQI(t,u,¬, |, id). Second, we can try to avoid any translationfrom C2 to ALCQI(t,u,¬, |, id) and adapt resolution based auto-mated theorem provers for our purposes [7].

The recent paper by Baader et al [4] proposes integration of de-scription logicsALCQIO (and its sub-languages) with an action for-malism for reasoning about Web services. Thispaper startswith ade-scription logic and then definesservices (actions) meta-theoretically:an atomic service is defined as the triple of sets of description logicformulas. To solve theexecutability and projection problems thispa-per introduces an approach similar to regression, and reduces thisproblem to description logic reasoning. Themain aim isto show howexecutability of sequences of actions and solution of the executabil-ity and projection problems can be computed, and how complexityof these problems depend on thechosen description logic. In the fullversion of [4], there is a detailed embedding of the proposed frame-work into the syntactic fragment of the Reiter’s SC. It is shown thatsolutions of their executability and projection problems correspondto solutions of these problems with respect to the Reiter’s basic ac-tion theories in this fragment for appropriately translated formulas(see Theorem 12 in Section 2.4). To achieve this correspondence,one needs to eliminate TBox by unfolding (this operation can re-sult potentially in exponential blow-up of the theory). Despite thatour paper and [4] have common goals, our developments start dif-ferently and proceed in the different directions. We start from thesyntactically restricted FO language (that is significantly more ex-pressive than ALCQIO), use it to construct the modified SC (where

8

actions are terms), define basic action theories in this language andshow that by augmenting (appropriately modified) regression withlazy unfolding one can reduce the executability and projection prob-lems to the satisfiability problem in C2 that is decidable. Further-more, C2 formulas can be translated toALCQI(t,u,¬, |, id), if de-sired. Because our regression operator unfolds fluents “on demand”and uses only relevant part of the (potentially huge) TBox , weavoidpotential computational problems that may occur if the TBox wereeliminated in advance. The advantage of [4] is that all reasoning isreduced to reasoning in description logics (and, consequently, can beefficiently implemented especially for less expressive fragments ofALCQIO). Our advantages are two-fold: the convenience of repre-senting actions as terms, and the expressive power of LDL

sc . BecauseC2 andALCQI(t,u,¬, |, id) areequally expressive, thereare some(situation suppressed) formulas in our SC that cannot be expressedinALCQIO (that does not allow complex roles).

An interesting paper [19] aims to achieve computational tractabil-ity of solving projection and progression problems by following analternative direction to the approach chosen here. The theory of theinitial state is assumed to be in the so-called proper form and thequery used in the projection problem is expected to be in a certainnormal form. In addition, [19] considersageneral SC and impose norestriction on arity of fluents. Becauseof thesesignificant differencesin our approaches, it isnot possible to compare them.

There are several other proposals to capture the dynamics of theworld in the framework of description logics and/or its slight ex-tensions. Instead of dealing with actions and the changes caused byactions, some of the approaches turned to extensions of descriptionlogic with temporal logics to capture the changes of the world overtime [1, 2], and some others combined planning techniques with de-scription logics to reason about tasks, plans and goals and exploitdescriptions of actions, plans, and goalsduring plan generation, planrecognition, or plan evaluation [10]. Both [1] and [10] review sev-eral other related papers. In [5], Berardi et al. specify all the actionsof e-services as constants, all the fluents of the system have onlysituation argument, and translate the basic action theory under suchassumption into description logic framework. It hasa limited expres-sivepower without using arguments of objects for actionsand/or flu-ents: thismay cause a blow-up of the knowledge base.

AcknowledgmentsThanks to the Natural Sciences and Engineering Research Councilof Canada (NSERC) and to the Department of Computer Science ofthe University of Toronto for providing partial financial support forthis research.

REFERENCES[1] Alessandro Artale and Enrico Franconi. A survey of temporal exten-

sions of description logics. Annals of Mathematics and Artificial Intel-ligence, 30(1-4), 2001.

[2] Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi,and Peter F. Patel-Schneider, editors. TheDescription Logic Handbook:Theory, Implementation, and Applications. CambridgeUn. Press, 2003.

[3] Franz Baader, Ian Horrocks, and Ulrike Sattler. Description logicsas ontology languages for the semantic web. In Dieter Hutter andWerner Stephan, editors, Mechanizing Mathematical Reasoning, Es-says in Honor of Jorg H. Siekmann on the Occasion of His 60th Birth-day, Lecture Notes in Computer Science, vol. 2605, pages 228–248.Springer, 2005.

[4] Franz Baader, Carsten Lutz, Maja Milicic, Ulrike Sattler, and FrankWolter. Integrating description logics and action formalisms: First re-sults. In Proceedings of the Twentieth National Conference on Ar-tificial Intelligence (AAAI-05), pages 572–577, Pittsburgh, PA, USA,July 2005. extended version is available as LTCS-Report-05-02 fromhttp://lat.inf.tu-dresden.de/research/reports.html.

[5] Daniela Berardi, Diego Calvanese, Giuseppe De Giacomo, MaurizioLenzerini, and Massimo Mecella. e-service composition by descriptionlogicsbased reasoning. In Diego Calvanese, GiuseppedeGiacomo, andEnrico Franconi, editors, Proceedings of the 2003 International Work-shop in Description Logics (DL-2003), Rome, Italy, 2003.

[6] Alexander Borgida. On therelativeexpressiveness of description logicsand predicate logics. Artificial Intelligence, 82(1-2):353–367, 1996.

[7] Hans de Nivelle and Ian Pratt-Hartmann. A resolution-based decisionprocedure for the two-variable fragment with equality. In A. LeitschR. Gore and T. Nipkow, editors, IJCAR’01: Proceedings of the FirstInternational Joint Conference on Automated Reasoning, pages 211–225, London, UK, 2001. Springer-Verlag, LNAI, V. 2083.

[8] GiuseppeDeGiacomo. Decidability of Class-Based Knowledge Repre-sentation Formalisms. Dipartimento di Informatica eSistemistica Uni-versita di Roma”La Sapienza”, Roma, Italy, 1995.

[9] Giuseppe De Giacomo, Luca Iocchi, Daniele Nardi, and RiccardoRosati. A theory and implementation of cognitive mobile robots. Jour-nal of Logic and Computation, 9(5):759–785, 1999.

[10] Yolanda Gil. Description logics and planning. AI Magazine, 26(2):73–84, 2005.

[11] Erich Gradel, Martin Otto, and Eric Rosen. Two-variable logic withcounting is decidable. In Proceedings of the 12th Annual IEEE Sym-posiumon Logic in Computer Science (LICS’97), pages306–317, War-saw, Poland, 1997.

[12] Michael Gruninger. Ontology of the process specification language. InSteffen Staab and Rudi Studer, editors, Handbook on Ontologies, pages575–592. Springer, 2004.

[13] Michael Gruninger and Christopher Menzel. Theprocess specificationlanguage (PSL): Theory and applications. AI Magazine, 24(3):63–74,2003.

[14] Yilan Gu and Mikhail Soutchanski. The two-variable situtation cal-culus. In Proc. of the Third European Starting AI Researcher Sympo-sium (STAIRS’06), to appear, Riva Del Garda, Italy, 2006. IOS Press.http://www.cs.toronto.edu/ yilan/publications/papers/stairs06.pdf.

[15] Ian Horrocks, Peter Patel-Schneider, and Frank van Harmelen. FromSHIQ and RDF to OWL: The making of a web ontology language.Journal of Web Semantics, 1(1):7–26, 2003.

[16] Richard Hull and Jianwen Su. Toolsfor compositeweb services: ashortoverview. SIGMOD Record, 34(2):86–95, 2005.

[17] Ullrich Hustadt and Renate A. Schmidt. Issues of decidability for de-scription logics in the framework of resolution. In R. Caferra andG. Salzer, editors, Automated Deduction, pages 191–205. Springer-Verlag, LNAI, V. 1761, 2000.

[18] Hector Levesque, Ray Reiter, Yves Lesperance, Fangzhen Lin, andRichard Scherl. GOLOG: A logic programming language for dynamicdomains. Journal of Logic Programming, 31:59–84, 1997.

[19] Yongmei Liu and Hector J. Levesque. Tractable reasoning with incom-pletefirst-order knowledge in dynamic systemswith context-dependentactions. In Proc. IJCAI-05, Edinburgh, Scotland, August 2005.

[20] Sheila McIlraith and Tran Son. Adapting Golog for composition of se-mantic web services. In D. Fensel, F. Giunchiglia, D. McGuinness, andM.-A. Williams, editors, Proceedings of the Eighth International Con-ference on Knowledge Representation and Reasoning (KR2002), pages482–493, Toulouse, France, April 22-25 2002. Morgan Kaufmann.

[21] Srini Narayanan and Sheila McIlraith. Analysis and simulation of webservices. Computer Networks, 42:675–693, 2003.

[22] Leszek Pacholski, Wiesław Szwast, and Lidia Tendera. Complexityof two-variable logic with counting. In Proceedings of the 12th An-nual IEEE Symposium on Logic in Computer Science (LICS-97), pages318–327, Warsaw, Poland, 1997. A journal version: SIAM Journal onComputing, v 29(4), 1999, p. 1083–1117.

[23] FioraPirri and Ray Reiter. Somecontributions to themetatheory of thesituation calculus. Journal of theACM, 46(3):325–364, 1999.

[24] Marco Pistore, AnnaPaola Marconi, Piergiorgio Bertoli, and PaoloTraverso. Automated composition of web services by planning at theknowledge level. In LesliePack Kaelbling and Alessandro Saffiotti, ed-itors, Proceedings of the Nineteenth International Joint Conference onArtificial Intelligence (IJCAI05), pages 1252–1259, Edinburgh, Scot-land, UK, July 30-August 5 2005. http://ijcai.org/papers/1428.pdf.

[25] Raymond Reiter. Knowledge in Action: Logical Foundations for De-scribing and Implementing Dynamical Systems. TheMIT Press, 2001.

[26] Evren Sirin, Bijan Parsia, Dan Wu, JamesHendler, and DanaNau. HTNplanning for web service composition using SHOP2. Journal of WebSemantics, 1(4):377–396, October 2004.

9

A ServiceSelectionModel to Impr oveCompositionReliability

Natallia Kokash1

Abstract. One of the most promising advantages of web servicetechnology is the possibility of creating added-value services bycombining existing ones. A key step for composing and executingservices lies in the selection of the individual services to use. Muchattention has been devoted to appropriate selection of service func-tionalities, but also the non-functional properties of the services playa key role. Due to ever changing business environment, service usersare not guaranteed from unexpected service faults. Service composi-tion can compensate the deficiencies of constituent components ag-gregating a redundant number of them for individual tasks. This pa-per proposes a service selection strategy targeting at minimizing theimpact of atomic service failure on the quality of service of compo-sitions.

1 Intr oduction

Service-Oriented Architecture (SOA) is an upcoming organizationalmodel aiming at simplifying large-scale business operations by con-sumption of ready-to-use services. The most prominent realizationof SOA is currently in the area of web services. Web servicesare loosely-coupled, platform-independent, self-describing softwarecomponents that can be published, located and invoked via the webinfrastructure using a stack of standards such as SOAP, WSDL andUDDI [12].

Composition of web services is probably the most interesting chal-lenge spawned by this paradigm. Many efforts have been devotedto development of automatic or semi-automatic service compositionmechanisms [1] [10] [16] [15]. We are striving for runtime compo-sition, when a composer automatically searches, binds and executesavailable web services to satisfy some user request. Such a scenariois hardly feasible for a large spectrum of applications. Automaticservice compositions are error prone. State-of-the-art techniques arenot mature enough to guarantee a common semantic of the involvedoperations. Testing, adaptation, verification and validation processesare required. However, statically composed services, able to accom-plish some generalized request classes (e.g., user trip planning), canpresume manifold alternative components for each subgoal and prac-tice dynamic switching between them. A set of services to satisfy aparticular user request is selected depending on conditions like Qual-ity of Service (QoS) parameters, service provider policy or user pref-erences. Several approaches for runtime selection of component ser-vices have been developed [7] [17] [18]. They tend to consider multi-ple quality factors and search for a solution that optimizes weightedcomposition of their average values under user constraints. In thispaper, we propose a novel service selection strategy. Our approach

1 Department of Information and Communication Technology, University ofTrento, Via Sommarive, 14, 38050 Trento, Italy, email: kokash@dit.unitn.it

differs from the existing works in two aspects. First, it is well-knownthat good average statistics do not prevent from unexpected servicefaults. We study the problem of service selection assuming theirprobable failures. The solution is represented by several composi-tions able to satisfy given constraints on quality parameters and toreduce fault recovery expenses. Second, we use a single quality mea-sure, that, though, takes into consideration the correlation betweenservice reliability and other parameters.

The paper is structured as follows. Section 2 discusses relatedwork. In section 3, quality and web service composition models areoutlined. Section 4 introduces a compound quality measure that char-acterizes reliability of redundant service compositions. Web serviceselection mechanism we propose is presented in Section 5. Finally,conclusions and future work are sketched in Section 6.

2 RelatedWork

In this section, we cover related work on QoS of atomic web servicesand web service compositions.

2.1 Quality of Atomic WebServices

Ran [13] describes basic non-functional QoS parameters. In Table 1,we list most common numeric factors that will be used below. Service

Table1. QoS factors of web services [13]

QoS DescriptionThroughput The number of requests served in a given time period.Capacity A limit of concurrent requests for guaranteed perfor-

mance.Latency The round-trip time between client request and ser-

vice response.Response time The time taken by a service to process its sequence of

activities.Availability The probability that a service is available.Reliability Stability of a service functionality, i.e., ability of a ser-

vice to perform its functions under stated conditionsReputation The average rate of the service reported by clients.Execution cost The amount of money for a single service execution.

Level Agreement (SLA) defines the agreed level of performance for aparticular service between a service provider and a service user. TheWeb Service Level Agreement (WSLA) project [6] is targeted at defin-ing and monitoring SLAs for web services. SLA parameters can bemeasured with different metrics, including composite ones like max-imum response time or average availability. Composite metrics arespecified byfunctions which are executed during the predefined time

10

intervals, specified byschedules. Sherchan et al. [14] report the rel-evance of recent service performance measurements. Service qualityparameters depend on manifold factors which should be taken intoaccount at the early stages of development. Menasce et al. [11] pro-vide a methodology for planning service capacity. Knowledge aboutthe number of potential users, frequency of service invocations andtheir time distributions is essential for the analysis. An accurate ca-pacity planning can be quite problematic because of factor uncer-tainty or limited budget. As a consequence, a signific ant number oftroublesome services could appear.

2.2 Quality of WebServiceCompositions

Service compositions that embed low-quality services inherit all theirdrawbacks. This poses a big challenge for the software developersbuilding new systems on the basis of available components. Cardosoet al. [4] describe the model that allows to predict quality of ser-vice for workflows based on atomic service QoS attributes. One cancompensate composition deficienc y if many services with compat-ible functionality exist. Several approaches have been proposed forquality-aware service selection. Zeng et al. [18] consider the serviceselection task as a global optimization problem. Linear programmingis applied to find the solution that represent the service compositionoptimizing the target function. The latter is defined as a linear com-bination of fi ve parameters: availability, successful execution rate,response time, execution cost and reputation. If the global character-istics (e.g., the total amount of money to accomplish the user goal),are not restricted, the optimal solution can be found by modifiedDijkstra’s algorithm searching on the graph of available composi-tions [8]. Martin-Diaz et al. [7] propose a constraint programmingsolution for procurement of web services whose demands and of-fers are temporal-aware. In [3] the problem is modelled as a mixedinteger linear program where both local and global constraints arespecified. Yu and Lin [17] modelled the service selection as a com-plex multi-choice multi-dimension 0-1 knapsack problem. Practiceof offering different quality levels by services was taken into con-sideration. The above solutions depend strongly on the user weightsassigned to each parameter. However, it is not trivial for a user toestablish them in right way. An example in Table 2 demonstrateslimitations of the algorithm in [18]. Let w1 = 0.6 and w2 = 0.4reflectthe user scores for response time and availability, correspond-ingly. After scaling and weighting phases service s1 will be chosen.However, the services have a small difference in response time anda huge diversity in availability rate. As a fast remedy, the intuitionabout absolute QoS values should be involved, e.g., from 0 to 100%for availability and from 0 to timeout ms for response time. Theprincipal drawback of the approach is that the cross-impact of differ-ent quality parameters is not considered.

Table2. QoS-aware WS selection [18]

Response time (ms) Availability (%) ResultOriginal Scaled Original Scaled w = (0.6, 0.4)

s1 1 1 10 0 0.6s2 2 0 100 1 0.4

Despite the efforts aimed at insuring web service reliability servicecomposition failures are almost inevitable. Nevertheless, they can begently treated and do not lead to the composition breakdown. Twobasic approaches for error recovery exist, namely backward and for-ward. The first one assumes the presence of redundant data allowing

to analyze the detected fault and put the system into a correct state.The second one returns the system into a previous fault-free statewithout requiring detailed knowledge of the fault. Workflow systemsrely intensely on backward error recovery if the resources are underthe control of a single domain. Forward recovery is extensively usedto handle errors in composite web services. Chafleet. al [5] proposea mechanism for fault propagation and recovery in decentralized ser-vice orchestrations. Decentralized architecture results in additionalcomplexity requiring fault propagation between partitions executedindependently.

3 WebServiceCompositionModel

As opposed to the discussed service selection approaches we do notconsider multiple QoS factors. Service reputation is excluded due toits subjective nature. High reputation of elementary services does notimply high reputation of their compositions due to potential problemswith input data and effect/precondition satisfaction that cannot befully verified at the planning phase. We do not consider the nature ofweb service faults and rely solely on probability of service success.It can be defined as

p(s) = Nsuc(s)/Ntotal(s),

where Nsuc is the number of successful service responses and Ntotal

is the total number of observed invocations. A service invocation isconsidered to be successful if the user goal is satisfied or we canproceed along with an execution of a composite service, i.e., (1) aconstituent service was available, (2) the successful response mes-sage was received within an established timeout, (3) no errors weredetected automatically during the output and effects checking, (4)preconditions of a subsequent service were satisfied. Along withthe probability of success we often use the probability of failurep(s) = 1 − p(s). The other relevant parameters are response timeqtime(s) and execution cost qcost(s) of service s.

A composite web service can be defined in terms of the standardBPEL (stands for Business Process Execution Language) [2] or othercomposition languages [9]. Services are composed by the followingthree operators

C ::= (s1; s2) | (s1|s2) | (s1 + s2),

where (s1; s2) denotes the sequential, (s1|s2) the parallel and (s1 +s2) the choice composition of services s1 and s2. If an error hap-pens in one of the parallel services, we suppose it will be correctlyforwarded to the end of partition [5]. After that we should decidewhether the whole parallel composition is failed or only the erro-neous branch has to be recovered. For the sake of simplicity wewill not consider parallel compositions here. Since we are mostlyinterested in the non-functional qualities, parallel compositions canbe approximately reduced to sequential ones as follows: for servicec = (s1|s2) its execution cost will be

qcost(c) = qcost(s1) + qcost(s2),

response time

qtime(c) = max(qtime(s1), qtime(s2)),

probability of success

p(c) = p(s1)p(s2)

11

Figure1. Composition graph

and probability of failure

p(c) = p(s1) + p(s2) − p(s1)p(s2).

Service composition can be represented as Directed Acyclic Graph(DAG) G = (S, T ) with two distinguished vertices (start and endpoints). Nodes denote states T = {tj |j = 1, ..., n} and edges arelabelled to represent available web services S = {si |i = 1, ..., m}.Generally, multiple edges between two nodes are permitted. Theprocessing of a user request begins from the start state t0. In theend state t the user goal is accomplished. These two states are well-defined for a given class of problems. It is assumed that all web ser-vices have deterministic behavior. A graph G = (T, S) is called acomposition graph (see Figure 1). Note that branching in the com-position graph corresponds to choice operator. Further, tail[si] willdenote a tail and head[si] a head of an edge si. Let also din[tj ] anddout[tj ] refer to input and output degree of a state tj , correspond-ingly.

Figure2. Configuration tree

A composition with choice operators can be separated into sev-eral sequential compositions, called configur ations, that correspondto paths between start and end states in a composition graph. Twoconfigurations are independent if they do not have common statesexcept start and end ones, and dependent otherwise. All possible con-figurations can be shown on theconfigur ation tree(see Figure 2). Thestart state of a composition graph corresponds to the start state of theassociated configuration tree, and nodes with the same labels havethe same output degree.

Definition 1 Node ti of a composition graph G is a return state ifeither it is the start state or its outdegree dout(ti) > 1.

The above statement defines the states in which a composite servicecan be returned to recover a failure of its components. For the com-position graph in Figure 1 return points are {t0, t2, t5}. A node ti isa return state of a configuration tree iff it is such in the correspondingcomposition graph.

4 Fault-tolerant ServiceCompositions

4.1 Fault Recovery

Existing service composition selection models do not take into ac-count unpredictable service faults. The problem cannot be fully re-solved by discarding the failed service. The time for finding a newsolution from scratch increases latency for the requests arrived inthe system. We propose to choose several configurations with goodqualities at the selection stage. If a failure occurs in the chosen con-figuration, another configuration can be switched into.

Figure3. Execution plan

In Figure 3, a possible execution plan is shown. A tuple 〈tj , ci〉with an incoming edge ak means that configuration ci is startedfrom state tj after event ak. In this example a1 means any fail-ure of composition c1, a2 denotes a failure of service s11 and a3

refers to a failure of services s4 or s7. A set of events and recov-ery actions can be established automatically based on the analysisof the dependency between configurations. In more complicated sce-narios the events like input/output is not correct/complete, precon-ditions/postconditions are not satisfied, message is lost, exception israised by a service, connection error, timeout is expired, SLA is vio-lated, etc., can require different reactions. At this point we can startanalyzing the error types in order to choose the optimal system be-havior.

4.2 Failur eRisk

Let c = (s1; s2; ...; sk) be a sequential composition with the onlyreturn point head[s1]. If a service si fails a new configuration can bestarted from state head[s1]. The results of services {s1, s2, ..., si}will not be used whereas their response time and execution cost in-crease the total expenses to satisfy a user request. We refer to theseexpenses as to the loss function of a service si failure. There are noreasons to impose penalties on services {s1, ..., si−1} since they arenot responsible for errors of service si. We propose a service selec-tion strategy based on the analysis of failure risks and targeted atdecreasing the expected loss in such a scenario.

Failure risk is a characteristic considering probability that somefault will occur and the resulting impact of this fault on the compositeservice. For an atomic service si it equals

r(si) = p(si)q(si).

Service s1 is considered to be better than service s2 if it has a smallerfailure risk r(s1) < r(s2).

Within the sequential composition c = (s1; ...; sk), k > 1, therisk of a service si failure is measured as

r(s1; ...; si) = p(s1; ...; si−1; si)q(s1; ...; si)

12

where

p(s1; ...; si−1; si) =

i−1∏

j=1

p(sj)p(si)

is the probability of composition failure while service si is beingexecuted, and

q(s1; ...; si) =

i∑

j=1

q(sj)

is the loss function of this failure. Since for a sequential compositionall services should be invoked to accomplish a task, we exploit a totalrisk value which for a k-service long chain equals

R(c) = R(s1; ...; sk) =

k∑

i=1

r(s1; ...; si). (1)

Let c = (s1 + ... + sl), l > 1, be a choice composition such thata service si is invoked if the alternatives {s1, ..., si−1} failed. Thefailure risk of an i-service long choice is defined as

r(s1 + ... + si) = p(s1; ...; si)q(s1; ...; si),

where

p(s1; ...; si) =

i∏

j=1

p(sj).

The choice composition fails if all invoked services fail. Obviously,the better candidates should be tried first. The question then is howmany services to consider. We propose to include a new candidate ifit does not increase the total failure risk for the choice composition,i.e.

R(c) = R(s1 + ... + sl) = mini=1,l

r(s1 + ... + si). (2)

Finally, the failure risk of a composition c = (c1; c2), where c1 =(s1; ...; sk) is a sequential composition and c2 = (s′1 + ... + s′l) is achoice one, can be computed as

R(c) = R(c1; c2) = R(c1) + p(c1)p(c2)(

q(c1) + q(c2))

.

Above, q = {qtime, qcost} refers either to response time or toexecution cost. If the user preferences are given, it can incorporateboth of them: q(s) = f(qtime, qcost). Assuming that f is a linearcombination, we get

q = w1qtime + w2qcost |w1 + w2 = 1, 0 ≤ w1, w2 ≤ 1.

For simplicity we supposed that the money for the invocation of afailed service s are not payed back and the time to detect the errordoes not differ significantly from the usual service response time. Ifthis is not the case, the corresponding corrections can be introduced,i.e., the loss function of a service s will be

q(s) = {qttd(s), qcost − qpenalty(s)},

where qttd stands for error time-to-detect and qpenalty is a penaltypayed by the provider of a failed service.

Failure risk is a compound measure considering probability ofconstituent service failures, their response time and/or execution costalong with the structure of a configuration tree. Intuitively, config-urations with frequent return points are more preferable. However,the composition selection will depend on the balance between all

mentioned parameters. We do not strictly require that the loss func-tion should be linear. So, we can measure the response time of acomposite web service with a certain probability as follows: LetP1(t ≤ t1) and P2(t ≤ t2) be the probabilities that services s1

and s2 respond within time t1 and t2, respectfully. Let P (t ≤ t0)be the probability that a composite service s = (s1; s2) will re-spond within time t0. Letting p1(t) and p2(t) be the correspondingprobability density functions, p(t) can be calculated as a convolu-tion p(t) =

∫

p1(t − τ)p2(τ)dτ and P (t ≤ t0) can be obtained by

taking corresponding distribution P (t ≤ t0) =t0∫

0

p(t)dt.

5 WebServiceSelectionMethodology

5.1 Objectives

It is reasonable to assume that an SLA with the end user is establishedin such a way that available service configurations can satisfy theconstraints on response time and execution cost provided the normalconditions, i.e., that the services are not overloaded and no failuresbefall. However, the unexpected faults of component services lead toresource loss and may cause the violation of negotiated parameters. Ifthere is reserve of the resources (the maximum budget for a task is notreached and there is time left before task execution deadline), a usertask can be completed by another configuration . Our objective is tochoose an execution plan (see Figure 3) that maximizes compositionreliability, which is actually defined by the probability to accomplisha user request within established time and cost boundaries.

The problem of increasing service reliability differs from thesearch of a single configuration with optimal quality parameters. Fora single-objective function the latter one can be formalized as se-lection of a path (s1; ...; sk) between the start and end states thatmaximizes the following target function:

f(c) = p(c)(qmax − q(c)) = p(s1; ...; sk)(qmax − q(s1; ...; sk)) =

=k∏

i=1

p(si)(qmax −

k∑

i=1

q(si)),

where qmax defines the resource limit, taken from an SLA (or chosenbig enough to guarantee the positive value of f(c)). Such a configu-ration can be found in time O(m), where m is a number of availableweb services, by searching of a path in a configu ration graph opti-mizing the formula above.

However, practical problems rarely have only one objective. Thesimplest multi-objective problems focus on two criteria. This sub-class of problems is known as dual criteria optimization. The basicapproach is to take the less important parameter as objective functionprovided that the most important criterion meets some requirements.We identify two basic dimensions, namely, response time and exe-cution cost. Although it is hard to predict which of them is moreimportant we suppose that for a provider of composite web servicesfocus should be put on response time. Usually, the internal structureof services is hidden from the end-user, so (s)he expects to pay thefix ed price for a single service execution (provided the same qual-ity level). At the same time, service delays can be indemnified bypenalties. On conditions that response time constraint is satisfied, aprovider can optimize its own expenses.

5.2 Failur eRisk Evaluation Algorithm

In this section we present our risk evaluation model for compositeweb services.

13

To simplify the explanation of the proposed algorithm we will usethe notion of graph contraction. The contraction of an edge (vi, vj)of a directed graph is the directed graph obtained by replacing twonodes vi and vj with a single node v such that v is a head of the edgesincoming to the original vertices and a tail of the edges outgoingfrom them. The contraction of a graph is a process of transformingthe graph by applying the operation of edge contraction. A sequen-tial composition (s1; ...; sk), k > 0, can be seen as an elementaryservice with the failure risk obtained by formula (1) (see Figure 4).

Figure4. Contraction operations in a composition graph

To show this graphically we can contract the path (s1; ...; sk), k >0, in the configuration tree to a single edges. After replacing all thepaths we will get a reduced tree, where each node is either a returnpoint or the end state, still unambiguously representing all possibleconfigurations (see Figure 5). Such a tree is called acontracted con-figur ation tree.

Figure5. Contracted configuration tree

Any choice composition (s1 + ... + sl), l > 0, can be seen asan elementary service with the failure risk obtained by formula (2).However, we can calculate failure risks of composite services withalternative components only if the failure risks of the latter ones areknown, which, in their turn, can be composite as well.

The above observations define our failure risk evaluation algo-rithm (see Algorithm 1). Given a composition graph, it computesthe failure risks of composite services defined by the subtrees of anyreturn point. Given these values, a weighted contracted configurationtree can be formed where edges with smaller weights represent themost promising directions.

For each composite service si let stack[si] be a structure whereQoS parameters of constituent services are accumulated. Startingfrom the end state we gradually contract edge chains and partitionsassigning failure risks to the corresponding services as has been dis-cussed in Section 4.2. The end state t is the only point satisfying thecondition dout[t] = 0 at the initial step of the algorithm. Since acomposition graph is acyclic, after removing of an edge si we againwill have the states without outgoing edges. When we reach a returnpoint, the chain in the stack of si is contracted and its failure risk ismeasured by (1). Provided that no more sequences can be processed,the algorithm switches into choice compositions. Each choice com-position is replaced by a service with the failure risk computed by

(2), and this information is transmitted to the precedent edges. Then,we repeat sequential composition replacement again, and so on, ter-minating if no more composite services are found in graph G′.

Algorithm 1. Failur eRisk Evaluation (FRE)1 G′ ← G, G′ = (T ′, S′)2 while |S′| ≥ 1 do3 Sequential(G′)4 Choice(G′)Sequential(G′)1 for all si | dout[head[si]] = 0 do2 if (dout[tail[si]] = 1) and (tail[si] 6= t0) then3 for all sj |head[sj ] = tail[si] do4 stack[sj ]← stack[si]← sj

5 S′ = S′\si

6 else//tail[si] is a return point7 s← sequential composition of services stack[si]8 remember R(s) as a weight of the edge si in graph G9 S′ ← S′\si ∪ s

Choice(G′)1 for all ti | (dout[ti] > 1) ∪ (∀tk ∈ adj[ti], dout[tk] = 0) do2 s← choice composition of services {sj} = {(ti, tk), | ∀tk}3 for all sj |head[sj ] = ti do4 stack[sj ]← s5 S′ ← S′\{si}

Proposition1 Given a composition graph G = (T, S), the algo-rithm FRE measures the failure risks of the composite services de-fined by the subtrees of return points in polynomial time from numberof available web services.

A proof follows from the next observations:

Sequential(G′): The information about each servicesi, | dout[tail[si]] = 1, is pushed into din[tail[si]] stacksand can be processed in time O(1) later. So, for any statetail[si], a time O(din[tail[si]]) is required and this state willnot be considered again by this function. Summing up by allstates we get the process time of all sequential compositionsO(

∑n

i=1din[tail[si]]) = O(m).

Choice(G′): For each state ti time mdout[ti] ln(dout[ti]) is re-quired to calculate the failure risk and din[ti] to transmit thisinformation for the precedent services. After that its outgoingedges are deleted and it will not be considered again. Hence, theprocessing of all choice compositions can be accomplished in timeO

(∑n

i=1(din[ti] + mdout[ti] ln(dout[ti])

)

= O(m2 ln(m)).

A composition configuration can be chosen by a simple greedyheuristic that selects a service with the least failure risk in any re-turn state. In case of a service failure, gradual change is preferable tosudden, large-scale switching into other configuration since we max-imally reuse the results of already invoked services, that is, a com-posite service should go back to the nearest return point and completethe job by ”attaching”a new configuration. The alternative choiceswith poor quality (i.e., ones that increase the total failure risk) areexcluded from the calculation of failure risk of choice composition.However, such services still can be invoked to recover a failure ifthere are no better alternatives and the loss of rollback to the nextreturn point is significant.

6 Concluding Remarksand Futur eWork

Risk analysis is an important process accompanying the develop-ment of any significant software system. Being business-oriented ap-plications, constructed from uncontrolled components and used via

14

the Internet, web service compositions imply a long list of potentialrisks, varying from security threats to economic unprofitableness. Insuch conditions self-adaptivity and redundancy are desirable com-position qualities traded against development cost and performanceefficienc y.

We proposed a model for selecting web services that aims at in-creasing the reliability of service compositions. We introduced thenotion of failure risk for web services and proposed a compositionfailure risk evaluation methodology. Further, we brieflydescribed theselection algorithm based on local analysis of promising configura-tions.

Several important issues have been left out of the scope of this pa-per. Careful study of parallel service compositions and dependabilitybetween different configu rations is needed. Comprehensive experi-ments should be carried out in order to characterize the effectivenessof our model. Here we pursued the goal of failure risk minimizationprovided that a request should be executed within some constraintson time and cost, but without intention to minimize these expenses.The problem of finding an execution plan that maximizes the proba-bility to fulfill the task and spend minimal resources can be tackled inthe same manner. In some cases we can distinguish permanent faultsand temporal faults (e.g., intermittent server crashes). The latter arecharacterized by time to repair. It can be reasonable to repeat the in-vocation of the same service instead of switching into an alternativeconfiguration.

We intend to deeper investigate the optimization problems relatedto usage of web service compositions. As a future work we are plan-ning to look into the perspectives of using advanced scheduling poli-cies. Real-life conditions such as limited service capacity, failures,execution deadlines, provider vs. client interests, etc., transform de-velopment of reliable composite services into a challenging task. Sta-tic selection models can be useful if the chosen services require sig-nificant adaptation efforts and involvement of alternative ones is notfeasible or expensive. In dynamic scenarios the end-user would pre-fer a fast service despite of its low average availability if it is avail-able at the moment of invocation, or a slower service provided thatthe faster one is overloaded.

Acknowledgments

We are grateful to Marco Aiello for his useful comments on the paper.

REFERENCES[1] Aggarwal, R., et al.: ”Constraint-driven Web Service Composition in

METEOR-S”, IEEE Conference on Service Computing, 2004.[2] Andrews, T., Curbera, T. et al.: ”BusinessProcess Execution Language

for Web Services”,2003,ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf.

[3] Ardagna, D., Pernici, B.: ”Global and Local QoS Constraints Guaran-tee in Web Service Selection,” IEEE International Conference on WebServices, 2005, pp. 805–806.

[4] Cardoso, J., Sheth, A., Miller, J., Arnold, J., Kochut, K.: ”Quality ofservice for workflows and web service processes”, Journal of Web Se-mantics, Vol. 1, No. 3, 2004, pp. 281–308.

[5] Chafl,G., Chandra, S., Kankar, P., Mann, V.: ”Handling Faults in De-centralized Orchestration of Composite Web Services”, InternationalConference on Service-Oriented Computing, 2005, pp. 410–423.

[6] Dan, A., Davis, D., Kearney, R., et al.: ”Web services on demand:WSLA-driven automated management”, IBM Systems Journal, Vol. 43,No. 1, 2004, pp. 136–158.

[7] Martin-Diaz, O., Ruize-Cortes, A., Duran, A., Muller, C.: ”An Ap-proach to Temporal-Aware Procurement of Web Services”, Interna-tional Conference on Service-Oriented Computing, 2005, pp. 170–184.

[8] Gu, X., Chang, R.: ”OoS-Assured Service Composition in managedService Overlay Networks”, IEEE International Conference on Distrib-uted Computing Systems, 2003.

[9] Kokash, N., D’Andrea, V.: ”ServiceOriented Computing and Coordina-tion Models”, Proceedings of Challenges in Collaborative EngineeringWorkshop, 2005, pp. 95–103.

[10] Lazovik, A., Aiello, M., Papazoglou, M.: ”Planning and monitoringthe execution of web service requests”, International Conference onService-Oriented Computing, 2003, pp. 335-350.

[11] Menasce, D. and Almeida, V.: Capacity Planning for Web services,Prentice Hall, Upper Saddle River, NJ, 2002.

[12] Papazoglou, M. P., Georgakopoulos, D.: ”Service-orientedcomputing”,Communications of the ACM, Vol. 46, No. 10, 2003, pp. 25–28.

[13] Ran, Sh.: ”A Model for Web Services Discovery With QoS”, ACMSIGecom Exchanges, Vol. 4, No. 1, 2003, pp. 1–10.

[14] Sherchan, W., Krishnaswamy, Sh., Loke, S-W.: ”Relevant Past Perfor-mance for Selecting Web Services”, International Conference on Qual-ity Software, 2005, pp. 439–445.

[15] Srivastava, B., Koehler, J., ”Web Service Composition - Current Solu-tions and Open Problems”, Proceedings of ICAPS Workshop on Plan-ning for Web Services, 2003.

[16] Sirin, E., Hendler, J., Parsia, B.: ”Semi-automaticComposition of WebServices Using Semantic Descriptions”, In Web Services: Modeling,Architecture and Infrastructure workshop in ICEIS, 2003.

[17] Yu, T., Lin, K.J.: ”Service Selection Algorithms for Composing Com-plex Services with Multiple QoS Constraints”, International Confer-ence on Service-Oriented Computing, 2005, pp. 130–143.

[18] Zeng, L., Benatallah, B., et al.: ”QoS-aware Middleware for Web Ser-vices Composition”, IEEE Transactions on Software Engineering, Vol.30, No. 5, 2004, pp. 311–327.

15

Abduction for Specifyingand Verifying WebServiceandChoreographies

FedericoChesani,PaolaMello, Mar coMontali 1

Mar coAlberti, Mar coGavanelli, Evelina Lamma, Sergio Storari 2

Abstract. Global choreographieshave beenrecentlyproposedasa way for specifyingtheoverall behaviour of a systemcomposedofheterogeneouswebservices.In this work, we proposeanabductiveframework basedon computationallogic to specifybothchoreogra-phiesandwebserviceinterfacebehaviours.Oneof themainmotiva-tionsfor usingcomputationallogic is thatits operationalcounterpartprovidesaproof-theoreticsupportableto verify, from differentview-points, the conformanceof servicesdesignedin a cooperative andincrementalmanner. We show how it is possibleto specifyboth thechoreography andthewebserviceinterfacebehaviours(restrictedtotheconversationaspects)usingauniformformalismbasedonabduc-tive logic programs.Then,we provide a definitionof conformance,andshow how, by usinganabductive proof procedure,it is possibleto automaticallyverify theconformanceof agivenwebservicew.r.t.acertainchoreography.

1 INTRODUCTION

Therecentandfastgrowth of network infrastructures,suchastheIn-ternet,is spawninganew rangeof scenariosandemergingparadigmsfor distributedcomputing.Oneof themis ServiceOrientedComput-ing, which finds its origin in object-orientedand componentcom-puting.Web servicetechnologyis an importantinstanceof ServiceOrientedComputingaimingat facilitatingtheintegrationof new ap-plications,avoidingdifficultiesdueto differentplatforms,languages,etc. Servicecomposition- building complex servicesfrom simplerones- requiresmethodologiesin ordertoverify, for instance,whetherthecommunicative behaviour (Behavioural Interface)of anexistingserviceconformsto theinteractionrules(a choreography) and,thus,whethertheservicein questionwould beableto play a givenrole inthatchoreography.

From the Web Servicetechnologyviewpoint a fundamentalre-quirements[4] is to provide tools to validateconformanceto chore-ography descriptionsto ensureinteroperability, to enablestaticor dy-namicverificationof choreographiesandto ensurethatthelocal be-haviour of participantsconformsto the choreography specification.To this purpose,it is crucial to formalizeboth choreographiesand(behaviour interfacesof) Web Servicesby using formal languagesthatprovidesthesevalidationcapabilities.

In theMulti-Agent Systems(MAS) community, ontheotherhand,thereis a wide literatureaboutcheckingcomplianceof agentsto so-cial rules,bothat run-timeandat design-time.Baldoniet al. [3] firstrecognisedthe similarities in the two areas.In particular, societies

1 DEIS,Universityof Bologna2 ENDIF, Universityof Ferrara

of agentsandcompositions of Web Services,althoughdefinedanddesignedin differentcontexts,sharethefollowing features:

• They describea collaborationbetweena collectionof partiesinorderto achieveacommongoal.

• They shouldcapturetheinteractionsin which theparticipantsen-gageto achieve thisgoal.

• They shouldcapturethedependenciesbetweeninteractions(con-trol-flow dependencies,messagecorrelations,time constraints,etc.)by expressingglobal interaction protocols.

• They shouldcaptureinteractionsfrom a global perspective and,therefore,they shouldnot describeany internalaction that doesnotdirectly resultin anexternal,visibleeffect.

• Protocolsshouldbeexpressed,if possible,in a formal language.

In this work, we investigatethe feasibility of usingan abductiveframework groundedon computationallogic, definedin thecontextof MAS for Global Computing,for modellingboth choreographiesandbehavioural interfacesof WebServices.

We build upon the SCIFF framework, developedin the areaofMAS for specificationandverificationof interactionin openagentsocieties.In SCIFF, a social specificationis meantto specify theobservable agentbehaviour, ratherthantheagents’internalsor poli-cies.SCIFF hasbeenusedfor expressingsocialsemanticsof agentcommunicationlanguages[1], andanumberof interactionprotocols.

Weproposeaframework, calledAlLoWS(AbductiveLogic Web-serviceSpecification),wherebothWebServicesandchoreographiesaremodelledasabductive logic programs.In AlLoWS, we exploitthe SCIFF proof procedureto formally prove conformanceof theparticipatingWebServicesto achoreography specification,by iden-tifying setsof abducedhypotheseswhich satisfyboth thespecifica-tionsandtheformal definitionof conformance.In this way, we stat-ically analysethe behaviour of choreographiesandindividual WebServices,andproveapriori conformance.

2 AlLoWS: AN ABDUCTIVE FRAMEW ORK

Theframework wepropose,AlLoWS(AbductiveLogic Web-serviceSpecification),is basedon Abductive Logic Programming(ALP[14]), andin particularit is derivedfrom theSCIFF framework, de-velopedin theSOCSprojectfor opensocietiesof agents[1].

As we demonstratein the following, the languageis expressiveenoughto specifytypical choreographiesandwebservices.Theop-erationalsemanticsof the languageis usedfor the verification ofconformanceof awebserviceto achoreography.

In AlLoWS, the behaviour of the web servicesis representedbymeansof events. Sincewe focus on the interactionsbetweenweb

16

services,events always representexchangedmessages.The syn-tax is the sameusedin [3]: a messageis describedby the termmx(Sender, Receiver, Content), wheremx is the type of mes-sage,andtheargumentsretaintheir intuitivemeaning.

AlLoWShastwo typesof events:happened events(denotedby thefunctorH) andexpected events(denotedby E, andalsocalledex-pectations). Bothareabducible,andrepresenthypotheseson,respec-tively, which eventshave happenedandwhich areexpectedto hap-pen:H(mx(. . .), Tx), expressesthefactthatamessagemx hasbeenexchangedbetweentwo peersat time Tx, whereasE(mx(. . .), Tx)saysthatthemessagemx is expectedto beexchangedat timeTx.

In thispaper, thetimeparametermaybeomittedwhennonessen-tial.

Choreographiesandwebservicesarespecifiedby imposingarela-tionbetweenhappenedandexpectedeventsbymeansof anabductivelogic program,asexplainedin Sections2.1and2.2.

2.1 Specificationof a Choreography

A choreography describes,from aglobalviewpoint,whatarethepat-ternsof communication,or interactions,allowed in a systemthatadoptssuchchoreography [4]. The choreography specificationde-finesthe messagesthat areallowed: it is not possibleto exchangeothermessagesthanthe onesspecified,andin a definedorder. Thechoreography alsoenliststhe participants,the rolesthe participantscanplay, andotherknowledgeaboutthewebserviceinteraction.

We specifya choreography by meansof an abductive logic pro-gram.

An abductive logic program[14] is a triple 〈P, A, IC〉, whereP

is a logic program,A is a setof distinguishedpredicatesnamedab-ducibles, andIC is asetof integrity constraints.Reasoningin abduc-tivelogic programmingis usuallygoal-directed(beingG agoal),andcorrespondsto finda setof abducedhypotheses∆ built from predi-catesin A suchthatP ∪ ∆ |= G andP ∪ ∆ |= IC. Suitableproof procedures(e.g.,Kakas-Mancarella[15], IFF [12], SLDNFA[7], etc.)have beenproposedto computesuchset∆, in accordancewith thechosendeclarativesemantics.

A choreography specificationPchor is definedby thetuple:

Pchor ≡ 〈KBchor, Echor, ICchor〉

• KBchor is theKnowledge Base,• Echor is thesetof abducible predicates, and• ICchor is thesetof Choreography Integrity Constraints.

KBchor specifiesdeclaratively piecesof knowledgeof thechore-ography, suchasroledescriptionsandthelist of participants.It is ex-pressedin theform of clauses(alogic program)thatmayalsocontainin their bodyexpectationsaboutthebehaviour of participants.

Theabducible predicates arethosethatcanbehypothesizedin ourframework, namelyhappenedevents(H) andexpectations(E).

Choreography Integrity Constraints areforwardrules,of theformbody → head, whosebody cancontainliterals and (happenedandexpected)events,andwhosehead is a conjunctionof expectations.The syntaxof ICchor is the samedefinedfor the SOCSIntegrityConstraints[1], but in AlLoWS we do not usenegative expectationsandnegation(¬), sincethey arenotneeded.

Considerthe simplechoreography in Fig. 1, wherea multi-partyinteractionis shown asa UML activity diagram.The interactionisinitiatedby a Customer thataskstheSupplier for a certaingood.TheSupplier queriestheWarehouse for theavailablequantityofthat good,andforwardsthe answerto the Customer. Then,if the

Figure1. UML activity-chartof asimplechoreography

quantity Q is higher than zero, then Supplier notifies the bill toCustomer, andashipmentorderis sentto Warehouse. Otherwisetheinteractionterminates,sincethereis nogoodavailablefor buying.

Thespecificationin termsof ICchor is givenby Eq. (1-5): in par-ticular, Eq. 4 shows how to expressalternative behaviours whoseselectionis dependentby the contentof previous messages,and itshows how to expressconcurrency of actions.It specifiesthat,aftercommunicatingtheavailablequantityQ of Good to Customer, andif Q > 0, thenSupplier shouldnotify the bill to Customer, anda shipmentorderto Warehouse. In AlLoWS, theconditionQ > 0is intendedasaconstrainta la CLP(ConstraintLogic Programming,[13]); CLP constraintscanalsobeusedto imposeanorderbetweenmessages,by imposingrelationson the time instantsthe eventsareexpected.

H(request(Customer, Supplier, Good), Tr)→ E(query(Supplier, Warehouse, Good), Tq) ∧ Tq > Tr.

(1)

H(query(Supplier, Warehouse, Good), Tq)→ E(answer(Warehouse, Supplier, Good, Q), Ta)

∧ Ta > Tq.(2)

H(answer(Warehouse, Supplier, Good, Q), Ta)→ E(provide(Supplier, Customer, Q), Tp) ∧ Tp > Ta.

(3)

H(provide(Supplier, Customer, Q), Tp) ∧ Q > 0→ E(send(Supplier, Customer, Bill), Tb)

∧ E(shipOrder(Supplier, Warehouse, Good), Ts)∧ Tb > Tp ∧ Ts > Tp.

(4)

H(send(Supplier, Customer, Bill), Tb)→ E(pay(Customer, Supplier, Bill), Tp) ∧ Tp > Tb.

(5)

2.2 Specificationof a WebService InterfaceBehaviour

Uniformly to the specificationof a choreography, we definethe in-terfacebehaviour of a webserviceasanAbductive Logic Program.Werestrictourspecificationto thecommunicativeaspectsof thewebservice.A WebServiceInterfaceBehaviour SpecificationPws is anAbductiveLogic Program,representedwith thetriple

Pws ≡ 〈KBws, Ews, ICws〉

17

• KBws is theKnowledge Base of theWebService,• Ews is thesetof abducible predicates, and• ICws is thesetof Integrity Constraints of thewebservice.

KBws andICws arecompletelyanalogousto their counterpartsin the choreography specification,except that they representan in-dividual,ratherthanglobal,perspective: they represent,respectively,thedeclarativeknowledgeandthepoliciesof thewebservice.

Ews is thesetof abduciblepredicates:asfor thechoreographies,itcontainsbothexpectationsandhappenedevents.TheexpectationsinEws canbedividedinto two significantsubsets:

• expectationsaboutmessageswherews is thesender(of theformEws(mx(ws, A, Content))), i.e.,actionsthatws intendsto do;

• expectationsaboutmessagesutteredby otherparticipantsto ws

(of the form Ews(mx(A, ws, Content)), with A 6= ws), whichcanbeintendedasthemessagesthatws is ableto understand.

(a) (b)

Figure2. Exampleof behavioural interfaces

In Fig. 2(a) thecommunicative partof the interfacebehaviour ofa web serviceis representedasUML activity diagrams.The corre-spondingtranslationin termsof ICws is givenby Eq.(6).

H(query(Supplier, Warehouse, Good), Tq)→ E(answer(Warehouse, Supplier, Good, Q), Ta)

∧Ta > Tq.

(6)

3 CONFORMANCE

Intuitively, conformanceis thecapabilityof awebserviceto interactwith theotherpeersaccordingto a choreography. A webservicews

will beconformantto a choreography if it compliesto thechoreog-raphy in all possibleinteractions.Althoughintuitive,suchdefinitionis not directly usablefor automaticverification,asit doesnot spec-ify which actionsthewebservicewill beableto perform,andhowtheotherpeerswill behave. We assumethewebservicewill actac-cordingto its own specifications,Pws, andthat theotherpeerswillbehaveasdefinedin thechoreography specification Pchor.

For instance,in Fig. 2(a) and 2(b) two possibleinterface be-havioursareshown: while thelattershowsawebserviceconformantfor theroleof Customer in thechoreography, theformerrepresentsa webservicethatwould play therole of Warehouse, but it is notconformantto that role w.r.t. thespecifiedchoreography. In particu-lar, thenon-conformanceis givenby thefactthatthewarehousewebservicedoesnotacceptthepossibleincomingshipordermessage.

Conformancecanbebasedon theobservationof therelationsbe-tweentheallowedinteractions,andthebehavioursexpectedbothbythechoreography andthewebservice.Basedon thecurrentinterac-tion status,thechoreography will prescribeacoherentsetof possibleevolutions.Eachevolution containsthe expectationsof the chore-ography on thebehaviour of theparticipants:someexpectationsareaboutthe web servicews undertesting,while otherswill concernthebehaviour of theotherparticipants.Thesetof expectationsof thechoreography will beindicatedin thefollowing with EXPchor.

Analogously, eachwebserviceparticipatingin thechoreographyhasexpectationson thebehaviour of theotherpeers:afteraquestionit will expect a reply, or after sendinga bill, it will expect a pay-ment.Also, the web servicemight have expectationsaboutits ownbehaviour, expressingtheintentionto performsomeactions.Thesetof expectationsof awebservicews is denotedby EXPws. Wewilloftenwrite EA(. . .) asashortcutfor E(. . .) ∈ EXPA.

The complianceof a web serviceis basedon the complianceofsingleinteractions:awebserviceis compliantif all theinteractionsitcanpossiblygeneratebelongto thechoreography specification.Notehowever that it is not necessary to checka full interactionhistory:assoonasa violation is detected,thesubsequent(possibly, infinite)evolutionsareof no interest.We focuson the interactionsof totalagreement: thosehistories(i.e., sequencesof happenedevents)forwhich all actionsexpectedbothby thechoreography andby thethewebserviceunderobservationareindeedconsideredashappened.

Definition 1 Given the abductive program 〈KBU , EU , ICU 〉,

• KBU , KBchor ∪ KBws

• EU , Echor ∪ Ews

• ICU , ICchor ∪ ICws

an interactionis a pair (HAP,EXP) where HAP is a set of atomsbuilt with predicate H, and EXP is a set of atoms build with predi-cates in EU such that

KBU ∪ HAP ∪ EXP |= G (7)

KBU ∪ HAP ∪ EXP |= ICU (8)

Total Agreement Interactions are the minimal interactions(HAP

py,EXPpy) for which

KBU ∪ HAPpy ∪ EXP

py |= ICtot

where ICtot contains the following implications

Echor(mx(S, R, M)), Ews(mx(S, R, M))→ H(mx(S, R, M))

(9)

Echor(mx(A, B, M)) ∧ A 6= ws ∧ B 6= ws

→ H(mx(A, B, M))(10)

G is the goal of the derivation; it dependson the propertyof thewebservicewewantto prove.

Conditions(7) and(8) specifytheabductive EXP. Note that foreachHAP therecouldbemoreEXP thatsatisfyconditions(7) and(8). Condition(9) imposesthat total agreementinteractionscontainin thehistoryonly messagesthatwereexpectedby boththechoreog-raphy andthewebservice.Condition(10) tacklesmulti-partyproto-cols,andrequiresthatany dialoguebetweenotherpeers(apartfromws) doesevolveasspecifiedin thechoreography.

Wecannow provideadefinitionof conformance basedonthetotalagreementinteractions,selectingthosethatindeedrespectthechore-ography andwebservicesspecifications.

18

Definition 2 (∃-Conformance) A web service specification Pws

is existentially conformant to a choreography specificationPchor if there exists at least one total agreement interaction(HAP

py,EXPpy) such that the following implications hold:

Ews(mx(ws, A, M)) → H(mx(ws, A, M)) (11)

Echor(mx(S, A, M)) → H(mx(S, A, M)) (12)

Definition 3 (∀-Conformance) A web service specification Pws isuniversallyconformantto a choreography specification Pchor if forall pairs (HAP

py,EXPpy) of Def. 1 the conditions (11-12) hold.

Condition(11) requiresthat if ws hadanexpectationaboutsend-ing amessage,thecorrespondingeventshouldhavehappened.If thisevent is not presentin HAP

py, from Def. 1 we can infer that theeventwasunexpectedfrom thechoreography viewpoint.This situa-tion correspondsto thecasewherews is determinedto uttera mes-sagethat is not envisagedby thechoreography: in this casethereisnot conformancebetweenws andthechoreography.

Condition(12)requiresthateverymessageexpectedby thechore-ography indeedhappens.Togetherwith conditions(9) and(10), thismeansthat all expectationsinvolving the web serviceundertestingarematchedby acorrespondingexpectationof thewebservice.Thisconditionis falseif thereexistsanexpectationof thechoreographywithoutacorrespondingexpectationfrom thewebservice,i.e.,eitherif thews mayreceive (duringinteractionsapprovedby thechoreog-raphy) a messageit is not ableto understand,or if the web servicefailedto to utteramessagethatthechoreography expects.

For symmetryreasons,onewouldexpectalsoa ruleaboutthesat-isfaction of a web service’s expectationon the behaviour of otherpeers.Sucha rule is not necessary, becausein this caseeither theinteractionis consideredsuccessfullyfinishedby the choreography(andin thiscaseweconsiderconformantthewebservice),or ws willbeexpectedto performsomefurtherinteraction,thatwill remainun-fulfilled from thechoreography viewpoint (andthenonconformancewill bedetectedby oneof therules(11-12)).

WhenDefinitions2 and3 hold togetherfor a webservice ws, wesaythatws is conformant. Let usseehow conformancecanbetested.

4 CONFORMANCE TEST

AlLoWS usestheSCIFF proof procedurefor proving conformance.SCIFFis anabductiveproofproceduredevelopedfor on-the-flycon-formancecheckingin MASs[2]. It takesasinputaninitial historyofhappenedeventsHAP

i andgeneratestheexpectedbehaviour of theagents(EXP) while acceptingon-line further events.SCIFF con-sistsof asequenceof transitions;whenit reachesquiescencein non-failurenodes,it hasasuccessfulderivation,indicatedwith

KBHAPi `HAPf

EXP G

whereG is thegoalof thesociety, HAPf is thefinal historyat the

quiescence,andEXP is thesetof generatedexpectations.In order to perform a priori conformancechecking,we needto

generate setsof events.We thereforedevelopeda generative versionof SCIFF, which is ableto producethehappenedevents,insteadofjust taking themasinput. We declaredH asanabduciblepredicateandaddedtheintegrity constraints(9) and(10). In thisway, wehavethat

KB `EXP∪HAP G

i.e.,aSCIFFderivationprovidesthesetof happenedeventsasoutputof theabductionprocess.

The verificationof the conformanceof a web service Pws to achoreography Pchor is performedin two steps.

Generation of total agreementinteractions. The first stepis tobuild total agreementinteractions.This is doneby applyingthegen-erative versionof SCIFF to the abductive programof Def. 1, withtheadditionalintegrity constraints(9) and(10), i.e.:

〈KBU , EU , ICtot〉

SCIFF is soundandcompletefor theso-calledallowed programs,i.e., undersomesyntacticrestrictionsthat aresatisfiedby the pro-gramsof AlLoWS. It canbe trivially proven that declaringthe H

predicateasabducibleandaddingintegrity constraints(suchas(9)and (10)) doesnot underminethe results,so the versionexploitedin AlLoWS is soundandcompleteaswell. Thanksto theseresults,thenon-failureleafnodesof theprooftreeareexactlythetotalagree-mentinteractions.Thus,if thiscomputationfails,thereexistsnototalagreementinteraction,sotheWebServiceis not∃-conformant.

Verification of total agreementhistories The secondstepis toperforma SCIFF derivation to checkif all the total agreementin-teractionsgeneratedin the previous steprespectthe conditionsinDef. 2. In this phasewe adopttheoriginal versionof SCIFF,whereH is not declaredasabduciblebut it is a predicatedefinedby theatomsin the setHAP

py (generatedin the previous step).In thisphase,we test that in eachnon-failure leaf nodethe (11) and(12)hold.

TheWebServiceis universallyconformantto thechoreography ifandonly if suchtestsucceedsonall thenon-failureleafnodes.

5 A CONFORMANCE TEST EXAMPLE

We discusshereonly the conformancetest of the Warehouse,andshow how AlLoWS detectsnon conformance.We start the confor-mancetestby providing asGoal expectationsabouttheeventsiniti-atingtheinteraction:

G ≡ {Echor(request(Customer, Supplier, Good), Tr),Ews(query(Supplier, Warehouse, Good), Tq).}

(13)

If weapplythegenerationstepdescribedin Sect.4, weobtainthetotalagreementinteractions.Weshow oneof theoutcomesin Fig. 3.Then,by applyingthesecondstepof theconformancetest,it resultsthat this total agreementset is not ∃-conformant,sincethe expec-tationEchor(shipOrder(Supplier, Warehouse, Good), Ts) doesnothavethecorrespondinghappenedevent,asrequiredby Eq.12.Infactthechoreography specifiesthat Supplier shouldsentashipmentorderto Warehouse; unfortunately, the latter is not ableto under-standtheorder(it doesnot expectsuchmessage),andthechoreog-raphy expectationdoesnothave thecorrespondinghappenedevent.

6 DISCUSSIONAND RELATED WORK

While a detailedcomparisonof theSCIFF languagewith otherlan-guagesfor web serviceand choreography specificationis, to date,ongoingwork, we believe that the languageprovidessufficient ex-pressivity for a wide rangeof applications,and ro expresstypicalconstructsfound in otherspecificationlanguages,suchasWSCDL[17].

For example,theintegrity constraintsin Eq.(14)

19

EXPpy

HAPpy

Echor(request(C, S, Good), Tr) H(request(C, S, Good), Tr)Echor(query(S, W, Good), Tq)Ews(query(S, W, Good), Tq) H(query(S, W, Good), Tq)Echor(answer(W, S, Good, Q), Ta)Ews(answer(W, S, Good, Q), Ta) H(answer(W, S, Good, Q), Ta)Echor(provide(S, C, Q), Tp) H(provide(S, C, Q), Tp)

∧Q > 0Echor(send(S, C, Bill), Tb)Echor(shipOrder(S, W, Good), Ts) H(send(S, C, Bill), Tb)Echor(pay(C, S, Bill), Tp) H(pay(C, S, Bill), Tp)

Figure3. A total agreementinteractiongeneratedduringthefirststepoftheconformancetest.

H(a, Ta) → E(b, Tb) ∧ Tb > Ta

∨ E(c, Tc) ∧ Tc > Ta

H(b, Tb) → E(a, Ta) ∧ Ta > Tb

(14)

representa loop,wheretheeventa canbefollowedby theeventbandanotheroccurrenceof a, or by aneventc.

Theintegrity constraintin Eq.(15)

H(a, Ta) ∧ c → E(b, Tb) ∧ Tb > Ta (15)

hasan operationalsemanticssimilar to that of a workunit: whentheeventa happens,theexpectationb will be raisedonly whenthepredicatec, which representsacondition,becomestrue.

Onelimitation of our languagestandsin the currentdifficulty torepresenttheoperatorof unconditional choice in choreographies.

An interestingobservation is that theSCIFF integrity constraintscanbe interpreted,both declaratively andoperationally, asreactiverules: they specify that, if a stateof affairs (i.e., a combinationofevents)occurs,thenan individual web service,or a compositionofwebservices,shouldbehave in someway. Wefollow Bry andEckert[6] in believing that reactive rulesarea suitabledeclarative andop-erationalformalismto specifywebsystems.In particular, outof BryandEckert’sTwelveTheses,theSCIFF languagefulfills:

• thefirst (“High level reactive languagesareneededon theWeb”):theSCIFF languagesabstractsaway from thelow level transportandcommunicationprotocols;

• the second(“Reactive Web rules should be processedlocallyandactglobally throughevent-basedcommunication”):a SCIFFbasedweb serviceis only observable in its communicative acts,while thereasoningprocessthatgeneratesthoseactsremainshid-den;

• thesixth (“A data-driven,incrementalevaluationof eventqueriesis the approachof choice”): operationally, the SCIFF integrityconstraintsareresolved incrementally, while new eventsarepro-cessed.

A numberof languagesfor specifyingservicechoreographiesandtesting“apriori” and/or“run-time” conformancehavebeenproposedin theliterature.Two examplesof theselanguagesarerepresentedbystatemachines[5] andPetrinets[8].

Our work is highly inspiredby Baldoni et al. [3]. We adopt,likethem,a Multi-agentSystemspoint of view, in defininga priori con-formancein order to guaranteeinteroperability. As in [3], we givean interpretationof the a priori conformanceasa propertythat re-latestwo formal specifications:theglobalonedeterminingthecon-versationsallowedby thechoreography andthe local onerelatedto

the single web service.But, while in [3] a global interactionpro-tocol is representedas a finite stateautomation,we claim that theformalismsandtechnologiesdevelopedin theareaof ComputationalLogic in providing a declarative representationof thesocialknowl-edge,couldbeappliedalsoin thecontext of choreographieswith re-spectto theconversationaspectsandconformancecheckingof WebServices.Thispapercanbeconsideredasafirststepin thisdirection.For example,a differencebetweenour work and[3] canbefoundinthe numberof partiesas they canmanageonly 2-partychoreogra-phieswhile we do not imposeany limit. We also manageconcur-rency, which they donot considerat themoment.

Anothersimilar work is describedin [5]. In this work, authorsfo-cusontwo-partychoreographiesinvolving eachonearequesterandaprovider (namedserviceconversations)andformulatesomerequire-mentsfor a modellinglanguagesuitablefor them.Therequirementsincludegenericity, automatedsupport,andrelevance.Theauthorsar-guethatstatemachinessatisfytheserequirementsandsketchanar-chitectureof aserviceconversationcontrollercapableof monitoringmessagesexchangedbetweena requesterand provider in order todeterminewhetherthey conformto aconversation.

An exampleof useof Petri netsfor the formalizationof chore-ographiesis discussedin [8]. Four different viewpoints (interfacebehaviour, providerbehaviour, choreography, andorchestration)andrelationsbetweenviewpointsareidentifiedandformalised.Thesere-lationsareusedto perform(global) consistency checkingof multi-viewpoint servicedesignstherebyproviding a formal foundationforincrementalandcollaborativeapproachesto service-orienteddesign.Our proposalis limited to a deepanalysisof the relation betweenchoreographiesandbehaviour interfacesbut dealwith both “a pri-ori” and“run-time” conformance.

Fosteretal. [11] proposeamodel-basedapproachto verify agivenservicecompositioncansuccessfullyexecuteachoreography, in par-ticular with respectto the obligations imposedon the servicesbya choreography. The web servicespecificationsandthe choreogra-phy are translatedto FSPalgebraandchecked by modelcheckingtechniques.Themaindifferencewith respectto ourwork is thatFos-ter et al. checka wholeservicecompositionagainsta choreography,while we only checka singlewebservice,assumingthat theothersareconformant.Anothernotabledifferenceis in theadoptedformalapproaches(abductionin ourcase,modelcheckingin theirs).

In [9, 10], theauthorsapplya formalismbasedon computationallogic to thea priori conformancein theMAS field.Their formalismis similar to theonewe propose,but they restricttheir analysisto aparticulartype of protocols(namedshallow protocols). Doing this,they addressonly 2-partyinteractions,without thepossibilityof ex-pressingconditionsover thecontentof theexchangedmessages,andwithout consideringconcurrency.

The useof abductionfor verificationwasalsoexplored in otherwork. Noteworthily, Russoet al. [16] usean abductive proof pro-cedurefor analysingevent-basedrequirementsspecifications.Theirmethodusesabductionfor analysingthe correctnessof specifica-tions, while our systemis more focussedon the checkof compli-ance/conformanceof asetof webservices.

7 CONCLUSIONS AND FUTURE WORK

Startingfrom theoryandtools for protocolconformanceandcom-plianceverificationin the researchareaof multi-agentsystems,weproposea formal framework basedon computationallogic (and,inparticular, basedon abduction)that canbe usedfor specifyingbe-haviour of webservicesbothfrom aglobalandlocal viewpoint.

20

In AlLoWS,theuseof computationallogic providesusa rich andflexible formal languagefor expressingchoreographies.AbductiveIntegrity Constraints,in fact,differentlyfrom traditionalformalismssuchasfinite state-machines,allow us to specifyprotocolswithoutdescribingeachlegal stateof the interaction.ICs allow us to in-cludeextra integrity constraintsthat in semi-formalmodelsareusu-ally left implicit. Moreover, the explicit representationof time andother parameterswithin the constraintsallows to handlesynchro-nization,rolesand, in general,conditionsrelatedto the contentofmessages.For instance,we have shown thatmulti-party interactionsandconcurrency canbetackled.Within theAlLoWS framework weformalizethenotionof a priori conformancesimilar to theonepre-sentedin [3], andshow that a proof-theoreticapproachcanbe ex-ploited to performthe conformancetest.To this purposea suitableproof procedurederived from SCIFF [2] is presented,in order toautomaticallycheckconformanceatdesign-time.

In futurework, we intendto extendthesetof interactionpatternssupportedby AlLoWS. Moreover, we areawarethatexploitationofthis languageshouldbe basedon a graphicallanguage,which sup-portsuserconveniencein capturingspecifications,modelverificationandvalidation.To this purposewe aredevelopinga visual languagefor expressingglobalprotocolsandaprogramfor its automatictrans-lation into ICs.

Ongoing work on the AlLoWS framework includesa detailedcomparisonwith other languagesfor choreography specification,suchasWS-CDL, and the implementation,andperformancetests,of specificcasestudies.

Acknowledgements

This work hasbeenpartially supportedby the MIUR PRIN 2005projectsSpecification and verification of agent interaction protocolsandVincoli e preferenze come formalismo unificante per l’analisi disistemi informatici e la soluzione di problemi reali.

REFERENCES[1] Marco Alberti, FedericoChesani,Marco Gavanelli, Evelina Lamma,

Paola Mello, and Paolo Torroni, ‘The SOCS computationallogicapproachfor the specificationand verification of agent societies’,in Global Computing: IST/FET International Workshop, GC 2004Rovereto, Italy, March 9-12, 2004 Revised Selected Papers, eds.,Cor-radoPriamiandPaolaQuaglia,volume3267of Lecture Notes in Arti-ficial Intelligence , 324–339,Springer-Verlag,(2005).

[2] Marco Alberti, Marco Gavanelli, Evelina Lamma,Paola Mello, andPaolo Torroni, ‘The sciff abductive proof-procedure’,in Proceedingsof the 9th National Congress on Artificial Intelligence, AI*IA 2005 ,volume3673of Lecture Notes in Artificial Intelligence , pp. 135–147.Springer-Verlag,(2005).

[3] MatteoBaldoni,CristinaBaroglio,Alberto Martelli, VivianaPatti, andClaudio Schifanella, ‘Verifying the conformanceof web servicestoglobalinteractionprotocols:A firststep’,in EPEW/WS-FM, eds.,MarioBravetti, Leıla Kloul, andGianluigiZavattaro,volume3670of LectureNotes in Computer Science. Springer, (2005).

[4] A. Barros,M. Dumas,andP. Oaks,‘A critical overview of thewebser-viceschoreography descriptionlanguage(ws-cdl)’, BPTrends, (2005).

[5] B. Benattallah,F. Casati,F. Toumani,and R. Hamadi, ‘Conceptualmodelingof webserviceconversations’,2681, 449–467,(2003).

[6] FranoisBry andMichael Eckert, ‘Twelve theseson reactive rulesforthe web’, in Proceedings of the Workshop on Reactivity on the Web,Munich,Germany, (March2006).

[7] M. Denecker andD. De Schreye, ‘SLDNFA: an abductive procedurefor abductive logic programs’,Journal of Logic Programming, 34(2),111–167,(1998).

[8] R. Dijkman and M. Dumas, ‘Service-orienteddesign: A multi-viewpointapproach’,International Journal of Cooperative InformationSystems, 13(4), 337–378,(2004).

[9] U. Endriss,N. Maudet,F. Sadri,andF. Toni, ‘Protocol conformancefor logic-basedagents’,in Proceedings of the Eighteenth InternationalJoint Conference on Artificial Intelligence, Acapulco, Mexico (IJCAI-03), eds.,G. GottlobandT. Walsh.MorganKaufmannPublishers,(Au-gust2003).

[10] Ulle Endriss, Nicolas Maudet, Fariba Sadri, and FrancescaToni,‘Logic-basedagentcommunicationprotocols’, in Advances in AgentCommunication, ed., F. Dignum, volume 2922 of LNAI, 91–107,Springer-Verlag,(2004).

[11] Howard Foster, SebastianUchitel, Jeff Magee, and Jeff Kramer,‘Model-basedanalysisof obligationsin webservicechoreography’, inProceedings of the International Conference on Internet and Web Ap-plications and Services (ICIW 2006), GuadeloupeFrenchCaribbean,(2006).IEEEComputerSocietyPress.

[12] T. H. FungandR. A. Kowalski, ‘The IFF proofprocedurefor abductivelogic programming’,Journal of Logic Programming, 33(2), 151–165,(November1997).

[13] J. Jaffar and M.J. Maher, ‘Constraint logic programming:a survey’,Journal of Logic Programming, 19-20, 503–582,(1994).

[14] A. C. Kakas,R. A. Kowalski, andF. Toni, ‘Abductive Logic Program-ming’, Journal of Logic and Computation, 2(6), 719–770,(1993).

[15] A. C. KakasandP. Mancarella,‘On therelationbetweenTruth Main-tenanceand Abduction’, in Proceedings of the 1st Pacific Rim In-ternational Conference on Artificial Intelligence, PRICAI-90, Nagoya,Japan, ed.,T. Fukumura,pp.438–443.OhmshaLtd., (1990).

[16] A. Russo,R. Miller, B. Nuseibeh,and J. Kramer, ‘An abductive ap-proachfor analysingevent-basedrequirementsspecifications’,in LogicProgramming, 18th International Conference, ICLP 2002, ed., P.J.Stuckey, volume2401of Lecture Notes in Computer Science, pp. 22–37,Berlin Heidelberg, (2002).Springer-Verlag.

[17] W3C. Web serviceschoreography descriptionlanguageversion1.0.HomePage:http://www.w3.org/TR/ws-cdl-10/.

21

An Immune System-Inspired Approach for Composite Web Services Reuse

Rosanna Bova 1, Salima Hassas 1, Salima Benbernou 1

Abstract. Recently, a growing number of Web Services have emerged at a fast rate. However, there are many situations where individual web services, alone, cannot satisfy user requirements. This has raised the need for service providers and application developers to develop value added services by combining existing web services into composite web services.

Web services composition is now a very active research field, and several solutions have been proposed. However, few existing solutions address the issue of service composition reuse and spe-cialization, i.e, how applications can be built upon existing simple or composite web services by reuse, restriction, or extension.

In this paper, we introduce the concept of abstract composite web service, that can be specialized to particular concrete composi-tions, and that can be reused in the construction of larger or ex-tended compositions. We propose an approach based on immune system, in which we combine structural and usage information in order to promote and create stable composite web services, in an affinity maturation process. 1

1 INTRODUCTION

A web service is a software system designed to support interoper-

able machine-to-machine interaction over a network, based on

standard web protocols and XML encoding.

There has been a great deal of research in the area of web ser-

vices in the past few years. A large part of these studies has been

dedicated to web services composition. The original idea of �ser-

vice composition� is not really new in software design. It can be

traced back to the simple concept of an executable library in many

programming languages, the so-called �code reuse.� Applying this

idea to software engineering, people have developed new applica-

tions using previously written software components, leading to

�software composition� or �software reuse.� In the web services

community the efforts are now mainly dedicated to some parts of

this problem, which, generally speaking, are the discovery of use-

ful �partner� web services, their composition and execution.

In this paper, we are interested in studying how web services

can be composed to provide more complex features, by reusing

abstract web service composites that can be specialized to particu-

lar concrete composites, or reused in the construction of larger or

extended composites. The former type of reuse can be viewed as a

descendent approach, while the latter is rather an ascendant ap-

proach, where small composites are used in larger composites.

This paper aims at defining a composition framework, and a

composer system, to achieve these goals semi-automatically. Sec-

tion 2 gives our problem formulation, illustrated by an example

scenario in section 3. Section 4 presents and discusses our ap-

proach and the processes involved, along with the immune system

metaphor. Section 5 situates it with related works, and section 6

concludes and presents the main perspectives of this work.

1 LIRIS, UMR 5205 CNRS, Université Claude Bernard Lyon 1, bâtiment Nautibus (710), 43 bd du 11 novembre 1918, 69622 Villeurbanne, France; e-mail:{rosanna.bova, salima.hassas, salima.benbernou}@liris.cnrs.fr

2 PROBLEM FORMULATION

Our goal is to define a web service composer system and frame-

work. This web service composer system will both be able to pro-

vide (reuse) and execute a composite web service requested by a

user or another system. As such, we assume that the composer

system is able to obtain success feedback about the execution of

each concrete composite web service. If the composite service is to

be executed by an external system, then a feedback mechanism is

needed to provide this feedback loop.

We consider that a composite service is a web service involving

the calling of other web services (composite or elementary) during

its execution. These referenced web services are typically struc-

tured in a sort of script or program using alternatives (conditions),

loops, parallel and sequence operators. For example, a BPEL script

defines such a composite web service. From the outside, a compos-

ite web service is like a normal executable web service, published

and accessed using the same protocols.

In the context of our approach, however, we see a composite

web service as a grey box, rather than a black box, in the sense that

part of its internal structure is accessible to our system.

To be able to reason about the similarity or compatibility of

functionalities across several web services, we assume that there

exists a higher level ontology and description language to describe

these functionalities, which goes beyond the mere interface (opera-

tions, inputs, outputs) of the web service. Defining such ontology is

in itself a difficult problem, but is out of scope of this paper.

We also suppose that this ontology is associated with a reposi-

tory or matching engine, taking in charge the matching of a selec-

tion of web services (composite or not) compatible with a given

semantic description. Thus, as a simplification, we will consider

that a user request for a web service is a web service semantic

description (without considering possible additional constraints or

user preferences). Our work is rather focused on how composite

web services are specialized or reused, than on the matching proc-

ess with a given semantic description.

We will also assume that our system does not create new com-

positions from scratch, but that compositions already exist, created

externally by software designers or architects. Our goal is then to

reuse these existing composite web services, and possibly adapt

them, by substituting some web services that they reference by

other compatible ones.

In order to do that, we introduce the concept of abstract com-

posite web service, based on Melloul and Fox�s web service high

level patterns, in [1]. In an abstract composite, some concrete web

services are replaced by web service semantic descriptions, i.e.

high level descriptions of the functionalities fulfilled by this web

service, using the above mentioned service ontology. The structure

of the initial composite service is conserved. Only one web service

may be described by an abstract description (in other words, se-

mantic descriptions may not span over several web services �slots�

in their hosting abstract web service).

22

The motivations behind this concept are two fold:

x First, it allows us to reuse composites by generalization and

specialization, by adapting composite services to other contexts,

and relieving some context specific constraints;

x Second, abstract composites will serve us as a link between

structural information and usage information.

Figure 1. Abstract and concrete composite web service example

Figure 1 shows an abstract composite web service; without detail-

ing structural information, constructed by substituting two web

services in a concrete specialization, WS2 and WS3, by two ab-

stract descriptions D2 and D3.

However, care must be taken when defining such abstract com-

positions, as stated by Melloul and Fow in [1]: a too abstract com-

posite may be unusable and useless, as it would contain too little

concrete information, and would be very difficult to specialize to a

given context. On the contrary, a very specific abstract composite

is difficult to reuse in different situations, obviously. There is a

compromise between the two, allowing a sufficient but useful

reuse, as in any component reusing problematic.

Another hypothesis in our work is that concrete composites con-

tain only fixed (resolved at composition time) web service refer-

ences: they may not for example include in their execution the

process of searching web services, and calling them afterward.

Finally, our problem is to find the proper and most usable com-

posite web service, that we will define as �stable� composite web

services, with respect to a given user request, and evaluation crite-

ria such as validity, pertinence, availability, and robustness, by

utilizing the information about the structure and usage of compos-

ite web services and their components. The composite web service

proposed by the composer system will either be existing concrete

composites, or automatic specializations of abstract composites.

3 TRAVEL AGENCY EXAMPLE

We use the classical travel agency example, since it involves sev-

eral kinds of web services and composite tasks using these web

services, in an overall service: planning a journey. Let us define the

following web services available, grouped by semantic categories:

x Travel ticket booking: plane1 (cover flight from and to Lon-

don), plane2 (cover flights from and to Paris), plane3 (covers

flight from and to Milan and Trento), and eurostar;

x Hotel booking: paradise hotel (in London and Paris), coconut

hotel (in Milan and Trento);

x Car rental: car1 (Milan, Trento), car2 (all cited cities);

We assume that we already have a concrete composite web service

named TravelToLondonFromParis, as shown in figure 2, which

consists in requesting a reservation web service for the eurostar

train from Paris to London, followed by the parallel booking of a

ParadiseHotel chain in London, and the renting of a car with car2.

The main rounded box represents the composite with its global

inputs (period) and outputs (train ticket, hotel booking and car

rental). Now let us suppose that there exists an abstract composite

web service named TravelToLondon, generalization of our previ-

ous concrete composite service, where the eurostar service is

replaced by the semantic description TravelTicket, with an input

parameter, destination, fixed to the value London (see figure 3),

and the paradise hotel by the semantic description HotelBooking.

We introduce another abstract composite, named DirectTravel,

which is an abstraction of TravelToLondon and also transitively an

abstraction of TravelToLondonFromParis, is presented on figure 4.

Here all involved web services are replaced by the abstract seman-

tic descriptions TravelTicket, HotelBooking and CarRental, with

the global inputs origin, destination, period, and the same outputs

as the two previous composite web services.

Figure 2. UML activity diagram of TravelToLondonFromParis

Figure 3. UML activity diagram of TravelToLondon

Figure 4. UML activity diagram of DirectTravel

Figure 5. UML activity diagram of IndirectTravel

Finally, we consider that there exists a last abstract composite web

service named IndirectTravel, which includes a reference to the

former abstract composite DirectTravel, as shown on figure 5. A

hotel booking may be necessary if the travel spans one night in the

intermediate city, represented by the alternative. The � sign on

DirectTravel indicates that it refers to another abstract composite

definition.

Hotel-

Booking

Direct-

Travel

origin

Inputs Outputs

train ticket

hotel book.

car rental

period

dest.

Travel-

Ticket �

eurostar

paradise

hotel

car2

period

Inputs Outputs

train ticket

hotel book.

car rental Paris -

London

Hotel-

Booking

Car-

Rental

origin

Inputs Outputs

train ticket

hotel book.

car rental

period

dest.

Travel-

Ticket

Travel-

Ticket

car2

period

Inputs Outputs

train ticket

hotel book.

car rental origin

to London

Hotel-

Booking

WS1

WS2 WS4

WS3 WS1

D2 WS4

D3

Concrete composite web service Abstract composite web service

generalization

23

4 IMMUNE SYSTEM INSPIRED APPROACH

4.1 A simplified view of immune systems

Figure 6. Pattern recognition of an antigen by B-cells

One of the roles of an immune system [2] is to protect our body

from attacks of invasive foreign substances. Such a foreign sub-

stance is called a pathogen, and is recognized by the immune sys-

tem as an antigen. The mechanisms used by the immune system for

this purpose are:

x The Pattern Recognition of foreign antigen in the immune

system, that is carried out by receptors on the surface of anti-

bodies released from the immune cells (lymphocytes: B-cells

and T-cells). The binding of an antigen to the different antibod-

ies requires that portions of the two structures have complemen-

tary shapes that can closely approach each other. The area on an

antigen where it has contact with an antibody is called an epi-

tope. The corresponding area on an antibody is called a para-

tope. The strength of the binding between an antigen and the

different antibodies is dependent on the affinity between them.

The higher the affinity, the stronger the binding.

x The Immune Response, constituted by two kinds of response. A

primary response is provoked when the immune system en-

counters an antigen for the first time. A number of antibodies

will be produced by the immune system in response to the in-

fection, which will help to eliminate the antigen from the body.

However, after a period of days the level of antibody begins to

degrade, until the time when the antigen is encountered again.

The secondary immune response is said to be specific to the an-

tigen that first initiated the immune response, and involves the

process of affinity maturation (see below).

x The Clonal Selection. When antibodies of a B-cell bind with an

antigen, the B-cell becomes activated and begins to proliferate.

New B-cell clones are produced that are an exact copy of the

parent B-cell, but then undergo somatic hypermutation and pro-

duce antibodies that are specific to the invading antigen.

x The Affinity Maturation process that guarantees that the im-

mune system becomes increasingly better at the task of recog-

nising patterns. After the primary immune response, when the

immune system first encounters a foreign substance and the

substance has been removed, a certain quantity of B-cells re-

mains and acts as an immunological memory. This is to allow

the immune system to launch a faster and stronger attack

against the infecting agent, called the secondary immune re-

sponse. This second, faster response is attributed to memory

cells remaining in the immune system, so that when the antigen,

or similar antigen, is encountered, a new immunity does not

need to be built up, it is already there. This means that the body

is ready to better combat any re-infection.

4.2 Immune system metaphor for our web service composition reuse problem

Although immune systems have greatly inspired our approach, our

ambition is not to define an exact correspondence between the

concepts, processes and mechanisms of our model, and those of the

immune system. We try to use this metaphor as much as possible,

especially when it helps understanding the rational of the model,

however some specificities of our problem and solution still don�t

have a counterpart in immune systems, and vice versa.

In our model, different composite web services are proposed to

the user in order to answer to a composition request, which repre-

sent the antigen aggression.

In an immune system, when neutralizing antigens, the immune

cells specialize in attacks of this or similar antigens, and become

memory cells through a process of affinity maturation. Thus mem-

ory cells are specialized cells for one category of antigens.

We imagine, in the same manner that an existing selection of

concrete composite web services exists, specialized to answer to a

category of request. However, as detailed in section 4.5.2, the sole

semantic compatibility with the request, managed by the semantic

matching mechanism, is not enough to ensure that a given concrete

composite will be successful and stable. We claim that there need

to be some sort of affinity value, derived from usage feedback

information.

In the immune system, the process of affinity maturation [3]

strongly depends on the processes of specialization and clonal

selection of the immune cells, which are based on the affinity value

between immune cells and antigens. The higher the affinity value

is, the more adequate the immune cells answer is. The affinity

value is based on the degree of complementarity between immune

cells and antigens.

In our model, we define some usage information representing

how and how many times web services or concrete composites are

used with respect to a given context, represented in turn by a chain

of ancestor abstract composites. Then, we define the process of

maturation as a process of electing composite web services as

stable composite web services.

Table 1. Correspondence with immune system

Immune System WS Composer System

Antigen User request

Pattern recognition Semantic matching with existing WS

+ user choice

Affinity Semantic compatibility +

Relative and global affinity values

Affinity maturation Stable composite WS election

Memory cells Stable composite WS

B cells Concrete or virtual composite WS

Table 1 summarizes these correspondences. Some of the terms

used here are detailed in section 4.5 .

4.3 Model and motivations

For achieving our goal, our idea is that structural information

should be combined with usage information extracted from the

composite web services, in order to promote and possibly publish

24

stable and relevant composite web services. Stable composite web

services will represent potential building blocks reusable in new

compositions corresponding to a category of requests, in the same

manner that the memory cells in an immune system react to a

certain category of antigens.

In particular, the structural information comprises: the compos-

ite definition itself, i.e. the structural constructs linking the refer-

enced internal web services together (that we will refer to as the

children of this composite), organizing them in a well defined

process; plus the generalization relations between composites. The

exact structural information available depends on the workflow or

process description language used to describe composite web

services, however we can always extract the composition depend-

encies between a composite and its children.

The usage information is represented by a metric in our model:

the relative affinity value, associated to a relation between each

child component of a composite web service and its various ab-

stractions. In the example of section 3, we have a relative affinity

relation between: eurostar and TravelToLondon, eurostar and

DirectTravel; ParadiseHotel and TravelToLondon, ParadiseHotel

and DirectTravel; car2 and DirectTravel.

We assume that we have a local repository that contains infor-

mation for a set of existing composite or simple web services.

Formally a web services, composite or simple, is defined as

ws = {I, O}, where I is its set of inputs, O its set of outputs.

Along with this information stored for each composite or simple

web service, we add in the repository some meta-information about

the structure � the generalization relationships and the composition

dependency relationships � and about the usage � the relative

affinity (valued) relationships.

Figure 7. Composite Web Services meta-information model

Figure 7 shows a UML class diagram describing our model. For

clarity reasons the relative affinity relation is not represented. Also,

in theory abstract composites may also contain (use) other abstracts

composites (not visible here). It includes notably:

x Concrete web service, which is both a composite and a real web

service. It uses web services, its children, that may in turn be

other concrete composites or elementary web services as well;

x Abstract composite, which is a composite but also contains

semantic descriptions.

The important relations (UML associations) are:

x The composition dependency relation, here the uses association;

x The generalization relation, represented by both the instantiates

and generalization directed associations.

4.4 Application to the Travel Agency example

Figure 8. Travel agency example: usage and structure meta information

Figure 8 represents in a same diagram the composition dependency

relations, the generalization relations, and the relative affinity

valued relations. For sake of clarity, only the first level of relative

affinity relations are shown on here; however these relations are by

construction repeated from any abstract composite to its direct

ancestor, following the generalization link, plus other ones. Thus,

very abstract composites like DirectTravel will have a lot of poten-

tial children with which they have a relative affinity.

It is important to note on this diagram that relations of different

nature are represented, which should not be confused: generaliza-

tion links, which in the opposite direction represent specialization

(or instantiation when leading to a concrete composite), are not of

the same nature as composition dependency links. Composition

dependency means that a given composite uses another composite

or simple web service: this is neither an instantiation nor a speciali-

zation. Relative affinity links can be seen as a potential composi-

tion in a specialized form of the abstract composite, augmented

with an affinity value.

With respect to section 3, we have added two new composites,

which will serve us later on, TravelToLondonFromFrance and

TravelToLondonFromGermany.

4.5 Process

Figure 9 represents our system as a global process. In practice,

however, some parts of this process are distributed among several

agents, the cells of our immune system. The distributed part in-

cludes the automatic specialization, the relative affinity update, and

the affinity maturation steps.

As stated in section 2, we consider that a user request is equiva-

lent to a semantic description, and that there exist a matching

mechanism selecting compatible candidates among the composites

and simple web services indexed in our repository.

DirectTravel

TravelToLondon

TravelToLondon-

FromParis

IndirectTravel

TravelToLondon-

FromGermany

TravelToLondon

-FromFrance

Coconut

Hotel

Airplane2

Eurostar

Car2

Airplane3

Paradise

Hotel

Composition dependency

Usage (relative affinity)

Generalization

Relations :

Composite Web Service

Elementary

Web Service

Concrete

Composite

Abstract

Composite

Semantic

description

0..*0..*

1

1 described by

needs

matchesmatches

described by

uses

instantiates

generali-

zation

25

After that, the composer system performs automatic specialization,

which consists of specializing compatible (candidate) abstract

composites, using relative affinity as guidance, into potential new

concrete composites. This task does not create composites from

scratch, but explores new instantiation possibilities.

Figure 9. Global process from user request to composite execution

Then, the system reorders all composition propositions, including

other candidate concrete composites obtained in the semantic

matching step, using a global affinity value for each composite,

and presents them to the user. The latter chooses one proposition:

this choice in itself brings some exploration in the system, since a

user is not forced to pick up the best composites. Then, the com-

posite is executed by the system, and the relative affinity values are

updated. The affinity maturation will possibly elect the new con-

crete composites, if used, as stable (i.e. memory cell), and associate

it with a semantic description, so that it becomes selectable by the

semantic matching engine. It is then usable in subsequent auto-

matic specializations.

4.5.1 Relative affinity

Definition 1 Relative affinity. A value of relative affinity is

always associated to a relation between a concrete web service

(composite or not), in execution, and the abstract composite of the

composite that calls it. This value is updated every time that this

concrete web service is executed as a child of one of this abstract�s

specialization. The relative affinity function is equal to:

usage

succr

freq

freqacaff ),( (1)

where freqsucc is the function measuring the number of times that

this concrete web service (c) has been used with success and

frequsage is the total number of time that this concrete web service

has been used.

Figure 10 illustrates the updating mechanism of the relative affinity

values between concrete web services (WS1, WS2, WS3, WS4 and

Y) and the generalization of the parent composite that calls them.

The execution of composite X includes the ordered execution of

WS1, WS2 and the composite Y. Once the concrete WS1 has been

executed, the relative affinity relation between AX (the abstract

composite of X) and WS1 is updated, or generated if it did not exist,

with an associated relative affinity value equal to the fraction be-

tween the number of successes and the total number of utilizations

of WS1 as a child of any specialization of AX. The same happens

between the abstract composite AX and the concrete WS2.

Figure 10. Relative affinity update example

Since execution of the composite Y includes the execution of WS3

and WS4, a relation between AY and the two concrete web services

WS3 and WS4 are generated or their relative affinity value updated.

Then, when the execution of the composite Y terminates, a relation

between the abstract composite AX and the composite Y is gener-

ated with a numeric value of relative affinity.

4.5.2 Affinity maturation

During the automatic specialization step, new virtual concrete

composite may be created by specializing abstract composites

compatible with a user request, with different children than those

present in existing concrete composites. As long as such a virtual

composite is not considered stable by the system, it does not has a

proper existence outside the current user session, and is not identi-

fied nor associated to a semantic description in the web service

repository of the composer system.

The only trace of its existence is represented by the global affin-

ity value calculated by the system, also used to order the proposi-

tions before presenting them to the user. This global affinity value

only depends on the relative affinity values of the various children,

and possibly grandchildren, etc., involved in the virtual composite.

Definition 2 Global Affinity. The global affinity value repre-

sents a weighted average of the various relative affinity values,

with respect to the whole ancestor chain of the concrete composite.

Its value is given by the following function:

n

acaff

Caff

n

i

m

j

j

iirij

g

¦ ¦

1 1

),(

)(

D

(2)

where C is the considered concrete composite, viewed here as a set

of n children concrete web services (c1� ci � cn); m represents the

number of ancestor abstract composites of C; aij are the semantic

descriptions of the children concrete web services to instantiate on

the jst ancestor, and corresponding to the concrete child ci; �

ij are

weight values, so that the sum of these weight values referring to

the same concrete child web service is equal to one; and affr(ci, aij)

is the relative affinity of ci with respect to aij.

X

AX

WS1

WS2 Y

AY

WS3

WS4

semantic

matching

User Web Service Composer System

request (semantic

description)

ordering and

presentation

automatic

specialization

choose a

concrete CWS

execute CWS

update relative

affinity values get results�

affinity

maturation

26

Definition 3 Virtual composite. A virtual composite is a com-

posite created by the composer system as a result of the automatic

specialization step, in response to a user request. This composite is

temporary to the session, and does not have an actual existence in

the composer system web service repository.

Definition 4 Stable composite. A stable composite is a former

virtual composite which has been used successfully at least one

time with a global affinity value exceeding a predefined threshold

(parameter of the composer system), that we refer to as the affinity

maturation threshold.

Figure 11. Example of global affinity value calculation

In the example of figure 11, the global affinity value is:

affg (C) = (�

11affr(c1, a11) + �

12affr(c1, a12) + �

21affr(c2, a21) +

�

22affr(c2, a22) + �

31affr(c3, a31) + �

32affr(c3, a32)) / n

where �

12 = �

21+�

22= �

31+�

32 = 1.

Once a concrete composite is considered stable, it is stored and

indexed in the web service repository, and associated to a semantic

description. As a real concrete composite, it can be matched di-

rectly to user requests without needing the specialization step, and

also becomes eligible as a child concrete web service, inside other

composite web services.

This stable composite election process is inspired by the im-

mune system�s affinity maturation process. Affinity is stimulated

by cross-usage, and different existing composites may contribute to

the maturation of the same new stable concrete composite.

One of its goals is to ensure some sort of long term memory to

the system, since stable composites may be kept for an arbitrary

long time in the system, even if their global affinity value falls

below the affinity maturation threshold for some period.

4.5.3 Example

To illustrate specialization and affinity maturation, let us suppose

that a user wishes to travel in London from France, in the context

of the scenario presented in section 3, and augmented in section

4.4, figure 8.

We assume that the user request is compatible with TravelTo-

LondonFromFrance. However, we also assume that TravelTo-

LondonFromParis and TravelToLondonFromGermany have been

used largely with success, so that the relative affinity of Paradise-

Hotel with respect to the abstract composite TravelToLondon is

higher than that of CoconutHotel. Although the context is slightly

different, ParadiseHotel is still applicable to the semantic descrip-

tion HotelBooking included in TravelToLondon. Thus, the com-

poser system will propose a virtual composite with ParadiseHotel

instead of CoconutHotel to the user, with a higher rank.

Now, let us suppose that the user chooses this virtual composite

web service, and that the execution is successful. If the global

affinity is greater than the affinity maturation threshold, a new

stable concrete composite is created and referenced in the reposi-

tory, and can now be used directly.

4.6 Exploration / exploitation ratio

Apart from the obvious exploration due to the fact that the user

chooses among different composite propositions from the system,

there is another interesting form of exploration in this process,

related to the automatic specialization step.

During this phase, the composer system tries to instantiate new

concrete composite from existing abstract ones, by substituting

some children web services. This exploration is guided by two

factors: (i) the existence of abstract composites and (ii) the relative

affinity values of potential children web services, with respect to

these abstract composites. Abstract composites are supposed to be

designed by system administrators or programmers, and influences

the way the system will reacts.

However the creation and enforcement of new composites, for a

given user request, is also highly influenced by the cross-usage of

various composites related to these abstract composites, and in-

volving other potential children web services in different contexts.

This influence is not limited to the specific usage of the concrete

candidate composites directly compatible with the user request.

As a consequence, the ratio between exploration and (usage)

exploitation is mainly determined by the density and structure of

the generalization and composition graphs formed by abstract

composites, by the initial distribution of the concrete composites

and the elementary web services in the system, and above all by the

variability of the requests and choices of users.

4.7 Discussion

The semantic level and matching mechanism are not covered in

this paper. However the language and ontology used for the seman-

tic descriptions is indeed very important for our approach to work

properly: the language used should allow designers to define ab-

stract descriptions, for abstract composites, that remain compatible

with more specific descriptions. Additionally, it should allow our

system to specialize an abstract description, when an automatic

specialization occurs. This specialized description will probably

add some constraints related to the parameters fixed in the concrete

composite, and also related to the newly associated children web

services.

Another issue is the relative importance of the children of a

given composite. We currently consider them evenly, with the

same weight, in the calculation of the global affinity value. Assum-

ing that if any of them fails, the whole composite fails (note that it

is not always the case, especially if the composite includes some

form of redundancy to increase its robustness), one might consider

that the weakest affinity score should be considered. Alternatively,

a more complex affinity value calculation, partly based on the

workflow structure of the composite, could be investigated.

c1 c2 c3

c1 1

2a 1

3a

2

2a 2

3a 2

1a relative affinity

generalization

semantic descr.

C

A1

A2

27

The affinity functions used in our approach does not define any

absolute confidence value associated to each web service or com-

posite web service, independently of any context. Even the global

affinity function is always relative to a context, represented by the

chain of ancestor abstract composites and the user request. This

design choice might be considered somehow restrictive, and one

may consider that the relative affinity values should be combined

with an absolute confidence value for each web service, so that

usage feedback may be shared more widely across usage contexts.

Our motivation is that the success of a web service is often very

context sensitive: a single parameter change can condition the

success or failure of a request.

5 RELATED WORKS

This approach is inspired by the work by Melloul and Fox in [1]. In

particular, the abstract composite concept in our model is close to

their high level composition patterns. Our contribution mainly adds

the automatic specialization process, the affinity relations, and the

affinity maturation process.

Although we do not use class inheritance explicitly, our gener-

alization/specialization relations suggest an object-oriented inheri-

tance model. In this direction different works can be found in the

area of workflow class inheritance. For example, in [4] Bussler

presents a framework to analyze the requirements for supporting

such workflow class inheritance. Different perspectives of inheri-

tance are discussed and a workflow class definition language is

proposed. In [5], Kappel and Lang present a workflow class speci-

fication, consisting in a set of object classes and rules. Subclasses

and inheritance are supported, at least partially.

In [6], Papazoglou and Yang describe a system called TOWE

that implements a set of classes providing the basic mechanisms

for workflow execution. Other workflow classes can then be de-

veloped by inheriting the functionality of basic workflow classes.

Our generalization relation, however, is defined by the substitu-

tion, in the composite definition, of one or more children concrete

web services by semantic descriptions. This relation is derived

from the composites structure: it is not a purely additional, higher

level classification of existing web service, which would rather

correspond to the semantic description level in our case.

Our approach differs from other related works about web ser-

vices composition in that it focuses on reusing existing abstract

composites that can be specialized into particular concrete compos-

ites, or reused in the construction of larger or extended composites.

Finally, we distinguish our work from automatic Web service

composition such as in the work by McIlraith et al. [7] on semantic

web service composition, and the work by Petrie et al. [8] on web

service planning, where the goal is to produce a composition plan.

Rather, we start with existing (high-level) plans, and focus on their

different possible reuse, by exploiting the combination of cross-

usage, the affinity relations, and structural meta-information, the

composition and generalization relations.

6 CONCLUSION AND FUTURE WORKS

In this paper we have proposed an approach to deal with composite

web service reuse and automatic specialization by children compo-

nent substitution, inspired by the human body immune system. The

shape correspondence between the antigen epitopes and the anti-

body paratopes is represented in our system by a relative affinity

function, measuring the degree of success of the use of a concrete

child web service, within the context of a concrete composite, with

respect to a more general abstract composite web service.

The associated affinity maturation process allows the emergence

of new stable concrete composites, resulting from automatic spe-

cializations and the accumulated cross-usage information. These

stable concrete composites are then identified and semantically

described, as any existing web service in our system.

This process, as well as the relative affinity calculation, is of

course guided by the definition of meaningful abstract composites,

which gives to the composer system administrators a degree of

control on the affinity propagation and on the potential automatic

specializations proposed by the system.

We are currently defining a prototype in order to validate the

feasibility of this approach on simple scenarios (work in progress).

A perspective is to extend the model to better account for the inter-

nal structure of web service composite in the relative affinity func-

tion (for example, differentiate redundant and mandatory children).

A second perspective is to consider the specificity of the request

in our global affinity evaluation: if a request is very specific, it is

reasonable to think that the relative affinity values related to the

most specific abstract composites are more important than the

relative affinity values related to the most abstract ones. On the

contrary, a very vague request will not care too much about the

former ones, but more about the latter.

A long term perspective is to leverage the distributed nature of

the immune system model, and its natural tolerance to heterogene-

ity. Instead of having one global composer system, this approach

can scale to a network of interconnected web service composition

domains managed by local composer systems. Such composer

systems may publish stable or abstract composites to each other,

with respect to some diffusion policy. This diffusion would corre-

spond to the spreading and cloning of memory cells into our blood.

REFERENCES

[1] L. Melloul and A. Fox �Reusable Functional Composition Patterns for

Web Services�, in proceedings of the IEEE International Conference

on Web Services (ICWS), San Diego, CA, USA, 498-506 (2004).

[2] L. N. de Castro and F. J. Von Zuben, �Artificial Immune Systems:

Part I, Basic Theory and Applications�, RT DCA Technical Report 1-

98. (1999).

[3] Berek, C. and M. Ziegner, �The Maturation of the Immune Response�,

Immunology Today, 14 (8), 400-402, (1993).

[4] C. Bussler, Workflow class inheritance and dynamic workflow class

binding, In Proceedings of the Workshop of Software Architectures for

Business Process Management at the 11th Conference on Advanced

Information System engineering, Heidelberg, Germany, 1999.

[5] G. Kappel, P. Lang, S. Rausch-Schott, and W. Retschitzegger, �Work-

flow Management Based on Objects, Rules and Roles�, IEEE Data

Engineering Bulletin, 18(1), 11 � 18, (1995).

[6] M. P. Papazoglou and J.Yang, �Design Methodology for Web Ser-

vices and Business Processes�, in Proceedings of the 3rd VLDB-TES

Workshop, Hong Kong, 2002. Also in LNCS, 2444, Springer, (2002).

[7] S. A. McIlraith, T. C. Son, and H. Zeng, �Semantic Web Services�,

IEEE Intelligent Systems, Special Issue on the Semantic Web, 16 (2),

46-53, (2001).

[8] C. Petrie, M. Genesereth, H. Bjornsson, R. Chirkova, M. Ekstrom, H.

Gomi, T. Hinrichs, R. Hoskins, M. Kassoff, D. Kato, K. Kawazoe, J.

U. Min, and W. Mohsin, �Adding AI to Web Services�, Agent

Mediated Knowledge Management, LNAI, 2926, Springer, 322- 338,

(2004).

28

DesigningSecurity RequirementsModelsthr oughPlanning

Volha Bryl and Fabio Massacci and John Mylopoulos and Nicola Zannone1

Abstract. The quest for designing secure and trusted software hasled to refined Software Engineering methodologies that rely on toolsto support the design process. Automated reasoning mechanisms forrequirements and software verification are by now a well-acceptedpart of the design process, and model driven architectures support theautomation of the refinement process. We claim that we can furtherpush the envelope towards the automatic exploration and selectionamong design alternatives and show that this is concretely possiblefor Secure Tropos, a requirements engineering methodology that ad-dresses security and trust concerns. In Secure Tropos, a design con-sists of a network of actors (agents, positions or roles) with delega-tion/permission dependencies among them. Accordingly, the gener-ation of design alternatives can be accomplished by a planner whichis given as input a set of actors and goals and generates alternativemulti-agent plans to fulfill all given goals. We validate our claim witha case study using a state-of-the-art planner.

1 Intr oduction

The design of secure and trusted software that meets stakeholderneeds is an increasingly hot issue in Software Engineering (SE).This quest has led to refined Requirements Engineering (RE) andSE methodologies so that security concerns can be addressed dur-ing the early stages of software development (e.g. Secure Troposvs i*/Tropos, UMLsec vs UML, etc.). Moreover, industrial softwareproduction processes have been tightened to reduce the number ofexisting bugs in operational software systems through code walk-throughs, security reviews etc. Further, the complexity of presentsoftware is such that all methodologies come with tools for automa-tion support.

The tricky question in such a setting is what kind of automation?Almost fifty years ago the idea of actually deriving code directlyfrom the specification (such as that advocated in [22]) started a largeprogramme for deductive program synthesis,2 that is still active now[5, 11, 25, 29]. However, proposed solutions are largely domain-specific, require considerable expertise on the part of their users, andin some cases do not actually guarantee that the synthesized programwill meet all requirements stated up front [11].

Another approach is to facilitate the work of the designer by sup-porting tedious aspects of software development by automating thedesign refinement process. This approach underlies Model DrivenArchitectures (MDA) [27], which focuses on the (possibly auto-

1 University of Trento, Italy, email: {bryl,massacci,jm,zannone}@dit.unitn.it2 A system goal together with a set of axioms are specified in a formal spec-

ification language. Then the system goal is proved from the axioms usinga theorem prover. A program for achieving the goal is extracted from theproof of the theorem.

matic) transformation from one system model to another. Tools sup-porting MDA exist and are used in the Rational Unified Process forsoftware development in UML. Yet, the state-of-the-art is still notsatisfactory [30].

Such approaches only cover part of the work of the designer. Weadvocate that there is another activity where the support of automa-tion could be most beneficial [20]:

“Exploring alternative options is at the heart of the require-ments and design processes.”

Indeed, in most SE methodologies the designer has tools to reportand verify the final choices (be it goal models in KAOS, UMLclasses, or Java code), but not actually the possibility of automati-cally exploring design alternatives (i.e. the potentialchoicesthat thedesigner may adopt for the fulfillment of system actors’ objectives)and finding a satisfactory one. Conceptually, this automatic selec-tion of alternatives is done in deductive program synthesis: theoremprovers select appropriate axioms to establish the system goal. In-stead, we claim that the automatic selection of alternatives shouldand indeed can be done during the very early stages of software de-velopment. After all, the automatic generation of alternatives is mostbeneficial and effective during these stages.

There are good reasons for this claim. Firstly, during early stagesthe design space is large, and a good choice can have significant im-pact on the whole development project. Supporting the selection ofalternatives could lead to a more thorough analysis of better qual-ity designs with respect to security and trust. Secondly, requirementsmodels are by construction simpler and more abstract than imple-mentation models (i.e. code). Therefore, techniques for automatedreasoning about alternatives at the early stages of the developmentprocess may succeed where automated software synthesis failed.

Since our overall goal is to design a secure system we have singledout the Secure Tropos methodology [16] as the target for our work.Its primitive concepts include those of Tropos and i* [7], but alsoconcepts that address security concerns, such as ownership, permis-sion and trust. Further, the framework already supports the designerwith automated reasoning tools for the verification of requirementsas follows:

1. Graphical capture of the requirements for the organization and thesystem-to-be,

2. Formal verification of the functional and security requirements by

• completion of the model drawn by the designer with axioms (aprocess hidden to the designer);

• checking the model for the satisfaction of formal properties cor-responding to specific security or design patterns.

29

In this framework (as in many other similar RE and SE frameworks)the selection of the alternatives is left to the designer. We will showthat we can do better.

Indeed, in Tropos (resp. Secure Tropos) requirements are con-ceived as networks of functional dependencies (resp. delegation ofexecution) among actors (organizational/human/software agents, po-sitions and roles) for goals, tasks and resources. Every dependency(resp. delegation of execution) also involves two actors, where oneactor depends on the other for the delivery of a resource, the fulfill-ment of a goal, or the execution of a task. Intuitively, these can beseen as actionsthat the designer has ascribed to the members of theorganization and the system-to-be. As suggested by Gans et al. [14]the task of designing such networks can then be framed as a plan-ning problem for multi-agent systems: selecting a suitable possibledesign corresponds to selecting a plan that satisfies the prescribed ordescribed goals of human or system actors. Secure Tropos adds tothe picture also the notion of delegation of permission and variousnotions of trust.

In this paper we show that it is possible to use an off-the-shelf plan-ner to select among the potential dependencies the actual ones thatwill constitute the final choice of the requirements engineer. If a plan-ner is already able to deliver good results then this looks a promisingavenue for transferring the technique to complex industry-level casestudies where a customized automated reasoning tool might be veryhandy. At the same time, if the problem is not trivial, not all plan-ners will be able to deliver and indeed this turned out to be the case.The techniques we use are sufficiently powerful to cope with secu-rity requirements as well as functional requirements, but we concen-trate here on their applicability to a security setting where an auto-mated support for the selection of potentially conflictingalternativesis more urgent. The application of the same planning techniques tothe overall software development phases can be found in [3].

In this work we have not focused on optimal designs: after all,human designers do not aim for optimality in their designs. As notedby Herbert Simon in his lecture on a “Scienceof Design” [31] whatmakes humans effective (in comparison to machines) is their abilityto identify a satisficing design as opposed to an optimal one.

Of course, we assume that the designer remains in the loop: de-signs generated by the planner are suggestions to be refined, amendedand approved by the designer. The planner is a(nother) support toolintended to facilitate the design process.

The rest of the paper is structured as follows. Section 2 explainsSecure Tropos concepts and describes the requirements verificationprocess. In Sections 3, 4 and 5 the planning approach to the systemdesign is introduced and explained, while in Section 6 the implemen-tation of our approach is presented. Finally, in Sections 7 and 8 a briefoverview of related work is presented and conclusions are drawn.

2 SecureTropos

Secure Tropos [16] is a RE methodology for modeling and analyzingfunctional and security requirements, extending the Tropos method-ology [7]. This methodology is tailored to describe both the system-to-be and its organizational environment starting with early phasesof the system development process. The main advantage of this ap-proach is that one can capture not only the what or the how, butalso the why a security mechanism should be included in the sys-tem design. In particular, Secure Tropos deals with business-level(as opposed to low-level) security requirements. The focus of suchrequirements includes, but is not limited to, how to build trust amongdifferent partners in a virtual organization and trust management. Al-

though their name does not mention security, they are generally re-garded as part of the overall security framework.

Secure Tropos uses the concepts of actor, goal, task, resource andsocial relations for defining entitlements, capabilities and responsi-bilities of actors. An actor is an intentional entity that performs ac-tions to achieve goals. A goal represents an objective of an actor.A task specifies a particular sequence of actions that should be ex-ecuted for satisfying a goal. A resource represents a physical or aninformational entity.

Actors’ desires, entitlements, capabilities and responsibilities aredefined through social relations. In particular, Secure Tropos sup-ports requesting, ownership, provisioning, trust, and delegation. Re-questing identifies desires of actors. Ownership identifies the legit-imate owner of a goal, a task or a resource, that has full authorityon access and disposition of his possessions. Provisioning identifiesactors who have the capabilities to achieve a goal, execute a task ordeliver a resource. We demonstrate the use of these concepts throughthe design of a Medical IS (Information System) for the payment ofmedical care.3

Example1 TheHealth Care Authority (HCA) is the “owner” ofthegoalprovide medical care; that is, it is theonlyonethatcande-cidewhocanprovideit andthroughwhatprocess.Ontheotherhand,Patient wantsthisgoal fulfilled. Thisgoal canbeAND-decomposedinto two subgoals:provisioning of medical care andpayment formedical care. TheHealthcare Provider hasthecapability for theprovisioning of medical care, but it shouldwait for authorizationfromHCA beforedoingit.

Delegationof executionis used to model situations where an actor(the delegator) delegates the responsibilities to achieve a goal, exe-cute a task, or deliver a resource to another actor (the delegatee) sincehe does not have the capability to provide one of above by himself.It corresponds to the actual choice of the design. Trust of executionrepresents the belief of an actor (the trustor) that another actor (thetrustee) has the capabilities to achieve a goal, execute a task or de-liver a resource. Essentially, delegation is an action due to a decision,whereas trust is a mental state driving such decision. Tropos depen-dency can be defined in terms of trust and delegation [17]. Thus,a Tropos model can be seen as a particular Secure Tropos model.In order to model both functional and security requirements, SecureTropos introduces also relations involving permission. Delegationofpermissionis used when in the domain of analysis there is a formalpassage of authority (e.g. a signed piece of paper, a digital creden-tial, etc.). Essentially, this relation is used to model scenarios wherean actor authorizes another actor to achieve a goal, execute a task, ordeliver a resource. It corresponds to the actual choice of the design.Trustof permissionrepresents the belief of an actor that another actorwill not misuse the goal, task or resource.

Example2 TheHCA mustchoosebetweendifferent providers forthe welfare managementfor executivesof a public institution. In-deed,sincethey havea specialprivate-lawcontract, they canqual-ify for both the INPDAP and INPDAI4 welfare schemes.The IN-PDAP schemerequiresthat the Patient partially paysfor medicalcare(with a ticket)andthemaincostis directlycoveredbytheHCA.On thecontrary, the INPDAI schemerequiresthat thePatient pays

3 An extended description of the example is provided in [4].4 INPDAP (Istituto Nazionale di Previdenza per i Dipendenti

dell’Amministrazione Pubblica) and INPDAI (Istituto Nazionale diPrevidenza per i Dirigenti di Aziende Industriali) are two Italian nationalwelfare institutes.

30

Figure1. Secure Tropos model

in advancethefull costof medicalcareandthengetsthereimburse-ment.Oncean institutionhasdecidedthepaymentscheme, this willbepart of therequirementsto bepassedontothenext stagesof sys-temdevelopment.Obviously, thechoiceof thealternativemayhavesignificant impactsonotherpartsof thedesign.

Figure 1 summarizes Examples 1 and 2 in terms of a Secure Tro-pos model. In this diagram, actors are represented as circles and goalsas ovals. Labels O, P and R are used for representing ownership, pro-visioning and requesting relations, respectively. Finally, we representtrust of permission and trust of execution relationships as edges re-spectively labelled Tp and Te.

Once the modelingphaseis concluded, Secure Tropos providesmechanisms for the verification of the model [16]. This means thatthe design process iterates over the following steps:

• model the system;• translate the model into a set of clauses (this is done automati-

cally);• verify whether appropriate design or security patterns are satisfied

by the model.

Through this process, we can verify the compliance of the modelwith desirable properties. For example, it can be checked whetherthe delegator trusts that the delegatee will achieve a goal, executea task or deliver a resource (trust of execution), or will use a goal,task or resource correctly (trust of permission). Other desirable prop-erties involve verifying whether an actor who requires a service, isconfident that it will be delivered. Furthermore, an owner may wishto delegate permissions to an actor only if the latter actually doesneed the permission. For example, we want to avoid the possibilityof having alternate paths of permission delegations. Secure Troposprovides support for identifying all these situations.

Secure Tropos has been used for modeling and analyzing real andcomprehensive case studies where we have identified vulnerabilitiesaffecting the organizational structure of a bank and its IT system [24],and verified the compliance to the Italian legislation on Privacy andData Protection by the University of Trento [23].

3 DesignasPlanning

So far the automated reasoning capabilities of Secure Tropos are onlyable to check that subtle errors are not overlooked. This is ratherunsatisfactory from the point of view of the designer. Whereas hemay have a good understanding of possible alternatives, he may notbe sure which is the most appropriate alternative for the case at hand.This is particularly true for delegations of permission that need tocomply with complex privacy regulations (see [23]).

Example3 Figures2(a)and2(c)presentfragmentsof Figure1, thatpoint out thepotentialchoicesof thedesign.Therequirementsengi-neer has identified trust relationsbetweentheHCA and INPDAPand INPDAI. However, whenpassingtherequirementsontothenextstage only one alternativehas to be selectedbecausethat will bethe systemthat is chosen.Figures 2(b) and 2(d) presentthe ac-tual choicescorrespondingto thepotentialchoicespresentedin Fig-ures2(a)and2(c), respectively.

Here, we want to support the requirements engineer in the selec-tion of the best alternative by changing the design process as follows:

• Requirements analysis phase

– System actors along with their desires, capabilities and entitle-ments, and possible ways of goal decomposition are identified.

– Trust relationships among actors both in terms of execution andpermission are defined.

• Design phase

– The space of design alternatives is automatically explored toidentify delegation of execution/permission.

– Depending on the time/importance of the goal the designer maysettle for satisficing solutions [31] or ask for an optimal solu-tion.

To support the designer in the process of selecting the best alterna-tive we advocate a planning approach which recently has proved tobe applicable in the field of automatic Web service composition [6].

31

(a) Potential choices

(b) Actual choice

(c) Potential choices

(d) Actual choice

Figure2. Design Alternatives

The basic idea behind the planning approach is to automaticallydetermine the course of actions (i.e. a plan) needed to achieve a cer-tain goal where an action is a transition rule from one state of thesystem to another [34, 28]. Actions are described in terms of precon-ditions and effects: if the precondition is true in the current state ofthe system, then the action is performed. As consequence of the ac-tion, the system will be in a new state where the effect of the actionis true. Thus, once we have described the initial state of the system,the goal that should be achieved (i.e. the desired final state of thesystem), and the set of possible actions that actors can perform, thesolution of the planning problem is the (not necessarily optimal) se-quence of actions that allows the system to reach the desired statefrom the initial state.

In order to cast the design process as a planning problem, we needto address the following question: which are the“actions” in a soft-ware design?When drawing the Secure Tropos model, the designerassigns the execution of goals from one actor to another, delegatespermission and – last but not least – identifies appropriate goal re-finements among selected alternatives. These are the actions to beused by the planner in order to fulfill all initial actor goals.

4 Planning Domain

The planning approach requires a specification language to representthe planning domain and the states of the system. Different typesof logics could be applied for this purpose, e.g. first order logic is

often used to describe the planning domain with conjunctions of lit-erals5 specifying the states of the system. We find this representationparticularly useful for modeling real case studies. Indeed, when con-sidering security requirements at enterprise level, one must be able toreason both at the class level (e.g. the CEO, the CERT team member,the employee of the HR department) and at the instance level (e.g.John Doe and Mark Doe playing those roles).

The planning domain language should provide support for speci-fying:

• the initial state of the system,• the goal of the planning problem,• the actions that can be performed,• the axioms of background theory.

Table 1 presents the predicates used to describe the initial stateofthesystemin terms of actor and goal properties, and social relationsamong actors. We use

• AND/OR decomposition to describe the possible decompositionof a goal;

• provides, requests and owns to indicate that an actor has thecapabilities to achieve a goal, desires the achievement of a goal,and is the legitimate owner of a goal, respectively;

• trustexe and trustper to represent trust of execution and trust ofpermission relations, respectively.

The desired state of the system (or goalof theplanningproblem) isdescribed through the conjunction of predicates done derived fromthe requesting relation in the initial state. Essentially, for each re-quest(a,g) we need to derive done(g).

By contrast, an actionrepresents an activity to accomplish a goal.We list them in Table 2 and define them in terms of preconditionsand effects as follows.

Satisfy. The satisfaction of goals is an essential action. Followingthe definition of goal satisfaction given in [16], we say that anactor satisfies a goal only if the actor wants and is able to achievethe goal, and – last but not least – he is entitled to achieve it. Theeffect of this action is the fulfillment of the goal.

DelegateExecution. An actor may not have enough capabilities toachieve assigned goals by himself, and so he has to delegate theirexecution to other actors. We represent this passage of responsi-bilities through action DelegateExecution. It is performed onlyif the delegator requires the fulfillment of the goal and trusts thatthe delegatee will achieve it. Its effect is that the delegator does notworry any more about the fulfillment of this goal after delegatingit since he has delegated its execution to a trusted actor. Further-more, the delegatee takes the responsibility for the fulfillment ofthe goal and so it becomes a his own desire. Notice that we do notcare how the delegatee satisfies the goal (e.g. by his own capabil-ities or by further delegation). It is up to the delegatee to decideit.

DelegatePermission. In the initial state of the system, only theowner of a goal is entitled to achieve it. However, this does notmean that he wants it or has the capabilities to achieve it. On thecontrary, in the system there may be some actors that want thatgoal and others that can achieve it. Thus, the owner could decideto authorize trusted actors to achieve the goal. The formal pas-sage of authority takes place when the owner issues a certificate

5 Let p be a predicate symbol with arity n, and t1, . . . , tn be its correspond-ing arguments. p(t1, . . . , tn) is called an atom. The expression literal de-notes an atom or its negation.

32

Goal PropertiesAND decompositionn(g : goal, g1 : goal, . . . , gn : goal)OR decompositionn(g : goal, g1 : goal, . . . , gn : goal)Actor Propertiesprovides(a : actor, g : goal)requests(a : actor, g : goal)owns(a : actor, g : goal)Actor Relationstrustexe(a : actor, b : actor, g : goal)trustper(a : actor, b : actor, g : goal)

Table1. Primitive Predicates

BasicActionsDelegateExecution(a : actor, b : actor, g : goal)DelegatePermission(a : actor, b : actor, g : goal)Satisfy(a : actor, g : goal)AND Refinen(a : actor, g : goal, g1 : goal, . . . , gn : goal)OR Refinen(a : actor, g : goal, g1 : goal, . . . , gn : goal)Absenceof TrustNegotiate(a : actor, b : actor, g : goal)Contract(a : actor, b : actor, g : goal)DelegateExecution under suspicion(a : actor, b : actor, g : goal)Fulfill(a : actor, g : goal)Evaluate(a : actor, g : goal)

Table2. Actions

that authorizes another actor to achieve the goal. We represent theact of issuing a permission through action DelegatePermissionwhich is performed only if the delegator has the permission onthe goal and trusts that the delegatee will not misuse the goal. Theconsequence of this action is to grant rights (on the goal) to thedelegatee, that, in turn, can re-delegate them to other trusted ac-tors.

AND/OR Refine. An important aspect of Secure Tropos is goal re-finement. In particular, the framework supports two types of re-finement: OR decomposition, which suggests the list of alterna-tive ways to satisfy the goal, and AND-decomposition, which re-fines a goal into subgoals which all are to be satisfied in orderto satisfy the initial goal. We introduce actions AND Refine andOR Refine. Essentially, AND Refine and OR Refine representthe action of refining a goal along a possible decomposition. Anactor refines a goal only if he actually need it. Thus, a precondi-tion of AND Refine and OR Refine is that the actor requests thefulfillment of the initial goal. A second precondition determinesthe way in which the goal is refined. The effect ofAND Refineand OR Refine is that the actor who refines the goal focuses onthe fulfillment of subgoals instead of the fulfillment of the initialgoal.

In addition to actions we define axiomsin the planning domain.These are rules that hold in every state of the system and are usedto complete the description of the current state. They are used topropagate actor and goal properties along goal refinement: a goal issatisfied if all its AND-subgoals or at least one of the OR-subgoalsare satisfied. Moreover, axioms are used to derive and propagate en-titlements. Since the owner is entitled to achieve his goals, executehis tasks and access his resources, we need to propagate actors’ enti-tlements top-down along goal refinement.

5 Delegationand Contract

Many business and social studies have emphasized the key roleplayed by trust as a necessary condition for ensuring the success of

organizations [9]. Trust is used to build collaboration between hu-mans and organizations since it is a necessary antecedent for coop-eration [1]. However, common sense suggests that fully trusted do-mains are simply idealizations. Actually, many domains require thatactors who do not have the capabilities to fulfill their objectives, mustdelegate the execution of their goals to other actors even if they donot trust the delegatees. Accordingly, much work in recent years hasfocused on the development of frameworks capable of coping withlack of trust, sometimes by introducing an explicit notion of distrust[14, 17].

The presence (or lack) of trust relations among system actors par-ticularly influences the strategies to achieve a goal [21]. In otherwords, the selection of actions to fulfill a goal changes dependingon the belief of the delegator about the possible behavior of the del-egatee. In particular, if the delegator trusts the delegatee, the first isconfident that the latter will fulfill the goal and so he does not needto verify the actions performed by the delegatee. On the contrary, ifthe delegator does not trust the delegatee, the first wants some formof control on the behavior of the latter.

Different solutions have been proposed to ensure for the delega-tor the fulfillment of his objectives. A first batch of solutions comesfrom transaction cost economics and contract theories that view acontract as a basis for trust [35]. This approach assumes that a dele-gation must occur only in the presence of trust. This implies that thedelegator and the delegatee have to reach an agreement before del-egating a service. Essentially, the idea is to use a contract to defineprecisely what the delegatee should do and so establish trust betweenthe delegator and the delegatee. Other theories propose models whereeffective performance may occur also in the absence of trust [12]. Es-sentially, they argue that various control mechanisms can ensure theeffective fulfillment of actors’s objectives.

In this paper we propose a solution for delegation of execution thatborrows ideas from both approaches. The case for delegation of per-mission is similar. The process of delegating in the absence of trustis composed of two phases: establishingtrustand control. The estab-lishing trust phase consists of a sequence of actions, namely Negoti-

33

Planner Release URLDLVK 2005-02-23 http://www.dbai.tuwien.ac.at/proj/dlv/K/IPP 4.1 2000-01-05 http://www.informatik.uni-freiburg.de/ koehler/ipp.htmlCPT 1.0 2004-11-10 http://www.cril.univ-artois.fr/ vidal/cpt.en.htmlSGPLAN 2004-06 http://manip.crhc.uiuc.edu/programs/SGPlan/index.htmlSATPLAN 2004-10-19 http://www.cs.washington.edu/homes/kautz/satplan/LPG-td 2004-06 http://zeus.ing.unibs.it/lpg/

Table3. Comparison among planners

hh

hh

hh

hhh

RequirementPlanner DLVK IPP CPT SGPLAN SATPLAN LPG-td

1 X X X X X2 X X X3 X X X X

Table4. Comparison among planners

ate and Contract. In Negotiate the parties negotiate the duties andresponsibilities accepted by each party after delegation. The postcon-dition is an informal agreement representing the initial and informaldecision of parties to enter into a partnership. During the execution ofContract the parties formalize the agreement established during ne-gotiation. The postcondition of Contract is a trust “undersuspicion”relation between the delegator and the delegatee. Once the delegatorhas delegated the goal and the delegatee has fulfilled the goal, thefirst wants to verify if the latter has really satisfied his objective. Thiscontrol is performed using action Evaluation. Its postcondition is the“real”fulfillment of the goal. To support this solution we have intro-duced some additional actions (last part of Table 2) to distinguish thecase in which the delegation is based on trust from the case in whichthe delegator does not trust the delegatee.

Sometimes establishing new trust relations might be more conve-nient than extending existing trust relations. A technical “side-effect”of our solution is that it is possible to control the length of trusted del-egation chains. Essentially, every action has a unit cost. Therefore,refining an action into sub-actions corresponds to increasing the costassociated with the action. In particular, refining the delegation ac-tion in absence of trust guarantees that the framework first tries todelegate to trusted actors, but if the delegation chain results too longthe system can decide to establish a new trust relation rather than tofollow the entire trust chain.

Need-to-knowproperty of a design decision states that the ownerof a goal, a task or a resource wants that only the actors who needpermission on its possession are authorized to access it. Essentially,only the actor that achieves a goal, executes a task or delivers a re-source, and the actors that belong to the delegation of permissionchain from the owner to the provider should be entitled to access thisgoal, task or resource. Thus, we want to obtain a plan where only theactions that contribute to reaching the desired state occur, so that ifany action is removed from the plan it no longer satisfies the goal ofthe planning problem. This approach guarantees the absence of alter-native paths of permission delegations since a plan does not containany redundant actions.

6 Using the Planner

In the last years many planners have been proposed (Table 3). Inorder to choose one of them we have analyzed the following require-ments:

1. The planner should produce solution that satisfy need-to-know

property by construction, that is, the planner should not produceredundant plans. Under non-redundant plan we mean that, bydeleting an arbitrary action of the plan, the resulting plan is nomore a “valid” plan (i.e. it does not allow to reach the desiredstate from the initial state).

2. The planner should use PDDL (Planning Domain Definition Lan-guage) [15], since it is becoming the “standard”planning languageand many research groups work on its implementation. In partic-ular, the planner should use PDDL 2.2 specifications [10], sincethis version support features, such as derived predicates, that areessential for implementing our planning domain.

3. The planner should be available on both Linux and Windows plat-forms as our previous Secure Tropos reasoning tool works onboth.

Table 4 presents a comparison among the planners we have con-sidered with respect to above requirements. Based on such require-ments, we have chosen LPG-td, a fully automated system for solvingplanning problems, supporting PDDL 2.2.

Figure 3 shows the specification of actions Satisfy andDelegatePermission in PDDL 2.2.

We have applied our approach to the Medical IS case study pre-sented in Figure 1. The desired state of the system is obviously onewhere the patient gets medical care. The PDDL 2.2 specification ofthe planning problem is given in [4].

Figure 4 shows the optimal solution (i.e. the plan composed of thefewer number of actions than any other plan) proposed by LPG-td.However, this was not the first choice of the planner. Before selectingthis plan, the planner proposed other two sub-optimal alternatives(see [4] for a discussion). It is interesting to see that the planner hasfirst provided a solution with INPDAP, then a solution with INPDAI,and then, finally , a revised solution with INPDAP. A number of otherexperiments were conduced to test the scalability of our approach.The results are reported in [4].

7 RelatedWork

In recent years many efforts have addressed the integration of se-curity with the system development process, in particular duringearly requirements analysis. In this setting, many researchers haverecognized trust as an important aspect of this process since trustinfluences the specification of security and privacy policies. How-ever, very few requirements engineering methodologies introducetrust concerns during the system development process. Yu et al. [36]

34

(: action Satisfy: parameters (?a − actor ?g − goal): precondition (and

(provides ?a ?g)(requests ?a ?g)(has per ?a ?g))

: effect (and(done ?g)not (requests ?a ?g)))

(a) Satisfy

(: action DelegatePermission: parameters (?a ?b − actor ?g − goal): precondition (and

(trustper ?a ?b ?g)(has per ?a ?g))

: effect (and(has per ?b ?g)))

(b) DelegatePermission

Figure3. Actions’ Specification

DelegateExecution Pat HP ProvideMCAND Refine HP ProvideMC ProvisioningMC PaymentMCDelegatePermission HCA HP ProvisioningMCSatisfy HP ProvisioningMCDelegateExecution HP HCA PaymentMCDelegateExecution HCA INPDAP PaymentMCAND Refine INPDAP PaymentMC PaymentTicket PaymentHCADelegateExecution HCA INPDAP PaymentHCASatisfy HCA PaymentHCAOR Refine INPDAP PaymentTicket PaymentTicketINPDAP PaymentTicketHPDelegatePermission HCA INPDAP PaymentTicketINPDAPSatisfy INPDAP PaymentTicketINPDAP

Figure4. The optimal solution

model trust by using the concept of softgoal, i.e. a goal having noclear definition for deciding whether it is satisfied or not. However,this approach considers trust as a separate concept from security anddoes not provide a complete framework to consider security and trustthroughout the development process. Haley et al. [18] propose to usetrust assumptions, problem frames, and threat descriptions to aid re-quirements engineers to define and analyze security requirements,and to document the decisions made during the process.

Other approach focus on security requirements without taking intoaccount trust aspect. van Lamsweerde et al introduce the notion ofantigoals for representing the goals of attackers [33]. McDermott etal. define abuse case model [26] to specify the interactions amongactors, which results are harmful to some actors. Similarly, Sindre etal. define the concept of a misuse case [32], the inverse of a use case,which describes a function that the system should block.

Model Driven Architecture (MDA) approach [27], proposed byObject Management Group, is a framework for defining software de-sign methodologies. Its central focus is on the model transformation,for instance from the platform-independent model of the system toplatform-specific models used for implementation purposes. Modelsare usually described in UML, and the transformation is performedin accordance with the set of rules, called mapping. Transformationcould be manual, or automatic, or mixed. Among the proposals onautomating a software design process the one of Gamma et al. ondesign patterns [13] has been widely accepted. A design pattern is asolution (commonly observed from practice) to the certain problemin the certain context, so it may be thought as a problem-context-solution triple. Several design patterns can be combined to form asolution. Notice that it is still the designer who makes the key deci-sion on what pattern to apply to the given situation.

The field of AI planning has been making advances during the lastdecades, and has found a number of applications (robotics, processplanning, autonomous agents, Web services, etc.). There are two ba-sic approaches to the solution of planning problems [34]. One isgraph-based planning algorithms [2] in which a compact structure

called a Planning Graph is constructed and analyzed. While in theother approach [19] the planning problem is transformed into a SATproblem and a SAT solver is used. An application of the planning ap-proach to requirements engineering is proposed by Gans et al. [14].Essentially, they propose to map trust, confidence and distrust de-scribed in terms of i* models [36] to delegation patterns in a work-flow model. Their approach is inspired by and implemented in Con-Golog [8], a logic-based planning language. In this setting, tasks areimplemented as ConGolog procedures where preconditions corre-spond to conditionals and interrupts. Also monitors are mapped intoConGolog procedures. They run concurrently to the other agent taskswaiting for some events such as task completion and certificate ex-piration. However, focus of their work is on modeling and reasoningabout trust in social networks, rather than on secure design.

8 Conclusions

We have shown that in our extended Secure Tropos framework it ispossible to automatically support the designer of secure and trustedsystems also in the automatic selection of design alternatives. Ourenhanced methodology allows one to:

1. Capture through a graphical notation the requirements for the or-ganization and the system-to-be.

2. Verify the correctness and consistency of functional and securityrequirements by

• completion of the model drawn by the designer with axioms (aprocess hidden to the designer),

• checking the model for the satisfaction of formal properties cor-responding to specific security or design patterns.

3. Automatically select alternative solutions for the fulfillment offunctional and security requirements by

• transformation of the model drawn by the designer into a plan-ning problem (a process hidden to the designer),

35

• automatic identification of an alternative satisficing the goals ofthe various actors by means of planner.

In this paper we show that this is possible with the use of an off-the-shelf planner to generate possible designs for not trivial securityrequirements. Of course, we assume that the designer remains in thedesign loop, so the designs generated by the planner are seen as sug-gestions to be refined, amended and approved by the designer. Inother words, the planner is a(nother) support tool intended to facili-tate the design process.

Our future work includes extending the application of this idea toother phases of the design and towards progressively larger indus-trial case studies to see how far can we go without using specializedsolvers.

ACKNOWLEDGEMENTS

We thank Alfonso Gerevini and Alessandro Saetti for the sup-port on the use of LPG-td. This work was partly supported bythe projects RBNE0195K5 FIRB-ASTRO, RBAU01P5SS FIRB-SECURITY, 016004 IST-FP6-FET-IP-SENSORIA, 27587 IST-FP6-IP-SERENITY, 27004 IST-FP6-STREP-S3MS, 2003-S116-00018PAT-MOSTRO, 1710SR-B/P PAT-STAMPS.

REFERENCES[1] Robert Axelrod, TheEvolutionof Cooperation, Basic Books, 1984.[2] Avrim Blum and Merrick L. Furst, ‘Fast Planning Through Planning

Graph Analysis’, 90(1-2), 281–300, (1997).[3] Volha Bryl, Paolo Giorgini, and John Mylopoulos, ‘Requirements

analysis for socio-technical systems: Exploring and evaluating alterna-tives’, Technical Report DIT-06-006, University of Trento.

[4] Volha Bryl, Fabio Massacci, John Mylopoulos, and Nicola Zannone,‘Designing security requirements models through planning’, TechnicalReport DIT-06-003, University of Trento.

[5] James Caldwell, ‘Moving Proofs-as-Programs into Practice’, pp. 10–17, (1997).

[6] M. Carman, L. Serafini, and P. Traverso, ‘Web service composition asplanning’, (2003).

[7] Jaelson Castro, Manuel Kolp, and John Mylopoulos, ‘TowardsRequirements-Driven Information Systems Engineering: The TroposProject’, 27(6), 365–389, (2002).

[8] Giuseppe de Giacomo, Yves Lesperance, and Hector J. Levesque,‘ConGolog, a concurrent programming language based on the situationcalculus’, 121(1-2), 109–169, (2000).

[9] Peter Drucker, Managing theNon-Profit Organization:PrinciplesandPractices, HapperCollins Publishers, 1990.

[10] Stefan Edelkamp and Jorg Hoffmann, ‘Pddl2.2: The language for theclassical part of the 4th international planning competition’, TechnicalReport 195, University of Freiburg, (2004).

[11] Thomas Ellman, ‘Specification and Synthesis of Hybrid Automata forPhysics-Based Animation’, pp. 80–93, (2003).

[12] Michael J. Gallivan, ‘Striking a balance between trust and control ina virtual organization: a content analysis of open source software casestudies’, 11(2), 277, (2001).

[13] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides,Design Patterns: Elementsof ReusableObject-OrientedSoftware,Addison-Wesley, 1995.

[14] G. Gans, M. Jarke, S. Kethers, and G. Lakemeyer, ‘Modeling the Impactof Trust and Distrust in Agent Networks’, pp. 45–58, (2001).

[15] M. Ghallab, A. Howe, C. Knoblock, D. McDermott, A. Ram,M. Veloso, D. Weld, and D. Wilkins, ‘PDDL – The Planning DomainDefinition Language’, (1998).

[16] Paolo Giorgini, Fabio Massacci, John Mylopoulos, and Nicola Zan-none, ‘Modeling Security Requirements Through Ownership, Permis-sion and Delegation’, pp. 167–176, (2005).

[17] Paolo Giorgini, Fabio Massacci, John Mylopoulos, and Nicola Zan-none, ‘Modelling Social and Individual Trust in Requirements Engi-neering Methodologies’, volume 3477, pp. 161–176, (2005).

[18] Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, and BasharNuseibeh, ‘Using Trust Assumptions with Security Requirements’, 11,138–151, (2006).

[19] Henry Kautz and Bart Selman, ‘Planning as satisfiability’, pp. 359–363.John Wiley & Sons, Inc., (1992).

[20] Emmanuel Letier and Axel van Lamsweerde, ‘Reasoning about partialgoal satisfaction for requirements and design engineering’, 29(6), 53–62, (2004).

[21] Niklas Luhmann, TrustandPower, Wisley, 1979.[22] Zohar Manna and Richard Waldinger, ‘A Deductive Approach to Pro-

gram Synthesis’, ACM Transactionson ProgrammingLanguagesandSystems, 2(1), 90–121, (1980).

[23] Fabio Massacci, Marco Prest, and Nicola Zannone, ‘Using a SecurityRequirements Engineering Methodology in Practice: The compliancewith the Italian Data Protection Legislation’, 27(5), 445–455, (2005).

[24] Fabio Massacci and Nicola Zannone, ‘Detecting Conflicts betweenFunctional and Security Requirements with Secure Tropos: John Rus-nak and the Allied Irish Bank’, Technical Report DIT-06-002, Univer-sity of Trento, (2006).

[25] Mihhail Matskin and Enn Tyugu, ‘Strategies of Structural Synthesis ofPrograms and Its Extensions’, 20, 1–25, (2001).

[26] J. McDermott and C. Fox, ‘Using Abuse Case Models for Security Re-quirements Analysis’, pp. 55–66, (1999).

[27] Object Management Group. Model Driven Architecture (MDA).http://www.omg.org/docs/ormsc/01-07-01.pdf, July 2001.

[28] Joachim Peer, ‘Web Service Composition as AI Planning - a Survey’,Technical report, University of St. Gallen, (2005).

[29] Steve Roach and Jeffrey Baalen, ‘Automated Procedure Constructionfor Deductive Synthesis’, 12(4), 393–414, (2005).

[30] Ragnhild Kobro Runde and Ketil Stølen, ‘What is model driven archi-tecture?’, Technical Report UIO-IFI-RR304, Department of Informat-ics, University of Oslo, (March 2003).

[31] Herbert A. Simon, TheScienceof theArtificial, MIT Press, 1969.[32] Guttorm Sindre and Andreas L. Opdahl, ‘Eliciting security require-

ments with misuse cases.’, 10(1), 34–44, (2005).[33] Axel van Lamsweerde, Simon Brohez, Renaud De Landtsheer, and

David Janssens, ‘From System Goals to Intruder Anti-Goals: AttackGeneration and Resolution for Security Requirements Engineering’, pp.49–56, (2003).

[34] Daniel S. Weld, ‘Recent Advances in AI Planning’, AI Magazine, 20(2),93–123, (1999).

[35] Rosalinde Klein Woolthuis, Bas Hillebrand, and Bart Nooteboom,‘Trust, Contract and Relationship Development’, OrganizationStudies,26(6), 813–840, (2005).

[36] Eric S. K. Yu and Lin Liu, ‘Modelling Trust for System Design Usingthe i* Strategic Actors Framework’, volume 2246, pp. 175–194, (2001).

36

Formal Developmentof WebServicesAntonella Chirichiello 1 and GwenSalaun2

Abstract. Formalmethodsarehelpful for many issuesraisedin thewebservicesarea.In this paper, we advocatetheuseof processal-gebraasafirst stepin thedesignanddevelopmentof executablewebservices.Verification toolscanbeusedto validatethecorrectexecu-tion of suchformal descriptions.We define someguidelinesto en-codeabstractspecificationsof services-to-bewrittenusingthesecal-culi into executablewebservices.As a back-endlanguage,we con-sider the orchestrationlanguageBPEL. We illustrateour approachthroughthedevelopmentof asimplee-businessapplication.

1 Intr oduction

Web services(WSs) are network-basedsoftware componentsde-ployed andthenaccessedthroughthe internetusingstandardinter-facedescriptionlanguagesand uniform communicationprotocols.Eachservicesolvesaprecisetask,andmaycommunicatewith otherservicesby exchangingmessagesbasedonXML standards.

Formalmethodsprovide anadequateframework (many specifica-tion languagesandreasoningtools) to describeWSsat an abstractlevel andthento tackle interestingissues,in particulartheir (auto-matic)compositionor correctdevelopment.Differentproposalshaveemerged recently to abstractlydescribeWSs and copewith thesequestions,most of which are groundedon transitionsystemmod-els (LabelledTransitionSystems,Mealy automata,Petri nets,etc)[2, 16, 21, 13, 17]. However, very few approacheshave beenpro-posedto help the designandthendevelopmentof WSs,especiallyfrom this kind of abstractdescriptions(asdonein theclassicalsoft-wareengineeringlife cycle to developsoftwaresystems).

In thispaper, weadvocatetheuseof processalgebra(PA) [3] (e.g.,CCS,π-calculus,LOTOS, Promela)as a startingpoint to developWSs.PA is a simple,abstractandformally-defined notationto de-scribetheexchangeof messagesbetweenWSs,andto reasonon thespecifiedsystems.Centralto ourapproachis thedefinition of amap-pingbetweenabstractprocessesandexecutableservices(implemen-tationsandtheir associatedinterfaces)assketchedin Figure1.

The useof PA for developmentpurposesmay be consideredintwo ways:(i) encoding meansspecifyingabstractlythenew serviceandits interactionswith theotherparticipants,andthentranslatingitinto anexecutablelanguage,(ii) reverse engineering meansextract-ing an abstractrepresentationfrom the serviceimplementation(ac-cordinglythedeveloperimplementsdirectly theserviceusinganex-ecutablelanguage)to validateits behaviour with respectto its mates.In bothsituations,weassumethattheexistingWSs(comparedto theone(s)underdevelopment)have behavioural interfacesfrom whichabstractdescriptionscanbeobtained(prospective hypothesispartic-

1 DIS - Universita di Roma “La Sapienza”, Italy, email:chirichiello@dis.uniroma1.it

2 INRIA Rhone-Alpes, VASY Project, France, email:Gwen.Salaun@inrialpes.fr

ularly with regardsto the currentWSDL technology, seeWS-CDL[26] asan exampleof proposalin this direction).The restrictionoftheservicevisibility to their public interfacesis a commonsituationin softwareengineeringdueto theblack-boxfeatureof components.Orchestration is a specific caseof servicedevelopmentwhich aimsat solving morecomplex tasksby developinga new service(oftencalledorchestrator) usingexisting servicesby exchangingmessageswith them.

++

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 Algebrarefinement

mappingabstract layer

reverse engineering

concrete layer

(WS

DL

, W

S−

CD

L...)

inte

rfa

ce

Figure1. Overview of ourapproach

This paperfocuseson the encodingof PA into executablecode.In this case,PAs areespeciallyworthy asa first descriptionstepbe-causethey enableusto analysetheproblemat hand,to clarify somepoints,andtosketcha(first) solutionusinganabstractlanguage(thendealingonly with essentialconcerns).Therefore,from sucha formaldescriptionof oneor moreservices-to-be,verification tools canbeusedto validatetheir correctexecutionand, if necessary, to verifyandensurerelevant temporalpropertiessuchassafetyandlivenessones[18].

Regarding the WS(s) to be implemented(comparedto the otheroneswhich are viewed as behavioural interfaces),we concentrateourselves,at theconcretelevel, on WSDL interfacesandBPEL ser-vices. We chosethesetechnologiesbecausethey are well-knownstandardsof widespreaduseandbecauseBPEL is process-orientedthereforemakingthe encodingtractable.Dependingon the expres-sivenessof theprocessalgebrausedin theinitial step,wecanobtaineither runningBPEL codeor just skeletonsof codeto be comple-mented.We emphasizethat a formal encoding/development(pre-serving semanticsbetweenboth levels) is not achieved yet sinceBPELdoesnothaveawidely acceptedformal semantics.

Theorganizationof this paperis asfollows.We startwith a shortintroductionof processalgebrain Section2.Section3 focusesonfor-mal verification, andwe emphasizewhich kind of checkcanbeper-formedon abstractdescriptionsof services.Section4 definesguide-linesformalisingtheencodingof processalgebrainto BPEL.Section5 describesan exampleof e-businessapplicationin which all thestepsadvocatedin our approacharesuccessively copedwith: analy-sis, formal description,verification, encodingof processesin BPELservices.Finally, in Section6 wedraw upsomeconcludingremarks.

37

2 ProcessAlgebraic Descriptionsof Services

PAs [3] areabstractlanguagesusefulto specifydynamicbehaviours(sequentiality, concurrency, parallelism,etc). Processesdefined us-ing themmaycommunicatetogetherby exchangingmessages.Thesecalculiareformalizedeitheraxiomaticallywith algebraiclawswhichcanbeusedto verify termequivalences,operationallyusingaseman-ticsbasedonLabelledTransitionSystems,or denotationallydefiningthemeaningof basicentities(andof their composition)usingfunc-tions.Theseformalismsaremostof thetimetool-equipped,enablingoneto simulatepossibleevolutionsof processes,to generatetestse-quences,to checkproperties(e.g., to ensurethatabadsituationneverhappens),to minimizebehaviours,to verify equivalences,etc.

As claimedin a previouswork [23], PAs areadequateto describeWSs,becausethey focuson descriptionof behaviours andso, theyare appropriateto specify the exchangeof messagesbetweenser-vices.Comparedto automata-basedapproaches,its main benefit isits expressiveness,mostlydueto theexistenceof numerousPAs en-ablingoneto choosethemostadequateformalismdependingon theaspectsof servicesto becaptured.Comparedto Petri nets,PA con-structsmake it possibleto specifycompositiondueto their compo-sitionality propertywhich allows for thedefinition of morecomplexbehavioursfrom simpleones.Finally, textual notationsaremoread-equatefor describingandreasoningon real-sizeproblems.

The large numberof processcalculi (CCS, TCSP, LOTOS, π-calculus,Promela,etc)andaccompanying tools (CWB-NC, CADP,MWB, SPIN,etc)offer a wide panelof expressivenessto dealwithvaluableissuesin the WS area.In this section,our goal is not tointroducea precisealgebra,but to presentthe commonconstructsappearingin mostof them.

Actions and interactions. The basicconceptto build dynamicbehaviours (or processes)is the so-calledaction. Actions areeitheremissions or receptions, denotedrespectively OACT (OutputAC-Tions) and IACT (Input ACTions) in the sequel.Two (or more)processescanevolve in parallel andsynchronizethemselveswhenthey arereadyto evolvealongthesameactionname;thebasicmatch-ing is onesenderandonereceiver. Differentcommunicationmodelsmaybeconsideredinvolving variantssuchasasynchronousvs syn-chronouscommunication,or binaryvs n-arycommunication.

Behavioural constructs.First,a termination END indicatestheendof a behaviour. An hidden or internal action INT maybeusedto make abstractsomepossiblepiecesof behaviours correspondingto internal evolutions.The hide HID operatoris sometimesusedto make explicit the hiding of someactionsto the environmentoftheprocess.Theusualthreemainconstructsarethesequence SEQ

proposingthe executionof an action followed by a behaviour, thenondeterministic choice CH betweentwo behaviours (sometimes,internal and external choicesare usedto distinguishthe sourceofthechoice),andtheparallel composition PAR (andall its underly-ing variantslike full synchronizationor interleaving) meaningpar-allel evolution andsynchronizationamongseveralprocesses.Manydynamicoperatorsmay be usedandappearin existing calculi: in-terruption,sequentialcomposition,or compensationand exceptionhandlingfor constructsmorerelatedto WSsissues[5].

Data descriptions.DataDD arenot alwaysdescribedwithin PA(this is not the casein basicCCS,for instance).Different levels ofrepresentationexist, for examplein Promela,basicdatatypes(inte-gers,boolean)may be handledandoneadvancedconstruct(array)is available.A moreexpressive calculusis LOTOSwhich allows therepresentationof expressivedatausingalgebraicspecifications[9].

Datatermsappearat differentplaceswithin dynamicbehaviours.

First, processesmaybeparameterizedwith a list of formal parame-ters(local variabledeclarationV D). Actionsmaybeextendedwithvaluepassingto exchangevalues:anemissionOACT maybepara-meterizedwith possibledataterms,whereasa receptionIACT maybeparameterizedwith variables.A behaviour maybeprecededby aguardGRD, andis thereforeexecutedonly if theguardconditionistrue.

Processes.A processis composedof anidentifierID, a list of ac-tionsAD, a list of local parametersV D, andits behaviour BHV .Theprocessbodyis built usingthebehavioural constructsdescribedabove, thus more complicatedbehaviours can be built from basiconesbecausePAs arecompositionallanguages.Theidentifier is use-ful to referto thebehaviour of theprocess,andparticularlyto instan-tiate or call it recursively. Note that recursive calls may be usedtoupdatelocal variables.

In this paper, we illustratethewriting of servicespecificationus-ing the LOTOS calculus.To make the readingof the forthcomingpiecesof specificationeasier, we give in Table1 thecorrespondencebetweenthePA abstractoperatorsmentionedabove andtheLOTOSones.

Abstractconstructs LOTOSconstructs

OACT act!vIACT act?x:tEND exitINT τSEQ act;BCH B1[]B2

PAR B1|[sync-actions]|B2

HID hide a1, ..., an in BDD algebraic specificationsGRD [bool-exp]→ BID,AD,V D,BHV P[action-list](var-list):= B

Table1. CorrespondencebetweenabstractandLOTOSconstructs

3 Verification

The major interestof usingabstractlanguagesgroundedon a clearsemanticsis that tools canbe usedto checkthat a systemmatchesits requirementsandworksproperly. Model checking [7] is thepre-ferred techniqueat this level (especiallycomparedto the theoremproving alternative[14]) becauseit workswith automata-basedmod-els (underlyingmodelsof process-algebraicnotations),and proofsarecompletelyautomated(press-button technology).Processalge-brasareequippedwith state-of-the-artverification tools,suchastheSPINmodelchecker [15] or theCADP toolbox [12], andhenceareadequateto any kind of press-button check.Reasoningabilities arestrongly relatedto the servicevisibility level. In any case(reverseengineeringor encodingof abstractprocessesinto code),interfacedescriptionlanguageshave to beexpressiveenoughto make thever-ification stepspossible.

As far as web servicesspecificities are concerned(componentsdeployed on the web, composedto work out preciserequests,andinteractingasautomaticallyaspossible),this kind of toolscanhelpin threecases:

(i) checkingthat two processesarein someprecisesenseequivalent– oneprocessis typically averyabstractoneexpressingthespeci-

38

fication of theproblem,while theotheris closerto theimplemen-tationlevel;

(ii) checkingthat a processverifies desirableproperties – e.g. thepropertythatthesystemwill never reachsomeunexpectedstate;

(iii) checkingthatinterfacesof severalservicesarecompatible sothatthey caninteracttogetherandendin acorrectterminationstate.

Intuitively, two processesor servicesareconsideredto be equiv-alentif they areindistinguishable from theviewpoint of anexternalobserver interactingwith them.This notion hasbeenformally de-fined in theprocessalgebracommunity[20], andseveralnotionsofequivalencehave beenproposedsuchas traceequivalence,obser-vationalequivalence,branchingequivalence,or strongbisimulation.In our opinion,branchingequivalence[25] is themostrelevantonein thecontext of webservices.Indeed,branchingequivalenceis thestrongestof the weakequivalences,although,unlike strongequiva-lence,it doesnot requirea strict matchingof τ transitions.In [23],we show how suchequivalencenotionscanbe usedto checkcom-patibility betweenservicesand then to ensurethe correctnessof acomposition.

Thepropertiesof interestin concurrentsystemstypically involvereasoningon thepossiblescenariosthat thesystemcango through.An establishedformalismfor expressingsuchpropertiesis givenbytemporal logics like CTL? [18]. Theselogics presentconstructsal-lowing to statein a formal way that, for instance,all scenarioswillrespectsomepropertyateverystep,or thatsomeparticulareventwilleventuallyhappen,andsoon. Themostnoticeablekindsof proper-tiesonemaywantto ensureare:

− safety properties, which statethat an undesirablesituationwillneverarise;

− liveness properties, whichstatethatsomethinggoodmusthappen.

Lastbut not least,compatibilitybetweentwo webservicesdependsnot only on staticpropertieslike thecorrecttyping of their messageparameters,but alsoon their dynamicbehaviour. Providing a simpledescriptionof the servicebehaviour basedon process-algebraicorautomata-basedformalismscanhelp detectingmany subtleincom-patibilitiesin their interaction.Moreover, thiscompatibilitycheckingcanto a largeextentbeautomatedif wedefine thenotionof compat-ibility in a sufficiently formal way. In [4], we proposeandcomparea numberof formal definitions of the compatibility notion,andweillustratethemonsimpleexamples.

4 CodeGeneration

Designinganddevelopingcertified andexecutableWSsis a promis-ing directionandveryfew proposalsaredealingwith suchaquestionin aformalway. A lot of work remainsto bedoneto haveatone’sdis-posala smoothandformal process(known asrefinement)enablingone to develop (correct)running WSs from abstractand validateddescriptions.

At this level, weespeciallyexperimentedtheuseof PA to developexecutableandcertified WSsfrom suchabstractdescriptions[24, 6].Thelink betweentheabstractlevel andtheconcreteoneis formalisedthroughsystematicguidelineswhich make it possibleto translatesuchabstractprocessesinto WSDL interfacesandBPEL processes.Dependingontheprocessalgebra(andparticularlyonits expressive-ness)usedin theinitial step,runningBPELservicesor justskeletonsof code(to becomplemented)maydirectlybeobtained.

In this section,we define guidelinesto enabledevelopersto writeout easilyadvancedskeletonsof BPEL codefrom abstractandvali-dateddescriptionsof services-to-be.Thepresentationof this section

follows thestructureof theintroductionto PA donein Section2. ForeachPA concept(actions,interactions,dynamicoperators,datade-scriptions,processes),wedescribehow it canbeencodedinto BPELand we illustrate with piecesof XML code.Here,we refer to PAandits underlyingconstructsin ageneralway, eventhoughwe illus-tratewith piecesof LOTOSspecification.Wevalidatedourapproachon many examplesof suchencodings.TheBPEL codeobtainedaf-ter translationwasdevelopedanddeployed usingthe OracleBPELProcessManager2.0[1].

Actions and interactions. Thebasicpieceof behaviour in PA, theso-calledaction,is translatedinto WSDL usingmessageswhich arecompletelycharacterizedby the message, portType, operation andpartnerLinkType tags.An abstractreceptionis expressedin BPELusing the receive activity or the pick activity with one onMessagetag.For example,theLOTOScoderequest?x:Nat denotesthere-ceptionof anintegervalueandthecorrespondingBPELcodeis

<receive partnerLink="Requester"

portType="tns:requestPortType"

operation="requestOperation"

variable="x"/>

An abstractemissionis written in BPEL usingthe asynchronous orone-way invoke activity. For example,theLOTOScoderequest!xdenotestheemissionof avalueandthecorrespondingBPELcodeis

<invoke partnerLink="Adder"

portType="tns:requestPortType"

operation="requestOperation"

inputVariable="x"/>

At the abstractlevel, an emissionfollowed immediatelyby a re-ceptionmay be encodedusing the BPEL synchronous or two-wayinvoke activity, performingtwo interactions(sendinga requestandreceiving a response).On the otherside,the complementaryrecep-tion/emissionis writtenoutusinga receive activity (or apick activitywith oneonMessage tag)followedby a reply one.As anexample,letus considertwo interactingprocessesexchangingan integer value.The emissionand the following receptionis written in LOTOS asrequest!x; result?y:Nat, andthecorrespondingBPELcodeis

<invoke partnerLink="Adder"

portType="tns:requestResultPortType"

operation="requestResultOperation"

inputVariable="x"

outputVariable="y"/>

While, on the other side of the communication,the receptionfol-lowed by the emissionrequest?x:Nat; result!x+z in LOTOSis translatedinto BPELasfollows

<receive partnerLink="Requester"

portType="tns:requestResultPortType"

operation="requestResultOperation"

variable="x"/>

...<reply partnerLink="Requester"

portType="tns:requestResultPortType"

operation="requestResultOperation"

variable="y"/>

with the samenameof port type andoperation.We emphasizethattheabstracttermx+z doesnot appearin theBPEL code,becauseit

39

wasreplacedby the variabley denotingthe resultof the term,andwhichhasto beassignedbeforehandto y usinganassign tag.

As far asthe numberof participantsto a communicationis con-cerned,let usremarkthatbinaryinteractionsareencodedstraightfor-wardly in BPEL (dueto its peer-to-peerinteractionmodel)whereasmulti-partycommunicationsareexpressedin BPEL decomposingitin asmany successive two-partycommunicationsasneeded.

Behavioural constructs. The sequenceSEQ matchesthe se-quence activity. The abstractterminationEND correspondsto theendof themainsequencein BPEL.For example,thefollowing pieceof LOTOSspecificationrequest!x; result?y:Nat; exit cor-respondsin BPEL to

<sequence>

<invoke ... />

<sequence/>

An hiddenactionINT is translatedinto BPELasalocalevolutionof aWSwhich is notvisible from anexternalpointof view. Accord-ingly, it correspondsto one(or more)assign statement.It mayalsocorrespondto a communicationof thewebserviceat handwith an-otherpartybut notvisible from outside.TheHID constructmakinghiddenactionsexplicit in PA is mappedin BPEL as the hiding ofeachconcernedaction(possiblyinvolved in a communicationwithotherpartners,thennot visible from outside).

ThechoiceCH is translatedusingeithertheswitch activity, defin-ing an orderedlist of case or the pick activity, defining a setof ac-tivities fired by a messagereception.Branchesof a choiceCH in-volveemissionsandreceptions,possiblyprecededby guards.In caseof a choiceamongemissions,nondeterminismexisting at the ab-stractlevel hasto beremoved.If guardsarepresent,theencodingisstraightforwardusingasmany case tagsasneeded,andtheotherwisetagmaybeusedto translatemutuallyexclusive conditions.Withoutguards,determinismmay be introducedin two ways: (i) addingapick activity andthendefining differentmessageswhosearrival in-dicatesthebehaviour to befired, (ii) usingaswitch activity definingcase conditionsinvolving for instancevaluesprovided beforehand,eachconditionfiring apossibleemission.

A choiceamongreceptionswithout guardsis straightforwardlytranslatedwith a pick: whenever a messagecomes,it is receivedonthecorrectport. In presenceof guards,thetranslationis trickier be-causea pick activity cannotbe introducedwithin a case one(this isaBPEL limitation). However, it canbeachievedreversingtherecep-tion andtheguardevaluation.Theresultin BPEL for eachbranchisapick with anonMessage tagprecedinga switch activity usedto testtheconditionandthento executethebehaviour if theguardis true.

A choiceinvolving emissionsandreceptions(without guards)istranslatedinto BPEL usinga pick with oneonMessage tag for eachbranchappearingat the abstractlevel. In caseof an emission,itshouldbedeterminizedbeforehand(asexplainedin thecaseinvolv-ing only emissions),andin caseof receptionit correspondsto ames-sagecoming from a partner. In presenceof guards,we can reusetranslationrulesmentionedbefore:usinga switch for an emission,usingapick andthenaswitchfor a reception.

TheparallelcompositionPAR is usedin two differentcases:(i)it describesa compositionof interactingservices;(ii) it maybeusedinternallyto aserviceto representtwo piecesof behaviour whichhasto be carriedout in different threadswith possibleinteractions.Inboth cases,eachoperandof the parallelcompositionis encodedasoneBPEL servicemeaningthat for thecase(ii), thearchitectureofthewholeis notpreserved.However, it is notaproblembecauseWSsaredefined in a compositionalway, andsuchauxiliary WSscanbe

hiddenfrom anexternal(or user)point of view, or not if onewantsto make themreusable.

Finally, we notethatmany additionalbehavioural constructsexistamongall theexisting PA, which would beusedandencodedafter-wardsinto BPEL. We have alreadystudiedsomeof themandtheirtranslationis not always straightforward, althoughoften tractable.However, it wouldbetoolongto commentall theseconstructsin thispaper.

Data descriptions. Threelevelsof datarepresentationin PA haveto beencodedinto BPEL: typeandoperationdeclarationsDD, localvariabledeclarationsV D, datamanagementin dynamicbehaviours(guardsGRD andparametersof actionsIACT andOACT ). As farasDD datatypedefinitions areconcerned,typesaredescribedusingXML Schemain theWSDL files. Elementsin theSchemaareeithersimple(many built-in typesarealreadydefined,e.g., integer, string,boolean)or morecomplex (e.g., list, set,etc,built usingthecomplex-Type tag).ConsideringLOTOS algebraicspecifications,correspon-denceis simplebecausesuchconstructsaresharedatbothlevels.Weintroducebelow a simpledatatypedefining a productcharacterizedby anidentifier andaquantityin LOTOS

type PRODUCTREQUEST is NATURAL, STRINGsorts ProductRequestopnsconspr (*! constructor *):

String, Nat -> ProductRequestproductId: ProductRequest -> Stringquantity: ProductRequest -> Nat...

endtype

The correspondingdefinition in XML Schemaas appearingin theWSDL file is

<types><schema ...><element name="ProductRequest">

<complexType><sequence>

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

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

</sequence></complexType>

</element>...</schema>

</types>

DD allows to define types but also operationson them. Suchabstractoperationsmay be encodedinto BPEL following differentways.First, they canbe defined within XPath expressions;severalkinds of functionsmay be called at this level suchas core XPathfunctions,BPELXPathfunctionsor customones.XPathexpressionsappearin theassign activity. They simplify theextractionof informa-tion from elementsor thestorageof avalueinto avariable.ComplexdatamanipulationmayalsobewrittenusingXSLT, XQueryor JAVA(e.g., JAVA exec tagsenableoneto insertJavacodeinto BPELcode).Anotherway to describedataoperationsis to usea databaseandad-equatequeriesto accessandmanipulatestoredinformation.

As regardsto dataappearingin behaviours,wegatherononehandIACT andV D becausethey just involvevariables,andontheotherhandOACT andGRD becausethey dealwith dataterms.First ofall, we recall thatactionparametersin PA for emissionsandrecep-tions (IACT andOACT ) aretranslatedusingthe message tag (intheWSDL file). Eachpart tagmatchesaparameterof anaction.

40

BPEL variablesareusedto encodevariablesappearingin IACT

andV D. They aredefined usingthevariable tag (global whende-fined beforetheactivity part)andtheirscopemayberestricted(localdeclarations)usingascope tag.If necessary, localor globalvariablesmaybeinitializedusinganassign aftertheir declaration.

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

</variables>...<sequence>

...<assign name="initialization">

<copy><from expression="0"/><to variable="y"/>

</copy><copy>

<from expression="0"/><to variable="z"/>

</copy></assign>

...</sequence>

Now, regardingtermsappearingin OACT andGRD, an emis-sion send(y) meansthat the dataexpression(e.g., x+z below) hasto be built and assignedto variabley beforesendingusing an as-sign tag, andmorepreciselythe copy tag. As far asGRD is con-cerned,guardsaredefined in BPEL usingthecase tagof theswitchconstruct.For example,theLOTOScode[x<5] -> result!x+z;

... is translatedinto BPELas

<switch> <!-- &lt; means < in BPEL --><case condition="bpws:getVariableData(’x’) &lt; 5"><assign name="result">

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

bpws:getVariableData(’z’)"/><to variable="y"/>

</copy></assign> <reply ... variable="y"/></case></switch>

Weemphasizethatdataarenotavailablein everyprocessalgebra.Sincethey areessentialin BPEL,it seemsconvenientto useaprocessalgebraexpressive enoughto specifydatadescriptions.Otherwise,they aredirectly encodedat theconcretelevel enhancingtheBPELskeletonsobtainedfrom thepurelydynamicdescription.

Processes. As mentionedbefore,abstractprocessesareencodedas BPEL services.A global abstractsystemis describedusing amain behaviour made up of instantiatedprocessescomposedinparallel and synchronizingtogether(they are not obliged to syn-chronizeon all actions).Let us observe that the main specification(P1|P2|...|Pn), (| denotinga parallelcomposition)doesnot matchaBPEL process.Thecorrespondenceis thateachabstractinstantiatedprocess(Pi), belongingto the global systemmentionedpreviously,matchesa BPEL WS. However, thearchitectureof thespecificationis notalwayspreserved.In specific cases(parallelbehaviourswithina process),it might be necessaryto define additionalservices.Thesetof messagesis notdefinedexplicitly in BPEL,but thecorrespon-dencebetweeninteractingservicesis madeexplicit usingthepartnerlink declaringon which partnerlink typeservicesinteract,andtheirrole in thecommunication(seebelow suchan interactiondefinitionbetweenanadderanda requester).

<partnerLinkname="Adder"partnerLinkType="tns:requestResultPartnerLinkType"partnerRole="requestResultAdder"myRole="requestResultRequester"/>

At a lower level, eachabstractprocessis usuallymadeupof threeparts:actiondeclarationsAD, processparametersV D, andits be-haviour BHV (body of the process).AD areencodedusingmes-sages/ operations/ port types/ partnerlink typesin theWSDL fileandvariablesin BPEL. V D correspondsto variablesin BPEL andBHV is encodedusingBPEL activities.For instance,thedefinitionof a processAdder usingtwo actionsrequest andresult, para-meterizedwith variablez is expressedin LOTOSas

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

andit canbetranslatedinto BPELas

<process name="Adder" ...>...<variables><variable name="request"

messageType="tns:requestMessage"/>...<variable name="z" type="xsd:int"/>

</variables><sequence name="main">...

</sequence></process>

Instantiations of processes areencodedinto BPELasanexchangeof messageswith the new processto be instantiated.In BPEL, in-stantiationsalways occur througha reception(a receive or a pickactivity).

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

or

<pick createInstance="yes"><onMessage ...> ...

In practicalapplications,suchinstantiationsareoften customersfilling in forms on-line, and thus requestingsomeserviceson theweb.

Theregularway to encodePA recursive process calls is relatedtothenotionof transaction. A transactioncouldbe defined asa com-pleteexecutionof a groupof interactingWSsworking out a precisetask.In this context, oneexecutionof a processis enough,thereforeabstractrecursive behaviours areencodedasnon recursive services(eachtransactioncorrespondsto a new invocationtheninstantiationof eachinvolvedservice).Suchanencodingis illustratedin Section5. In thecaseof anabstractchoiceamongdifferentbehaviours,someof themendingwith recursivecallsandotheronesendingwith exits,the while activity may be used.The conditionof the while is com-putedfrom guardsof behaviours endingwith exits (conjunctionofguardnegations).

5 Application: a StockManagementSystem

Many servicesinvolvedin e-businessapplicationsmaybedevelopedfollowing our approach:auction bargaining, on-line sales(books,CDs,DVDs, flowers,etc), bankingsystems(own accountmanage-mentfor instance),trip organizations,(car)renting,requestengines,(hotel,show, etc)reservations,any kindof on-linepayment,etc.Such

41

a formal-baseddevelopmentis of interestto save time(thenmoney),thento respectdeadlines,andto favour thecorrectnessof theresult.

In thissection,ourgoalis to focusonanexampleandto show howfollowing our approach(analysis,specification,verification, encod-ing, runningcode)we candesignanddevelopexecutableWSs.Thecomprehensive specificationwritten in LOTOS and all the WSDLandBPELfiles encodedfor thisexampleareavailableon-lineat thisURL (demo40):

http://www.inrialpes.fr/vasy/cadp/demos.html

5.1 Inf ormal requirementsand analysis

For the sake of comprehension,we choosea simple problem.Letus imaginethat a chainof supermarkets (called local storesin thefollowing) have to be suppliedwith goods(or products)every day(or assoonasneeded,it dependson thelocalpolicy). All theneededgoodsarecentralizedin acentralstorewhoserole is to supplyall thelocal storeswhenthey requestsomething.This centralstorehastobe suppliedaswell by suppliersparticularlydedicatedto a specificproduct(e.g., vegetablesor cold food).

Our goal hereinis to develop the web servicecorrespondingtothecentralstoreassumingtheexistenceof servicesdescribinglocalstoresand suppliers.It is obvious that many local storesand sup-plierscaninteractwith onecentralstore(even if afterwardsseveralinstancesof centralstorescouldbecreated).

Local storesandsuppliersareviewed throughtheir public inter-facesthatweassumerepresentedusingasimplebehaviouraldescrip-tion. It is out of scopehereto introducean adequatelanguageforinterfacedescription.In thissection,we introducethemusingtransi-tion systemswith parameterizedactions.A local store(Fig. 2) sendsa request(an identifier id anda quantityqt) to acquirea certainamountof a product,andwaitsfor anacceptanceor a refusal.Simi-larly, asupplierreceivesarequestandrepliesdependingonits abilityto satisfytherequest.

okS

requestS?id?qt

nok

ok

request!id!qt

nokS

Local store Supplier

Figure2. Behavioural interfaces:local storeandsupplier

A centralstoremayreceive requestsfrom local storesandrepliesdependingon theavailability of thatproductin its stock.It alsohasto supply its stockand thenshouldrequestpossiblemissingprod-uctsto a supplierwhich answersdependingon its ability to satisfytherequest.As a simplified version,stockscanbeviewedassetsofcouples,eachcouplecontaininga productidentifier anda quantity.A pictorial representationof all the interactingservicesis given inFigure3.

5.2 Specification and validation

LOTOSis appropriateto describeabstractlythesystemparticularlythanksto its expressiveness(dataand behaviours) and its toolbox

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

Figure3. Overview of theservice-to-beandits mates

CADPis helpful to validatespecifications.Westartwith thedescrip-tion of thedatapart.We representa stockasa setof couples(id,qt)with two constructors(empty andadd) to build it. Someoperationsallow to accessandupdateastock,suchastheincrease operationwhich incrementsthequantityof aproduct.

type STOCK is NATURAL, BOOLEANsorts Stockopns empty (*! constructor *) : -> Stock

add (*! constructor *) :Nat, Nat, Stock -> Stock

increase : Nat, Nat, Stock -> Stock...

From the local storeandsupplierautomatadescribingtheir pub-lic interfaces,LOTOSspecificationsareeasilygeneratedmakingthereasoningstepspossible.For thelackof space,herewefocusonly onthecentralstoreprocess.This processhastwo possiblebehaviours:(i) it receivesa requestfrom a local storeand it repliesdependingon the availability of the requiredquantity in the stock,(ii) in caseof theexistencein thestockof a productwhosequantityis lessthana threshold(to bedefined arbitrarily), a request(the identifier andaquantity, let us say5 for example)is sentto a supplieranda replyreceived.Thestockis updatedin caseof deliveryor restockingusingadequateoperations(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))

)

42

endproc

To validatethis new service,severalverification stepscanbeper-formedusingCADPto ensureacorrectprocessingof theinteractingprocesses.Severalmistakesin thespecificationhave beenfoundout(in the design,in the interactionflows, in the datadescriptionandmanagement).Simulationhashelpedto clarify misunderstandingsintheanalysisof theproblemathand.Proofswereverified usingEVAL-UATOR [19] (anon-the-flymodelchecker partof CADP) which canbe usedto ensuresafety, livenessandfairnesspropertieswritten inµ-calculus.Dueto thesimplicity of theproblemathand,weparticu-larly checktheabsenceof deadlock,andlivenesspropertiesensuringfor examplethat the firing of everyrequest gate (also checkedwith requestS) is eitherfollowedby anacceptanceor a refusal.

[true* . "request!*"] <("ok" or "nok")> true

5.3 Translation into BPEL

In this subsection,our goal is to emphasizehow previousguidelinesareusedto encodeabstractprocesseswritten in LOTOShereinintoBPEL. We explain this translationthrougha sampleof the BPELcodeimplementedfor thecentralstore.

Developmentenvir onment.TheDevelopmentwascarriedoutus-ing OracleBPEL ProcessManager2.0, BPEL Console,BPEL De-signer[1]. The processmanagerprovides an infrastructurefor de-ploying, executingand managingBPEL processes.The consoleisuseful to test the deployed BPEL services.The designermakes itpossibleto build BPEL codefrom a developer-friendly visual tool,andto validateandpackBPEL processes.Datahave beendescribedusinga Microsoft Accessrelationaldatabase(it is obvious that anyDBMS couldbeusedat this level). Thepackagejava.sql washelp-ful to accessthe databaseandthe driver JDBC-ODBCto make theconnectionbetweenJava classesandthe database.We usethe Javaexec activity to insertJavacodeinto BPELcodesoasto call theJavamethodsdefinedto accessandupdatethedatabase.

Following the guidelines.Let usfocusonthefirst half of thecen-tral store(theinteractionwith thelocalstore)wespecifiedpreviouslyin LOTOS.We overview how theconstructsinvolved in this behav-iour areexpressedin BPEL. Firstly, LOTOS emissionsand recep-tions(gates,variablesandtypes)areencodedin theWSDL file. Notethat the ok andnok actionshave beenencodedinto BPEL usingthe samenameof messagebut both branchesaredistinguishedbythevalueof its Booleanparameter(true in caseof availability, falseotherwise).

Eachstockis encodedasasimpletablewith two fields (identifier,quantity).A Java classhasbeenencodedandcontainsmethodstoaccessandupdatecorrectlyeachdatabase(usingSQL queries),e.g.,to testtheavailability of aproduct.Wehighlight thatthecentralstorehandlesonerequestafter theother. Thereby, it possiblyupdatesthedatabaseattheendof eachtransactionandconcurrentaccessesto thebasearethendiscarded.

TheLOTOSsequenceis directly translatedusingthesequence ac-tivity. Thereceptionandtheemissionin this partof thecentralstoreare translatedas a pick activity with one onMessage tag followedby a reply. Thechoiceis composedof two brancheswith guardsandemissions(withoutparameters),consequentlyaswitch activity is em-ployedto translatethisLOTOSbehaviour, andeachbranchis imple-mentedusingacase activity with guardscorrespondingto queriesonthedatabase.

Recursive calls areencodedasexits into the BPEL code.In thecaseat hand,we introducethe transactionnotion correspondingtoa requestpostedby a local storeand to a reply dependingon theavailability of theproductin thedatabase.Thus,suchatransactionisinstantiatedevery time thata new requestis received.In theLOTOSspecification,recursive callsareaccompaniedof stockupdates.Thisis donein BPELupdatingthedatabasebeforetheservicecompletes.

Sampleof BPEL. Our goal in this part is to introducetheskele-ton of the BPEL codedescribinginteractionsbetweenthe centralstoreandthelocal store.Thecentralstoreservicewasimplementedthrougha BPEL service,its WSDL interface,a databaseanda Javaclasscontainingthe usefulmethodsto interactwith the databases.Forexperimentationpurposes,someotherserviceswereencoded(lo-cal storesandsuppliers)usingthesametechnologies.

<sequence name="main"><pick createInstance="yes"><onMessage partnerLink="LocalStore"

portType="tns:CentralStore"operation="requestProduct"variable="productRequest">

<!-- invocation from the LocalStore --><sequence>...<!-- verifying the availability of the product --><bpelx:exec language="java" version="1.4"><![CDATA[...//open the connection with the databaseDBConnection 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><!-- send the response to the LocalStore --><reply name="response"

partnerLink="LocalStore"portType="tns:CentralStore"operation="requestProduct"variable="productResponse"/>

<!-- if the order is accepted --><!-- we update the stock -->...

</sequence></case><otherwise><sequence><!-- state the response to false -->...<!-- send the response to the LocalStore --><reply .../></sequence>

43

</otherwise></switch>

</sequence></onMessage>...</sequence>

ImplementingWSsin BPEL usingall thenecessarytechnologies(Java, databases,BPEL ProcessManager)is not so simple.Never-theless,with a minimumknowledgeof suchtechnologies,WSscanbe implementedanddeployedeasilyandratherquickly (dependingof courseon thesizeof theapplication)following ourapproach.

6 Concluding Remarks

Developmentof webservicesdistributedonthewebis arecentissueandtheneedof formal approachesto ensurea smoothandvalidatedprocessis obvious for many e-businessapplications.In this paper,weadvocatedsuchanapproachstartingfrom simpleandabstractde-scriptionsof processesandendingwith executablewebservicesim-plementedin BPEL.Thetwo maincontributionsof our proposalarefirst a simplified developmentthanksto guidelinesenablingonetoencodeabstractprocessesinto executableones.Secondly, validationstepsaremadepossiblethroughthe useof formal reasoningtools,which usuallyaccompany processalgebra,therebyenablingonetodetectpossibleerrorsandflawsatanearlystage.

In comparisonwith somerelatedworks [11, 22, 10, 21] dealingwith mappingsbetweenabstractandconcretedescriptionsof WSs,we do not arguefor a reverseengineeringdirectionfor themappingbut we proposea methodto developWSs.A judiciouschoiceof ourabstractlanguage(e.g. LOTOS)makesthespecificationof advanceddatadescriptionsandoperationsonthempossibleattheabstractlevel(morecomplex thanin [11] whereoperationscannotbemodelledasanexample)aswell asattheexecutableone.Ourmethodwasusedtodevelopanddeploy runningWSs,consequentlyit hasnot remainedataconceptuallevel asit is mostof thetime thecase.

We emphasizethat a formal encoding(preservingsemanticsbe-tweenboth levels) is not achieved yet sinceBPEL doesnot havea widely acceptedformal semantics.Theproposedencodingmakesit possibleto obtain running BPEL processesfrom abstractspeci-fications. However, tricks and choiceimplementationsare needed,due to the limitations of BPEL as executablelanguage,especiallyregardingtheway interactionsamongprocessesaremanaged,or ac-tivities combined.BPEL, like many otherwebserviceprogramminglanguages,facilitatesthedevelopmentof servicesthatengagein con-currentinteractions.Anyway, aspointedout in [8], it fails to addressmorecomplex scenariosthatgobeyondsimplesequencesof requestsandresponsesor thatinvolve many participants.In particular, BPELcannotdealwith one-to-many interactionswith partialsynchroniza-tion amongthe partnerservices,especiallywhentheseservicesarenotknown in advance.As regardstheseBPEL limitations,wewouldlike to applyour approachto anothertarget languagesuchasGPSL[8] whichseemsmoresuitableto theimplementationof services.

Acknowledgments. The authors thank Lucas Bordeaux andMarcoSchaerffor judiciouscommentsthey madeonthiswork. Thiswork is partially supportedby ProjectASTRO fundedby theItalianMinistry for Researchunderthe FIRB framework (funds for basicresearch).

REFERENCES[1] Oracle BPEL Process Manager 2.0.

Availableathttp://www.oracle.com/technology/products/ias/bpel/.

[2] D. Berardi,D. Calvanese,G. De Giacomo,M. Lenzerini,andM. Me-cella,‘AutomaticCompositionof E-servicesThatExportTheirBehav-ior’, in Proc. of ICSOC’03, volume2910of LNCS, pp. 43–58, Italy,(2003).Springer-Verlag.

[3] Handbook of Process Algebra, eds.,J.A. Bergstra,A. Ponse,andS.A.Smolka,Elsevier, 2001.

[4] L. Bordeaux,G. Salaun, D. Berardi,andM. Mecella,‘When aretwoWebServicesCompatible?’,in Proc. of TES’04, ed.,M.-C. Shanetal.,volume3324of LNCS, pp.15–28,Canada,(2004).Springer-Verlag.

[5] M. ButlerandC. Ferreira,‘An OperationalSemanticsfor StAC, aLan-guagefor ModellingLong-RunningBusinessTransactions’,in Proc. ofCOORDINATION’04, volume2949of LNCS, pp.87–104,Italy, (2004).Springer-Verlag.

[6] A. Chirichiello and G. Salaun, ‘Encoding AbstractDescriptionsintoExecutableWeb Services:Towardsa Formal Development.’,in WebIntelligence 2005 (WI’05), eds.,A. Skowron, R. Agrawal, M. Luck,T. Yamaguchi,P. Morizet-Mahoudeaux,J.Liu, andN. Zhong,pp.457–463.IEEEComputerSociety, (2005).

[7] E. M. Clarke, O. Grumberg, andD. Peled,Model Checking, TheMITPress,2000.

[8] D. Cooney, M. Dumas,andP. Roe,‘GPSL: A ProgrammingLanguagefor ServiceImplementation.’,in FASE’06, eds.,L. andR. Heckel, vol-ume3922of LNCS, pp.3–17.Springer, (2006).

[9] H. Ehrig and B. Mahr, Fundamentals of Algebraic Specification 1:Equations and Initial Semantics, volume6 of EATCS Monographs onTheoretical Computer Science, Springer-Verlag,New-York, 1985.

[10] H. Foster, S.Uchitel, J.Magee,andJ.Kramer, ‘Model-basedVerifica-tion of WebServiceCompositions’,in Proc. of ASE’03, pp. 152–163,Canada,(2003).IEEEComputerSocietyPress.

[11] X. Fu, T. Bultan, andJ. Su, ‘Analysisof InteractingBPEL Web Ser-vices’, in Proc. of WWW’04, USA, (2004).ACM Press.

[12] H. Garavel, F. Lang,andR. Mateescu,‘An Overview of CADP 2001’,EASST Newsletter, 4, 13–24,(2001). Also availableasINRIA Techni-calReportRT-0254.

[13] R. HamadiandB. Benatallah,‘A PetriNet-basedModel for WebSer-vice Composition’,in Proc. of ADC’03, volume 17 of CRPIT, Aus-tralia, (2003).AustralianComputerSociety.

[14] J. Harrison, ‘Verification: Industrial Applications’. Lecture at 2003Marktoberdorf Summer School, USA.

[15] G. Holzmann,The SPIN Model-Checker: Primer and Reference Man-ual, Addison-Wesley, 2003.

[16] R. Hull, M. Benedikt,V. Christophides,andJ.Su,‘E-Services:a LookBehind the Curtain’, in Proc. of PODS’03, pp. 1–14, USA, (2003).ACM Press.

[17] A. Lazovik, M. Aiello, andM. P. Papazoglou,‘PlanningandMonitor-ing the Executionof Web ServiceRequests’,in Proc. of ICSOC’03,volume2910of LNCS, pp.335–350,Italy, (2003).Springer-Verlag.

[18] Z. Mannaand A. Pnueli,Temporal Verification of Reactive Systems:Safety, Springer, 1995.

[19] R.MateescuandM. Sighireanu,‘Efficient On-the-FlyModel-Checkingfor RegularAlternation-FreeMu-Calculus’,Science of Computer Pro-gramming, 46(3), 255–281,(2003).

[20] R. Milner, Communication and Concurrency, InternationalSeriesinComputerScience,PrenticeHall, 1989.

[21] S. NarayananandS. McIlraith, ‘AnalysisandSimulationof WebSer-vices’,Computer Networks, 42(5), 675–693,(2003).

[22] M. Pistore,M. Roveri, andP. Busetta,‘Requirements-DrivenVerifica-tion of WebServices’,in Proc. of WS-FM’04, volume105of ENTCS,pp.95–108,Italy, (2004).

[23] G.Salaun,L. Bordeaux,andM. Schaerf,‘DescribingandReasoningonWebServicesusingProcessAlgebra’, in Proc. of ICWS’04, pp.43–51,SanDiego,USA, (2004).IEEEComputerSocietyPress.

[24] G. Salaun, A. Ferrara,andA. Chirichiello, ‘NegotiationamongWebServicesusingLOTOS/CADP’, in Proc. of ECOWS’04, volume3250of LNCS, pp.198–212,Germany, (2004).Springer-Verlag.

[25] R. J. vanGlabbeekandW. P. Weijland,‘BranchingTime andAbstrac-tion in BisimulationSemantics’,Journal of the ACM, 43(3), 555–600,(1996).

[26] W3C,Web Services Choreography Description Language Version 1.0.Availableathttp://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/.

44

Implicit vs.Explicit Data-Flow Requir ementsin WebServiceCompositionGoalsAnnapaolaMar coni1 and Mar coPistore2 and PaoloTraverso3

Abstract. While several approaches to the automated compositionof Web services have been proposed in the literature, so far very fewof them take into account a key aspect of the composition problem:how to specify data-flowrequirements, i.e. requirements on data thatare exchanged among component services.

In this paper we present two different ways to specify compositionrequirements on exchanged data. Implicit data-flowrequirementsarea set of rules that specify how the functions computed by the com-ponent services are to be combined by the composite service. Theyimplicitly define the required constraints among exchanged data.Ex-plicit data-flowrequirementsare a set of explicit specifications onhow the composition should manipulate messages and route themfrom/to components. We integrate the two specification languageswithin a state of the art framework for the automated synthesis ofcompositions. We compare them through an experimental evaluation,both from the point of view of efficienc y and scalability as well asfrom that of practical usability.

Keywords: Web Service Composition Requirements, ModelingLanguages, Automated Planning

1 Intr oduction

Service composition is one of the fundamental ideas underlying Webservices and service oriented applications: composed services per-form new functionalities by interacting with component services thatare available, e.g., on the Web. The automated synthesis of composedservices is one of the key tasks that can significantly support the de-sign and development of service oriented applications.

Several methods have been proposed to cope with the automatedsynthesis of composed services (see, e.g., [7, 8, 4, 2, 11, 10]). Inthese approaches, given a set of available component services, com-position requirements specify the desired behaviors that should beenforced on the component services, and the composition task corre-sponds to the synthesis of a composition, e.g., a new service, or a setof constraints on the behaviors of existing services, that realizes thedesired behavior.

However, most of the approaches that have been proposed so fardo not take into account a key aspect of the composition problem: thespecification ofdata-flowrequirements, i.e. requirements on data thatare exchanged among component services. This is a significant andchallenging problem, since, in real life scenarios, business analystsand developers need a way to express complex requirements on theexchanged data. Moreover, to make the automated composition aneffective and practical task, the requirements specification should beeasy to write and to understand for the analyst. Surprisingly, verylittle effort has been devoted in the literature to address this problem.

In this paper we present and discuss two different approaches ad-dressing the problem of specifying and using composition data flow

1 ITC-irst, Trento, Italy, email: marconi@itc.it2 University of Trento, Italy, email: pistore@dit.unitn.it3 ITC-irst, Trento - Italy, email: traverso@itc.it

requirements. Implicit data-flowrequirements, see, e.g., [10], are aset of rules that specify how to combine the functions computed bythe component services to transform incoming messages into outgo-ing messages. A composition goal contains references to such rulesand functions. They implicitly define the required constraints amongexchanged data. Consider, for instance, a virtual travel agency thatcomposes two component services, a flight and a hotel reservationservice. An implicit data flow requirement for the composition canstate that the price of the offer to the customer should be computedon the basis of the costs of the hotel and of the flight. The costin the offer can be specified formally as a function that composestwo components’ cost functions in some desired way. This require-ment implicitly specifies a data flow from the (flightand hotel) mes-sages of the components to the composed service, the agency service.The composition task should determine from this specification whichmessages and which data should be sent from a service to another.

Explicit data-flowrequirementsare a set of explicit specificationson how the composition should manipulate messages and route themfrom/to components. The composition goal consists in a set of con-straints that directly and explicitly define the valid routings and ma-nipulations of messages that the composition can perform. Theseconstraints can be described in a graphical way, e.g., as data-nets[6]. A data net is a graph where the input/output ports of the exist-ing services are modeled as nodes, the paths in the graph defin e thepossible routes of the messages, and the arcs define basic manipula-tions of these messages performed by the orchestrator. For instance,an explicit data flow requirement for a virtual travel agency is thatthe hotel service output message with the data about the cost of theflightas well as the flightoutput message with the data for the costof the hotel should be input to the composed virtual travel agency.

In this paper, we present the two approaches, show how they canbe used to specify data-flow requirements within a state-of-the-artautomated composition framework [11, 12, 10] and finally comparethem wrt their efficienc y and usability.

The rest of the document is organized as follows. In Section 2we describe the problem of web service composition and we illus-trate the necessity to define complex data flow requirements. In Sec-tion 3 we brieflyrecall both explicit and implicit data-flow require-ments modeling approaches. In Section 4 we discuss how they canbe integrated in the automated composition framework proposed in[11, 12, 10]. In Section 5 we compare the two proposed approaches.Finally, Section 5 concludes the paper with related work and finalremarks.

2 WebServiceComposition: The P&S Scenario

With automated composition of Web Services we mean the genera-tion of a new composite service that interacts with a set of existingcomponent services in order to achieve given composition require-ments. We assume that the component services are described througha complex interaction protocol defined in BPEL4WS (Business Pro-cess Execution Language for Web Services) [1], even if the described

45

PRODUCER SERVICE

!offer(cost, size, delay)

! not_avail

NOT_AVAIL

? request(item)

? nack ? ack

SUCC

SHIPPER SERVICE

CANCELED

START

cost := costOf(item)size := sizeOf(item)

delay := delayOf(item)

!offer(cost, delay)

! not_avail

NOT_AVAIL

? request(size, location)

? nack ? ack

SUCCCANCELED

START

cost := costOf(size, location)

delay := delayOf(size, location)

CUSTOMER SERVICE

? offer(cost, delay) ? not_avail

NOT_AVAIL

? request(item, location)

? nack ? ack

SUCCCANCELED

START

Figure1. The PurchaseandShipcomponent services

approach does not depend on the specific aspects of the BPEL4WS

language.BPEL4WS is an industrial language for the specification and ex-

ecution of business processes made available through Web services.BPEL4WS provides an operational description of the (stateful) behav-ior of web services on top of the service interfaces defined in theirWSDL specifications. ABPEL4WS description identifies the partnersof a service, its internal variables (together with their type specifica-tion), and the operations that are triggered upon the invocation of theservice by some of the partners. Operations include assigning vari-ables (possibly using internal functions), invoking other services andreceiving responses, forking parallel threads of execution, and non-deterministically picking one amongst different courses of actions.Standard imperative constructs such as if-then-else, case choices, andloops, are also supported.

In this section we illustrate the problem of automated compositionof Web services on the Purchase and Ship case study introduced in[11, 10]. We will focus in particular on the problem of specifying therequirements of such a composition.

Example1 (Purchaseand Ship) The Purchase and Ship (P&Sfromnowon)exampleconsistsin providinga furniturepurchaseandship service by combiningtwo independent existing services, a fur-nitureproducerProducer anda deliveryserviceShipper. Thisway,theCustomer, alsodescribedasa service, maydirectlyaskthecom-positeserviceP&S to purchasea givenitemanddeliverit at a givenplace(for simplicity, weassumethat theshipmentorigin is fixed andleaveit implicit).

Theinteractionswith theexistingserviceshaveto follow specificprotocols.For instance, theinteractionswith theShipper start witha requestfor transportinga productof a givensizeto a given lo-cation. This might not be possible, in which casethe requesterisnotified, and theprotocol terminateswith failure. Otherwise, a costanddeliverytimeare computedandsentback to therequester. ThentheShipper waits for either an acceptanceor a refusalof theofferfrom the invoker. In the former case, a delivery contract has beendefinedandtheprotocolterminateswith success,while it terminateswith failure in the latter case. Similar protocolsare defined alsoforProducer andCustomer. Figure 1 showsthe interaction protocolsof thecomponentservices.

A typical interactioncouldbeasfollows:

1. theCustomer asksP&S for an item i that hewantsto be trans-portedat locationl;

2. P&S askstheProducer for thesize, thecost,andhowmuch timedoesit take to producetheitemi;

3. P&S askstheShipper for theprice andtimeneededto transportanobjectof such a sizeto l;

4. P&S sendsthe Customer an offer which takesinto accounttheoverall cost(plusan addedcostfor P&S) andtimeto achieveitsgoal;

5. the Customer sendsa confirmation of the order, which is dis-patchedbyP&S to Shipper andProducer.

This is however only thenormalcase, andother interactionsshouldbe considered,e.g., for the casesthe producerand/or deliveryser-vicesare not able to satisfytherequest,or theuserrefuses thefinaloffer. Figure2 showsa possibleimplementationof theP&S compos-ite servicehandlingall thepossiblecomponentserviceinteractions4.

PURCHASE&SHIP SERVICE

!P.request(item)

? C.request(item, location)

? P.not_avail !P.offer(prod_cost, size, prod_delay)

! C.not_avail ? S.request(size, location)

? S.not_avail !S.offer(ship_cost, ship_delay)

! C.not_avail

! P.nackcost := addCost(prod_cost, ship_cost)

delay := addDelay(prod_delay, ship_delay)

! C.offer(cost, delay)

? C.nack ? C.ack

! P.nack

! S.nack

! P.ack

! S.ack

Figure2. The PurchaseandShipcomposite service

Given the description of the component services and of the cus-tomer interface, the next step towards the definition of the automated

4 In Figure 2 and in all presented examples, we shorten Customer with C,Producer with P, and Shipper with S.

46

composition domain is the formal specification of the compositionrequirements. As we will see from the examples presented in the restof this section, even for simple case studies we need a way to expressrequirements that define complex conditions, both for what concernsthe control flow and for the data exchanged among the componentservices.

Example2 (Control-flow requirements) TheP&S hasthegoal to“sellhome-delivered furniture” . Thismeansthat wewantto reach asituationwhere thecustomerhasconfirmedanorderandtheservicehasconfirmedthecorrespondingsub-ordersto producerandshipper.However, it maybethecasethat there are no availableitems(or noavailableshipments)satisfyingthecustomerrequest,or that thecus-tomerdoesn’t like theproposedoffer and thusrefusesit. We cannotavoidthesesituations,thereforewecannotaskthecompositeserviceto guaranteethis requirement.Moreover, in casethis requirementcannotbe satisfied, we do not want theP&S to order an item (nora shipment)withoutbeingsure that our customeracceptedtheoffer,aswell aswedo not wantdispleasedcustomers that haveconfirmedorders which will neverbefulfilled. Thus,our global terminationre-quirementwouldbesomethinglike: do whatever is possibleto ”sellhome-delivered furniture” and if somethinggoeswrong guaranteethat thereare ”nosinglecommit”.

Modeling composition requirements requires to express recoveryconditions and preferences among subgoals (’mandatory’ and ’de-sired’). In previous works [11, 12, 10], we have proposed to modelcontrol-flow requirements exploiting the E AGLE specification lan-guage [3]. EAGLE is a temporal logics with preferences: its operatorsare similar to CTL operators, but their semantics, formally defined in[3], takes into account the notion of preference and the handling offailure when subgoals cannot be achieved. An example of an EAGLE

requirement is given in the following example.

Example3 The EAGLE formalizationof the control-flow require-mentsin Example2 is thefollowing.

TryReach

C.SUCC ∧ S.SUCC ∧ P.SUCCFail DoReach

(C.NOT AVAIL ∨ C.CANCELED) ∧

(P.NOT AVAIL ∨ P.CANCELED) ∧

(S.START ∨ S.NOT AVAIL ∨ S.CANCELED)

Thegoal is of theform “ TryReach c Fail DoReach d”. TryReach c

requires a servicethat tries to reach condition c, in our casethecondition“sell home-delivered furniture”. During theexecutionofthe service, a statemaybe reachedfrom which it is not possibletoreach c, e.g., sincethe item is not available. Whensuch a stateisreached,the requirementTryReach c fails and the recovery condi-tion DoReach d, in our case“no single commit”, is considered.

To express the desired properties of the service to synthesize, thecontrol-flow requirement of Examples 2 and 3 has to be completedwith requirements on the data flow.

Example4 (Data-flow requirements) In order to provide consis-tent information,the P&S serviceneedsto exchange data with thecomponentsand its customerin an appropriate way. For instance,wheninvokingtheProducer service, theinformation abouttheitemmustbethesameonethat theP&S receivedin thecustomerrequest.Similarly, theinformationsentto theShipper serviceabouttheloca-tion mustbe that obtainedfromthecustomer, while the informationaboutthelocation mustbethat receivedfromtheProducer service.

Moreover, thecostproposedto thecustomermustbethesumof thecostsofferedbytheProducer andbytheShipper servicesplussomeadditional feefor theP&S service. Similarly for thecomputationofthedelayof theP&S.

The example shows that, even for naive composition problems, weneed a way to express different forms of data flow requirements: fromsimple data links between incoming and outgoing message parts(e.g., forwarding the information received by the customer about thelocation to the Shipper service), to the specification of complex datamanipulation (e.g., when computing the overall service cost).

3 Modeling Data Flow Requirements

In this section we present two different approaches, implicit vs ex-plicit, to the specification of data-flow requirements. The former ex-ploits the knowledge level model for web services presented in [10],while the latter uses the data-flow requirements modeling languageproposed in [6].

3.1 Implicit Data Flow Requirements:KnowledgeBase

The specification of the data-flow requirements within the knowledgelevel composition approach [10] exploits the semantic annotations inthe abstract process descriptions of the component services. Such an-notations specify how incoming messages are manipulated within thecomponent service (by means of internal functions and assignments)to obtain outgoing messages. For instance, in the Shipper serviceprotocol of Figure 1, the semantic annotation cost := costOf(size,location) models the fact that the Shipper obtains the cost of theshipment by means of its internal function costOf applied on thesize and location information received in the customer request.

In the following example we show how the specification of theimplicit data-flow requirements exploits the functions of the compo-nent services and uses additional functions specifying how the datacomputed by the components need to be combined in the compositeservice.

Example5 (Implicit data flow requirements) A possible specifi-cation of the data-flowcompositionrequirementsin Example4 isthefollowing:

C.cost =

addCost(P.costOf(C.item),S.costOf(P.sizeOf(C.item), C.location)) ∧

C.delay =

addDelay(P.costOf(C.item),S.costOf(P.sizeOf(C.item)), C.location))

Thegoaldeclaresthat theofferedcostmustbeobtainedbyapplyingthe function addCost to the costsoffered by the producerand theshipper(andsimilarly for theoffereddelay).

Within this approach the data-flow requirements specify how themessages to be sent must be obtained by composing functions of thecomponent services and of the new composite service. These require-ments implicitly constrain the message exchanges that must occurwith the component services and the internal data manipulation thatthe composite service must perform.

Given a data-flow composition goal, we automatically generateits knowledge level representation. This declares what the compositeservice must know and how goal variables and functions must berelated with the variables and functions of the component services.

47

In [10] we formally defined the knowledge level model in terms of asuitable knowledge base (from now on KB), of which we recall herethe definition.

Definition 1 (KnowledgeBase)A knowledgebaseKB is a setof propositionsof thefollowing form:

• KV (x) wherex is a variablewith anabstract type;• K(x = v) where x is an enumerativevariableandv is oneof its

possiblevalues;• K(x = y) wherex andy are twovariableswith thesametype;• K(x = f(y1, . . . , yn)) where x, y1, . . . , yn are variableswith

an abstract typeandf is a functioncompatiblewith the typesofx, y1, . . . , yn.

With K(p) we mean that we know that proposition p is true and withKV (x) that we know the value of the variable x.

Example6 To obtain the knowledge level data-flowrequirements,weflattenthefunctionsintroducingauxiliary variablesuntil onlyba-sicpropositionsare left:

C.cost = goal.added cost ∧C.delay = goal.added delay ∧

goal.added cost = addCost(goal.prod cost, goal.ship cost) ∧goal.added delay = addDelay(goal.prod delay, goal.ship delay) ∧goal.prod cost = P.costOf(goal.user art) ∧goal.ship cost = S.costOf(goal.prod size, goal.user art) ∧goal.prod delay = P.delayOf(goal.user art) ∧goal.ship delay = S.delayOf(goal.prod size, goal.user art) ∧goal.user art = C.item ∧

goal.prod size = P.sizeOf(goal.user art) ∧goal.user loc = C.location

From this flattened goal we can extract the goal variables:goal.added cost, goal.added delay, goal.prod cost, goal.prod delay,goal.ship cost, goal.ship delay, goal.prod size, goal.user art, andgoal.user loc; and the goal functionsgoal.addCost(Cost, Cost):Costandgoal.addDelay(Time, Time):Time.

Thegoalcanthenbeautomaticallytranslatedinto its correspond-ing knowledge levelgoal:

K(C.cost = goal.added cost)∧K(C.delay = goal.added delay)∧K(goal.added cost = goal.addCost(goal.prod cost, goal.ship cost))∧K(goal.added delay = goal.addDelay(goal.prod delay, goal.ship delay))∧K(goal.prod cost = P.costOf(goal.user art))∧K(goal.ship cost = S.costOf(goal.prod size, goal.user art))∧K(goal.prod delay = P.delayOf(goal.user art))∧K(goal.ship delay = S.delayOf(goal.prod size, goal.user art))∧K(goal.user art = C.item)∧K(goal.prod size = P.sizeOf(goal.user art))∧K(goal.user loc = C.location)

The knowledge-level representation of the data-flow compositionrequirements defines therefore a knowledge base, that we call theknowledge baseof the goal. Intuitively, this knowledge base spec-ifies what the new composite service must know at the end of itsexecution.

3.2 Explicit Data Flow Requirements:Data Net

The aim of the data flow modeling language presented in [6] is toallow the specification of complex requirements concerning data ma-nipulation and exchange. In particular, data flow requirements spec-ify explicitly how output messages (messages sent to component ser-vices) must be obtained from input messages (messages received

from component services). This includes several important aspects:whether an input message can be used several times or just once, howseveral input messages must be combined to obtain an output mes-sage, whether all messages received must be processed and sent ornot, etc..

In the following we will brieflydescribe the basic elements of thelanguage, show how they can be composed to obtain complex ex-pressions and provide an intuitive semantics (for further details see[6]).

• ConnectionNode������������������

A connectionnodecan be external or internal. An external con-nection node is associated to an output (or an input) external port.Intuitively, an external input (output) node characterizes an exter-nal source (target) of data and it is used to exchange data with theoutside world.

• IdentityIt is connected to one connection node in input and one node inoutput. It forwards data received from the input node to the outputnode. The graphical notation for the data-flow identity elementid(a)(b), with input node a and output node b, is the following:

a b!

• OperationIt is related to a function definition, is connected to as many in-put nodes as the number of function parameters and only to oneoutput node corresponding to the function result. When it receivesdata from all the input nodes, it computes the result and forwardsit to the output channel. The graphical notation for the data-flowoperation element oper[f](a,b)(c) characterizing function f, withinput nodes a and b and output node c, is the following:

������������

��������

��

�����������

����������� � � � � � f c

a

b

• ForkIt is connected to a node in input and to as many nodes as neces-sary in output. It forwards data received on the input node to allthe output nodes. The graphical notation for the data-flow fork el-ement fork(a)(b,c), with input node a and output nodes b and c,is the following:

b

ca

• MergeIt is connected to one node in output and as many nodes as neces-sary in input. It forwards data received on some input node to theoutput node. It preserves the temporal order of data arriving oninput nodes (if it receives data on two or more input nodes at thesame time, the order is nondeterministic). We represent the data-flow merge element merge(a,b)(c), with input nodes a and b andoutput node c as:

������������

����

��������

b

ca

• ClonerIt is connected to one node in input and one node in output. Itforwards, one or more times, data received from the input node tothe output node. The data-flow cloner element clone(a)(b), withinput node a and output node b is represented as:

48

+a b

• FilterIt is connected to one node in input and one node in output. Whenit receives data on the input node it either forwards it to the out-put node or discards it. We represent the data-flow filter elementfilt(a)(b), having input node a and output node b as:

a b

?

The diagram obtained by suitably composing data-flow elementsby means of connection nodes is called data net (see Figure 3). Adata net is characterized by a set of external connection nodes associ-ated to input ports NI

ext, a set of external connection nodes associatedto output ports NO

ext, a set of internal connection nodes Nint, a set ofdata-flow elements D and a set of data values V . Given a data-flowelement d we denote with in nodes(d) the set of input connectionnodes of d and with out nodes(d) the set of output connection nodesof d.

Definition 2 (Data Net)A data net D is a tuple〈NI

ext, NOext, Nint, D, V 〉 where:

• for each n ∈ NIext thereexistsa uniquedata-flowelementd ∈ D

s.t.n ∈ in nodes(d);• for each n ∈ NO

ext thereexistsa uniquedata-flowelementd ∈ D

s.t.n ∈ out nodes(d);• for eachn ∈ Nint thereexistsa uniquedata-flowelementd1 ∈ D

s.t.n ∈ in nodes(d1) andthereexistsa uniquedata-flowelementd2 ∈ D s.t.n ∈ out nodes(d2);

• for each d ∈ D, in nodes(d) ⊆ NIext ∪ Nint and

out nodes(d) ⊆ NOext ∪ Nint.

A possible specification of the data net for the Purchase and Shipexample is presented in Figure 3, which we will (partially) explain inthe following example.

Example7 Thefir st data-flowrequirementfromthetop

id(C.request.item)(P.request.item)

specifiesthat theitem informationsentto theProducer mustbeob-tainedfromtherequest receivedfromtheCustomer.Thelast requirement

oper[addDelay](P.offer.delay, S.offer.delay)(C.offer.delay)

specifies that theP&S mustapply its internal function addDelayon thedelay receivedin theoffers fromtheProducer andfromtheShipper to obtainthedelay to besentin theoffer to theCustomer.Andsoon.

The semantics of a data net model is given in terms of the acceptedexecutionsof the data net D, which define the valid sequences ofmessages exchanged by the composite service with the componentservices.

Formally, given a data net D = 〈NIext, N

Oext, Nint, D, V 〉, we

denote with Next the sets of all external connection nodes, formallyNext = NI

ext ∪ NOext. An event e of D is a couple 〈n, v〉, where

n ∈ Next ∪ Nint, and v ∈ V , which models the fact that the datavalue v passes through the connection node n. An executionρ of D isa finite sequence of eventse0, ..., en. Given an execution ρ we defineit’s projection on a set of connection nodes N ⊆ Next ∪ Nint, anddenote it with ΠN (ρ), the ordered sequence e′0, ..., e

′m representing

the events in ρ on a node in N .

In [6] we formally define when an executionρ is accepted by adata net D = 〈NI

ext, NOext, Nint, D, V 〉 using regular expressions 5.

We recall here some basic aspects, please refer to [6] for completedetails. We require that for each identity element id(a)(b) in D

Π{a,b}(ρ) =

X

v∈V

〈a, v〉 · 〈b, v〉

!∗

and for each operation element oper[f](a,b)(c) in D

Π{a,b,c}(ρ) =

X

v,w∈V

(〈a, v〉 · 〈b, w〉 + 〈b, w〉 · 〈a, v〉) · 〈c, f(v, w)〉

!∗

and for each fork element fork(a)(b,c) in D

Π{a,b,c}(ρ) =

X

v∈V

〈a, v〉 · (〈b, v〉 · 〈c, v〉 + 〈c, v〉 · 〈b, v〉)

!∗

and similarly for all other data net elements.A data net can be used to specify the desired behavior of a service

for everything that concerns the exchange of data with its commu-nication partners. In particular, as shown in the data net of Figure 3,external connection nodes are associated to input (or output) portswhich model BPEL4WS messages, or message parts, which are usedto store data received (or sent) by the process while interacting withother services.

Since the behavioral aspect we are interested in concerns the dataflow among the process and its partners, we characterize an execu-tion of a BPEL4WS process W , denoted with exec(W ), as the setof all possible ordered sequence of input/output messages (or mes-sage parts) received and sent by the process from its activation to itstermination. Notice that each message carries both the informationabout the external port on which it has been sent/received and aboutits content (value).

Definition 3 (data net satisfiability)LetW bea BPEL4WS processandD = 〈NI

ext, NOext, Nint, D, V 〉 a

datanet.WesaythatW satisfies D whenfor each processexecutionρW ∈ exec(W ) thereexistsanacceptingexecutionρ ofD such thatΠNext

(ρ) = ρW .

4 The AutomatedCompositionFramework

In this section we show how both the implicit and explicit data-flowrequirement specification approaches can be integrated in a generalframework for the automated composition of Web services.

The work in [11] (see also [12]) presents a formal framework forthe automated composition of web services which is based on plan-ning techniques: component services define the planning domain,composition requirements are formalized as a planning goal, andplanning algorithms are used to generate the composite service. Theframework of [11] differs from other planning frameworks since itassumes an asynchronous, message-based interaction between thedomain (encoding the component services) and the plan (encoding

5 We use notation Σv∈V to express alternatives that range over all the possi-ble values v ∈ V that can flow through the net.

49

! ����

S.request.location

! ����

S.request.size

����

C.offer.delay

addCost ����

C.offer.cost

addDelay

! ��

P.request.item

��������

� � ������

������������

������������

������������

������������

������������

C.request.location

P.offer.size

P.offer.cost

S.offer.cost

S.offer.delay

P.offer.delay

C.request.item

Figure3. The data net for the PurchaseandShipcomposition scenario

the composite service). We now recall the most relevant features ofthe framework defined in [11].

The planning domain is modeled as a statetransitionsystem(STSfrom now on) which describes a dynamic systems that can be in oneof its possible states(some of which are marked as initial statesand/or as final states) and can evolve to new states as a result ofperforming some actions. Actions are distinguished in inputactions,which represent the reception of messages, output actions, whichrepresent messages sent to external services, and internal actions,which represent internal evolutions that are not visible to externalservices, i.e., data computation that the system performs without in-teracting with external services. A transitionrelation describes howthe state can evolve on the basis of inputs, outputs, or internal actions.

Definition 4 (statetransition system(STS))A state transition system Σ is a tuple〈S,S0, I,O,A,R,F〉 where:

• S is thefinite setof states;• S0 ⊆ S is thesetof initial states;• I is thefinite setof inputactions;• O is thefinite setof outputactions;• A is thefinite setof internalactions;• R ⊆ S × (I ∪ O ∪ A) × S is thetransitionrelation;• F ⊆ S is thesetof acceptingstates.

The automated synthesis problem consists in generating a state tran-sition system Σc that, once connected to Σ, satisfies the compositionrequirement. We now recall the definition of the state transition sys-tem describing the behavior of Σ when connected to Σc.

Definition 5 (Controlled system)Let Σ = 〈S,S0, I,O,A,R,F〉 and Σc =〈Sc,S

0

c , Ic,Oc,A,Rc,Fc〉 be two state transition systemssuch thatI = Oc andO = Ic. ThestatetransitionsystemΣc . Σ,describing the behaviors of systemΣ when controlled by Σc, isdefinedasfollows:

Σc . Σ = 〈Sc × S,S0

c × S0, I,O,A,Rc . R,Fc ×F , 〉

where:

〈(sc, s), a, (s′c, s′)〉 ∈ (Rc . R), if

〈sc, a, s′c〉 ∈ Rc and 〈s, a, s

′〉 ∈ R

In an automated synthesis problem, we need to generate a Σc thatguarantees the satisfaction of a composition requirement ρ . This isformalized by requiring that the controlled system Σc . Σ must sat-isfy the goal ρ, written Σc .Σ |= ρ. In [11], ρ is formalized using theEAGLE language that we already introduced in Section 2 for speci-fying the control flow. The definition of whether ρ is satisfied is givenin terms of the executions that Σc . Σ can perform.

Given this, we can characterize formally an automated synthesisproblem.

Definition 6 (AutomatedSynthesis)Let Σ bea statetransitionsystem,and let ρ bean EAGLE formuladefining a compositionrequirement.Theautomatedsynthesisprob-lemfor Σ andρ is theproblemof finding a statetransitionsystemΣc

such thatΣc . Σ |= ρ.

The work in [11] shows how to adapt to this task the “Planning asModel Checking” approach, which is able to deal with large non-deterministic domains and with requirements expressed in EAGLE.It exploit powerful BDD-based techniques developed for SymbolicModel Checking to efficiently explore domainΣ during the construc-tion of Σc.

4.1 Integrating implicit data-flow requirements

In the following we will show how BPEL4WS processes can be auto-matically translated into their knowledge level models and how thesecan be used, together with the data-flow requirements specification,to obtain the composition domain at the knowledge level (for an ex-haustive description of the approach see [10]).

The main characteristic of the knowledge level approach is thepossibility to model data at an abstract level (paying no heed to theactual data exchanged between processes) and thus to efficiently per-form complex reasoning on data manipulation and flow among theconsidered services.

As we have shown in [6], BPEL4WS processes can be modeled asSTSs (see Definition 4). We omit the formal definition of the transla-tion, which can be found at http://astroproject.org. Intuitively, inputactions of the STS represent messages received from the componentservices, output actions are messages sent to the component services,internal actions model assignments and other operations which donot involve communications, and the transition relation models theevolution of the service. This modeling doesn’t capture explicitlydata transformation within the process, since the only effect of a tran-sition is the evolution of the process state.

In [10] we have shown how this model can be extended to capturedata manipulation by adding a proper knowledge base to each state inthe STS. Intuitively, the knowledge base of each component serviceis obtained from the variables, types and functions of the service.

The knowledge-level composition domain Σk is obtained by com-bining the knowledge bases of the component services and theknowledge base of the goal, by instantiating the input and outputactions of the component services on goal variables, and by addingthe private actions obtained by applying goal functions to goal vari-ables. Each state of Σk models both the evolution of the services

50

(process states) and the evolution of the data knowledge (knowledgebase). The execution of a transition affects not only the states of theprocesses but also the knowledge base according to the data transfor-mation performed.

The planning goal ρ is the EAGLE formalization of the com-position control-flow requirements. We enrich ρ by adding to theTryReach part the knowledge level data-flow requirements (knowl-edge base of the goal, see Example 6).

Given the domain Σk described above, we can apply the approachpresented in [11] and obtain a deadlock free Σc that controls Σk bysatisfying the composition requirements g. Despite of the fact thatthe synthesized controller Σc is modelled at the knowledge level, itselementary actions model communication with the component ser-vices (sending and receiving of messages) and manipulation of goalvariables; given this, it is straightforward to obtain the executableBPEL4WS composite service from Σc.

4.2 Integrating explicit data-flow requirements

As we have seen in previous sections, a data net D of a particularcomposition problem specifies how messages received from the com-ponent services can be used by the new composite process to obtainoutgoing messages. Therefore, the idea of representing D as a STSΣD , which models the allowed data flow actions, is quite intuitive.In particular, input actions in ΣD represent messages received by thecomponent services, output actions represent messages sent by thecomponent services and internal actions represent assignments thatthe composite process performs on its internal variables.

We assume that, in the BPEL4WS specification of the compositeservice, a variable will exist for each connection node in D; vari-ables associated to external connection nodes are those used by thenew composite process to store received messages and to prepare themessages to be sent, while variables associated to internal connec-tion nodes are those used to manipulate messages by means of inter-nal functions and assignments. Then ΣD defines constraints on thepossible operations that the composite process can perform on thesevariables. A nice feature of our approach is that this can be donecompositionally, i.e., a “small”automaton can be associated to eachelement of the data net, and STS ΣD is obtained as the synchronizedproduct of all these small automata.

More precisely, for each output operation of a component servicewhich is associated to some external input port in the data net wedefine a STS which represents the sending of the message (as an out-put action) and the storing of all message parts (as internal actions).Similarly, for each input operation of a component service which isassociated to some external output port in the data net we define aSTS which represents the storing of all message parts (as internal ac-tions) and the reception of the message (as an input action).Finally,we define a STS for each data-flow element of the data net. TheseSTSs have no input/ouput actions since they model manipulation ofvariables through assignments. Please refer to [6] for all the encodingdetails .

The STS ΣD , modeling the data net D, is the synchronized prod-uct of all the STSs corresponding to external connection nodes andto data-flow elements of D. The synchronized product Σ1||Σ2 mod-els the fact that the systems Σ1 and Σ2 evolve simultaneously oncommon actions and independently on actions belonging to a singlesystem.

We are ready to show how we can integrate the explicit data-flow requirements specification approach within the automated com-position framework presented in [11]. Given n component services

W1, ..Wn and a data net D, modeling the data-flow composition re-quirements, we encode each component service Wi as a STS ΣWi

and the data net D as a STS ΣD . The composition domain Σ for theautomated composition problem is the synchronized product of allthese STSs. Formally, Σ = ΣD ‖ ΣW1

‖ .. ‖ ΣWn. The planning

goal ρ is the EAGLE formalization of the composition control-flowrequirements. We enrich ρ by requiring that Σ is in an accepting state.

Given the domain Σ and the planning goal ρ we can apply the ap-proach presented in [11] to generate a controller Σc, which is suchthat Σc .Σ |= ρ. Once the state transition system Σc has been gener-ated, it is translated into BPEL4WS to obtain the new process whichimplements the required composition. The translation is conceptu-ally simple; intuitively, input actions in Σc model the receiving of amessage from a component service, output actions in Σc model thesending of a message to a component service, internal actions modelmanipulation of data by means of expressions and assignments.

5 Comparisonof the two approaches

In this section we compare the two proposed approaches from a tech-nical point of view, from the point of view of the performance, andfor what concerns the usability.

The two approaches present similar characteristics. First of allboth of them extend the automated composition framework proposedin [11, 12]. Moreover, they adopt the same strategy to encode datamanipulation and exchange at an abstract level in the compositiondomain: introducing goal variables (which model variables of thenew composite BPEL4WS process) and encoding data-flow require-ments as constraints on the operations that can be performed ongoal variables. A first difference can be seen in the way they ex-tract these variables and constraints: the knowledge-level approachobtains them by flattening the data-flow goal, while the other ap-proach directly obtains them from the data net, where they are ex-plicitly defined. However, the main difference lies in the way the twoapproaches reason on goal variables: the implicit approach encodesthe knowledge on the equalities between these variables (knowledgebase) in the states of the composition domain and uses this infor-mation to check whether the goal is satisfied; while the data netbased approach doesn’t explicitly encode data within the composi-tion domain (states simply model the evolution of the processes) andintroduces new STSs modeling the synchronization between opera-tions that manipulate goal variables. This difference is reflectedin thecomplexity of the obtained composition domain, which in the knowl-edge level approach is much heavier. In order to test the performanceof the proposed approaches, we have conducted some experiments onproblems extracted from realistic web service domains. One of theseis the P&S example, which we use as a reference example through-out this paper. This is a quite simple example: the interactions amongthe components and the composite service are quite straight and thedata-flow requirements are pretty simple. The other scenario we con-sidered is the Virtual Travel Agency (VTA) example (for furtherdetails see [6]). This composition problem requires a high degree ofinterleaving between components (to achieve the goal, it is necessaryto carry out interactions with all component services in an interleavedway) and both the knowledge base of the goal and the data net aremuch more complex (due to the number of functions and to the needof manipulating data in a complex way). The results (see Table 1)are not surprising: the knowledge level approach shows worse per-formances both for the model construction time (obtaining the com-position domain) and composition time (synthesizing the controllerand emitting the BPEL4WS process). This results come straight fromthe different encodings: the knowledge level encoding is much more

51

KnowledgeLevel Data Netmodel construction composition model construction composition

P&S 4.391 sec. 0.672 sec. 2.207 sec. 0.027 sec.VTA 29.268 sec. 21.761 sec. 2.584 sec. 0.178 sec.

Table1. Experiments with P&S and VTA.

complex (building the STS Σk, that defines the composition domain,requires to compute several fix ed point iterations), and consequentlythe synthesis task is much harder.

For what concerns usability, the judgment is not so straightfor-ward: the two approaches adopt very different perspectives and eachcan thus be preferable depending on the particular composition sce-nario. Modeling data-flow composition requirements through a datanet requires to explicitly link all the messages received from com-ponent services with messages sent to component services and todeclare all internal connection nodes (and thus exhaustively definethe composite service internal variables). Moreover in this approachcomponent services are black boxes exporting only input and outputports: there is no way to reason about their internal data manipulationbehaviors. The knowledge-level approach adopts a more abstract per-spective: on the one hand it allows to leave out most implementationdetails (avoiding to explicitly define internal variables and functions),on the other hand it allows to reason on semantic annotations captur-ing the component service internal behavior (this becomes essentialwhen dealing with autonomic web services).

6 Conclusionsand RelatedWorks

In the paper we have compared two different approaches, implicitand explicit, to define data flow requirements for the automated com-position of Web services and shown how they can be integratedwithin an existing automated composition framework. The formeris based on the knowledge level automated composition approachpresented in [10], while the latter uses the data-flow requirementsmodeling language proposed in [6]. Though the explicit modelingpresents much better performances (due to the very light encoding),both of them have been shown to handle realistic composition prob-lems. The choice of the approach to be used must be made on thebasis of the specific composition problem.

Several approaches have been proposed to model Web Servicecompositions and Web Services in general, but none of them ad-dresses the problem of specifying data flow constraints. In the ap-proach proposed in [13] component services are defined in terms oftheir inputs and outputs; given the inputs and outputs of the service,a rule is then defined which indicates which outputs can be obtainedby the service given which inputs. When a developer wishes to cre-ate and deploy a new composite service, he specifies the inputs andoutputs of the composite service and submits it to the system, whichdetermines if the composite service can be realized using the exist-ing services. This rule based approach can be adopted exclusively formodeling simple composition problems, where component servicesare atomic and deterministic.

The methodology proposed in [5] is founded on Tropos [9], anagent-oriented software development technique that supports earlyand late requirements analysis, as well as architectural and detaileddesign. The key idea of this approach is that Web Services are de-signed by starting from stake-holders goals, that are then analyzedand refined into subgoals and tasks. However, the starting point forWeb Service compositions are usually abstract workflows, which

are derived from business scenarios, rather than high level businessgoals.

In [14] the authors propose a UML-based model-driven methodfor Web Service composition. They show how composite Web Ser-vice models can be transformed into executable models by meansof UML model transformations. The weakness of UML-based ap-proaches is that modeling complex composition scenarios is a de-manding and difficult task since they require to use several differentUML diagrams (e.g. activity, class, collaboration diagrams); more-over, the relationships between these diagrams do not have a clearand formal semantic.

For what concerns the formal specification of the requirementsthat the new composite service should satisfy, most of the existingapproaches specify them as reachability conditions (e.g. [8]). A re-markable exception is the work described in [11, 12, 10], on whichwe based our work, where the composition requirements is formal-ized using EAGLE [3].

REFERENCES[1] T. Andrews, F. Curbera, H. Dolakia, J. Goland, J. Klein, F. Leymann,

K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weeravarana.Business Process Execution Language for Web Services (version 1.1),2003.

[2] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Me-cella, ‘Automatic composition of E-Services that export their be-haviour’, in Proc. ICSOC’03, (2003).

[3] U. Dal Lago, M. Pistore, and P. Traverso, ‘Planning with a Languagefor Extended Goals’, in Proc.AAAI’02, (2002).

[4] R. Hull, M. Benedikt, V. Christophides, and J. Su, ‘E-Services: A LookBehind the Curtain’, in Proc.PODS’03, (2003).

[5] D. Lau and J. Mylopoulos, ‘Designing Web Services with Tropos’, inProc. ICWS’04, (2004).

[6] A. Marconi, M. Pistore, and P. Traverso, ‘Specifying Data-Flow Re-quirements for the Automated Composition of Web Services’, in Proc.SEFM’06, (2006).

[7] S. McIlraith and S. Son, ‘Adapting Golog for Composition of SemanticWeb Services’, in Proc.KR’02, (2002).

[8] S. Narayanan and S. McIlraith, ‘Simulation, Verification and Auto-mated Composition of Web Services’, in Proc.WWW’02, (2002).

[9] A. Perini, P. Bresciani, F. Giunchiglia, P. Giorgini, and J. Mylopoulos,‘A Knowledge Level Software Enineering Methodology for Agent Ori-ented Programming’, in Proc.of theFifth InternationalConferenceonAutonomousAgents, (2004).

[10] M. Pistore, A. Marconi, P. Traverso, and P. Bertoli, ‘Automated Com-position of Web Services by Planning at the Knowledge Level’, in Proc.IJCAI’05, (2005).

[11] M. Pistore, P. Traverso, and P. Bertoli, ‘Automated Composition of WebServices by Planning in Asynchronous Domains’, in Proc. ICAPS’05,(2005).

[12] M. Pistore, P. Traverso, P. Bertoli, and A.Marconi, ‘Automated Synthe-sis of Composite BPEL4WS Web Services’, in Proc.ICWS’05, (2005).

[13] S. Ponnekanti and A. Fox, ‘SWORD: A Developer Toolkit for WebService Composition’, in Proc.WWW’02, (2002).

[14] D. Skogan, R. Gronmo, and I. Solheim, ‘Web Service Composition inUML’, in Proc.EDOC’04, (2004).

52

Web Service Compositionin a Temporal Action Logic 1

Laura Giordano2 and Alberto Martelli3

Abstract.The paperpresentsan approachto reasoningaboutweb service

compositionusing a temporalaction theory. Web servicesare de-scribedby specifyingtheir interactionprotocolsin anactiontheorybasedonadynamiclineartime temporallogic. Theproposedframe-work providesa simpleformalizationof thecommunicative actionsin termsof their effectsandpreconditionsand the specificationofan interactionprotocolby meansof temporalconstraints.We adopta socialapproachto agentcommunication,wheretheactioneffectscanbedescribedin termsof changesin thesocialstate,andprotocolsin termsof creationandsatisfactionof commitmentsamongagents.Weshow how theproblemof webservicecompositioncanbeformu-latedin theactiontheoryasaplanningproblem,andweshow how itcanbesolvedusinganautomatabasedapproach.

1 Introduction

One of the central issuesin the field of multi-agentsystemscon-cernsthe specificationof conversationpolicies (or interactionpro-tocols),which govern the communicationbetweensoftwareagentsin an agentcommunicationlanguage(ACL) [4]. To allow for theflexibility neededin agentcommunication[14, 10] new approacheshave beenproposed,which overcomethe limitations of the tradi-tional transitionnet approach,in which the specification of inter-actionprotocolsis doneby makinguseof finite statemachines.Aparticularlypromisingapproachto agentcommunication,first pro-posedby Singh[22], is thesocialapproach[5, 11,14]. In thesocialapproach,communicativeactionsaffect the“socialstate”of thesys-tem,ratherthantheinternal(mental)statesof theagents.Thesocialstaterecordssocialfacts,like thepermissionsandthecommitmentsof theagents.

In thispaperweadoptasocialapproachin thespecificationof theinteractionsamongWeb servicesand,in particular, we addresstheproblemof servicecomposition[23],wherethe objective is “to de-scribe,simulate,compose,test,andverify compositionsof Webser-vices”[15]. In ourproposalWebservicesaredescribedby specifyingtheir interactionprotocolsin an action theorybasedon a dynamiclinear time temporallogic. Sucha logic hasbeenusedin [7, 9] toprovide thespecificationof interactionprotocolsamongagentsandto allow the verification of protocolpropertiesaswell as the veri-fication of the complianceof a setof communicatingagentswith aprotocol.

1 Thisresearchhasbeenpartiallysupportedby theprojectMIUR PRIN2005“Specificationandverification of agentinteractionprotocols”

2 Dipartimentodi Informatica,Universita del PiemonteOrientale,Alessan-dria - email: laura@mfn.unipmn.it

3 Dipartimento di Informatica, Universita di Torino, Torino - email:mrt@di.unito.it

Fromseveralpointsof view thewebservicedomainis well suitedto this kind of formalization.The proposedframework provides asimpleformalizationof thecommunicative actionsin termsof theireffectsandpreconditionsandthespecificationof aninteractionpro-tocol by meansof temporalconstraints.To accommodatetheneedsof theapplicationdomain,in which informationis inherentlyincom-plete,in Section2 we extendtheactiontheorydefined in [9] to dealwith incompleteinformation,by introducingepistemicmodalitiesinthelanguageto distinguishwhatis known aboutthesocialstatefromwhatis unknown.

Weconsidertheproblemof composingwebservices,by referringto anexampleconsistingof two servicesfor purchasingandfor ship-pinggoods.Bothserviceshaveaninteractionprotocolwith thesamestructure:the customersendsa requestto the service,the servicereplieswith an offer or by sayingthat the serviceis not available,andfinally , if thecustomerreceivestheoffer, it mayacceptor refuseit.

In Section3 we show how to specifysuchinteractionprotocols,by adoptingasocialapproach.Communicativeactions,suchasofferor accept, aremodeledin termsof their effectson the social state(actionlaws). A protocolwill bespecifiedby puttingconstraintsonthe executabilityof actions(preconditionlaws), andby introducingtemporalconstraintsspecifyingfulfillment of commitments.Severalverification problemsconcerningpropertiesof thewebservicescanbe modelledassatisfiability andvalidity problemsin the logic. Wemake useof an automatabasedapproachto solve theseproblemsand, in particular, we work on the Buchi automatonwhich canbeextractedfrom thelogical specificationof theprotocol.

In Section4 wedefine theservicecompositionproblemasaplan-ning problem,whosesolution requiresto build a conditionalplan,allowing the interactionwith the componentservices.The plan canbeobtainedfrom theBuchiautomatonderivedfrom thelogicalspec-ification of the protocol.We will alsobrieflyaddressother relatedproblemssuchasbuilding a new servicethat is ableto managetheinteractionsbetweenthe customerandthe two services,or provingthecorrectnessof agivenserviceimplementationwith respectto thespecificationof theinteractionprotocols.

2 The action theory

In thissectionwedescribetheactiontheorythatis usedin thespecifi-cationof theservices.Wefirst introducethetemporallogic onwhichouractiontheoryis basedandits epistemicextension.

2.1 Dynamic Linear Time Temporal Logic

In thissectionwebrieflydefine thesyntaxandsemanticsof DLTL asintroducedin [12]. In sucha lineartime temporallogic thenext state

53

modality is indexedby actions.Moreover, (andthis is theextensionto LTL) the until operatoris indexed by programsin PropositionalDynamicLogic (PDL).

Let Σ bea finite non-emptyalphabet.ThemembersofΣ areac-tions. Let Σ∗ andΣω be the setof finite and infinite wordsonΣ,whereω = {0, 1, 2, . . .}. Let Σ∞ =Σ∗∪Σω. Wedenoteby σ, σ′ thewordsoverΣω andby τ, τ ′ thewordsoverΣ∗. Moreover, wedenoteby ≤ theusualprefix orderingoverΣ∗ and,for u ∈ Σ∞, we denoteby prf(u) thesetof finite prefixesofu.

We define thesetof programs(regularexpressions)Prg(Σ) gen-eratedby Σ asfollows:

Prg(Σ) ::= a | π1 + π2 | π1; π2 | π∗

wherea ∈ Σ and π1, π2, π rangeover Prg(Σ). A set of finitewords is associatedwith eachprogramby the usualmapping[[]] :Prg(Σ) → 2Σ

∗

.Let P = {p1, p2, . . .} be a countablesetof atomicpropositions

containing> and⊥. Wedefine:

DLTL(Σ) ::= p | ¬α | α ∨ β | αUπβ

wherep ∈ P andα, β rangeoverDLTL(Σ).A modelof DLTL(Σ) is a pair M = (σ, V ) whereσ ∈ Σω and

V : prf(σ) → 2P is a valuationfunction. Given a modelM =(σ, V ), a finite wordτ ∈ prf(σ) anda formulaα, thesatisfiabilityof a formulaα at τ in M , written M, τ |= α, is defined asfollows(weomit thestandarddefinition for thebooleanconnectives):

• M, τ |= p if f p ∈ V (τ);• M, τ |= αUπβ if f thereexistsτ ′ ∈ [[π]] suchthatττ ′ ∈ prf(σ)

andM, ττ ′ |= β. Moreover, for everyτ ′′ suchthatε ≤ τ ′′ < τ ′4,M, ττ ′′ |= α.

A formula α is satisfiable iff thereis a modelM = (σ, V ) andafinite wordτ ∈ prf(σ) suchthatM, τ |= α.

The formula αUπβ is true at τ if “α until β” is true on a finitestretchof behavior which is in the linear time behavior of the pro-gramπ.

The derived modalities〈π〉 and [π] can be defined as follows:〈π〉α ≡ >Uπα and[π]α ≡ ¬〈π〉¬α.

Furthermore,if we let Σ = {a1, . . . , an}, theU , © (next), 3 and2 operatorsof LTL canbe defined asfollows:©α ≡

∨a∈Σ

〈a〉α,

αUβ ≡ αUΣ∗

β, 3α ≡ >Uα, 2α ≡ ¬3¬α, where,in UΣ∗

,Σ is takento bea shorthandfor theprograma1 + . . . + an. HencebothLTL(Σ) andPDL arefragmentsof DLTL(Σ). As shown in [12],DLTL(Σ) is strictly more expressive than LTL(Σ). The satisfiabil-ity andvalidity problemsfor DLTL arePSPACE completeproblems[12].

2.2 Epistemic modalities

In the following we needto describethe effectsof communicativeactionsonthesocialstateof theagents.In particular, wewantto rep-resentthefactthateachagentcanseeonly partof thesocialstateasit is only awareof someof thecommunicative actionsin theconver-sation(namelythoseit is involved in asa senderor asa receiver).For this reason,we introduceknowledgeoperatorsto describetheknowledgeof eachagentaswell astheknowledgesharedby groupsof agents.More precisely, we introducea modaloperatorKi to rep-resenttheknowledgeof agenti andthemodaloperatorKA, where

4 We defineτ ≤ τ ′ if f ∃τ ′′ suchthat ττ ′′= τ ′. Moreover, τ < τ ′ if f

τ ≤ τ ′ andτ 6= τ ′.

A is a setof agents,to representtheknowledgesharedby agentsinA. Groupsof agentsacquireknowledgeaboutsocialfactswhentheyinteractby exchangingcommunicativeactions.ThemodaloperatorsKi andKA arebothof typeKD. They arenormalmodalitiesruledby the axiom schemaKϕ → ¬K¬ϕ (seriality). Following the so-lution proposedin [1], we restrict epistemicmodalitiesto be usedin front of literals,andwe neitherallow nestedapplicationsof epis-temicmodalitiesnor we allow epistemicmodalitiesto beappliedtobooleancombinationof literals.Hence,thoughlogic KD45 is usu-ally adoptedto representbeliefoperators,herewedonotneedto addthepositiveandnegative introspectionaxioms.

TherelationsbetweenthemodalitiesKi andKA areruledby thefollowing interactionaxiom schema:KAϕ → Kiϕ, wherei ∈ A,meaningthatwhat is knowledgeof a groupof agentsis alsoknowl-edgeof eachsingleagentin thegroup.As usual,for eachmodalityKi (respectively, KA) we introducethe modalityMi (resp.MA),which is definedasthedualofKi, i.e.Miϕ is ¬Ki¬ϕ.

2.3 Domain descriptions

Thesocialstateof theprotocol,which describesthestageof execu-tion of the protocol from the point of view of the differentagents,is describedby a setof atomicpropertiescalledfluents, whoseepis-temicvaluein astatemaychangewith theexecutionof communica-tiveactions.

Let P be a setof atomicpropositions,the fluentnames. A fluentliteral l is afluentnamef or its negation¬f . Weintroducethenotionof epistemicfluentliteral to beamodalatomKl or its negation¬Kl,wherel is a fluentliteral and K is anepistemicoperatorKi or KA.Wewill denoteby Lit thesetof all epistemicliterals.

An epistemicstate(or, simply, a state)is defined asacomplete5

and consistentset of epistemicfluentliterals, and it provides, foreachagenti (respectively for eachgroupof agentsA) a three-valuedinterpretationin which eachliteral l is true whenKil holds, falsewhenKi¬l holds,andundefinedwhenboth¬Kil and¬Ki¬l hold.Observe that,giventhepropertyof seriality, consistency guaranteesthat a statecannotcontainbothKf andK¬f , for someepistemicmodalityK andfluentf . In fact,from Kf it followsby serialitythat¬K¬f , which is inconsistentwith K¬f .

In the following we extendtheactiontheorydefined in [9] to ac-commodateepistemicliterals.

A domaindescriptionD is defined asa tuple(Π, C), whereΠ isa setof (epistemic)action laws andcausallaws, andC is a setofconstraints. Theactionlaws in Π have theform:

2(Kα → [a]Kl) (1)

2(Mα → [a]Ml) (2)

wherea ∈ Σ andKα is a conjunctionof epistemicfluentsof theformKl1 ∧ . . .∧Kln, andMα is aconjunctionof epistemicfluentsof theform Ml1 ∧ . . . ∧Mln.

The meaningof (1) is that executingaction a in a statewherel1, . . . , ln areknown (to be true) causesl to becomeknown, i.e. itcausestheeffectKl to hold.As anexamplethelaw 2(Kfragile →[a]Kbroken) meansthat, after executingthe action of droppingaglassthe glassis known to be broken, if the action is executedina statein which the glassis known to be fragile. (2) is necessaryin order to deal with ignoranceaboutpreconditionsof the actiona. It meansthat the execution of a may affect the beliefs about

5 A setS of epistemicfluentliteralsis completeif, for all literals l andepis-temicoperatorsK, eitherKl ∈ S or¬Kl ∈ S.

54

l, whenexecutedin a statein which the preconditionsareconsid-eredto bepossible.Whenthepreconditionsof a areunknown, thislaw allows to concludethat the effects of a are unknown as well.2(Mfragile → [a]Mbroken) meansthat,afterexecutingtheac-tion of droppinga glass,the glassmay be broken, if the action isexecutedin astatein whichtheglassmaybefragile(i.e.K¬fragile

doesnothold).Thecausallaws in Π have theform:

2((Kα ∧©Kβ) → ©Kl) (3)

2((Mα ∧©Mβ) → ©Ml) (4)

wherea ∈ Σ andKα is a conjunctionof epistemicfluentsof theform Kl1 ∧ . . . ∧ Kln, Kβ is a conjunctionof epistemicfluentsoftheform Kln+1 ∧ . . . ∧ Klm, andsimilarly for Mα andMβ.

The meaningof (3) is that if l1, . . . , ln areknown in a stateandln+1, . . . , lm areknown in thenext state,thenl is alsoknown in thenext state.Suchlaws areintendedto expresses“causal”dependen-ciesamongfluents.Causallaw (4) is definedsimilarly.

Theconstraintsin C are,in general,arbitrarytemporalformulasofDLTL. Constraintsput restrictionson thepossiblecorrectbehaviorsof aprotocol.Thekind of constraintswewill usein thespecificationof a protocolincludetheobservationson thevalueof epistemicflu-ent literals in the initial stateandthe preconditionlaws. The initialstateInit is a (possiblyincomplete)setof epistemicliterals,whichis madecompleteby adding¬Kl to Init whenKl 6∈ Init.

Thepreconditionlawshave the form: 2(α → [a]⊥), wherea ∈Σ andα is anarbitrarynon-temporalformulacontaininga booleancombinationof epistemicliterals.Themeaningis that theexecutionof anactiona is notpossibleif α holds(i.e. thereis noresultingstatefollowing theexecutionof a if α holds).Notethat,whenthereis nopreconditionlaw for anaction,theactionis executablein all states.

Theactiontheorydescribedabovereliesonasolutionto theframeproblemsimilar to theonedescribedin [9]. A completionconstruc-tion is defined which, givena domaindescription,introducesframeaxiomsfor all the frame fluentsin the style of the successorstateaxiomsintroducedby Reiter[20] in thecontext of thesituationcal-culus.Thecompletionconstructionis appliedonly to theactionlawsandcausallaws in Π andnot to the constraints.The valueof eachfluentpersistsfrom astateto thenext oneunlessits changeis causedby the executionof an actionasan immediateeffect (effect of theactionlaws) or an indirecteffect (effect of thecausallaws). We callComp(Π) thecompletionof asetof lawsΠ.

LetΠ beasetof actionlawsandcausallaws.Bothactionlawsandcausallaws canbeequivalentlywritten in the following normalizedform (wherein actionlaws thesecondconjunctis omitted):

2(〈a〉> → ((Kα ∧ [a]Kβ) → [a]Kl))2(〈a〉> → ((Mα ∧ [a]Mβ) → [a]Ml)).

Theactionlaws andcausallaws for a fluentf in Π canthenhavethefollowing forms:

2(〈a〉> → (Kαi ∧ [a]Kγi → [a]Kf))2(〈a〉> → (Kβj ∧ [a]Kδj → [a]K¬f))2(〈a〉> → (Mαi ∧ [a]Mγi → [a]Mf))2(〈a〉> → (Mβj ∧ [a]Mδj → [a]M¬f))

We define the completionofΠ asthesetof formulasComp(Π)containing,for all actionsa andfluentsf , thefollowing axioms:

2(〈a〉> → ([a]Kf ↔(∨

i(Kαi ∧ [a]Kγi)) ∨ (Kf ∧

∧j(K¬βj ∨ ¬[a]Mδj))))

2(〈a〉> → ([a]K¬f ↔(∨

j(Kβj ∧ [a]Kδj)) ∨ (K¬f ∧

∧i(K¬αi ∨ ¬[a]Mγi)))).

Theselaws saythata fluentKf (K¬f ) holdseitheras(directorindirect)effect of theexecutionof someactiona, or by persistency,sinceKf (K¬f ) held in thestatebeforetheoccurrenceof a anditsnegationis notaresultof a. Observethatthetwo frameaxiomsabovealsodeterminethevaluesin astatefor [a]Mf andfor [a]M¬f .

As adifferencewith [9], wedonotdistinguishbetweenframeandnon-framefluentsin a domaindescriptionandin the following weassumethatall epistemicfluentsareframe,thatis, they arefluentstowhich the law of inertia applies.The kind of non-determinismthatwe allow hereis on thechoiceof theactionsto beexecuted,whichcanberepresentedby thechoiceconstructof regularprograms.

3 Protocol specification

In thesocialapproach[22, 24] aninteractionprotocolis specifiedbydescribingthe effectsof communicative actionson the socialstate,andby specifyingthepermissionsandthecommitmentsthatariseasaresultof thecurrentconversationstate.Theseeffects,includingthecreationof new commitments,canbeexpressedby meansof actionlaws.

The action theory introducedabove will be usedfor modellingcommunicative actionsand for describingthe social behavior ofagentsin amulti-agentsystem.In defining protocols,communicativeactionswill be denotedby action name(s,r), wheres is the senderandr is thereceiver. In particular, two specialactionsareintroducedfor eachprotocolPn: begin Pn(s, r) andend Pn(s, r), which aresupposedto startandto finish eachrun of theprotocol.For eachpro-tocol, we introducea specialfluentPn (wherePn is the “protocolname”)which hasto betrueduring thewholeexecutionof thepro-tocol: Pn is madetrueby theactionbegin Pn(s, r) andit is madefalseby theactionend Pn(s, r).

3.1 Commitments and permissions

Among the most significant proposalsto usecommitmentsin thespecificationof protocols(or moregenerally, in agentcommunica-tion) arethoseby Singh[22], GuerinandPitt [11], Colombetti[5].

In order to handlecommitmentsand their behavior during runsof a protocolPn, we introducetwo specialfluents.Onerepresentsbase-level commitmentsand hasthe form C(Pn, i, j, α) meaningthatagenti is committedto agentj to bring aboutα, whereα is anarbitrarynon temporalformula not containingcommitmentfluents.Thesecondcommitmentfluentmodelsconditionalcommitmentsandhasthe form CC(Pn, i, j, β, α) meaningthat in protocol Pn theagenti is committedto agentj to bringaboutα, if theconditionβ isbroughtabout.

Commitmentsarecreatedaseffectsof the executionof commu-nicative actionsin theprotocolandthey are“discharged”whentheyhavebeenfulfilled. A commitmentC(Pn, i, j, α), createdatagivenstateof a run, is regardedto be fulfilled in the run if thereis a laterstatein therun in whichα holds.

We introducethe following causal laws for automaticallydis-charging fulfilled commitments6:

(i) 2(©α → ©Ki,j(¬C(Pn, i, j, α)))(ii)2((Ki,j(CC(Pn, i, j, β, α)) ∧©β) →

©Ki,j(C(Pn, i, j, α)))

6 Weomit thethreesimilar ruleswith K replacedbyM

55

(iii) 2((Ki,j(CC(Pn, i, j, β, α)) ∧©β) →©Ki,j(¬CC(Pn, i, j, β, α)))

A commitment to bring about α is considered fulfilled andis discharged (i) as soon as α holds. A conditional com-mitment CC(Pn, i, j, β, α) becomesa base-level commitmentC(Pn, i, j, α) whenβ hasbeenbroughtabout (ii) and the condi-tional commitmentis discharged(iii).

We canexpressthe condition that a commitmentC(Pn, i, j, α)hasto befulfilled beforethe“run”of theprotocolis finished by thefollowing fulfillment constraint:

2(Ki,j(C(Pn, i, j, α)) → Pn U α)

We will call Comi thesetof constraintsof this kind for all commit-mentsof agenti. Comi statesthatagenti will fulfill all thecommit-mentsof which it is thedebtor.

At eachstageof the protocolonly someof the messagescanbesentby theparticipants,dependingon thesocialstateof theconver-sation.Permissionsallow to determinewhich messagesareallowedat a certainstageof the protocol.The permissionsto executecom-municative actionsin eachstatearedeterminedby social facts.Werepresentthemby preconditionlaws.Preconditionson theexecutionof actiona canbeexpressedas:2(α → [a]⊥) meaningthatactionacannotbeexecutedin astateif α holdsin thatstate.

We call Permi (permissionsof agenti) thesetof all theprecon-dition laws of theprotocolpertainingto theactionsof which agentiis thesender.

3.2 An example

Let usconsiderasanexampleaservicefor purchasingagood.Thereare two roles:A customer, denotedby C, anda producer, denotedby P. Thecommunicativeactionof theprotocolare:request(C, P ).meaningthatthecustomersendsarequestfor aproduct,offer(P ,C )andnot avail(P, C), the producersendsan offer or saysthat theproductis not available,accept(C, P ) andrefuse(C, P ), thecus-tomeracceptsor refusesthe offer. Furthermore,aspointedout be-fore, therewill be theactionsbegin Pu(C, P ) andend Pu(C, P )to startandfinish theprotocol.

As mentionedbefore,thesocialstatewill containonly epistemicfluents.We denotethesocialknowledgeby KC,P , to meanthat theknowledgeis sharedby C andP .

Thesocialstatewill containthefollowing fluents,which describethe protocol in an abstractway: requested, the producthasbeenrequested,offered , theproductis availableandanoffer hasbeensent(we assumethat¬offered meansthat the productis not available),accepted, theoffer hasbeenaccepted.ThefluentPu meansthattheprotocolis beingexecuted.

Furthermore,we introducesomebase-level commitments(to sim-plify thenotation,in the following we will useKw

C,P (f) asa short-handof theformulaKC,P (f) ∨ KC,P (¬f)):

C(Pu, C, P,KC,P (requested))C(Pu, P, C,Kw

C,P (offered))C(Pu, C, P,Kw

C,P (accepted))

Wealsoneedthefollowing conditionalcommitments:

CC(Pu, P, C,KC,P (requested),KwC,P (offered))

CC(Pu, C, P,KC,P (offered),Kw

C ,P (accepted))

For instance,thefirst conditionalcommitmentsaysthattheproduceris committedto sendanoffer, or to saythat theproductis not avail-able,if a requestfor theproducthasbeenmade.

Wecannow givetheactionrulesfor theactionof theprotocol.Weassumeall fluentsto be undefinedin the initial state(i.e., for eachfluentf , for eachepistemicmodalityK, ¬Kf and¬K¬f hold in theinitial state),exceptfor fluentPu which will beknown to be false.Theexecutionof begin Pu(C, P ) andend Pu(C, P ) will havethefollowing effects:

2[begin Pu(C, P )]KC,P (Pu) ∧KC,P (C(Pu, C, P,KC,P (requested))) ∧KC,P (CC(Pu, P, C,KC,P (requested),Kw

C,P (offered)))∧KC,P (CC(Pu, C, P,KC,P (offered),Kw

C ,P (accepted)))2[end Pu(C, P )]KC,P (¬Pu)

After startingtheprotocol,thecustomeris committedto make a re-quest,andtheconditionalcommitmentsarecreated.

Theactionlaws for theremainingactionsarethefollowing:

2[request(C, P )]KC,P (requested)2[offer(P ,C )]KC ,P (offered)2[not avail(P, C)]KC,P (¬offered)2[accept(C, P )]KC,P (accepted)2[refuse(C, P )]KC,P (¬accepted)

Wecannow give thepreconditionsfor theactionsof theprotocol.

2(¬KC,P (¬Pu) → [begin Pu(C, P )]⊥)2((¬KC,P (Pu)∨KC,P (requested)) → [request(C, P )]⊥)2((¬KC,P (Pu) ∨ ¬KC,P (requested) ∨ Kw

C,P (offered)) →[offer(P ,C )]⊥)

2((¬KC,P (Pu) ∨ ¬KC,P (requested) ∨ KwC,P (offered)) →

[not avail(P, C)]⊥)2((¬KC,P (Pu) ∨ ¬KC,P (offered) ∨ Kw

C ,P (accepted)) →[accept(C, P )]⊥)

2((¬KC,P (Pu) ∨ ¬KC,P (offered) ∨ Kw

C ,P (accepted)) →[refuse(C, P )]⊥)

2(¬KC,P (Pu) → [end Pu(C, P )]⊥)

For instance,actionrequest(C, P ) cannotbe executedif it is notknown that the protocolhasbeenstartedor if it is known that therequesthasalreadybeenachieved(to avoid repeatingtheaction).

3.3 Protocols and their runs

A protocol is specified by giving a domaindescription,defined asfollows:

Definition 1 A domaindescriptionD is a pair (Π, C) where

• Π is thesetof theactionandcausallawscontaining:

– the laws describingthe effectsof each communicativeactionson thesocialstate;

– thecausallawsdefining thecommitmentrules.

• C = Init ∧∧

i(Permi ∧ Comi) is theconjunctionof thecon-

straints on the initial stateof the protocol and the permissionsPermi andthecommitmentsComi of all theagentsi.

GivenadomaindescriptionD, wedenoteby Comp(D), thecom-pleteddomaindescription,thesetof formulas:

(Comp(Π) ∧ Init ∧∧

i

(Permi ∧ Comi))

56

Definition 2 Giventhe specificationof a protocol by a domainde-scriptionD, therunsof thesystemaccordingtheprotocolareexactlythemodelsof Comp(D).

Notethatprotocol“runs”arealwaysfinite, while thelogic DLTLis characterizedby infinite models.To take this into account,we as-sumethateachdomaindescriptionof a protocolwill besuitablyex-tendedwith an actionnoop which doesnothingandwhich canbeexecutedonly afterterminationof theprotocol,soasto allow acom-putationto goon foreverafterterminationof theprotocol.

Note that the domaindescriptionspecifyinga protocol containsinformationrelatedto thesemanticsof theactions,andinformationrelatedto the “control”of the protocol, i.e. the allowed sequencesof actions.For instance,thepreconditionrule of actionoffer(P ,C )specifiesboththatthisactionneedsarequestto beexecuted,andthatit canbeexecutedonly oncein theprotocol.Thelatterpreconditiondependson theprotocolratherthanon thesemanticsof theaction.

In thelogic DLTL thecontrolof arigid protocollikethisonecouldbeeasilyrepresentedby meansof a regularprogram.In ourexamplewemightdefine thefollowing regularprogramπ:

begin Pu(C, P ); request(C, P );((offer(P ,C ); (accept(C ,P) + refuse(C ,P))) +not avail(P ,C ));

end Pu(C ,P)

andaddaconstraint〈π〉> requiringthateachmodelmustbegin withanexecutionof π. However in thispaperwedonotusethis formula-tion becauseit hasthedrawbacksthatit requirestheuseof theprod-uct versionof thetemporallogic [9] to dealwith thecompositionofprotocols.

Oncethe interfaceof a servicehasbeendefined by specifyingitsprotocol,severalkindsof verification canbeperformedon it as,forinstance,theverification of servicescompliancewith theprotocolatruntime,theverification of propertiesof theprotocolandtheverifi-cationthat a given implementedservice,whosebehavior is known,is compliantwith theprotocol.

The verification that the interactionprotocolhasthe propertyϕamountsto show thattheformula

(Comp(Π) ∧ Init ∧∧

i

(Permi ∧ Comi)) → ϕ, (5)

is valid, thatis thatall theadmittedrunshave thepropertyϕ.Verifying thattheasetservicesarecompliantwith agiveninterac-

tion protocolatruntime,giventhehistoryτ = a1, . . . , an describingtheinteractionsof theservices,amountsto checkif thereis a run ofthe protocolcontainingthat sequenceof communications.This canbedoneby verifying thesatisfiability of theformula

(Comp(Π)∧Init∧∧

i

(Permi∧Comi))∧ < a1; a2; . . . ; an > >

wherei rangesonall theservicesinvolvedin theprotocol.Finally, theproblemof verifying thata service,whoseactualbe-

havior is given,is compliantwith agiveninteractionprotocol,canbemodelledasa validity problem,assumingthat the abstractdescrip-tion of theservicecanbegivenby meansof a regularprogram.Foran exampleandthe detaileddescriptionof this verification taskwereferto [7].

3.4 Reasoning about protocols using automata

Verification and satisfiability problemscan be solved by extend-ing thestandardapproachfor verification of LinearTime Temporal

Logic,basedontheuseof Buchiautomata.WerecallthataBuchi au-tomatonhasthesamestructureasatraditionalfinite stateautomaton,with the differencethat it acceptsinfinite words.More preciselyaBuchiautomatonoveranalphabetΣ is a tupleB = (Q,→, Qin, F )where:

• Q is afinite nonemptysetof states;• →⊆ Q × Σ × Q is a transitionrelation;• Qin ⊆ Q is thesetof initial states;• F ⊆ Q is asetof acceptingstates.

Let σ ∈ Σω. Thena run of B overσ is a mapρ : prf(σ) → Q suchthat:

• ρ(ε) ∈ Qin

• ρ(τ)a→ ρ(τa) for eachτa ∈ prf(σ)

Therunρ is acceptingif f inf(ρ)∩F 6= ∅, whereinf(ρ) ⊆ Q is givenby q ∈ inf(ρ) if f ρ(τ) = q for infinitely manyτ ∈ prf(σ).

As describedin [12], the satisfiability problemfor DLTL can besolvedin deterministicexponentialtime,asfor LTL, by constructingfor eachformulaα ∈ DLTL(Σ) a Buchi automatonBα suchthatthelanguageof ω-wordsacceptedby Bα is non-emptyif andonly ifα is satisfiable.

A more efficient approachfor constructinga Buchi automatonfrom a DLTL formulamakinguseof a tableau-basedalgorithmhasbeenproposedin [6]. Givenaformulaϕ, thealgorithmbuildsagraphG(ϕ) whosenodesarelabelledby setsof formulas.Statesandtran-sitionsof the Buchi automatoncorrespondto nodesandarcsof thegraph.As for LTL, the numberof statesof the automatonis, in theworstcase,exponentialin thesizeif theinputformula,but in practiceit is muchsmaller.

Sincethe nodesof the graphG(ϕ) arelabeledby setsof formu-las,what we actuallyobtainby the constructionis a labeledBuchiautomaton,which canbedefinedby addingto theabove definition alabelingfunctionL : S → 2Lit, whereLit is thesetof all epistemicliterals. It is easyto obtainfrom an acceptingrun of the automatona setof modelsof thegiven formula.It is sufficient to completethelabelof eachstatein aconsistentway.

The validity of a formula α can be verified by constructingtheBuchi automatonB¬α for ¬α: if the languageacceptedby B¬α isempty, thenα is valid, whereasany infinite word acceptedbyB¬α

providesacounterexampleto thevalidity of α.For instance,givenacompleteddomaindescription

(Comp(Π) ∧ Init ∧∧

i(Permi ∧ Comi))

specifyinga protocol,we can constructthe correspondinglabeledBuchi automaton,suchthatall runsacceptedby theautomatonrep-resentrunsof theprotocol.

We will show now how we cantake advantageof thestructureoftheproblemsconsideredin thispaperto optimizetheconstructionoftheBuchiautomaton.Wecanpartitiontheabovedomaindescriptioninto two formulas

α = (Comp(Π) ∧ Init ∧∧

iPermi)

β =∧

iComi

whereα containsthe descriptionof the initial state,preconditionsandeffectsof theactions,andβ containstemporalformulasspecify-ing commitmentfulfillment.

TheBuchiautomatonfor thewholeformulacanbeconstructedbybuilding the two Buchi automatacorrespondingto α andβ andbymakingtheir synchronousproduct.The Buchi automatonfor β can

57

beconstructedwith thegeneralalgorithmmentionedabove. Instead,the Buchi automatoncorrespondingto α canbe easilyobtainedbymeansof a moreefficient technique,exploiting the fact that in ouractiontheorywe assumeto have completestatesanddeterministicactions.In fact,wecanobtainfrom thedomaindescriptionafunctionnext statea(S), for eachactiona, for transforminga stateto thenext one,andthenbuild theautomatonby repeatedlyapplyingthesefunctions to all stateswherethe preconditionsof the action hold,startingfrom theinitial state.

The approachwe have describedhere is similar to the modelchecking techniqueswhichareusedto provepropertiesof programs.For thisreasonwewill sometimescall modelautomatontheautoma-tonobtainedfrom α. Themaindifferencehowever is thatin thestan-dardmodelcheckingapproach,themodelis givenasatransitionsys-temandonly thepropertiesto beprovedareexpressedin a temporallogic. Here insteadwe usea uniform languageto expressboth theactiontheoryandits properties,andtheconstructionoutlinedaboveis just anoptimizationof thegeneralalgorithmfor obtaininganau-tomatonfrom a temporalformula.An advantageof this approachisthatwe canspecifya protocolby mixing actionrulesandprecondi-tionswith temporalpropertiessuchasthecommitmentrules.

4 Composing protocols

Assumenow thatwe have a serviceShfor shippinggoods,andthatthe customerwants to reasonon the compositionof the producerserviceof theprevioussectionandof this service.For simplicity weassumethat the protocolof the shippingserviceis the sameasthatof producerservice.To distinguishthe two protocolswe will addthesuffix Pu or Shto their actionsandfluents,while therole of theshipperwill bedenotedby S. TheShprotocolrulesthe interactionsbetweenacustomerC andashipperS.

ThedomaindescriptionDPS of thecomposedservicecanbeob-tainedby takingtheunionof thesetsof formulasspecifyingthetwoprotocols:DPS = DPu ∪ DSh. Sincewe want to reasonfrom thesideof the customer, we will replacethe epistemicoperatorsKC,P

andKC,S with KC , representingthe knowledgeof the customer.Thus the runsof the composedservicePS aregiven by the inter-leaving of all runsof thetwo protocols.

Theaim of thecustomeris to extractfrom thedomaindescriptionof PS a plan allowing it to interactwith the two services.Thegoalof the plan will be specified by meansof a setof constraintsCon-str which will take into accountthepropertiesof thecomposedser-vice. For instance,thecustomercannotrequestanoffer to theship-pingserviceuntil it hasnot receivedanoffer from theproducer. Thiscanbe easilyexpressedby addinga new preconditionto the actionrequest Sh(C, S):

2(¬KC(offered Pu) → [request Sh(C ,S)]⊥)Otherconstraintcannotbe easilyexpressedby meansof precon-

ditions, since they involve more “global” propertiesof a run. Forinstancewe expectthat the customercannotacceptonly oneof theoffersof thetwo services.Thispropertycanbeexpressedby thefol-lowing formula

3〈accept Pu(C, P )〉 ↔ 3〈accept Sh(C, S)〉

statingthatthecustomermustacceptbothoffersor noneof them.Then,thespecificationof theinteractionprotocolof thecomposed

serviceis givenby DPS∪Constr, from whichthecustomerwill ex-tracttheplan.To dothis,however, wemustfirst discussanimportantaspectof theprotocol,i.e. thedifferentkindsof nondeterminismin-volved.

Weassumethat,if aprotocolcontainsapointof choiceamongdif-ferentcommunicativeactions,thesenderof theseactionscanchoosefreelywhichoneto execute,and,on theotherhand,thereceivercan-not make any assumptionon which of the actionsit will receive.Therefore,from the viewpoint of the receiver, that point of choiceis a point of nondeterminismto careabout.For instance,the cus-tomercannotknow whethertheservicePu will reply with offer Puor not avail Pu after receiving the request.Thereforethe customercannotsimply reasonan a singlechoiceof action,but he will haveto considerall possiblechoicesof the two services,thusobtainingalternative runs,correspondingto a conditionalplan. On the otherhand,thecustomerhasnot to careabouthisown choices.

An exampleof conditionalplanis thefollowing7

begin Pu; requestPu;(offer Pu; begin protocol Sh;requestSh;

(offer Sh;acceptPu; acceptSh;endPu; endSh+not avail Sh;refusePu; endPu; endSh))+

(not avail Pu; endPu)

Thisplanis representedasaregularprogram,where,in particular,“+” is thechoiceoperator.

Thefirst stepfor obtainingaconditionalplan consistsin buildingtheBuchiautomatonobtainedfrom thedomaindescriptionDPS andtheconstraintsConstr. As wewantto reasonabouttheexecutionsofthe protocol satisfyingthe constraints,from the composeddomaindescriptionDPS we can computethe next state function definingthestatetransitionsof themodelautomatonof thecomposedproto-col. Thesynchronousproductof suchanautomatonwith theBuchiautomatonBConstr for theconstraintformulaConstr(whichalsoin-cludesthe fulfilment constraints

∧iComi) is thencomputed.This

productcaneitherbe doneon the fly while building the modelau-tomatonor it canbe doneafter the modelautomatahasbeencom-pletelybuilt.

While performingtheproductoperationa specialattentionhastobedevotedto avoid cuttingout actionswhich canbereceivedby thecustomer(suchasoffer Shandnot avail Sh) which, thoughallowedby theprotocol,mightnotsatisfytheconstraints.In fact,sinceweareusinga lineartime temporallogic, theconstraintsin Constrcanonlyexpresspropertiesdealingwith a single run. For instance,the runbegin Pu; requestPu; offer Pu; acceptPu; begin Sh; requestSh;offer Sh; acceptSh; endPu; endSh is correctwith respectto theabove constraints,sinceboth offers areaccepted.However, assumethat the customerchoosesto executethis plan,and,after executingactionrequestSh, theshippingservicereplieswith not avail Sh. Atthis point thereis no otherway of continuingthe execution,sincethecustomerhasalreadyacceptedtheoffer by theproducer, while itshouldhave refusedit.

If in astates of themodelautomatonasetof “receive”actionsarepossible,all the statess′ which areobtainedfrom s in the productautomatonmust satisfy the condition that all the “receive” actionspossiblein s arealsopossiblein s′. If this happensto be falsedueto missingtransitionsin theconstraintautomaton,theresultingstatein theproductautomatonis kept to bea danglingstate(a statewithno outgoingedges).The intuition is that sucha staterepresentsafailurestateasit cannotdealwith all thepossible“receive” actionsoccurringin thecorrespondingstateof theprotocol.

To take this into account,we will mark as AND statesthosestatesof themodelautomatonwhoseoutgoingarcsarelabeledwithactionswhosesenderis one of the services,such as offer Pu or

7 Weomit senderandreceiverof communicativeactions.

58

not avail Pu8. A conditionalplan can thenbe obtainedby search-ing theproductautomatonwith a forward-chainingalgorithmwhichconsidersall AND statesasbranchingpointsof theplan.

The complexity of this algorithm dependson the way it is im-plemented,in particularon thepossibilityof keepingin memoryallstatesof the productautomaton.If the algorithmdoesnot remem-ber thestatesit visits, exceptfor thoseon thesearchstack,thenthecomplexity will beexponentialin thesizeof theautomaton.

Ontheotherhand,if theproductautomatonis given,thesearchfortheconditionalplancanbedoneby makinguseof fasteralgorithms,so that the problemof finding a conditionalplan canbe solved inpolynomialtime in thesizeof thegraph.In facta depth-first searchalgorithmcantry to build theconditionalplanby visiting thegraphwithout expandingagain a nodewhich hasalreadybeenvisited.Fortheapplicationunderconsideration,theproblemis furthersimplifiedby the fact that web servicesarealwaysassumedto terminate,andthusacceptingrunsalwayscontainfinite sequencesof actionsdiffer-ent from the noop action,followed by a sequenceof noop actionsendingin anacceptancecycle.

In the casethe completeproductautomatonis given, we mightadopta differentapproachto theconstructionof a conditionalplan,consistingin “pruning”oncefor all the automatonby removing allarcswhich do not leadto anacceptingstate,andall AND statesforwhich thereis someoutgoingarc not leadingto an acceptingstate.This canbe achieved by startingfrom the acceptingstates,andbypropagatingbackwardstheinformationon thestatesfor which a so-lution exists.

In this way we are guaranteed that, if there is a runσ1; offer Sh; σ2 , whereσ1 andσ2 aresequencesof actions,theremustalsobea run σ1; not avail Sh; σ3, for somesequenceof ac-tionsσ3. Thereforethecustomercanexecutethefirst partσ1 of therun,beingsurethatit will beableto continuewith runσ3 if theship-ping servicereplieswith not avail Sh. In otherwords,thecustomerwill beableto actby first extractinga linearplan,andbegin execut-ing it. If, atsomestep,oneof theservicesexecutesanactiondifferentfrom theonecontainedin theplan,thecustomercanbuild anew planoriginatingfrom thecurrentstate,andrestartexecutingit.

In theconstructionof theconditionalplan,we have takeninto ac-countonly thenondeterministicactionsof thetwo services.Howevertherearesomechoicesregardingthe actionsof the customer, suchas acceptPu or refusePu, that cannotbe madeat planningtime.Thesenondeterministicchoicescanalsobe consideredin a condi-tional plan.In our examplewe might have thefollowing conditionalplan

begin Pu; requestPu;(offer Pu; begin protocol Sh;requestSh;

(offer Sh;(acceptPu; acceptSh;endPu; endSh+refusePu; refuseSh;endPu; endSh)+

not avail Sh;refusePu; endPu; endSh))+(not avail Pu; endPu)

Notethat,in thecaseof nondeterministicactionsof thecustomer,wearenot imposingall choicesto bepresentin theconditionalplan,as we did for the actionsof the other participants,becausesomechoicesmight not be possibledue to the constraints.For instance,afteracceptPu thecustomermustnecessarilyexecuteaccept Sh.

Up to now the kind of reasoningperformedon composedproto-cols hastaken into accountonly the “public”actions,i.e. the com-

8 For simplicity, we assumethat thereis no statewhoseoutgoingarcsarelabeledwith actionssentandreceivedby thesameagent.

municativeactionsof thecomponentprotocols.However, in general,thecustomershouldbeableto use“private”actionsto reasonaboutthe information received from the servicesand to decidewhat ac-tion to execute.Sincethe information sentby the serviceswill beavailableonly at runtime,suchan actionshouldbe consideredasanondeterministicactionatplanningtime.Wemighteasilyextendourapproachto thiscaseby extendingthespecificationof thecomposedserviceswith “private”actionsandfluentsof thecustomer.

Theapproachdescribedin this sectioncanbeappliedto themoregeneralproblemof building a new servicethat is able to interactdirectly with thecustomerthrougha suitableprotocol[19]. Thefirststepis to put togetherthethreeprotocolsdescribingtheinteractionswith thetwo servicesandwith thecustomer. Thenext stepis to addsuitableconstraintssimilar to theonesgivenabove.For instancewemaystatethattheoffer of eachof thetwo servicescanbeacceptedifandonly if thecustomeracceptsthem:

(3〈accept Pu〉 ↔ 3〈accept Cu〉) ∧(3〈accept Sh〉 ↔ 3〈accept Cu〉)

wherethesuffix Cu refersto theinteractionprotocolof thecustomer.We canthenproceedasbeforeby building the Buchi automaton

fromthecomposedprotocolandextractingfrom it aconditionalplan.Thisplancanbeconsideredasaspecificationof the(abstract)behav-ior of thenew service.

As a final remark,a differentproblemthat canbe tackledin thisformalism,if thespecificationof thenew serviceis given,is thatofverifying thatthenew servicecanindeedbeobtainedby composingthecomponentservices.This requiresto verify that,in everyrunsat-isfying theactionspecificationaswell asthenew protocolspecifica-tion,all thepermissionsandcommitmentsof thecomponentservicesaresatisfied.This kind of verification requiresa validity check.Weomit thedetailedspecificationof this taskfor lackof space.

5 Conclusions and related work

In thispaperwehavepresentedanapproachfor thespecificationandverification of interactionprotocolsin a temporallogic (DLTL). Ourapproachprovidesa unified framework for describingdifferentas-pectsof multi-agentsystems.Programscanbeexpressedasregularexpressions,(communicative) actionscanbe specifiedby meansofactionandpreconditionlaws,socialfactscanbespecifiedby meansof commitmentswhosedynamicsis ruled by causallaws, andtem-poral propertiescanbe expressedby meansof temporalformulas.To dealwith incompleteinformation,we have introducedepistemicmodalitiesin the language,to distinguishwhat is known aboutthesocialstatefrom whatis unknown.

Variousverification problemscan be formalizedas satisfiabilityandvalidity problemsin DLTL, andthey canbesolvedby developingautomata-basedmodelcheckingtechniques.

Our proposalis basedon a social approachto agentcommuni-cation,which allows a high level specificationof the protocolanddoesnot requirea rigid specificationof thecorrectactionsequences.For this reasonthe approachappearsto be well suitedfor protocolcomposition,and,in particular, to reasonaboutcompositionof webservices.As a first stepin this direction, in [8] we have addressedthe problemof combiningtwo protocolsto define a new morespe-cializedprotocol.Herewe have shown thatservicecompositioncanbe modeledby taking the formulasgiving the domaindescriptionsof theservices,by addingto themsuitabletemporalconstraints,andtranslatingthesetof formulasinto a Buchi automatonfrom which a(conditional)plancanbeobtained.

59

Theproposalof representingstatesassetsof epistemicfluentlit-eralsis basedon [1], whichpresentsamodalapproachfor reasoningaboutdynamicdomainsin a logic programmingsetting.A similar“knowledge-based”approachhasbeenusedto define thePKSplan-ner, allowing to planunderconditionsof incompleteknowledgeandsensing[16]. PKSgeneralizestheSTRIPSapproach,by representinga stateasa setof databasesthat modelthe agent’s knowledge,andactioneffectsasupdatesto thesedatabases.

The problemof the automatedcompositionof web servicesbyplanningat the“knowledgelevel” is addressedin [18]. Webservicesaredescribedin standardprocessmodelingandexecutionlanguages,like BPEL4WS, andthenautomaticallytranslatedinto aplanningdo-main that modelsthe interactionsamongservicesat the knowledgelevel. The planningtechnique[19] consistsin the following steps.First constructa parallel statetransition systemthat combinesthegiven servicesin a planningdomain.The next stepconsistsin for-malizing the requirementsfor the compositeserviceasa goal in aspecific languagewhichallowsto expressextendedgoals[3]. Finallythe plannergeneratesa plan that is translatedinto a statetransitionsystemandinto aconcreteBPEL4WS process.Theplanningproblemis solvedby makinguseof thestateof theart plannerMBP.

Theapproachto webservicecompositionpresentedin this paperhasanalogieswith the onepresentedin [18], in particularwith re-spectto the sequenceof stepsperformedto build the plan. As wehave alreadypointedout, our approachbasedon DLTL providesaframework, wheredifferent aspectssuchas action theories,proto-colsandtheirpropertiescanbeexpressedin auniformwayasDLTLformulas.A further advantageis that DLTL formulascanbe trans-latedinto Buchi automata,from which it is easyto extract runsandplans.

In [2] theproblemof automaticservicecompositionis addressedassumingthat a setof availableservices(whosebehavior is repre-sentedby finite statetransitionsystems)is giventogetherwith apos-sibly incompletespecificationof the sequencesof actionsthat theclient would like to realize.The problemof checkingthe existenceof acompositionis reducedto theproblemof checkingthesatisfiabil-ity of aPDL formula.ThisprovidesanEXPTIME complexity upperbound.As a differencewith [2], in our approachclient requirementsarespecifiedby providing a setof conditionsthat the targetservicemustsatisfy. Thecompositionproblemconsideredin [2] is a gener-alizationof theverification problemwe have addressedat theendofsection4 to thecasewhentheprotocolof thetargetserviceis under-specifiedandthecomponente-servicesthatwill provide theservicesrequiredby theclient arenot known. Theextensionof our approachto dealwith underspecifiedspecificationsof thetargetservicewill besubjectof furtherinvestigation.

REFERENCES[1] M. Baldoni,L. Giordano,A. Martelli, andVivianaPatti. Reason-

ing aboutcomplex actionswith incompleteknowledge:a modalapproach.In Proc.ICTCS’01-LNCS2202, pages405–425,2001.

[2] D. Berardi,G.DeGiacomo,M. Lenzerini,M. MecellaandD Cal-vanese.Syntesisof UnderspecifiedCompositee-ServicesbasedonAutomatedReasoning.In Proc. ICSOC’04, 2004.

[3] U.DalLago,M.Pistore,P.Traverso:Planningwith aLanguageforExtendedGoals.AAAI 2002,447-454

[4] F.DignumandM.Greaves,“Issuesin AgentCommunication:AnIntroduction”. In F.Dignum and M.Greaves (Eds.), IssuesinAgentCommunication,LNAI 1916,pp.1-16,1999.

[5] N. FornaraandM. Colombetti.Defining InteractionProtocolsus-ing aCommitment-basedAgentCommunicationLanguage.Proc.AAMAS’03, Melbourne,520–527,2003.

[6] L. GiordanoandA. Martelli. Tableau-basedAutomataConstruc-tion for DynamicLinearTime TemporalLogic. Annalsof Math-ematicsandArtificial Intelligence, to appear, Springer2006.

[7] L. Giordano,A. Martelli, andC. Schwind.Verifying Communi-catingAgentsby Model Checkingin a TemporalAction Logic.Proc. Logics in Artificial Intelligence, 9th EuropeanConference,JELIA2004, Lisbon,Portugal,SpringerLNAI 3229,57-69,2004.

[8] L. Giordano,A. Martelli, andC. Schwind. Specializationof In-teractionProtocolsin a TemporalAction Logic. LCMAS05(3rdInt. Workshopon Logic andCommunicationin Multi- AgentSys-tems), Edinburgh,1stof August2005.

[9] L. Giordano,A. Martelli andC. Schwind.SpecifyingandVerify-ing InteractionProtocolsin a TemporalAction Logic Journal ofAppliedLogic (Specialissueon Logic BasedAgentVerification),Acceptedfor publication,2006,Elsevier.

[10] M. Greaves, H. Holmbackand J. Bradshaw. What Is a Con-versationPolicy?. Issuesin Agent Communication,LNCS 1916Springer, 118-131,2000.

[11] F. GuerinandJ.Pitt. Verification andComplianceTesting.Com-municationsin Multiagent Systems, SpringerLNAI 2650, 98–112,2003.

[12] J.G. Henriksenand P.S. Thiagarajan. Dynamic Linear TimeTemporalLogic. in Annalsof Pure and Applied logic, vol.96,n.1-3,187–207,1999

[13] N.R. Jennings.CommitmentsandConventions:thefoundationof coordinationin multi-agentsystems.In Theknowledge engi-neeringreview, 8(3),233–250,1993.

[14] N. Maudet and B. Chaib-draa. Commitment-basedanddialogue-game basedprotocols: new trends in agent commu-nication languages. In The Knowledge EngineeringReview,17(2):157-179,June2002.

[15] S.NarayananandS.McIlraith. Simulation,Verification andAu-tomatedCompositionof Web Services. In Proceedingsof theEleventhInternationalWorld Wide Web Conference(WWW-11),77–88,May 2002.

[16] R. Petrick and F. Bacchus.A knowledge-basedapproachtoplanningwith incompleteinformation and sensing.In Proceed-ings of the InternationalConferenceon Artificial IntelligencePlanning(AIPS),212-222,2002.

[17] M.PistoreandP.Traverso.PlanningasModel Checkingfor Ex-tendedGoals in Non-deterministicDomains. Proc. IJCAI’01,Seattle,479-484,2001.

[18] M. Pistore,A. Marconi,P. Bertoli andP. Traverso.AutomatedCompositionof Web Servicesby Planningat the KnowledgeLevel. Proc. InternationalJoint Conferenceon Artificial Intelli-gence(IJCAI), 1252–1259,2005.

[19] M. Pistore,P. TraversoandP. Bertoli. AutomatedCompositionof WebServicesby Planningin AsynchronousDomains.ICAPS2005.2–11,2005.

[20] R. Reiter. Theframeproblemin thesituationcalculus:asimplesolution(sometimes)anda completenessresult for goal regres-sion. In Artificial IntelligenceandMathematicalTheoryof Com-putation: Papers in Honor of John McCarthy, V. Lifschitz, ed.,359–380,AcademicPress,1991.

[21] M. P. Singh. Agent communicationlanguages:Rethinkingtheprinciples.IEEEComputer, 31(12),40–47,1998.

[22] M. P. Singh.A socialsemanticsfor AgentCommunicationLan-guages.In Issuesin AgentCommunication2000, SpringerLNCS1916,31–45,2000.

[23] B. Srivastava andJ. Koehler. Web ServiceComposition- Cur-rent Solutionsand OpenProblems,In ICAPS 2003 Workshopon Planningfor WebServices,Pages28 - 35, Trento,Italy, June2003.

[24] P. Yolum andM.P. Singh. Flexible ProtocolSpecificationandExecution: Applying Event CalculusPlanningusing Commit-ments.In AAMAS’02, 527–534,Bologna,Italy, 2002.

60

� � ��� ��������� ��� ����� �������� ����������������� ������� ��� !��"$#%�%�&�� ���%��� ���� ��� ��"'���)(*�+�)�,�

-/.10204365879. : ;<. =?>?. @?. =BA CED F GH. :E36IKJ2L�M$:E3N520O3P=$IRQ&SUT$5O58IV01

W X =U0O:4SY>ZT$[K0O3NSU=\Y]4^Z_`^bac]Ed4egfhejilknm opabegd4oP_cqld2_prOs`egils`^bo`oYtuqlvg^bopw4opx4w4yzf|{}t~els`^�qgdE{t~els`^&yzdE{O^brn^bdE{O^bd2_�{O^b�8yhab^bo�{O^�{Oyza�q�_`^�{,_`eR{Oyh�K^�s`^bdj_�igejqlfho����Nd_`]4yzo��Yqbkj� �B^��$yz{O^bd�_`]4^�yzdj_`^�s���qlab^��$y�_`]�]8w4t~qgd4ouqldE{�tuqlvg^�y�_t~els`^�abegt�rEfh^��K�p��{O^b�8yhab^�a�qld�x�^�qld2k�v8yhd�{�el�<tuqlac]Eyhd4^�qlx4fz^_`e�x�^�r4]2k8o`yha�qlfzf�k����8y|q�q��pyhs`^�els�q�a�qlx4fz^��~els�fhegigyza�qlfhfhkR���8yzq�qd4^�_N�/els`vO��abegd4d4^ba�_`^�{�_`e�el_�]E^�s<{4^b�2yzab^bob�9��{O^b�8yhab^�yzo el�pyhd2_`^�s`^boP_xn^ba�qlw4o�^ el� yh_`op��w4dEa�_�yzegdEqlfzy�_`yz^bob�n\Y]4^bdV��^b�g^bd¡yh�1_`]4ego`^ {O^b�8yhab^boZq�s`^abegt~r4fz^�_�^bfhk {Oyh�K^¢sc^bdj_��U�/^�a�qld�yhtuqligyzd4^�abegdEd4^ba�_�yzd4i�_�]E^bt�yhd)q{8kOdEqlt~yza�d4^�_6�/els`vn�4�$]4^�s`^£{O^b�8yhab^bo$abegw4f|{�qgr4r�^�qls?qldE{¡{Oyzo`qlr4rn^�q�s�$y�_`]4egwO_ ]Eq��2yzd4i¤q$�py|{O^/v2dEe��$fh^�{Oig^/el�E_`]4^B�p]Eegfh^/d4^�_6�/els`vn�l\Y]4^bdV�yh_}�/egw4f|{ xn^�w4o`^���w4f?_`e�o`^�q�s`ac]�q�{O^b�8yhab^���els�q�ils`ejw4r�el�<{O^b�8y�¥ab^boc�B_�]�q�_Ys`^�qlfzyh¦b^bo$q<ab^�s�_cqlyzd}��w4d4a�_`yhegd�qlfhyh_6kj�4elsp_�e~o�^bdE{�{4q�_cq<_�euq��wOs�_`]4^�s1{4^b�2yzab^+�p]4yzac]£tuq�_`ac]E^bo9qpab^�s�_cqlyhd£a�s`yh_`^�s`yzqpo`egt�^��$]4^�s`^U^bfzo�^yzd�_`]4^ud4^�_6�/els`vn�§�6d�elsc{O^�s£_`e¡]EqldE{4fh^uo�wEac]�¨2w4^�s`yz^bob�V�/^u]�q��g^~_`e{O^bo`a�s`yhxn^u{O^b�8yhab^bo��K_`]4^byhs���w4dEa¢_`yzegdEqlfzy�_`yz^bo£qld�{�_`]4^u{4q�_cq}_`]4^�ka�qld^��Oac]EqldEig^u�$y�_`]�el_`]4^�s`o��1©4egs _`]Eq�_�r4wOs`rnego`^g�§�/^�q�s`^u�/els`v8yzd4i�egdq�d4^��ªfzqld4igw�qlig^�el�Y{O^bo�a�s`yzrO_`yhegd�el�Y{O^b�2yzab^bob�Vyzd��$]4yha¢]�_`]4^���w4d4a�¥_`yzegdEqlfhyh_`yh^bo/q�s`^p«4s`oP_�¥¬abf|qlo�oUabyh_`yh¦b^bd4o��g­�^p�Yqld2_U_`e£tuqlvg^$y�_Brnego�o`yhx4fz^_`e�{O^�«Ed4^g�VyzdO��^�s£qldE{¨2w4^�s�k�r�ejo�o�yzx4fhk�abegt~rnego�^�{���wEd4a�_�yzegdEqlfzyh_�yz^bob�qldE{}_`e�s`^�_�s`yh^b�g^¤_`]4^u��ils`egw4r�el�c�Y{O^b�2yzab^boYs`^�qlfzyh¦byzd4i�_`]4^bt���Nd_`]4^�s`^btuqlyzd4yhdEi�el�B_`]4yzo�rnego`y�_`yzegd�rEqlrn^�s��V�/^�«4s`o�_£oP_cq�_`^�_`]4^f|qld4igwEqlig^Zs`^�¨2w4y�s`^bt~^bd2_`o/_�]�q�_/�/^¤t~el_�yz�lq�_�^¤x2k}{Oyh�K^¢sc^bdj_$qlr4r4fzyha�q�¥_`yzegd�o�ab^bdEq�s`yzegob�1\/]4^bdV�§�/^�rOs`^bo�^bd2_ _�]E^utuqlyzd�ac]Eq�scqla�_`^�s`yzoP_`yzabo el�_`]4^¤s`w4fz^¤xEqlo`^�{�fzqld4ijwEqlig^Z_`]Eq�_p�/^�rOs`egrnego�^g��®8yzd4ab^¤_`]4^¤o`r�^babyh«Ea�q�¥_`yzegd�el�+_�]EyhoZfzqldEigwEqlig^ yzoZqu�/els`v�yhd�rOs`egils`^bo`ob���/^p¯Pw4o�_Zyhfzfzw4oP_�scq�_`^yh_`opt~qlyzd�abegt~r�ejd4^bdj_`o$qldE{}��^�ql_�w4s`^boY_�]4s`egw4ig]�^��4qlt�rEfh^bob�° ± . =?²UT$. ²+IRQ&I�³pT?36:4I§´ªI§=B085­�^¡�$yzfhf?yzdj_�s`eO{Ow4ab^�]E^�s`^¡_`]Os`^b^�o`ab^bdEq�s`yhejou�$]4yzac]�yhfzfhw4o�_�scq�_`^¡_`]4^s`^�¨2w4yhs`^bt�^bd2_`opel�1egwOs?{O^bo�a�s`yzrO_`yhegd¡qld�{�¨jw4^�s�k�fzqldEigwEqlig^bob�°BµPW ¶ 3NIV·�3N=?²ª.¸·�I�@�[K.+´º¹p=$S§·�3P=$²»3¬0O5

¼NS/[V.9043NSU=\Y]4^«4s`oP_¡o`ab^bdEq�s`yze�abegt�^bo�_`e�o�]4e���_`]4^�yhd2_`^�s`^boP_¡el�<o�^�q�scac]4yzd4iq�{4^b�2yzab^�xjk�yh_`o fze2a�ql_�yzegdV� ®8w4r4rnego`^ukjegw�]�q��g^}q�{O^b�2yzab^}qlx4fz^u_`e{Oyzo�r4f|q�k�q��2y|{O^be�abegt~yhdEi��½s`egt¾q¡�/^bx�a�qlt��+®8w4rEr�ego`^�qlfho`e�_`]Eq�_kjegw�]�q��g^�_`e�{O^baby|{O^��p]E^¢_`]4^�s~k2egw�a�qld�ige_`e�o�v8yYyzd&qo`r�^babyh«Ea�$yhd2_`^�suo�rnels�_`o�s`^bo`els�_��+\§e�]4^bfzr�kjegw4suac]4egyzab^�kjegw�tuq�k��Yqld2_~_`eo�^�qls`ac]�q}�/^bxa�qlt�dE^�q�s¤_`]4^<s`^bo`els�_�o�e�_`]Eq�_¤kjegw�abqgdac]E^bacv¡_`]4^¨2wEqlfzy�_6k�el�n_�]E^Yo�dEe��£�j\/]E^bdV�lkjegwOsB¨2w4^�s�k<yzo+qgx�egw4_UqZ��w4d4a�_`yzegdEqlfhyh_6k¿ a�qlrO_`wOs`yzd4i��8yz{4^be�el��^bd8�2yhs`egd4t~^bdj_ ¿ rn^�s���els`t~^�{&x2k q�{O^b�2yzab^��egwEdE{�xjk�y�_`opfze2a�q�_`yzegd ¿ dE^�q�s$q�ab^�s�_cqlyzd��pyzdj_`^�s$o�rnels�_`oYs`^bo�els�_��1 ÀKÁgÂ1Ã�ÄÆÅ~ÇUÈ É+ÊjË Ì�ÍcÎ6Ï6Ë Ð�Ñ Ò�ÓÔÈ/Î6Í`ÊjÒ�ÕjÖ Í�×ÙØ2ÎNÚbÊjÛcÍ�×ÙÍ`Ü�ÚbË�Ö½ÝÞ ÏPÚ�Ð6ÐNË Ï6Ì�ÚbÎcß ÐNÚ�Êjà2ÚbÕ2Ú�Ê�Ñ�× Ü�ÚbÎ6Ë�Í�Ã�ÛPájÎ6Ë Ï6ÐNË ÊjÍ�ß Î6Ò�âjÏ6ÏNÍ�Ðcã�äBË�ܤÚ�åjß ÓzÎ

°/µ¬° ;<:4.+=$58æ¢I�:4:E3N=$²ªç�¼6I�5\Y]4^�o�^babegd�{�o�ab^bdEq�s`yze�o`]4e��$oZ_`]4^�dE^bab^bo�o�yh_6k�el�U«Ed�{OyhdEi�q��Yqbk�_`e^��Oac]Eqgd4ig^£{4q�_cq�x�^�_N�/^b^bd�_6�/eu{OyzoP_cqld2_${4^b�2yzab^bo£����els$yzd4oP_cqld4ab^¤«Efz^boxn^�_6�/^b^bd�abegt~r4wO_`^�s`oc�+�$y�_`]4egw4_/�/els�s�kOyhd4i~qlxnegwO_Y]4e��)_�e~{Oe<yh_��O�6d_`]4^�a�qlo`^�el�¤_N�Be�{Oyho�_cqldj_}abegt~r4wO_`^�s`o��U^��Oac]�qld4igyhdEi�«Efz^bo�a�qld xn^o`yht~r4fz^¡y��Z_`]4^�k&q�s`^¡xnel_`]&abegd4d4^ba�_`^�{�_`e�_`]4^¡�Ndj_`^�s`d4^�_��Uegd4^¡a�qldr4wEx4fhyzo�]}yh_`oB«Efz^?egd�_`]4^?�/^bx�qldE{�igyz�g^?_�]E^?è?é?ê�_�e _`]4^Zel_`]4^�sYegd4^yzd�elsc{O^�s$_�e~��^�_`ac]�yh_��4ëZe��£�4yh�1^�qla¢]�egd4^�el�1_`]4^bt�yho$abegd4d4^ba�_`^�{}_`e{Oyh�K^�s`^bdj_$ê��$ë �8_`]4yzd4igoYa�qld}xn^babegt~^Zt~els`^Zabegt~r4fzyha�q�_`^�{K�4©1yhdEqlfzfhkg�yh�+�/^ �Yqld2_Z_�e�^¢�Oa¢]Eqld4ig^�{4q�_cq�xn^�_6�/^b^bd�eg_�]E^¢s�v2yzdE{Oo¤el�B{O^b�8yhab^bob��/^Z�pyzfhfK]Eq��g^?_`e<«EdE{�qldE{�]EqgdE{Ofh^�q rnego�o`yhxEf�k�fzegd4i<rEql_�]�xn^�_6�/^b^bd_`]4^bt��

°/µ�ì í 36586.VA$3P=$²»3P=�.¸>¤365808.+=U0�¼NSY[K.10O3NSU=ï?^�s`^�yzo�q�t~els`^�abegt~r4fz^�_`^�o`ab^bdEq�s`yze4�p�6_¡fz^�_`o�qlr4rn^�q�s¡_`]Eq�_¡_`]4^abegt~rnego�yh_`yhegd�el�E��w4d4a�_`yhegd�qlfhyh_`yh^bo a�qld�x�^Yyhd2_`^�s`^boP_`yhdEi4�j®8w4r4rnego�^/kjegw]Eq��g^�qurK{8�+«�fh^<oP_`els`^�{�o�egt~^��$]4^�s`^<yhd�kjegwOs¤abegt~r4wO_`^�s��VqldE{¡kjegwd4^b^�{ð_`e){Oyzo�r4f|qbkRy�_�_�]4s`egw4ig],q&�8y|{O^be�rOs`e�¯P^ba�_`elsfhe8a�q�_`^�{Ryhd,q{OyzoP_cqld2_ s`e8egtñ�p]4^�s`^�rn^begr4fz^}q�s`^u�Yqgy�_`yzd4i¡_`e¡�Yq�_`ac]�y�_�� ®8e4�§kjegwq�s`^�o�^�q�s`a¢]4yzd4i���els�q�{O^b�8yzab^�qlxEfh^�_`e�{4yho`r4fzq�k�kjegw4s�«Efz^�yhd _`]Eq�_s`e8egt��g�¬_Uo�egw4d�{Oo+fhyzvg^Y_`]4^/«Es`oP_+o`ab^bdEq�s`yze¤xEwO_��l_`]4^p�2y|{O^be�rOs`e�¯P^ba�_`elsa�qld4dEel_�{Oyho`r4f|qbk�«Efz^bo£�½s`egtòqld2k�abegt�rEwO_`^�s<x4wO_ �½s`egtñ_`]4^�egdE^�y�_yzo�abegdEd4^ba�_`^�{�_`e4�Z\/]4yzo�t�^�qldEo¡_`]4^�^��Orn^ba�_�^�{�qld4oP�/^�s�_�e kjegwOs¨2w4^�s�k)yzo¡q�abegt~rnego�^�{)��w4d4a�_`yzegdEqlfzy�_6kKóY«4s`oP_��YkjegwOs¡«Efh^�t w4oP_¡xn^_�scqld4o���^�s�s`^�{�_`e�_`]Eql_ abegt~r4wO_`^�s���_`]4^bd�yh_<t w4oP_<xn^uabegd8�g^�s�_`^�{�xjk_`]Eq�_9abegt�rEwO_`^�s§yzd qY�8yz{4^bepo�_Ps`^�qlt��b�$]4yzac]£yho§o`^bdj_§_�ep_`]4^UrOs`e�¯P^ba�_`els_`e~xn^�{4yho�rEfzq�kj^�{K�

°/µ�ô ;�M$IR:4I�³YTZ36:4I§´ªI§=B085\Y]4^&o�ab^bd�q�s`yhego�yhd2_�s`eO{Ow4ab^�{¸rOs`^b�8yzegw4o�fhk¸o�w4igig^bo�_�_�]E^���egfzfhe��pyzd4is`^�¨2w4yhs`^bt�^bd2_`o/��elsYegw4sYf|qld4igwEqlig^g�8­�^¤d4^b^�{�el�9abegwOs`o`^?_`e�{O^bo`a�s`yhxn^q»{O^b�8yhab^�xjk�o`r�^babyh�½kOyhd4i»yh_�o ��w4dEa�_�yzegdEqlfzyh_�yz^bob�}\Y]4^�yht~rnels�_cqldj_rnegyzdj_Zyzo$_`]Eql_?�/^ d4^b^�{�qus`yha¢]�{O^bo`a�s`yhrO_`yzegd�el�+��w4d4a�_`yzegdEqlfzy�_`yz^�o��n�6drEqls�_�yzabw4f|q�s��§_`]4^}t~els`^u_`]4^���w4d4a�_`yzegdEqlfzy�_`yz^bo�q�s`^�abegdEoP_�scqlyzd4^�{K�§_`]4^^�qlo`yh^�sUyh_Uyzo _`e¤«Ed�{<_`]4ego�^$abels�s`^bo�rnegdE{Oyzd4i¤_`e£q¤ijyh�g^bduo�rn^baby�«Ea�q�_`yzegdels ¨jwE^�s�kj��\/]4^�s`^���els`^g�K�/^<�$yhfzf w4o�^�_cq��8egdEegt�yz^bo¤��els�_6k8rEyhd4i¡{O^b�8y�¥ab^bo��g��wEd4a�_`yhegdEqlfzyh_�yz^bo/qldE{�_`]4^byhsByzd4r4wO_`oBqld�{~egwO_`r4w4_�o��g­�^$�pyzfhfnqlfzo�eqlfzfze���_�]E^/o�rn^baby�«Ea�q�_`yzegd<el��rOs`^babegd�{Oy�_`yzegd4o qgdE{ rnegoP_`abegdE{Oyh_`yhegd4o1��els^��OrOs`^bo�o`yhdEi/_`]4^+abegdE{Oyh_`yhejd4o�w4dE{O^�s��$]4yha¢]¤_�]E^1��w4d4a�_`yhegd�qlfhyh_6kZa�qld�xn^s`^�qlfzyz¦�^�{V�4qldE{}_�]E^?sc^�f|q�_`yzegd4o�]4yzr4oYxn^�_6�/^b^bd�yh_`oYyzd4r4wO_`opqld�{}egwO_`r4wO_q��½_`^�sYyh_`oBs`^�qlfzyh¦�q�_`yzegd��rnego�o�yzx4fhkux2kuo`rn^baby��½kOyhdEi _�]E^Zabels�s`^bo�rnegdE{Oyzd4i��wEd4a�_`yhegdV�2yh��y�_/yhoBv8d4e��$d��¢�j­�^$dE^b^�{uqlfzo�e£_`e£dEqlt~^$_`]4^ ��o�yzt~r4fz^$elsabegt~rnego�^�{E����w4dEa�_�yzegdEqlfzyh_�yz^bo<yzd�elsc{O^�s<_`e�abegt~rnego�^�_`]4^bt¾qldE{�_`eo`r�^babyh�½k�_`]4^byhs$yhd4rEwO_`ob�4egw4_�rEwO_`o$qldE{�rnego�o�yzx4fhk}el_`]4^�s$rOs`egrn^�s�_`yh^bo��

61

©EwOs�_`]4^�s`t~els`^g���/^Yd4^b^�{<_�e¤o`r�^babyh�½k<rOs`egrn^�s�_�yz^bo1_`]Eq�_Uq�s`^Yo�rn^babyh«Ea_`e�{O^b�2yzab^bo ¿ fhyzvg^�yh_`our4]2k8o�yza�qlfpfze2a�q�_`yzegdV�+yh_`o�q��lqlyhf|qlx4yzfhyh_6k�egsuyh_`oa�qlrEqlabyh_6k ¿ qld�{u_�e _`]4^?��w4d4a�_`yzegdEqlfzy�_`yz^bo/el�9{O^b�2yzab^bob�O�6d}rEq�s�_`yza�wEfzq�s��tuqld2k {O^b�8yhab^bo+q�s`^Byzt~t~^�s`o�^�{ yzd _�]E^B^bd8�8y�s`egdEt�^bd2_��g®8ejt�^/el�E_`]4^bt��^g� i4��o�^bd4o`els`ob�nabqgt�^�scqlo���a�qlrO_`els`o �z�h� �pig^�_$_`]4^ yhdEr4wO_`o$��elsZo�egt~^ el�_`]4^byhsZ��w4d4a�_`yzegdEqlfhyh_`yh^boZ�½s`egt�_�]E^<^bd2�8y�s`egdEt�^bd2_¤yhd��$]4yzac]�_`]4^�k�q�s`^fze2a�q�_`^�{K��®8egt~^<el_�]E^�s`o���^g� i4�K]4^�q�_`^�s��no`r�^�qlvg^�s��KrOs`e�¯P^ba�_`els��1�h�z� �?qla�_egd&_`]4^¡^bd8�8y�s`egd4t~^bd2_�yzd��$]4yzac]&_`]4^�k&q�s`^¡fze2a�q�_`^�{�_`]Os`egw4ig]&_`]4^egwO_`r4w4_�opeg�9o`egt~^¤el�9_`]4^byhsp��w4d4a�_`yhegd�qlfhyh_`yh^bo��©9yzdEqlfzf�kj�§egdE^ut wEoP_<qlfzfhe�� _`e¡^��OrOs`^bo�o abegt~r4fz^���¨jwE^�s`yh^bo£�$]4yha¢]o�rn^babyh�½k�_`]4^uo�^�q�s`a¢]4^�{&��ils`egw4r�el�c��{O^b�2yzab^bo£els£��w4d4a�_`yzegdEqlfzy�_`yz^bo£xjkrEq�s�_`y|qlfhfhk}yzd4o�_`qld2_`yzql_�^�{�rEq�_�_`^�s`d4opegspabegdE{4y�_`yzegd4ob��6_$yhop�/els�_`]¡d4el_`yhabyzd4i�_`]Eql_$t~egoP_$el�1_`]4^¤s`^�¨2w4yhs`^bt�^bd2_`op_�]�q�_p�/^]Eq��g^Urnegyhd2_`^�{�egwO_§��els1{O^bo`a�s`yhxEyhd4i?{4^b�2yzab^+��w4d4a�_`yzegdEqlfhyh_`yz^bo9qlfho`e$]4egf|{��els<{O^bo�a�s`yzx4yhdEi�o�^�s`�8yzab^bob���6d��qga¢_��V_`]4^���w4d4a�_`yhegd�qlfhyh_`yh^bo£el�Y{O^b�8yzab^boa�qlduxn^$o`^b^bd�qloBo�^�s`�8yhab^bob�8\Y]4^�s`^���els`^g�2egwOsBf|qld4igwEqgig^$abegw4f|{uqlfzo�e£xn^w4o`^�{}��els?{O^bo`a¢scyhx4yzd4i~yzt~t~q�_`^�s`y|qlfVo`^�s`�2yzab^bob�Ey�� ^g�z�4o�^�s`�8yzab^boY_`]Eq�_?q�s`^d4el_ps`^�qlfzyh¦b^�{�x2k�q�r4]2k8o�yza�qlf�{4^b�2yzab^g�4x4wO_$x2k�q�o�el�½_6�pq�s`^g�

ì ��T$:��:4S+î£S+58.+¼­�^Zr4s`egr�ejo�^¤q<fhegigyza�qlfns`w4fz^ZxEqlo�^�{}f|qld4igwEqlig^Z�p]4yzac]�oP_`yhfzfKd4^b^�{Oo/_`exn^/«EdEqlfzyh¦b^�{��½_`]4^Yo�k8d2_cq��K�gqlt~egd4i¤el_`]4^�s`o¢�c�j\Y]4yho+fzqldEigwEqlig^/�pyzfzfOxn^o�]Ee��$d�yhd�_`]4yzopo�^ba�_`yhejd�yzfzfhw4o�_Ps¢q�_�^�{�x2k}^��4qlt~r4fz^�o��

ìYµPW � .15O3N[�[KSB´¸î£SU=?I§=U0O5�S+æ}SUT$: ¼6.+=$²UT?.1²UI������ � �����������������­�^${O^�«�d4^Y_cq��8egdEegt�yz^boUqloUo�yzt~r4fh^pyzd4abfzw4o�yzegd~o�_`q�_`^bt~^bd2_�oUxn^�_6�/^b^bdabf|qlo�o�^bou�$]4yzac]�q�s`^¡w4d�q�s�k�s`^bfzql_�yzegd4o��B\/]4^¡��egfzfhe��pyzd4i�yhd2_�s`e8{4w4ab^bo��egw4s£{4y��K^�s`^bd2_¤_cq��Oegd4egt~yh^bo£d4^b^�{O^�{�_`e�_6k8rn^~egx8¯P^ba�_`o¤�/^~]Eqld�{Ofh^g�dEqlt~^bfhk�{O^b�8yhab^bo��E{4q�_cqO�4fze8a�q�_�yzegd4o$qld�{}��w4d4a�_`yhejdEqlfhyh_`yh^bo�ó•­�^�{O^�«Ed4^�q_cq��8egdEegt£k���els������! #"���$c�U©Eels�yhdEoP_cqld4ab^¡]4^�s`^�q�s`^o�egt~^Yabf|qlo�o`^bo el�V{O^b�8yhab^bo�ó�%�&4�('*),+�-*.�/E�*0�1)*/�23.42�)*5()*/E��%(/6!+�5()*/E�7 )98*5()*/E��:;69-!<;=*8*>()*/E��%(/�.9?*)@,5�.�/E�4qldE{A'(@,/()9),+K�O\Y]4^bd}o`egt~^Zel�_`]4^btòq�sc^}o�w4xnabfzqlo`o�^bo<el�$eg_�]E^�s`ob�§��els�^��Oqlt~r4fz^gó�%(/.9?*)�@,5�.�/

@:;69-!<;=*8*>()*/@:�)*B69@*)

•­�^�{4^�«Ed4^qld4el_`]4^�s}_cq��8egd4ejt£k���elsC�9D�EFDl�/©4egs}yzd4oP_cqld4ab^g�/egd4^tuqbk]Eq��g^�_`]4yho£v8yhd�{el�Y{Eq�_cqOó %(:(GE�H%'O�HG;6*=*)4��els`ijqld4yz¦b^b{_`]4yzo�YqbkKóI%9:(G

@G6*=*)4�J%'

@G6*=*)�qld�{KG6*=*)

@:�8*5(8E�9­�^�qlfzo�e

rOs`e��8y|{O^~_`]4^uabfzqlo`oML*+�B6,/.�+�2�),+�5¡�pyh_`]�q�o�rn^baby|qlf+t~^�qld4yzd4i4�§�¬_oP_cqldE{Oo1��els _`]4^ON abegd2_`^��2_�mgqldE{<]4y|{O^bo+qlfzf4{4q�_cq?yzd4abegt~yhdEi?�½s`ejt,elsegwO_`igegyzd4i}_`e�qldjk8_`]4yhdEi�x4wO_£q}v8d4e��$d�{O^b�8yhab^g��©4els�yzd4oP_cqld4ab^g��qrOs`yzdj_`^�s/rOs`e��8yz{O^boYq£rOs`yzdj_`^�{�rEqlr�^�s/�p]4yzac]}d4e el_`]4^�sY{O^b�8yzab^?a�qlda�q�_`ac] {Oy�s`^ba�_`fhk�qldE{�qlw4_�ejt~q�_`yza�qlfhfhk P�rOs`e�¯P^ba�_`els`obm�{Oyzo�rEfzq�k¤a�qld4d4el_xn^Za�qlw4il_`]�xjk}qgdjk}{4^��8yzab^bo4P4q<]4^�q�_`^�sYrOs`e��8yz{O^bo/�Yq�s`t _�]QP8_�]E^bo�^yhd2_`^�scqla�_`yhegdEoU�pyh_`]u_`]4^?^bd8�2yhs`egd4t~^bdj_Yq�s`^?rEwO_/w4dE{O^�sB_`]4yzoBabf|qlo�ob�

•­�^{O^�«EdE^�kj^�_�qld4el_`]4^�s�_cq��8egdEegt£k&��elsSR3TUD9"���$�elsCTWV�"XD�E #V�Y�$`�ï?^�s`^<q�s`^ o�egt~^ yhdEoP_cqld4ab^bo?el�+fze2a�q�_`yzegd4oZL�89/95�1n��L*[�/�.�<;)4�]\-96�84�G9/(8,+�@�)4�_^(`��Oa�8,<8,+n�b%�8*/6(-8�c0�.�d�>�.O�B­)yh_�]�_`]4^bo`^�yzd4abfzw4o�yzegd4obóG9/(8,+�@�)

@L*[�/�.�<)

@L�8*/95�1

@^9+]6,B()*/-�)4�Eqld�{}o`e~egdV�

•­�^�{O^�«�d4^�q�_cq��Oegd4egt£k���elsfehgY3"iE #V�Y3D*T jE ��$ ��ï?^�s`^�q�s`^o�egt~^ ^��Oqlt~r4fz^boRel����wEd4a�_`yhegdEqgfhyh_`yh^bobók:;69-!<;=*8*>E�ml�n4:;69-!<;=*8*>E�0�1)*/�2].42�)*5()*/�n�'*),+�-*.�/E�;09/(8,+�-,o�)*/E�%(/6!+�5E���h�z�

�����qp rM�#����s!tSuv�,wx��yF�F��� �­�^£qlfzfhe��Rqlfzo�e~x4yzdEq�s�k�s`^bf|q�_`yhejd4oYs`^brOs`^bo�^bd2_`yhdEi�r4s`egr�^�s`_�yz^bopegd¡{O^�¥�8yhab^bo+qld�{£��wEd4a�_`yhegdEqgfhyh_`yh^bob�j\/]4ego`^Bs`^bf|q�_`yhejd4o+q�s`^B_Nk8rn^�{<xjk<abfzqlo`o�^bob�ï?^�s`^£q�s`^�o�egt~^�el�9_�]E^Zs`^bf|q�_`yhegdEoYkjegw�a�qld�t�^b^�_�ó

•©4els�_N�/e�yhdEoP_cqld4ab^bo

D1

qldE{D2

el�B_`]4^~abf|qlo�oM:�)*B69@�)4�V�/^~o`qbk_`]Eq�_z&(.�+9+)@,5()*{

(D1, D2)yho£_�s`w4^�y��$qldE{�egd4fhk�y��

D1

qldE{D2q�s`^�^by�_`]4^�s$fzegigyha�qlfzf�k�els$r4]jkOo�yza�qlfzf�k�a�ejd4d4^ba�_`^�{ P

•©4els�qld�yzd4oP_cqld4ab^

del�+_�]E^ abf|qlo�oO:�895(8}qld�{¡��els�qld�yhd4o�_cqld4ab^

Del�1_`]4^£abf|qlo�oZ:�)*B69@�)4� '�5�.�/()*{(d, D)

yzop_�s w4£yh�+qldE{¡egd4fhk�yh�1_ ]4{4q�_cq

dyzopoP_ els �{�yzd�_�]E�{Ob�8yzab

DP

•©4elsBqld~yzd4oP_cqld4ab

d�½s bo rV�

D�9el�n_ ]4pabf|qlo�o|:�8*5(8u��s bo�r���:�)*B69@�)2�

qldE{£��els+qld�yhd4o�_ qgd4abLel�E_ ]4/abf|qlo�o�(+�6,B()*/-�)4��};.(@�8*56*.�+

(d, L)��s bo�rV�c}.(@�8*56*.�+(D, L)

��yzo}_�s w4yh�<qldE{)egd4fhk yh�£_ ]4�{4q�_cqd��s bo�rV�

D�/yhopfze8abql_��{�q�_p_ ]4¤fze8a�q�_ yhegd

LP

•©4elsYqld�yzd4o�_ qldEab

Fel�V_ ]4?abfzqlo obG�[9+�@,5�qldE{~��els/qgd�yhd4o�_ qgd4ab

Del�B_ ]4uabfzqlo o~:�)*B6(@�)4� 7 8�-,G�[9+�@,5(D, F )

yzo¤_�s w4uy��pqldE{�egd4f�kyh�_ ]4£{Ob�2yzab

D]EqloY_ ]4¤��w4d4a�_ yzegdEqlfzy�_Nk

Fyzd�y�_ o${Obo a�s yhrO_ yzegdV�

•©4els¤qld¡yhdEoP_cqld4ab

Fel�1_ ]4£abf|qlo�oOG�[9+�@,5}qldE{���els

O, I1, . . . , In

�yhdEoP_cqld4abboZel��:�8*5(8}els�:�)*B69@�)4�

Input(F, [I1, . . . , In])yzo?_�s w4

y��Kqld�{ egdEf�k yh��_ ]4/o �jw4bdEabI1, . . . , In

s brOs bo�bd2_ o1_�]E/yzd4r4wO_+el�_ ]4¤��w4d4a�_ yzegdEqlfhyh_6k

F���$dE{

Output(F, O)yhoY_�s w4�yh�1qld�{�egd4f�k

y��Os brOs bo�bd2_ oY_ ]4�egwO_ r4wO_$el�

F�

����;�q� � ���wx�,���!�]���,yF����� ��Nd}elsc{O�sY_�e<s brOs bo�bd2_ o/_�]E?��w4d4a�_ yzegdEqlfzy�_ yzbo/el�1q igyz�gbd�{4b�2yzab?�/w4o ~q}o�vgegfzbt���w4d4a�_ yzegdV�V©Eels�yzd4oP_cqld4ab<_ ]4<«4s o�_¤��w4d4a�_ yhejdEqlfhyh_6k�el�q<yzd4o�_ qldEab

Deg�§_ ]4¤abf|qlo�oc%&<�pyzfhfVxnZ_ ]4Zs bo w4f�_pel�9_ ]4Z��w4d4a�_ yzegd

f1(D)�E\Y]4bdV�O�/�]Eq��ggó%�&

(D) ∧l*:;�*',%9}(\*�

(f1(D))�

����;� � rv�(�!���O�4�3����y������ �\��/eR��w4d4a�_ yzegdEqlfzy�_ yzbo�a�qld»]Eq��g��qla¢] el_ ]4�s�_ ]4�o qlt~�yhdEr4wO_ o_Nk8rnuqgdE{�_ ]4uo qlt~uegwO_ r4wO_�_Nk8rn�qlo£�qlac]�el_ ]4�s���x4wO_£_ ]4�ka�qldrn�s���els t�{4y��K�s bd2_�qla�_ yhegd4o���©4els�yhd4o�_ qgd4abg�Z�/�a�qld,yztuqligyzd4�q��wEd4a�_ yhegdEqlfzyh_6k�ig�_�_ yhd4i_6�/eyzd2_�bij¢sco<_ er4s e��8yz{4}_ ]4�o�wEt¾el�?yh_ oyzd4r4wO_ o��1�p]Eyhfz�qldEel_�]E�s���wEd4a�_ yhegdEqlfzyh_6k��$yhfzfYigyz�g�_�]E�ils �q�_ boP_uel�yh_ oZ_6�/e�yzd4r4wO_ o��V©Eels¤_ ]Eq�_�r4wOs rnego�g�VegwOs�f|qld4igwEqlig�yzd4abfzwE{O�o�egt~xEqgo�yha���wEd4a�_ yhegd4o£o�w4rEr�ego �{�_ e�x�~v8d4e��pd�fzyzvgg�K��els£yzd4oP_cqldEabl�V_ ]4o�_ qld�{4q�sc{�q�s yh_�]Et��_ yza�qlfK��w4dEa¢_ yzegd4o��

ìpµ¬° í 3�� I�:4I§=B0�¹p3N=$>Z5�SUæ�:ETZ¼6I�5���qp]�#���A���,��s!�F�,�#����y� �A�4��� �!yFs����#�Hy�������y� �Sy������������A�F�!�� wOs�_cq��8egdEegt�yzbo~q�s �o�yzt~r4fh�egd2_ egfhegigyzbo<�$y�_ ]�abfzqlo o�bo<s w4fz�{�xjkrEqls bdj_�¥¬ac]4yzfz{<s bf|q�_ yzegd4o�]4yzruqldE{�x2k _ ]4pabegd4o�_Pscqlyzd2_ o+el�n_6kOr�pel�n_ ]4s bf|q�_ yhegdEo${OegtuqlyhdEob���Bel_ ]¡{Obo a�s yhxn�{�x2k�_ ]4¤��egfhfze��$yzd4igob�©Eels<��Oqlt~r4fzg��_ ]4�abf|qlo�o�%(/�.9?9)�@,5�.�/�yho<q¡o w4xna�f|qlo�o<el��:�)*B69@�)�q%(/�.9?*)�@,5.�/

@:�)*B69@�)2�¢ó%(/�.9?*)�@,5�.*/

(X) ⇒:�)*B69@�)

(X)­�&]Eq��g�s w4fzbo�qlo o�e8abyzq�_ �{,�pyh_ ] x4yzdEq�s�k�s bf|q�_ yhegdEo_ e)_Nk8rn_ ]4bt�� ©4els�yzd4o�_ qldEabg�§_ ]4}x4yzdEq�s�k�s bf|q�_ yhegd�'�5�.�/()*{xOs egw4ij]j_<_ ]4s w4fzgó]'�5�.*/()*{

(X, Y ) ⇒:�8*5(8

(X) ∧:�)*B69@�)

(Y )

���qp]�jp��A���,��s!�F�,�#����y� �Z�!�]���,yF�F������wU�yF�������h���;�,�*���4���©Eels�egdE�{Ob�8yhab}_ ]4�s �a�qld�xn�egd4}els~t~els ���w4d4a�_ yhegdEqgfhyh_ yhbob� �6degw4spf|qld4igw�qligg�O��wEd4a�_�yzegdEqlfzyh_�yzbo£��byh_ ]4�s$o�yzt�rEfh�els$abegt~rnego��{E�Yq�s ^«4s o�_�¥Æabf|qlo�o1abyh_�yz¦bbd4ob� � d4Ba�qld�qlo�o e2aby|q�_ U_ e$_ ]4bt q$dEqlt~/qld�{£rOs el¥rn�s�_ yhbo�� abegt~r�ejo�}_ ]4bt��_�¡els be��j�s��+q���w4d4a�_ yhegd�qlfhyh_6k

Fabqgd�xn

{O�«�d4�{�xjk�els$yhdO���s �{���s egt�yh_ oY_6kOr�u��ac]Eego�bd��½s egt�_ ]4�o�w4xnabfzqlo oel�~G�[9+�@,58�¢�+o qbkOyzd4i�%(/6!+�5

(F )P1��s egtHy�_ ouyhd4rEwO_ ouqldE{�y�_ ouegwO_ r4wO_

rnego�o yhxEf�k��$y�_ ]�rOs egrn�s�_ yhbo���OrOs bo�o��{�yzd�q�_ egt~o4P9�½scegtòabegt~r�ego y�¥_ yzegd4ob�� o�yzt~r4fh ��w4d4a�_ yzegdEqlfzy�_6k

Fabqgdñ]Eq��g tuqld2k yhdEr4wO_ ob�¡­�

abegd4o yz{4�s}_ ]4�fhyzoP_�el�£yh_ o�_Nk8rn�{ yzd4r4wO_ oI1, . . . , In

��byh_ ]4�s�{4q�_cq

62

els�{4^��8yzab^boc�a�qlfzfh^�{¸yh_`o�yzd4r4wO_�� \Y]4^bdF]Eqlo�q�o�yzd4igfz^&egwO_`r4wO_

O�

Fa�qld�]Eq��g^�rOs`^babegdE{4y�_`yzegd4o¸�½_`]4ego`^�abegdE{Oyh_`yhejd4o�t<w4oP_)xn^

s`^�qlfzyh¦b^�{ª_`eRrn^�s���els`t _`]4^�o�yzt~r4fh^ ��w4d4a�_`yzegdEqlfhyh_6kE�¢� �¬_�a�qld qlfho`e]Eq��g^£rnegoP_`abegdE{Oyh_`yhejd4op�$]4yzac]�q�sc^�s`^�qlfhyz¦b^�{�egdEab^�_`]4^£o�yzt~r4fz^���w4d4a�¥_`yzegdEqlfhyh_6k�yzo~qlac]4yz^b�g^�{K� ©Eels�yzd4oP_cqldEa�^}�/^}]�q��g^}_�]Eyho<s`w4fz^���els�_`]4^09/(8,+�-,o�)*/���wEd4a�_`yhegdEqgfhyh_6k}el� q����

%�&(D) ∧

7 8-,G�[9+�@,5(D, f1(D))

∧ Output(f1(D), O) ∧ Input(f1(D), [I1, I2])⇒

09/(8,+�-,o()*/(f1(D)) ∧ Stored(O, I2) ∧ Copy(I1, O)elsp_ ]4yzopegd4¤��els$qgd�qj{4{O�s��4yzfhfzw4oP_�scq�_ yzd4i�_ ]4�xEqlo�yzaZ��w4d4a�_ yhegd4o

Adder(D) ∧7 8�-,G�[9+�@,5

(D, f1(D))∧ Input(f1(D), [I1, I2])

⇒ Addition(f1(D)) ∧ Output(f1(D), P lus(I1, I2))

ìYµÆì LSUªî£S+5O3P=$² æ¢T?=?[n0436SU=?. ¼P360O3NI�5�$o¤b�jegvg�{�yhd�� ���¬�n�/<�Yqld2_Z_ e�bdEqgx4fh<s �qlo egd4yhdEi�qlx�egw4_�q}abegt�¥rnego��{}��w4dEa�_�yzegdEqlfzy�_Nk}xEqlo��{�egd�yh_�opabegdEoP_ y�_ w4bd2_prEqls�_�o$qld�{}dEel_Y_ es �2w4yhs qg{4{4y�_ yzegdEqlfZyzdO��els tuq�_ yhejd)qlxnegwO_�_ ]4byhs�yzt~r4fhbt~bd2_cq�_�yzegdV�\Y]2wEob�U�/�o�bq�abegt~rnego��{&��wEd4a�_ yhegdEqlfzyh_6k qlo�q�_�s b�el�£o yht~r4fz��w4dEa�_�yzegdEqlfzy�_ yzbo �$]4�s u_ ]E�egw4_�rEwO_<el�$egdE�o yht~r4fz���w4d4a�_ yzegdEqlfhyh_6kyzoYegd4¤el�§_ ]4¤yzd4r4wO_pel�9]Eyho/�Æq�_�]E�s��4\Y]4�s ���els g�Eq<abegt~r�ego �{���w4d4a�¥_ yzegdEqlfhyh_6k�$y�_ ]

kyhdEr4wO_ o yho d4el_ ]4yzd4i¡t~els u_ ]Eqld�q¡o�yzt~r4fhu��w4d4a�¥

_ yzegdEqlfhyh_6k�pyh_ ]nyhdEr4wO_ o�s babbyh�8yzd4i¡y�_ o

nyzd4r4wO_ o���s egt

no yht~r4fz

��w4dEa�_�yzegdEqlfzy�_ yzbopels$abegt~r�ego �{}��w4d4a�_ yhejdEqlfhyh_ yhboY�$y�_ ]kyzd4r4w4_�o���®8e4�

�/<o��_¤o�egt~<fhegigyza�qlf§s wEfhbo?_ e�{O�«Ed4�q�abegt~r�ego �{¡��w4d4a�_ yzegdEqlfzy�_6kj�©9yhs oP_��§�/}{O�«Ed4}qld�w4dEq�s�k�s bfzq�_ yzegd G�[9+�@,5�n,'9)��p]4yzac]�qlababbrO_ oegd4fhk}fzyhoP_ opel�9��w4d4a�_ yzegdEqlfzy�_ yzboY�g�s yh�½kOyhd4i~o�egt~¤r4s egrn�s�_�yzbo£����wOs�_ ]4�s_ ]4ego ¤fzyho�_ o$q�s ¤a�qlfzfz�{}o �jwEbd4abbopel�9��w4d4a�_ yzegdEqlfzy�_ yzboc�¢ó� fzyzoP_Uel�n��wEd4a�_ yhegdEqlfzyh_ yhboUt~qg{4pel�Kegd4Y��w4d4a�_ yhegd�qlfhyh_6k

F��egsUegd4

abegt~rnego��{���w4dEa�_�yzegdEqlfzy�_Nk4�pyzoZquo��2w4bd4ab el� ��w4d4a�_ yzegdEqlfzy�_ yz�o��n\Y]4o��2w4bd4ab�el�/��w4d4a�_ yzegdEqlfzy�_ yzbo

[F ]qldE{�_ ]4~��w4d4a�_ yzegdEqlfzy�_Nk

F]Eq��g

_ ]4?o qlt~?yzd4r4wO_��O\/]4?egwO_ r4w4_Beg�[F ]yzo/q£o �jw4bdEa�?tuqg{O?el��egdEf�k

_ ]4�egwO_ r4wO_$el�F�

G�[9+�@,5(F ) ∧ Input(F, I) ∧ Output(F, O)

⇒G�[9+�@,5�n,'9)

([F ]) ∧ Inputs([F ], I) ∧ Outputs([F ], [O])G�[9+�@,5�n�&�.42�<

(F ) ∧ Input(F, I) ∧ Output(F, O)⇒

G�[9+�@,5�n,'9)([F ]) ∧ Inputs([F ], I) ∧ Outputs([F ], [O])

��o��2w4bd4abZel����w4d4a�_ yhegd�qlfhyh_ yhbolFqldE{}q£o yht~r4fz$��w4d4a�_ yhegd�qlfhyh_6k

F��elsYq abegt~rnego��{�egd4��+a�qld}t~qlvg¤q£dE��)o��jwEbd4ab?el����w4d4a�_ yzegdEqlfzy�¥_ yzbo

[F | lF ]�l\/]4/yhdEr4wO_1el�

lFqldE{

Ft wEoP_1xnB_�]EBo qlt~YqldE{£�pyzfhf

xnB_ ]4/yzd4r4w4_ el�[F | lF ]

�l\Y]4/egw4_ r4wO_ el�[F | lF ]

yzo9_ ]4Yo��2w4bd4abtuqg{O�el�9_ ]4�egwO_ r4wO_peg�

FqldE{}_ ]4�egwO_ r4wO_$el�

lFó

G�[9+�@,5(F ) ∧

G�[9+�@,5�n,'*)(lF ) ∧ Inputs(lF, I)

∧Input(F, I) ∧ Outputs(lF, Os) ∧ Output(F, O)⇒

G�[9+�@,5�n,'9)([F | lF ])

∧ Inputs([F | lF ] , I) ∧ Outputs([F | lF ] , [O | Os])G�[9+�@�5�n�&(.42�<(F ) ∧

G�[9+]@,5�n,'*)(lF ) ∧ Inputs(lF, I)

∧Input(F, I) ∧ Outputs(lF, Os) ∧ Output(F, O)⇒

G�[9+�@�5�n,'*)([F | lF ])

∧ Inputs([F | lF ] , I) ∧ Outputs([F | lF ] , [O | Os])ë?e����§�/�]Eq��g�abegt~r�ego �{���w4dEa�_�yzegdEqlfzy�_Nk�x2k�_ ]4yho s w4fzg���$]4�s ^F :: lF

yzoY_ ]4¤�Yqbk}�/�{4bd4el_ Z_ ]4�abegt~rnego�yh_�yzegdV�G*[9+�@,5

(F ) ∧G�[9+�@,5�n,'*)

(lF ) ∧ Outputs(lF, Os)∧Input(F, Os) ∧ Inputs(lF, Is) ∧ Output(F, O)

⇒G*[9+�@,5�n�&(.42�<

(F :: lF )∧ Input(F :: lF, Is) ∧ Output(F :: lF, O)� w4�s yzboq�s �dEel_egd4fhkðwEo����w4f ��elswEo��s o�_ e�o �q�s ac] {Ob�2yzabbob�

x4wO_<a�qld�qlfzo�e�]Eq��g�yzdj_ �s �_ o yzd�{8k8d�qlt�yza�qlfUabegt~rnego�yh_ yhegd���­)]4yhfzo��qls ac]4yzd4i���els}q��w4d4a�_ yhegd�qlfhyh_6kj�+kjegw&a�qld�«Ed�{&q�{Ob�8yhab�qlx4fz�_ e

rn�s���els t _ ]4Z_cqlo�v�x4wO_Ys �jw4yhs yzd4i�yhd4rEwO_ o/kjegw�{Oe�d4el_prOs e��2y|{O~��elsel�U_ ]4<�Ys yzd4i}_6k8rn��¢�V\Y]4bdV�n_ ]4�tuqlyhdy|{O�q�yzoZ_ e}fz�_Z_ ]4yzo�{Ob�2yzabf|qlw4d4a¢]�q�d4���2w4�s�k�_ e�ij�_�yh_ o�d4b�{O�{�yzd4r4wO_ o<_ ]Oscegw4ig]�el_ ]4�s{Ob�8yzabboY�p]4yzac]�t~yzig]j_$]Eq��jZ_ e~o��q�s a¢]¡qlijqlyhd�_ ]4bt~o�bfz�gbob�ô Q&I§¼N.90OI�> �*S+:4¹Y5��qldjk�qlrEr4fhyza�q�_ yhegdEo~x4fzego�o egt~�{�_ e��qlabyzfzy�_cq�_ �tuqld8wEqlfpabegt~r�ego y�¥_ yzegd�el� {4b�2yzabbo$qld�{�o��s �8yhabbo��]�¡els ¤s babbd2_ f�kj�Eo�btuqld2_ yha�tuq�s v8w4ryzouw4o��{�yhd�­�bx�o �s �2yzabbo~_�e�qlwO_ egtuq�_ yha�qlfzf�k�abegt~rnego��_ ]4btHxjko r�babyh�½kOyhd4i�_ ]4u_cqlo v_�e�rn�s���els t�� ���Æ���+�gbd��pyh_ ]�{Ob�8yzabbob�9o�egt~�/els v8o�� ���Zo��_�w4r)q�abegt~rnego�yh_ yhegd _ ]Os egw4ig])q�oPkOoP_ bt%qlr4r4fhk8yzd4i{Obo a�s yhr4_�yzegd�el�1r4f|qld�_�e~tuqlvg£q��lqlyzfzqlx4fz¤_ ]4¤abegt~rnego��{}��w4d4a�_ yhegdV�ï?e��/b�g�s��O�$]4yzfh�o w4ac]¡q�abegt~rnego�yh_�yzegd�yzoprn�s���els t~�{�x2k�q�abbd2_Pscqlf{O�{4yha�q�_ �{�o��s �8yhabg�8�/?rOs egrnego $_ e<o�rOs �qg{u_ ]4Zabegt~r4wO_cq�_ yhegd}el�9qabegt~rnego��{ ��w4d4a�_ yhegd�_ ]Os egw4ig]�_�]EYabegt�rnegd4bd2_ o1��egw4dE{<x2k�jwE�s yhbob�\Y]4�qlrErOs ejqlac] el�������$yzo�xEqlo��{&egd�_ ]4¡o�rnbabyh«Ea�q�_ yhegd el�¤rOs �¥{O�«�d4�{ rEq�_�_ �s d4o�el��o��s �8yhab�abegt~r�ejo�y�_ yzegdV�~\Y]4�abegt~r�ego y�_ yzegdqlfzfhe��/�{�q�s �_ ]4ego ��p]4yzac]�a�qld,x��egx4_ qlyzd4�{Rx2kRyhd4o�_cqld4abyzq�_ yzegdel�u_ ]4ego �rEql_P_ �s d4o��Z�6d,abegd2_�scqloP_��?�/�qlyzt q�_�qlwO_ egtuq�_�yzd4i�_ ]4abegd4o�_�s w4a�_ yhegd»el��o��s �8yhab abejt�rnego�yh_ yhegdEo�_ ]Os egw4ig]»egdO¥��4k jw4�s�kqld4o��/�s yhdEi4�� LSU=?[V¼PT$5O3NSU=�. =?> ��I�:458î£I�[n04367UI�5�Nd}_�]EyhoYrnego�yh_ yhegd�rEqlrn�s��8�/¤]Eq��jZo vg�_ ac]4�{�_ ]4¤tuqlyhd}���q�_�w4s boYel�_ ]4�s w4fh�¥¬xEqlo �{�f|qld4igwEqlig�_ ]Eq�_¤�/�rOscegr�ego <_ e�{Obo a�s yhxn~{4b�2yzabboqldE{}_ ]4byhsp��w4d4a�_ yzegdEqlfhyh_ yzbob�\Y]4?{OyzoP_ yzd4igw4yzo�]4yzd4i£rnegyzdj_Bel�V_�]EyhoBfzqldEigwEqlig$yzo+_ ]Eq�_U��wEd4a�_�yzegdEq�¥fzy�_ yzbo?q�s �«4s oP_?abfzqlo oP¥¬aby�_ yz¦bbd4ob�EëZqgt�yzd4i~_ ]4bt�qlfzfhe��$op_�euabegt~rnego�_ ]4bt%qldE{&_ e�]Eq��gqld��2wEqlf?rOs e8abbo�o yhd4i�el�£o yht~r4fz�qld�{ abegt<¥rnego��{���w4d4a�_ yhegd�qlfhyh_ yhbo�ó§�/}a�qld�qlo�o e2aby|q�_ }yhd4rEwO_ ob�9ejwO_ r4wO_ ob� qldE{rOs ejr��s�_ yzboY�pyh_ ]���o yht~r4fz�elspabegt~rnego��{��U��w4dEa�_�yzegdEqlfzy�_ yzbob�­�$q�s Y�Begs v2yzd4i�egd<_ ]4po�rnbabyh«Ea�q�_ yhegd~el�VqZw4o �s�¥���s yhbdE{4f�k ��egs t<¥xEqlo �{�f|qld4igwEqgig���elsu{Obo�a�s yzx4yhdEi{Ob�8yhabbo~qldE{�_ ]4byhs<��w4d4a�_ yzegdEqlfzy�¥_ yzbob�4qldE{}q abels�s bo�rnegdE{4yhd4i ��els t<¥¬xEqlo �{}jwE�s�kuf|qld4igwEqligg�8­�¤q�s ^igw4y|{O�{�qldE{�abegd4oP_�scqlyzd4�{�xjk_�]E~igejqlf+el�Yig�_�_ yhd4i�qld�qlwO_ egtuq�_�yza_�scqld4o fzq�_ yzegd�el�V_ ]4$��els t~oByzdj_ e<q£o��_/el��� s egfhegi£s w4fzbob�O\/]Eps �qlo egdyzo _ ]Eq�_+�/Y�Yqldj_+_ e���Or4fhejy�_+_ ]4prEq�_�_ �s dO¥¬t~q�_ a¢]4yhdEi£qldE{�yzdO���s bd4aba�qlrEqgx4yhfzy�_ yzbopel��� s egfhegi���els$o�wEr4rnels�_�yzd4iu2w4�s�k�qld4o��/�s yhd4iE�\Y]4�d4��8_�oP_ br��$yhfzf�xn�_ e&yhd8�gbo�_�yzijq�_ �q�rnb�s¡_�e&rnb�s�{O�¥r4fze�k8t~bd2_pel� q�d4�_6�/els v�eg�1{4b�2yzabbo${Obo�a�s yzxnb{�{4babfzq�scq�_ yz�gbf�k�qldE{2w4�s yz�{�yzd<qY��wEfhfhk£{Obabbd2_�scqlfhyz¦b�{¤�pqbkj��­�Br4fzqld£_ e?oP_ wE{8k¤�$]4�_ ]4�so w4ac]}q {ObrEfhe�k8t~bd2_/a�qld�xn?qla¢]4yzb�g�{uegdu_ egr�el�V_ ]4¤®8egt~�­)]4�s ^yzdO�½scqlo�_Ps wEa�_�w4s �� ���¬�Q&I�æcI�:4I§=?[KI�5 !#" ÁOß2Å�ÛcÄ�Ö�ÎNÚbË ÐNá�ÚbÊjà%$Yß'&Bß2ÁlÒ�ÊE×)( Ç à2Ú+*gÐNË�ÊjåZå�Ò�Ö Ò�å?Ó|Ò�Î�*jÎ6Ò�å�ÎNÚbܤÜZË�ÊjåË�ʤÐNájÍBÏ6ÍcܤÚ�Ê�ÐNË�Û-,1Í Õ/.�ß�0�ÐNá£Ä�Ê�ÐNÍcÎ6Ê2Ú�ÐNË�Ò�Ê2ÚbÖ4Á�ÑgÜ1*8Ò�ÏNË âjÜ�Ò�Ê£ÀEÒ�å�Ë�ÛcÚ�ÖØ2Ò�Î6ܤÚ�Ö Ë32cÚbÐ6Ë�Ò�ÊjÏ+ÒbÓ4&9Ò�ÜZܤÒ�ÊjÏNÍ ÊjÏNÍp ͢ÚbÏ6Ò�ÊjË Êjåj×/57698�8 !;: ß 6 " ÁOß=<UÚbÎNÚcÑlÚbÊ2ÚbÊ�Ú�Êjà�ÁOßKÅ~ÛcÄ�Ö�ÎNÚbË ÐNáE×>( ÁlË�Ü$âjÖhÚ�ÐNË Ò�ÊE×�Ì�Í Î6Ë ?2Û¢Ú�ÐNË Ò�Ê�ÚbÊjàÚ�âgÐ6Ò�ܤÚbÐNÍ à&ÛcÒ�Ü@*OÒ�ÏNË ÐNË Ò�Ê&ÒbÓ1,1ÍcÕ�ÏNÍcάÌlË�Û ÍcÏA.�ß !9! ÐNá�Ë�Ê�Ð6ÍcÎ6Ê2Ú�ÐNË�Ò�Ê2Ú�ÖÛcÒ�ÊgÓ|ÍcÎ6Í ÊjÛcÍYÒ�ÊCB�Ò�Î6Ö àCB�Ë�àjÍDB�Í ÕE×/57698�896 : ß E+" B&ß ÃGFnß�àjÍ� ÒlÍ Ì�ÍcÎ Ú�Êjà'ÚbÖ½ß�×IH=J�K'L;M�N#NPO;K'LAQSR'OANUT V�LXW9Y7TZJ�K)[\ K]Y7NPJ�9M_L;Y TZJ�KaY7JCH=J�b�cJ�dXT�Y TZJ�K'W�e]W9KgfhJ9K)LXJ9b�c_J9dXT�Y7TZJ�K'W�e�ijOAY k�J�9d#lh×

&1Ú�Ü$ÕjÎ6Ë àjå�ÍpÉ+ÊjË Ì�ÍcÎ6Ï6Ë ÐÆÑ%FVÎ6ÍcÏ6Ï¢×]69898 ! ß m9" Å�ß Ã�&/ß+ Ò�âjÏ6ÏNÍ�Т×nFnß+Ç à+o¬Ë Ü�ÚbÊE×nFnß�&9á2Ú�ÐPÚ�Ö Ë�Û�×+Ø1ßBÈBÒ�Ú�Ï6àjÒ�â_p�×UÚbÊjàÀ§ß§ÁlË�ÜZÒ�ÊE×�( ÁlÒ�ܤÍU,+ájÍcÎ6Í<Ë�Ê�ÐNájÍ<Ï6ÍcÜ�ÚbÊ�ÐNË ÛC,1ÍcÕ/. ß9Á_qBØ�Ár�Ås69898�t5½ÄÆÊ�ÐNÍcÎ6Ê2Ú�ÐNË�Ò�Ê2ÚbÖ�&9Ò�ÊgÓzÍcÎ6ÍcÊjÛ Í�Ò�Êu&9âjÎ6Î6ÍcÊ�Ðg$nÎ6ÍcÊjàjÏ�Ë Êv$ ájÍ Ò�άÑ�ÚbÊjàF�ÎNÚbÛ ÐNË ÛcÍYÒbÓ4&9Ò�Ü@*jâgÐNÍcÎUÁlÛcË ÍcÊjÛ Í : ×/5 o¬Ú�Ê�â2Ú�άÑ%69898�t : ß 0 " Å�ß>w§ÚbÖ�Ö pcÍ�×1Ø1ß Â+Ú�Ü@*2Ú�ÎNÚbÊ�Ñ�× Ú�Êjà�À§ß>w�ÍcÎ6ÛcÒ�âgÐNÍcÎc×�( ØKÖ�ÍUxgË�ÕjÖ Í�ÛcÒ�ÜZÃ*OÒ�Ï6Ë ÐNË Ò�ÊRÒbÓ�ÏNܤÚbάÐ�àjÍ�ÌgË ÛcÍ�Ï6ÍcάÌlË�ÛcÍ Ï;. ß1$ ájÍ�69898�0&ÄÆÊ�ÐNÍcÎ6Ê2Ú�ÐNË�Ò�Ê2Ú�Ö&9Ò�ÊgÓ|Í Î6ÍcÊjÛ Í~Ò�ÊuFnÍcάÌ�ÚbÏNË Ì�Í�Á�ÑlÏ6ÐNÍ Ü¤Ï ÚbÊjày&1Ò�Ü1*gâjÐ6Ë�Êjåu57F§Á_&�. 890 : ×57698�890 : ß

63

Automatic Web Service Composition:Service-tailored vs. Client-tailored Approaches 1

Daniela Berardi, Giuseppe De Giacomo, Massimo Mecella 2 and Diego Calvanese 3

1 Introduction

Web services (also called simply services) are self-describing,platform-agnostic computational elements that support rapid, low-cost and easy composition of loosely coupled distributed applica-tions. From a technical standpoint, Web services are modular appli-cations that can be described, published, located, invoked and com-posed over a variety of networks (including the Internet): any pieceof code and any application component deployed on a system can bewrapped and transformed into a network-available service, by usingstandard (XML-based) languages and protocols (e.g., WSDL, SOAP,etc.) - see e.g., [1]. The promise of Web service is to enable the com-position of new distributed applications/solutions: when no availableservice can satisfy a client request, (parts of) available services canbe composed and orchestrated in order to satisfy such a request. Notethat service composition involves two different issues [1]: the synthe-sis, in order to synthesize, either manually or automatically, a spec-ification of how coordinating the component services to fulfill theclient request, and the orchestration, i.e., how executing the previousobtained specification by suitably supervising and monitoring boththe control flow and the data flow among the involved services. Inthis short position paper, we argue (Sec. 2) that most proposals onautomatic composition synthesis are service-tailored and only feware client-tailored. We then outline (Sec. 3) the specific approachdeveloped in the years by the authors, which is good example of aclient-tailored approach.

2 Automatic Service Composition

In order to discuss automaticservice composition, and compare dif-ferent approaches, we introduce here a sort of conceptual frameworkfor “semantic service integration”, that is constituted by the follow-ing elements 4:

• the communityontology, which represents the common under-standing on an agreed upon reference semantics between the ser-

1 This work has been supported by the Italian project MAIS and the EUprojects/NoEs TONES, SemanticGOV and INTEROP.

2 Dipartimento di Informatica e Sistemistica, Universita di Roma“La Sapienza” , Via Salaria 113, 00198 Roma, Italy. E-mail:{berardi,degiacomo,mecella}@dis.uniroma1.it.

3 Libera Universita di Bolzano/Bozen, Facolta di Scienzee Tecnolo-gie Informatiche, Piazza Domenicani 3, 39100 Bolzano, Italy. E-mail:calvanese@inf.unibz.it.

4 Such a framework is inspired by the research on “semantic data integra-tion” [18, 12, 26]. Obviously that research has dealt with data (i.e., staticaspects) and not with computations (i.e., dynamic aspects) that are of inter-est in composition of services. Still many notions and insights developedin that field may have a deep impact in service composition. An exampleis the distinction that we make later between “service-tailored” and “client-tailored” service integration systems, which roughly mimic the distinctionbetween Global As View (GAV) and Local As View (LAV) in data integra-tion.

vices 5, concerning the meaning of the offered operations, the se-mantics of the data flowing through the service operations, etc;

• the set of availableservices, which are the actual Web servicesavailable to the community;

• the mappingfor the available services to the community ontology,which expresses how services expose their behavior in terms ofthe community ontology;

• and the client servicerequest, to be expressed by using the com-munity ontology.

In general, the community ontology comprises several aspects: onone side, it describes the semantics of the information managed bythe services, through appropriate semantic standards and languages(e.g., OWL and OWL-S 6, WSMO 7); on the other side, it shouldconsider also some specification of the service behaviors, on pos-sible constraints and dependencies between different service opera-tions, not limited solely to pre- and post-conditions, but consideringalso the process of the service. In building such a “semantic serviceintegration” system, two general approaches can be followed.

• In the Service-tailored approach, the community ontology is builtmainly taking into account the available services, by suitably rec-onciling them; indeed the available services are directly mappedas elements of the community ontology, and the service request iscomposed by directly applying the mappings for accessing con-crete computations.

• Conversely in the Client-tailored one, the community ontologyis built mainly taking into account the client, independently fromthe services available; they are described (i.e., mapped) by usingthe community ontology, and the service request is composed byreversing these mappings for accessing concrete computations.

In fact, most of the research on automatic service composition hasadopted, up to now, a service-tailored approach. For example, theworks based on Classical Planning in AI (e.g., [27], [7]) considerservices as atomic actions –only I/O behavior is modeled, and thecommunity ontology is constituted by propositions/formulas (factsthat are known to be true) and actions (which change the truth-valueof the propositions); available services are mapped into the commu-nity ontology as atomic actions with pre- and post-conditions. In or-der to render a service as an atomic action, the atomic actions, aswell as the propositions for pre- and post-conditions, must be care-fully chosen by analyzing the available services, thus resulting in aservice-tailored approach.

Other works (e.g., Papazoglou’s et al. [28], Bouguettaya at al. [20],Sheth et al. [10, 9]) have essentially considered available services as

5 Note that many scenarios of cooperative information systems, e.g., e-Government or e-Business, consider preliminary agreements on underlyingontologies, yet yielding a high degree of dynamism and flexibility.

6 cfr. http://www.daml.org/services/owl-s/.7 cfr. http://www.wsmo.org/.

64

atomic actions characterized by the I/O behavior and possibly effects.But differently from those based on planning, instead of concentrat-ing on the automatic composition, they have focused more on onmodeling issues and automatic discovery of services described mak-ing use of rich ontologies.

Also the work of McIlraith at al. [19] can be classified as service-tailored: services are seen as (possibly infinite) transition systems,the common ontology is a Situation Calculus Theory (therefore issemantically very rich) and service names, and each service namein the common ontology is mapped to a service seen as a procedurein Golog/Congolog Situation Calculus; the client service request isa Golog/Congolog program having service names as atomic actionswith the understatement that it specifies acceptable sequences of ac-tions for the client (as in planning) and not a transition system thatthe client wants to realize.

Finally, the work by Hull et al. [8, 14] describes a setting whereservices are expressed in terms of atomic actions (communications)that they can perform, and channels that link them with other ser-vices. The aim of the composition is to refine the behavior of eachservice so that the conversations realized by the overall system sat-isfy a given goal (dynamic property) expressed as a formula in lineartime logic. Although possibly more on choreography synthesis thanon composition synthesis of the form discussed here, we can stillconsider it a service-tailored approach, since there is no effort in hid-ing the service details from the client that specifies the goal formula.

Much less research has been done following a client-tailored ap-proach, but some remarkable exceptions should be mentioned: thework of Knoblock at al. [21] is basically a data integration approach,i.e., the community ontology is the global schema of an integrateddata system, the available services which are essentially data sourceswhose contents is mapped as views over the global schema, and theclient request is basically a parameterized query over such a schema;therefore the approach is client-tailored, but neither the ontology normappings consider service behavior at all.

The work of Traverso et al. [25, 23, 22] can be classified alsoas client-tailored: services are seen as (finite) transition systems, thecommon ontology is a set of atomic actions and propositions, as inPlanning; a service is mapped to the community ontology as a tran-sition system using the alphabet of the community and defining howtransitions affect the propositions, and the client service request asksfor a sequence of actions to achieve GOAL1 (main computation), withguarantees that upon failure GOAL2 is reached (exception handling).

Finally, the line of research taken in [3, 4, 5, 6], but also in [11],has the dynamic behavior of services at the center of its investiga-tion. In order to study the impact of such dynamics on automaticcomposition, all these works make simplifying assumptions on thecommunity ontology, which essentially becomes an alphabet of ac-tions. Still the notion of community ontology is present, and in factall these works adopt a client-tailored approach.

A fundamental issue that arises is: if such rich descriptions of thedynamic behavior of the services can be combined with rich (nonpropositional) descriptions of the information exchanged by the ser-vices, while keeping automatic composition feasible. The first resultson this issue are reported in [2], where available services that operateon shared world description (in a form of a database) are consid-ered. Such services can either operate on the world through someatomic processes as in OWL-S, or exchange information throughmessages. While the available services themselves are with finitestates, the world description is not. Under suitable assumptions onhow the world can be queried and modified, decidability of servicecomposition is shown. Interestingly [2] shows that even if the avail-able services can be modeled as deterministic transition systems, thepresence of a world description whose state is not known at compo-sition time, requires dealing with nondeterminism of the same form

we have studied here.

� �� ����� ��� ����

� �� ����� ��� ����

��� ��� � � ���

� � ��� ��� ��� �������

� ��!#"�$&% '#( % ! '#) $+* ) !-, !/. ( ,10-2 % ' , (

3 4�5� ��6 � ��

3 4�5� ��6 � ��

798;:+<=:=>?>A@=BDCFE G@;HA>A:=IJ@D>AK BLB=:DINMD:DO=K >DK :=<

P

P

QRQQ

S �T� �U�� �4�UV �� �UU� ���W

�� �44� 4� P

X :=HAY;H=G=> >A@=ZF@+GD>[@FE \]7

^� ��� �� �

^� ��� �� �

_ ��`��U�� ���

a ����b� � ���

c ���� ���

a ����b� � �� dc���

egf1h/i-j k lFmk h l n k o hFp

m o#qDr k lo q o#sut o

m p

Figure 1. Comparison of the various approaches

Figure 1 summarizes, on the basis of the previous discussion, theconsidered works. The three axis represent the levels of detail ac-cording to which the community ontology and the mappings and theclient request can be modeled. Namely, (i) staticsin thesystemrep-resents how fine grained is the modeling of the static semantics (i.e.,ontologies of data and/or services, inputs and outputs, alphabet of ac-tions, etc.); (ii) dynamicsin componentservicesrepresents how finegrained is the modeling of the processes and behavioral features ofthe services (only atomic actions, transition systems, etc.); and (iii)dynamicsin client servicerequestrepresents how fine grained is themodeling of the process required by the client, varying from a sin-gle step (as in the case of services consisting essentially of queriesover a data integration system) to a (set of) sequential steps, to a (setof) conditional steps, to including loops, up to running under the fullcontrol of the client (as in our approach). Black/whitelollipops rep-resent service-tailored (white) vs. client-tailored (black) approaches.

3 The Roman Approach

The approach to automatic service composition undertaken by theauthors, referred to as the Romanapproach in [15], is an example ofa client-tailored approach. Its distinguished features can be summa-rized as follows.

• The available services are grouped together into a so call commu-nity.

• Services in the community share a common set of actions Σ, theactionsof the community. In other words, each available servicein the community exports its behavior to the community itself interms of the actions in Σ.

• Each action in Σ denotes a (possibly complex) interaction betweenthe a service and a client, and as a result of such interaction theclient may acquire new information (not necessarily modeled ex-plicitly) that may be of help in choosing the next action to perform.

• The behavior of each available service is described in terms of afinite transitionsystem(aka finite state machine) that makes useof the actions in Σ.

• The client request itself is expressed as a finite transition systemthat makes use of the actions in Σ. Such a transition system, calledtarget service, is deterministic, since we assume that there is nouncertainty on the behavior that the client want to realize throughcomposition of the available services.

65

• The orchestrator has the ability of scheduling services on a step-by-stepbasis. Hence the orchestrator has the ability of controllingtheinterleavingof multiple services executed concurrently.

• The compositionsynthesisconsists on synthesizing a program forthe orchestrator such that by suitably scheduling the available ser-vices it can provide the target service to the client.

To fix the idea, this setting for service composition can be under-stood in terms of the previously proposed framework as follows:

• the community ontology is simple a set of actions, namely theactions of the community;

• the available services are the actual Web services that have joinedthe community;

• the mapping from the available services to the community on-tology is constituted by the transition systems that represent theavailable services; note that indeed these are expressed in terms ofthe actions of the community;

• the client service request is the target service, which again is ex-pressed in terms of the actions of the community.

Therefore this setting adheres to the client-tailored approach.In [3, 5], we have addressed the simplest case in which available

services are modeled as deterministic finite transition systems, thenin [4] we have considered the “angelic non/determinism” extension,i.e., the target service is “under-specified” (the client delegates thecomposer to resolve certain choices) and interactions between ser-vices without client involvement can happen. Finally in [6], we haveaddressed the automatic composition synthesis when the behavior ofthe available services is nondeterministic, and hence is not fully con-trollable by the orchestrator (“diabolic non/determinism”).

The presence of nondeterministic conversations stems naturallywhen modeling services in which the result of each interactionwith its client on the state of the service can not be foreseen. Letus consider as an example, a service that allows buying items bycredit card; after invoking the operation, the service can be in astate payment OK, accepting the payment, or in a different statepayment refused, if the credit card is not valid, with not enoughcredit, etc. Note that the client of a nondeterministic service can in-voke the operation but cannot control what is the result of it. In otherwords, the behavior of the service is partially controllable, and theorchestrator needs to cope with such partial controllability. Note alsothat if one observes the status in which the service is after an oper-ation, then s/he understand which transition, among those nondeter-ministically possible in the previous state, has been undertaken by theservice. We assume that the orchestrator can indeed observe states ofthe available services and take advantage of this in choosing how tocontinue a certain task 8.

Typically reactive process synthesis [24, 17] make use of tech-niques based on automata on infinite trees. Even if these are perfectlysuitable from a theoretical point of view, there are critical steps, sucha Safra’s construction for complementation, that have resisted effi-cient implementation for a long time. Only recently, we are startingto understand how to avoid such steps –see [16] for a discussion.

Interestingly the technique proposed by the authors are based onreduction to satisfiability in Propositional Dynamic Logic (PDL)[13] with a limited use of the reflexive-transitive-closure operator.Now, PDL satisfiability shares the same basic algorithms behind thesuccess of the description logics-based reasoning systems used for

8 The reader should observe that also the standard proposal WSDL 2.0 hasa similar point of view: the same operation can have multiple output mes-sages (the out message and various outfault messages), and theclient observe how the service behaved only after receiving a specific outputmessage.

OWL9, such as FaCT10, Racer11, Pellet12, and hence its applicabilityin the context of composition synthesis appears to be promising.

REFERENCES[1] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. WebServices.Con-

cepts,ArchitecturesandApplications. Springer, 2004.[2] D. Berardi, D. Calvanese, G. De Giacomo, R. Hull, and M. Mecella.

Automatic composition of transition-based semantic web services withmessaging. In Proc.VLDB2005.

[3] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Me-cella. Automatic composition of e-Services that export their behavior.In Proc.of ICSOC2003.

[4] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Me-cella. Synthesis of underspecified composite e-Services based on auto-mated reasoning. In Proc.of ICSOC2004.

[5] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Me-cella. Automatic service composition based on behavioural descrip-tions. International Journal of Cooperative Information Systems,14(4):333–376, 2005.

[6] D. Berardi, D. Calvanese, G. De Giacomo, and M. Mecella. Composi-tion of services with nondeterministic observable behavior. In Proc.ofICSOC2005.

[7] J. Blythe and J. Ambite, editors. Proc.ICAPS2004WorkshoponPlan-ningandSchedulingfor WebandGrid Services, 2004.

[8] T. Bultan, X. Fu, R. Hull, and J. Su. Conversation specification: a newapproach to design and analysis of e-service composition. In Proc. ofWWW2003.

[9] J. Cardose and A. Sheth. Introduction to semantic web services andweb process composition. In Proc.of SWSWPC2004.

[10] F. Curbera, A. Sheth, and K. Verma. Services oriented architecture andsemantic web processes. In Proc. ICWS2004.

[11] C. Gerede, R. Hull, O. H. Ibarra, and J. Su. Automated composition ofe-services: Lookaheads. In Proc. ICSOC2004.

[12] A. Y. Halevy. Answering queries using views: A survey. VLDBJournal,10(4):270–294, 2001.

[13] D. Harel, D. Kozen, and J. Tiuryn. DynamicLogic. The MIT Press,2000.

[14] R. Hull, M. Benedikt, V. Christophides, and J. Su. E-services: a lookbehind the curtain. In Proc.of PODS2003.

[15] R. Hull and J. Su. Tools for design of composite web services. InTutorial at SIGMOD2004.

[16] O. Kupferman and M. Y. Vardi. Safraless decision procedures. In Proc.of FOCS2005.

[17] O. Kupferman and M. Y. Vardi. Synthesis with incomplete information.In Proc. ICTL 1997.

[18] M. Lenzerini. Data integration: A theoretical perspective. In Proc. ofPODS2002.

[19] S. McIlraith and T. Son. Adapting golog for composition of semanticweb services. In Proc.KR2002.

[20] B. Medjahed, A. Bouguettaya, and A. Elmagarmid. Composingweb services on the semantic web. Very Large Data BaseJournal,12(4):333–351, 2003.

[21] M. Michalowski, J. Ambite, S. Thakkar, R. Tuchinda, C. Knoblock, andS. Minton. Retrieving and semantically integrating heterogeneous datafrom the web. IEEE IntelligentSystems, 19(3):72–79, 2004.

[22] M. Pistore, A. Marconi, P. Bertoli, and P. Traverso. Automated compo-sition of web services by planning at the knowledge level. In Proc. ofIJCAI 2005.

[23] M. Pistore, P. Traverso, P. Bertoli, and A. Marconi. Automated synthe-sis of composite bpel4ws web services. In Proc.of ICWS2005, 2005.

[24] A. Pnueli and R. Rosner. On the synthesis of a reactive module. InProc.of POPL’89, pages 179–190, 1989.

[25] P. Traverso and M. Pistore. Automated composition of semantic webservices into executable processes. In Proc. ISWC2004.

[26] J. D. Ullman. Information integration using logical views. TheoreticalComputerScience, 239(2):189–210, 2000.

[27] D. Wu, B. Parsia, E. Sirin, J. Hendler, and D. Nau. Automating daml-sweb services composition using shop2. In Proc. ISWC2003.

[28] J. Yang and M. Papazoglou. Service components for managing thelife-cycle of service compositions. InformationSystems, 29(2):97–125,2004.

9 http://www.omg.org/uml/10 http://www.cs.man.ac.uk/˜horrocks/FaCT/11 http://www.sts.tu-harburg.de/˜r.f.moeller/racer/12 http://www.mindswap.org/2003/pellet/

66

Causal link matrix and AI planning: a model for Webservice composition

Freddy Lecue1 and Alain Leger1

Abstract. Automated composition of Web services or the process

of forming new value added Web services is one of the most promis-

ing challenges in the Web service research area. Even if semantics

is one of the key elements to describe Web service capabilities and

processes, there is still some work to be done. Indeed Web services

described at functional level need a formal model to perform the

automated composition of Web services. The suggested model (i.e.

Causal link matrix) is a necessary starting point to apply problem-

solving techniques such as regression-based search for Web service

composition. The innovative model supports a semantic context in

order to solve an AI planning-oriented Web service composition.

1 Introduction

Web service [1] provides the feature richness, flexibility and scalabil-

ity needed by enterprises to manage the SOA challenges. By Web ser-

vices we mean loosely coupled, reusable software components that

semantically encapsulate discrete functionality and are distributed

and programmatically accessible over standard internet protocols.

Web services proliferation over the web implies difficulties to find

specific services that can perform specialized tasks. Even if manual

Web service combination from scratch can be difficult and time con-

suming, the combination of existing services is an alternative and

promising approach. Indeed new abilities are necessary to support

dynamic and automated tasks such as discovery, selection and com-

position. The main ability is to describe capability (inputs, outputs,

preconditions, and effects: IOPEs) and process model (Web services

activities, interaction protocol) of Web services. The latter needs are

covered by means of semantic Web services. A semantic Web service

[23] is described as a Web service whose internal and external de-

scription is in a language that has well-defined semantics. Most of the

work in semantic Web services composition has focused on two main

levels of composition: functional [18, 21, 11] and process [5, 16, 19]

levels. The former level considers Web services as “atomic” com-

ponents described in terms of their IOPEs, and executed in a sim-

ple request-response step. The latter level supposes Web services as

stateful processes with an interaction protocol involving in different

sequential, conditional, and iterative steps. The functional and pro-

cess level composition as complementary methods is an interesting

trade-off to propose solutions for composition. Hence the study of a

formal model for the functional level composition or the process of

chaining Web services according to their functional description.

The rest of the paper is organized as follows. Section 2 presents the

causal link matrix (CLM) as a formal model to describe Web services

at functional level. In section 3, an AI planning-oriented method is

1 France Telecom R&D, France, 4, rue du clos courtel F-35512 CessonSevigne, email: {freddy.lecue, alain.leger}@orange-ft.com

presented to solve a Web service composition with CLMs features.

We briefly comment on related work in section 4. Finally in section 5,

we draw some conclusions and talk about possible future directions.

2 Formal model

Algorithms for Web service composition have to not only find fea-

sible plans with relevant Web services, but also to find the optimal

plan according to an optimization criteria. The latter criteria will be

viewed as a quality of semantic connection between Web services.

Indeed the semantic connection between Web services is consid-

ered as essential to form new value-added Web services. The formal

model (i.e. the CLM) aims at storing all those connections (i.e. causal

links) in order to find the best Web service composition.

The CLM pre-computes all semantic links between Web services

as an Output-Input matching because a Web service composition is

mainly made up of semantic connections. Thus Web service compo-

sition is mainly oriented by the CLM of the domain. The idea behind

the CLM is a model for functional level composition of Web services.

2.1 Semantic Web service composition formalism

Functional parameters (i.e. input and output) of Web services are

concepts referred to in an ontology T , e.g. OWL-S profile [2],

WSMO capability [10]. Finding a semantic similarity between two

parameters Oy and Ix is similar to find a mapping [12] between

two knowledge representations encoded using the same ontology T .

Causal links store this semantic similarity. Despite some methods

[7, 14, 17], solving a mapping problem is hard because the syntactic

form of two knowledge representations rarely matches exactly. Four

kinds of semantic matching [17] are considered in our model (Table

1) to check semantic similarity between two concepts Oy and Ix.

Web service composition is close to function composition in the

mathematical area. A trivial Web service composition of two Web

services sy and sx is considered as a mathematical composition

sx ◦ sy . The latter composition means that sy precedes sx and there

exists a positive value of SimT between all input parameters of sx

and some output parameters of sy . CLMs (i.e. matrices of semantic

connections) are introduced with the aim of finding not only trivial

but also more complex compositions.

2.2 Causal link matrices

CLMs contribute to the automated process of Web service composi-

tion by classifying Web services according to a formal link called

“causal link”. A causal link is related to a logical dependency among

input and output parameters of two different Web services. The lat-

ter link describes a semantic relation between an output parameter

67

Match Type Exact Plug-in Subsume Fail

SimT (Oy , Ix) 1 23

13

0Logic meaning Oy ≡ Ix Oy ⊂ Ix Oy ⊃ Ix Otherwise

Table 1. Semantic matching functions described by SimT .

Oy ∈ T of a Web service sy ∈ SWs and an input parameter

Ix ∈ T of a Web service sx ∈ SWs. Thereby sx and sy are se-

mantically and partially linked according to a matchmaking function

SimT (Oy, Ix). In our semantic context, a causal link [20] is refined

as a triple 〈sy, SimT (Oy, Ix), sx〉. The function of semantic sim-

ilarity SimT returns a value in [0, 1] depending on the matching

degree, and SimT is necessary to value Web services connections.

Definition 1. A causal link 〈sy, SimT (Oy, Ix), sx〉 is valid (i.e.

valid transition) iff SimT (Oy, Ix) > 0.

A CLM contains all valid transitions for a composition goal be-

cause causal links help to detect inconsistencies. Indeed all valid

causal links between Web services are explicitly valued by the SimT

function. The latter value is based on the semantic quality of valid

causal links. A CLM aims at storing all valid causal links in an ap-

propriate way. The more valid causal links there are, the better it is.

Definition 2. The set of p× q CLMs2 is defined as Mp,q(P((SWs ∪T )×]0, 1])). Columns {1, . . . , q} are labelled by (Input(SWs) ∪β) ⊆ T , the inputs parameters of services in SWs and/or the con-

cepts described by the goal set β ⊆ T . Rows {1, . . . , p} are labelled

by Input(SWs). Each entry mi,j of a CLMM is defined as a set of

pairs (sy , score) ∈ (SWs ∪ T )×]0, 1] such that

(sy, score) =

(

(sy, SimT (Oy, Cj)), sy∈SW s, Oy∈Out(sy)

(sy, 1), sy∈T

(1)

with Ci ∈ T ∩ In(sy) ⊆ Input(SWs) is the label of the ith row.

with Cj ∈ T ∩ (Input(SWs)∪β) is the label of the jth column.

Out(sy) is the set of output parameters of the Web services sy

whereas In(sy) is its set of intput parameters. β contains the set

of goals as concepts in T . The variable score refers to the degree

of match SimT (Oy, Cj) between an output parameter Oy ∈ Tof sy and Cj ∈ Input(SWs)∪β in case sy ∈ SWs. In the alterna-

tive case sy ∈ T , the value score is 1. A CLM pre-computes the

semantic similarities between all output and input parameters of a

closed set of Web services. All entries are valid causal links defined

in P((SWs ∪ T )×]0, 1]).

Definition 3. Let M be a CLM and KB be the set of instantiated

concepts {C1, . . . , Ct} ⊆ Input(SWs)∩T .M is initialised accord-

ing to KB iff mi,k ⊇ (Ck, 1), ∀i ∈ {1, . . . , p}, ∀k ∈ {1, . . . , t}.

2.3 Causal link matrix issues

The key contribution of the CLM is a formal model to control a set of

Web services which are relevant [3, 23] for a Web service composi-

tion. Thus the set of Web services SWs is closed in order to limit the

dimension of the CLM. This model allows performance analysis of

proposed plans with a concrete view of the composition background:

causal links and their semantic dependency. The CLM aims at pre-

chaining Web services according to a semantic similarity based on

their Output/Input specification in order to prepare a suitable context

for an AI planning problem [16].

2 P(S) refers to the set of parts of a set S. #S refers to the Cardinality of S.

3 AI planning and Causal link matrices

A simple form of AI planning Π = 〈SWs,KB, β〉 is introduced to

avoid problems [22] from planning-based Web services composition,

e.g. non determinism and implicit goal. SWs (i.e Actions) refers to

a closed set of possible state transitions, KB is an Initial state and

β ⊆ T is an explicit goal representation described as a set of con-

cepts in a terminology T . Thus we propose a solution plan in a well-

defined domain: goals are explicitly given, initial state is well defined

and Web services are strictly defined at functional level. So non deter-

minism, implicit goal, fuzzy Web service description and behaviour

are out of the question. Therefore it does seem possible to directly

apply current AI planning methods to our specific problem.

The Web service composition method consists of finding a plan

that produces the desired outputs β according to a knowledge base

KB. The causal link score allows the early detection of impossible,

feasible and best links between Web services (Definition 1). That is

why our method is based on the causal link validity between Web

service. Sequence-composability defines a composition sx ◦ sy if an

output of sy is consumed by an input of another Web service sx.

Theorem 1 expressed the sequence-composability in CLMs [13].

Theorem 1. Let M be a CLM, and sx, sy be two Web services in

SWs. sx and sy are sequence-composable iff ∃i ∈ {1, .., p}, ∃j ∈{1, .., q}, ∃v ∈ ]0, 1] such that (sy, v) ⊆ mi,j . j.label and i.label

are respectively inputs of sx (In(sx)) and sy (In(sy)).

3.1 A regression-based approach

The composition process consists of a recursive and regression-based

approach. A Web service with a goal β as output parameter has to be

found in SWs. In case of success, the process is iterated with its in-

put parameters as new goals. Alternatively, the process is stopped

and the plan is reduced to the empty plan ∅. All the process is recur-

sive until all goals and new goals are concepts in KB. The algorithm

1 presents the complete method of composition and returns a plan

composed of valid and “sequence-composable” causal links. CLMs

ease the regression-based search because Web services are seman-

tically well ordered in a robust and formal model. The solutions are

plans wherein Web services are semantically chained by causal links.

Algorithm 1: Composition by regression-based approach Ra4C.

Input: A CLMM ([mi,j]), a plan π, a planning problem

Π = 〈SWs,KB, β〉, a temporary set of solved goals G.

Result: A set of solution plans π.

beginSc ← ∅; // Temporary set of pairs in (SWs ∪ T )×]0, 1].if ((∃Ck ∈ KB) & (SimT (Ck, β) 6= 0)) then π ← β;

foreach Ii ∈ Input(SWs) doif ∃(α, v) ∈ mIi,β then Add((α, v), Sc);

if Sc 6= ∅ then

foreach (α, v) ∈ Sc with α ∈ SWs doπ ← π ∪ α ;

foreach In(α) doif β ∈ G then π ← π ∩ ∅; // inconsistent plan

elseAdd(β, G); Π← 〈SWs,KB, In(α)〉;π ← π ∪ (

V

In(α)Ra4C(M,π,Π,G);

else π ← π ∩ ∅; // inconsistent plan

return π;end

68

The Ra4C algorithm builds a plan with no cycle in the order-

ing constraints and no causal link conflicts to dispose of inconsistent

causal links (consistency [20]). Moreover the Ra4C algorithm pro-

poses a plan wherein every input of every Web service is achieved

by some other previous Web service (completeness [20]). Thus the

proposed plan is a partial order of well-ordered causal links. Indeed,

a CLM contains all necessary information about complete plans be-

cause a CLM explicitly stores all valid causal links between Web

services. The correctness proof of algorithm 1 is detailed in [13].

Therefore the algorithm 1 returns a set of correct, complete and

consistent plans. However such a set may contain a large number of

plans. So pruning strategies for plans-space is necessary to propose a

set of optimal solutions. A “causal link”-based optimization criteria

is proposed in [13] to detect the optimal plans.

4 Related work

Two different approaches [6, 8] propose matrices to represent the

Web services domain. [6] solve an AI planning problem where ac-

tions are viewed as tasks. Actions are formally described with their

preconditions and effects. Tasks are executed by concrete Web ser-

vices, according to a service/task (row/column) matrix. [8] propose

a simple method to store Web service: an input/output (row/column)

matrix. The matrix models introduced by [6, 8] do not propose rea-

soning about those matrices. In fact, matrices are simply considered

as representation models. Moreover no semantic feature is intro-

duced in their models. From HTNs [24] to regression planning based

on extensions of PDDL [9], different planning approaches have been

proposed for the composition of Web services. Situation calculus is

proposed in [16] to represent Web service and Petri nets for describ-

ing the execution behaviours of Web services. A planner is declared

as a state chart in [4], and the resulting composite services are exe-

cuted by replacing the roles in the chart by selected individual ser-

vices. [15] propose a composition path, nevertheless they only con-

sidered two kinds of services operator and connector with one input

and one output parameter. [25] propose a forward chaining approach

to solve a planning problem. The composition path is based on the

shortest path algorithm on the graph of Web services space.

5 Conclusion and future work

Despite the fact that Web service composition is in its infancy, some

proposals are being studied. Nevertheless no theoretical model has

been proposed to help automation of composition at the best stage of

our knowledge. In this paper we outlined the main challenge faced in

semantic Web services. Indeed we showed how the CLM tackles this

challenge by providing a necessary formal model which draws a con-

crete context for automatic Web service composition. This concrete

context captures semantic connections between Web services. The

composition model has its roots in AI planning domain and takes ad-

vantage of the causal link expressivity by extending its definition in a

semantic context. Semantically weighted by the SimT function, the

latter link refers to a local optimization criteria in order to find solu-

tion plans. Moreover solution plans have properties of completeness,

correctness, consistency. The model of functional level composition

is easily applied to Web services which are described according to

the OWL-S (service profile) or WSMO (capability model) specifi-

cation. Finally, contrary to [6, 8], our matrix model pre-computes

the semantic similarities between Web services according to causal

links. Web service composition is viewed as causal link composition.

For further studies we plan to improve and extend the set of semantic

Web service matching functions for optimization reasons.

REFERENCES

[1] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju, Web

Services: Concepts, Architectures and Applictions, 2004.[2] Anupriya Ankolenkar, Massimo Paolucci, Naveen Srinivasan, and Ka-

tia Sycara, ‘The owl services coalition, owl-s 1.1 beta release’, Techni-cal report, (July 2004).

[3] Boualem Benatallah, Mohand-Said Hacid, Alain Leger, ChristopheRey, and Farouk Toumani, ‘On automating web services discovery’,VLDB J, 14(1), 84–96, (2005).

[4] Boualem Benatallah, Quan Z. Sheng, Anne H. H. Ngu, and MarlonDumas, ‘Declarative composition and peer-to-peer provisioning of dy-namic web services’, in ICDE, pp. 297–308, (2002).

[5] Tevfik Bultan, Xiang Fu, Richard Hull, and Jianwen Su, ‘Conversationspecification: a new approach to design and analysis of e-service com-position’, in International conference on WWW, pp. 403–410, (2003).

[6] Daniela B Claro, Patrick Albers, and Jin-Kao Hao, ‘Selecting web ser-vices for optimal composition’, in ICWS International Workshop on

Semantic and Dynamic Web Processes, Orlando - USA, (2005).[7] Simona Colucci, Tommaso Di Noia, Eugenio Di Sciascio, Marina

Mongiello, and Francesco M. Donini, ‘Concept abduction and contrac-tion for semantic-based discovery of matches and negotiation spaces inan e-marketplace’, in Proceedings of the 6th ICEC, pp. 41–50, (2004).

[8] Ion Constantinescu, Boi Faltings, and Walter Binder, ‘Type based ser-vice composition’, in WWW (Alternate Track Papers & Posters), pp.268–269, (2004).

[9] D. M. Dermott, ‘PDDL - the planning domain definition language’,Technical report, (August 07 1997).

[10] Dieter Fensel, Michael Kifer, Jos de Bruijn, and John Domingue, ‘Webservice modeling ontology submission, w3c submission’. June 2005.

[11] M. Klusch, B. Fries, M. Khalid, and K. Sycara, ‘Owls-mx: Hybrid owl-s service matchmaking’, in AAAI, (November 2005).

[12] Ralf Kusters, Non-Standard Inferences in Description Logics, volume2100 of Lecture Notes in Computer Science, Springer, 2001.

[13] Freddy Lecue, Semantic web services composition in Master Research

report, Master thesis, University of Saint-etienne and Ecole des minesde Saint-etienne (France), Saint-etienne, July 2005.

[14] L. Li and I. Horrocks, ‘A software framework for matchmaking basedon semantic web technology’, in Proceedings of the Twelfth Interna-

tional Conference on WWW, pp. 331–339, (2003).[15] Z. Morley Mao, Randy H. Katz, and Eric A. Brewer, ‘Fault-tolerant,

scalable, wide-area internet service composition’, Technical report,(October 25 2001).

[16] S. Narayanan and S. McIlraith, ‘Simulation, verification and automatedcomposition of web services,’, Eleventh International WWW Confer-

ence, 7–10, (May 2002).[17] M. Paolucci, T. Kawamura, T.R. Payne, and K. Sycara, ‘Semantic

matching of web services capabilities’, in the First ISWC (June 2002).[18] Massimo Paolucci, Katia P. Sycara, and Takahiro Kawamura, ‘Deliver-

ing semantic web services.’, in Proceedings of the international confer-

ence on WWW (Alternate Paper Tracks), pp. 829–837, (2003).[19] Marco Pistore, Pierluigi Roberti, and Paolo Traverso, ‘Process-level

composition of executable web services: ”on-the-fly” versus ”once-for-all” composition’, in ESWC, pp. 62–77, (2005).

[20] S.J. Russell and P. Norvig, Artificial Intelligence: a modern approach,Prentice-Hall, 1995.

[21] Evren Sirin, Bijan Parsia, and James A. Hendler, ‘Filtering and select-ing semantic web services with interactive composition techniques’,IEEE Intelligent Systems, 19(4), 42–49, (2004).

[22] Biplav Srivastava and Jana Koehler, ‘Web service composition - currentsolutions and open problems’, in ICAPS 2003 Workshop on Planning

for Web Services, (July 22 2003).[23] Katia P. Sycara, Massimo Paolucci, Anupriya Ankolekar, and Naveen

Srinivasan, ‘Automated discovery, interaction and composition of se-mantic web services’, J. Web Sem, 1(1), 27–46, (2003).

[24] Dan Wu, Bijan Parsia, Evren Sirin, James A. Hendler, and Dana S.Nau, ‘Automating DAML-S web services composition using SHOP2’,in ISWC, pp. 195–210, (2003).

[25] Ruoyan Zhang, Ismailcem Budak Arpinar, and Boanerges Aleman-Meza, ‘Automatic composition of semantic web services’, in ICWS, pp.38–41, (2003).

69

Using Quantified Boolean Logics to Verify Web ServiceComposition Requirements1

Enrico Giunchiglia2 and Massimo Narizzano3 and Marco Pistore4 and Marco Roveri5 and Paolo Traverso6

Abstract. This paperillustratesa framework for the definition offormal requirementson the behavior of Web servicecompositions.The framework exploits Quantified Linear Time Logics (QLTL) asformal specification language.The paper also discussestwo ap-proachfor the verification of such formal requirements.The firstapproach,which is classical,transformsQLTL formulasinto (non-quantified)LinearTimeLogic formulasby expandingthequantifiers,andthenexploits SAT-basedBoundedModel CheckingtechniquesontheresultingLTL formulas.Thesecondapproach,which is novel,exploits BoundedModel Checkingtechniquesbasedon QuantifiedBooleanFormulas(QBF), thus avoiding the explicit expansionofthequantifiers.

1 Introduction

Webservicetechnologyis rapidlyemergingasoneof themostpracti-calapproachesfor thedevelopmentof distributedbusinessprocessesthat integrateandcomposecustomers’,vendors’,andbusinesspart-ners’applications.However, composingservicesis madedifficult bythefactthat,while aimingatworkingtogether, usuallycompaniesdonotwantto uncover theinternalstructureof their businessprocessesto eachother. Moreover, they wantto keeptheability to rethinkandreorganizetheir businessprocessesand to modify accordinglytheimplementation.

Businessprocessdescriptionlanguageslike BPEL4WS [1] pro-vide meansto describethe interfacebehavior of serviceswithoutnecessarilyrevealingor constrainingtheinternalbehavior of thepro-cesses.They canhencebe seenasthe basictechnologyfor andin-tegrationof businessprocessesthatguaranteestheautonomyof thecompaniesparticipatingto the integration.However, in order to beeffectively usedfor composingbusinessprocesses,thistechnologicalinfrastructureneedsto beenrichedwith toolsandmethodologiesthatsupportthedevelopmentof thiscompositionandthatpermitto man-agethechangesandadaptationsof businessmodelsandof businessprocesses.This requiresto take into accountthe businessstrategyandgoalschangesin thesoftwaresystem.To this purpose,businessgoalsandbusinessrequirementsneedto bemadeexplicit in thebusi-nessprocessmodel.A “strategic”descriptionneedsto beprovidedofthedifferentactorsin thebusinessdomainwith their goalsandwiththeirmutualdependenciesandexpectations.Moreover, thisstrategicdescriptionhasto bevalidatedandverified againsttheactualimple-mentationof the Web services,in order to guaranteean alignmentbetweenthetwo models.

In this paperwe describea framework for modeling businessre-quirementsof Webservicecompositions.Theframework is basedonTropos[4], which providesa “strategic” descriptionof thedifferent

1 This work is partially fundedby the MIUR-FIRB projectRBNE0195K5“Knowledge Level Automated Software Engineering” andby theECproject507219“PROSYD”.

2 DIST, Universityof Genova, Italy, email:giunchiglia@unige.it3 DIST, Universityof Genova, Italy, email:mox@dist.unige.it4 DIT, Universityof Trento,Italy, email:pistore@dit.unitn.it5 ITC-IRST, Trento,Italy, email:roveri@irst.itc.it6 ITC-IRST, Trento,Italy, email:traverso@irst.itc.it

actorsin the businessdomainwith their goalsandneedsandwiththeir mutual dependenciesandexpectations.As shown in previouswork [7], Troposbusinessrequirementscanbeexploitedto drive thedesignof businessprocessesandto tracechangesin therequirementsandin theprocesses.

Troposhasaformalcounterpartin theFormalTroposspecificationlanguage[3]. FormalTroposallows for defining constraintsandre-quirementson the behaviors of thedifferentactorsparticipatingto aWebservicecomposition.Theseconstraintscanbeseenashigh-levelcounterpartsof thedetaileddescriptionof thebehaviors of servicesdescribedin languagessuch asBPEL4WS.More precisely, FormalTroposallowsfor thespecificationof formalconstraintsexpressedinQuantifiedLinearTimeLogics(QuantifiedLTL, or QLTL). This log-ics providesstandardtemporaloperatorsthatallow to reasonon thebehavior andon the evolution of the system.Moreover, it providesexistentialanduniversalquantifiers, which permit to reasonon thedifferentinstancesthatmayexist on a single“class”.Thepossibilityto combinetemporaloperatorsandquantifiers is very importantinWebservicecompositionscenarios.Consider, for instance,thattheremay be different “instances”of the sameactor (e.g.,differentcus-tomersor differentproviders),thatdifferent“instances”of thesameprocessmay be running,andthat theseinstancesmanagedifferentdatavalues.Expressingconditionsin thisscenario(e.g.,thefactthateachcustomercanhave at mostoneopenorderwith everyprovider)requiresthecapabilityto specifyquantifierson theseinstances.

Givena formal specificationof therequirementsof a Webservicecompositionscenarioin termsof Troposandof FormalTropos,dif-ferent forms of formal verification are possible.In particular, it ispossibleto validatetherequirementsof thecomposition,in ordertocheckthat they areconsistentandthat they satisfythe expectationsof thedifferentactors.Moreover, it is possibleto verify therequire-mentsagainst the implementationof the Web servicecomposition,definedfor instanceby asetof BPEL4WSprocesses.

This however requiresthecapabilityto verify QLTL formulas.Inthepaper, wepresenttwo approachesto thisverification. Thefirst ap-proach,which is classical,transformstheQLTL formulasinto (non-quantified)LTL formulasby expandingthequantifiers,andthenex-ploits SAT-basedBoundedModel Checkingtechniqueson the re-sultingLTL formulas.This approachhasthedefectsthat the result-ing LTL formulasare usually very large, and that the structureoftheoriginal formulas,which is givenby thequantifiers,is lost in theexpansionand cannotbe exploited in the verification. The secondapproach,which is novel, exploits BoundedModel Checkingtech-niquesbasedon Quantified BooleanFormulas(QBF). In this case,the expansionof the quantifiers is avoided,and the verification isperformedusing efficient techniquesand tools for that can reasondirectlyonQBF specifications.

2 Modeling Service Composition Requirements

In this sectionwe describehow we model Web servicecomposi-tionsat therequirements level usingtheTroposlanguage.Troposisfoundedon thepremisethatduring therequirementsanalysisphaseof the software developmentprocessit is important to understand

70

andmodelthestrategic aspectsunderlyingtheorganizationalsettingwithin whichthesoftwaresystemwill eventuallyfunction.By under-standingthesestrategic aspects,onecanbetteridentify the motiva-tionsfor thesoftwaresystemandtherole that it will play insidetheorganizationalsetting.In thispaperweconsideranextensionof Tro-pos,whichis calledTropos4WS,andwhichis suitablefor integrationwith businessprocessmodels.

We introduceTropos4WSin the context of a simple case-studyconcerninga health-careagency thathasto provide assistanceto thecitizens.The following figure is a Troposdiagramthat provides ahigh-level descriptionof thecase-studydomain:

It representsthe main actors (circles) and goals (ovals) ofthe domain: the Citizen that aims at being assisted; theHealthcareAgency which aims at providing a fair assistancetothecitizens;theTransportsInc whichprovidestransportationser-vices; the MealsInc which deliversmealsat home;and the Bankwhichhandlesthegovernment’s finances.Thepicturealsodescribesthe dependenciesand expectationsthat exist amongtheseactors.For instance,the citizen dependson the sanitaryagency for be-ing assisted,and this is formulatedin the model with dependencyReceiveAssistance from Citizen to HealthcareAgency.

Startingfrom this high-level view, the Troposmethodologypro-ceedswith an incrementalrefinementprocess.The next figure, forinstance,shows a refinementof the interactionsbetweenCitizenandHealthcareAgency:

Goals (ovals) are decomposedinto sub-goals,or operationalizedinto tasks(hexagons),taking into accountthe dependenciesexist-ing amongthe different actors.For instance,the Citizen refinesthe goal BeingAssisted into the three sub-taskof DoRequest,ReceiveService and Pay. DoRequest is further refined intoInitialRequest, ProvideInformation, WaitAnswer. The re-finement procedureendsoncewe have identified all basictasksthatdefine the businessprocess.To thesebasictaskswe associatemes-sages(rectangles)thatdescribethebasicinteractionsamongactors.For instance, task InitialRequest requiresto senda messageRequest to theHealthcareAgency. This messageis receivedandprocessedby theHealthcareAgency taskReceiveRequest.

TheTroposgraphicalmodelshavea formal counterpartdescribedin the Formal Troposspecificationlanguage.Formal Tropos (here-after FT) hasbeendesignedto supplementa Troposmodelwith aprecisedescriptionof its dynamicaspects.In FT thefocusis on thecircumstancesin which thegoalsandtasksarise,andon thecondi-tions that leadto their fulfillment. In this way, the dynamicaspects

of a requirementsspecificationareintroducedat the strategic level,without requiringan operationalizationof the specification.A pre-cisedefinition of FT andof its semanticscanbe found in [3]. Herewepresentonly themostrelevantaspectsof thelanguage.

An FT specification describesthe relevant objectsof a domainand the relationshipsamongthem. The descriptionof eachobjectis structuredin two layers.Theouterlayer is similar to a classdec-larationanddefinesthestructureof theinstancestogetherwith theirattributes.Theinnerlayerexpressesconstraintsonthelifetime of theobjects,usingtypedQuantified LTL formulas.Several instancesofeachelementmayexist duringtheevolutionof thesystem.To distin-guishamongthedifferentinstances,a list of attributesis associatedto eachclass.Eachattributehasa sort which canbeeitherprimitive(boolean,integer. . . ) or classes.The inner layerof anFT classdec-larationconsistsof constraintsthatdescribethedynamicaspectsofentities,actors,goals,anddependencies.In FT wedistinguishamongCreation, Invariant, andFulfillment constraints.Creationconstraintsdefine conditionsthatshouldbesatisfiedwhena new in-stanceof aclassis created.In thecaseof goalsandtasks,thecreationis interpretedasthemomentwhentheassociatedactorbeginsto de-sire the goal or to performthe task.Invariant constraintsdefineconditionsonthelife of all classinstances.Fulfillment constraintsshouldholdwheneveragoal is achievedor a task is completed.Cre-ationandfulfillment constraintsarefurtherdistinguishedassufficientconditions(trigger), necessaryconditions(condition), andnec-essaryandsufficient conditions(definition).

In FT, constraintsaredescribedwith formulasin an LTL logicswith typedquantifiers.Besidesthe standardboolean,relationalandtemporaloperators,the logic provides the quantifiersForall andExists, which rangeover all the instancesof a given class.Con-sider the following fragmentof FT specification,correspondingtotaskDoRequest:TASK DoRequestMode achieveActor CitizenSuper BeingAssistedAttribute constant need: AssistanceNeed

result: booleanInvariant F EXISTS ir: InitialRequest (ir.super = self)Invariant EXISTS ir: InitialRequest (ir.super = self & Fulfilled(ir))

-> F EXISTS pi: ProvideInformation (pi.super = self)Invariant EXISTS pi: ProvideInformation (pi.super = self & Fulfilled(pi))

-> F EXISTS wa: WaitAnswer (wa.super = self)Invariant Fulfilled(self) -> EXISTS wa: WaitAnswer

(wa.super = self & Fulfilled(wa) & (result <-> wa.result))Fulfillment definition EXISTS wa: WaitAnswer (wa.super = self & Fulfilled(wa))

The first three invariants describethe expectedevolution of thetask and its relations with the subtasks.Namely, if the taskDoRequest is started,then eventually sub-taskInitialRequestis entered(1st invariant). After InitialRequest hasended,sub-task ProvideInformation is eventually entered(2nd invariant).And after also this sub-taskhasended,WaitAnswer is eventuallystarted(3rd invariant).The fourth invariantconstrainsthe valueofattribute result of the task to the value of the sameattribute ofsub-taskWaitAnswer once this sub-taskhas ended.Finally, theFulfillment definition tells usthat thesub-taskWaitAnswerhasto completebeforewecanconsidertheDoRequest taskfulfilled(necessarycondition)andthat, if WaitAnswer hascompleted,thenDoRequest will eventuallybefulfilled (sufficient condition).

In FT it is possibleto validatea requirementsspecificationby al-lowing thedesignerto specifypropertiesthattherequirementsmodelis supposedto satisfy. We distinguishbetweenAssertion proper-ties,which describeconditionsthat shouldhold for all valid evolu-tions of the specification,andPossibility properties,which de-scribeconditionsthat shouldhold for at leastone valid evolution.Somedesiredpropertiesfor the consideredcase-study arereportedin thefollowing:

POSSIBILITY P1Exists dr: DoRequest (Fulfilled(dr))

ASSERTION A1Forall c: Citizen (

Forall r: Response (r.receiver = c -> ! r.result) ->

71

Forall rs: ReceiveService (rs.actor = c -> ! Fulfilled(rs)))

ASSERTION A2Forall dr: DoRequest ((Exists ra: ReceiveAssistance (ra.depender = dr.actor & Fulfilled(ra)& Forall r: Request (r.sender = dr.actor & r.need = dr.need

-> r.receiver = ra.dependee)))-> (F Fulfilled(dr)))

PossibilityP1aimsat guaranteeingthat thesetof constraintsof theformal businessrequirementsspecification allow for the fulfillmentof thetaskof doinga requestin somescenarioof themodel.Asser-tion A1 requiresthatit is notpossiblefor thecitizento fulfill its goalof receiving assistanceservicesunlessa positive answerto a requestfrom thesanitaryagency hasbeenreceived.Finally, assertionA2 re-quiresthat the taskof doing a requestis eventually fulfilled alongevery scenariounderthe condition that: thereis a sanitaryagencythat is boundedto provide assistanceto the user(citizen’s depen-dency ReceiveAssistance); and,thecitizensendstherequeststothatparticularsanitaryagency.

3 Verifying Service Composition Requirements

In thissectionwedescribeourapproachto verify anFT specificationof aWebservicecompositionscenario.

Theverification techniqueswe wantto applyrequirea finite-statemodel.For thisreason,upperboundsneedto bespecifiedto thenum-ber of instancesof the different classesthat appearin the formalspecification.Given thesebounds,a fin ite stateautomatonis built.Its statesdescribevalid configurationsof class instances,accordingto theclasssignaturesandattributesthatappearin theformal speci-fication. Its transitionsdefine valid evolutionsof theseconfigurationsaccordingto somegenericconstraintsthat capturethe semanticsofFT, e.g.,thatconstantattributesshouldnotchangeover time,or that,oncefulfilled, agoalstaysfulfilled forever.

The creation,invariant,andfulfillment constraintsof the variousclassesarecollectedin aset{Ci | i ∈ I} of temporalconstraints.Inthis way, thevalid behaviors of a modelarethoseexecutionsof thefinite-stateautomatonthatsatisfyall temporalconstraintsCi. Check-ing if assertionA is valid correspondsto checkingwhetherthe im-plication

V

i∈ICi ⇒ A holdsin themodel,i.e., if all valid scenarios

alsosatisfytheassertionA. Checkingif possibilityP holdsamountto checkwhether

V

i∈ICi∧P is satisfiable,i.e., if thereis somesce-

nariothatsatisfiestheconstraintsandtheproperty. In bothcases,theverification of a property is translatedto theverification of a QLTLformula.

In [3] we have shown how this verification canbeperformedus-ing SAT-basedmodelcheckingtechniques.SAT-basedmodelcheck-ing algorithmslook for a traceof a given lengththat satisfies—orfalsifies— a (non-quantified)LTL property. Sincethe lengthof thetraceis fix ed,eachstatein thetracecanbemodeledthrougha setofdedicatedvariables,andtheLTL propertycanbeunrolled into a setof constraintson thesevariables.For instance,in theboundedinter-pretationthe formula requiring thata givenconditionholdseventu-ally in the future is unrolledinto the requirementthat theconditionholdsin someof the(variablesdefining the)statesof thefinite trace.SAT-basedalgorithmsareusuallyvery effi cientfor tracesof reason-ablelength. Thelimit of this techniqueis that,if notraceis foundfora given length,thenit may still be the casethat the propertyis sat-isfied by a longertrace.That is, SAT-basedmodelcheckingverifiesthesatisfiability of apropertyonly up to agivenlength,andis hencecalledBoundedModelChecking(BMC) [2].

If appliedto the verification of FT specifications, theBMC-basedapproachdescribedabove has a bottleneck,namely it requirestotransforma QLTL formula into a non-quantifiedLTL formula (no-tice that we assumeboundedrangesfor all the classesexploited inthe model).A grounding procedurehas beendefined in [3] whichremoves all the quantifiers by replacingthem with a suitablecon-junctionor disjunctionon all thepossibleinstancesof thequantified

variables.In many cases,however, theLTL formulathatresultsfromthegroundingis very large.Moreover, the“structure”of theoriginalformula,which is givenby thequantifiersis lost in thegroundedver-sion,and which couldbeusedfor moreefficient satisfiability checkalgorithms,is lost in thegrounding.

Theapproachjustdescribed,whichconsistsin applyingaground-ing stepand then a unrolling stepto the QLTL formula, and thento exploit SAT-solverson the resultingproblem,is illustratedin thetop/right-sideof thefollowing figure:

QLTLModel Checking

ProblemModel Checking

Problem

LTL

Problem

SAT−basedBMC

Problem

QBF−basedBMC

grounding(bounds)

unrolling (length)unrolling (length)

QBF−solvers SAT−solvers

The left-side part of the figure illustratesan alternative approach,which is basedon QBF-basedBoundedModel Checking[5]. Sim-ilarly to SAT-basedBMC, also in this casewe look for a counter-exampletraceof fix ed length, and hencewe perform an unrollingon thetemporalformulato beverified. In thiscase,however, quanti-fiers areallowedin thespecificationof theunrolledproperty, whichis hencemodeledasaQuantifiedBooleanFormula(QBF).Thisway,thegroundingstepis not necessaryanymore,morecompactformu-las areobtainedand,moreimportant,QBF-solverssuchasthe onedescribedin [6] canbe exploited to the verification. The detailsofQBF-basedBoundedModel Checkingareomittedfor lack of space— theinterestedreadercanreferto [5]. Weconcludethesectionwiththefollowing table,thatreportstheresultsof verification of theWebservicecompositionscenariodescribedpreviously usingSAT-basedandQBF-basedmodelchecking.

Test T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 T 9 T 10SAT 48.8 53.8 42.6 62.3 FAIL 62.3 54.4 48.8 FAIL 61.5QBF 12.5 21.7 10.3 12.5 30.9 17.3 14.2 13.4 51.5 12.9

The resultsclearly show the advantageof the QBF-basedapproachin termsof time requiredfor theverification.

REFERENCES[1] T. Andrews, F. Curbera,H. Dholakia,S. Systems,Y. Goland,J. Klein,

F. Leymann,K. Liu, D. Roller, D. Smith,S. Thatte,I. Trickovic, andS.Weerawarana.Businessprocessexecutionlanguagefor webservices,version1.1,2003.

[2] A. Biere,A. Cimatti,E.M. Clarke,andY. Zhu.SymbolicModelCheck-ing withoutBDDs. In Proc. TACAS’99, 1999.

[3] A. Fuxman, L. Liu, J. Mylopoulos, M. Pistore, M. Roveri, andP. Traverso. Specifyingandanalyzingearly requirementsin Tropos.Requirements Engineering Journal, 2004.

[4] P. Giorgini, M. Kolp. J. Mylopoulos, and M. Pistore.The TroposMethodology:anoverview. In Methodologies And Software Engineer-ing For Agent Systems. Kluwer AcademicPublishing,2004.

[5] E. Giunchiglia,M. Narizzano,M. Pistore,M. Roveri, andP. Traverso.QBF-based Bounded Model Checking. Technicalreport,2006.

[6] E. Giunchiglia,M. Narizzano,andA. Tacchella.QuBE++:anEfficientQBF Solver. In Proc. FMCAD’04, 2004.

[7] R. Kazhamiakin,M. Pistore,and M. Roveri. A Framework for In-tegrating BusinessProcessesand BusinessRequirements. In Proc.EDOC’04, 2004.