AI for Service Composition - ECAI 2006

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 combined into suitable workflows of tasks, in order to provide new functionalities or applications. Service composition has the potentiality to revolutionize the classical approaches to data integration and business process integration, reducing development time and effort. Standards and platforms based on service models and supporting 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 management of service compositions, including tasks such as their generation, allocation of resources, execution, monitoring and repair. For instance, knowledge representation techniques have been exploited to provide suitable semantic annotations of services; planning has been applied to an automatic generation of the workflows composing the services; scheduling has been applied to resource allocation and workflow optimization; and agent techniques have been applied to support a dynamic adaptation of the workflows. However, many issues remain to be resolved. These include (1) forming precise, clean and general characterizations of service compositions, and identifying the most appropriate ways to formalize the critical steps in their life cycle; (2) determining suitable languages to represent service compositions in all their relevant aspects and finding ways of bridging the gap between service composition languages used in the industry and languages exploited in AI; (3) highlighting important challenges for AI to be effective in practical, industrial contexts, proposing techniques and tools able to address these challenges in realistic scenarios, and finding architectures for integrating such techniques in a robust, integrated environment. The 8 full papers and 4 short papers appearing in this proceedings address these and other relevant problems in service composition. This workshop has been organized under the MIUR-FIRB project RBNE0195K5 ”Knowledge Level Automated Software Engineering”. It is the continuation of three successful workshops at ICAPS 2003, ICAPS 2004, and AAAI 2005, and aims at becoming a regular meeting place for researcher and practitioners 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, USA Jim Blythe, USC Information Sciences Institute, USA Jana Koehler, IBM Research Laboratory, Switzerland Sheila McIlraith, University of Toronto, Canada Biplav Srivastava, IBM Research Laboratory, India

Local Organization Annapaola Marconi, ITC-irst, Trento, Italy

ii

Table of Contents A Logic For Decidable Reasoning About Services Y. Gu, M. Soutchanski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 A Service Selection Model to Improve Composition Reliability N. Kokash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Abduction for Specifying and Verifying Web Service and Choreographies F. Chesani, P. Mello, M. Montali, M. Alberti, M. Gavanelli, E. Lamma, S. Storari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 An Immune System-Inspired Approach for Composite Web Services Reuse R. Bova, S. Hassas, S. Benbernou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Designing Security Requirements Models through Planning V. Bryl, F. Massacci, J. Mylopoulos, N. Zannone . . . . . . . . . . . . . . . . . . . . . . . . . .28 Formal Development of Web Services A. Chirichiello, G. Salaun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Implicit vs. Explicit Data-flow Requirements in Web Service Composition Goals A. Marconi, M. Pistore, P. Traverso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Web Service Composition in a Temporal Action Logic L. Giordano, A. Martelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 A Composition oriented proposal to describe functionalities of devices S. Tandabany, M. Rousset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Automatic Web Service Composition: Service-tailored vs. Client-tailored Approaches D. Berardi, G. De Giacomo, M. Mecella, D. Calvanese . . . . . . . . . . . . . . . . . . . . 63 Causal link matrix and AI planning: a model for Web service composition F. Lecue, A. Leger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Using Quantified Boolean Logics to Verify Web Service Composition Requirements E. Giunchiglia, M. Narizzano, M. Pistore, M. Roveri, P. Traverso . . . . . . . . . 69

iii

iv

A Logic For Decidable Reasoning About Services Yilan Gu1 and Mikhail Soutchanski2 Abstract. We consider a modified version of the situation calculus built using a two-variable fragment of the first-order logic extended with counting quantifiers. We mention several additional groups of axioms that need to be introduced to capture taxonomic reasoning. We show that the regression operator in this framework can be defined similarly to regression in the Reiter’s version of the situation calculus. Using this new regression operator, we show that the projection problem (that is the main reasoning task in the situation calculus) is decidable in the modified version. We mention possible applications of this result to formalization of Semantic Web services.

1 Introduction The Semantic Web community makes significant efforts toward integration of Semantic Web technology with the ongoing work on web services. These efforts include use of semantics in the discovery, composition, and other aspects of web services. Web service composition is related to the task of designing a suitable combination of available component services into a composite service to satisfy a client request when there is no single service that can satisfy this request [16]. This problem attracted significant attention of researchers both in academia and in industry. A major step in this direction is creation of ontologies for web services, in particular, OWL-S that models web services as atomic or complex actions with preconditions and effects. An emerging industry standard BPEL4WS (Business Process Execution Language for Web Services) provides the basis for manually specifying composite web services using a procedural language. However, in comparison to error-prone manual service compositions, (semi)automated service composition promises significant flexibility in dealing with available services and also accommodates naturally the dynamics and openness of service-oriented architectures. The problem of the automated composition of web services is 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 that achieves the goal [20, 21, 26, 24]. Despite that several approaches to solving this problem have already been proposed, many issues remain to be resolved, e.g., how to give well-defined and general characterizations of service compositions, how to compute all effects and side-effects on the world of every action included in composite service, and other issues. Other reasoning problems, well-known in AI, that can be relevant to service composition and discovery are executability and projection problems. Executability problem requires determining whether preconditions of all actions included in a composite service can be satisfied given incomplete information about the world. Projection problem requires determining whether a certain goal condition is satisfied after the execution of all component services given an incomplete information about the current state. In this paper we would like to concentrate on the last problem because 1 2

Dept. of Computer Science, University of Toronto, Canada, email: [email protected] Department of Computer Science, Ryerson University, Canada, email: [email protected]

it is an important prerequisite for planning and execution monitoring tasks, and for simplicity we start with sequential compositions of the atomic actions (services) only (we mention complex actions in the last section). More specifically, following several previous approaches [20, 21, 5, 26, 16], we choose the situation calculus as an expressive formal language for specification of actions. However, we acknowledge openness of the world and represent incomplete information about an initial state of the world by assuming that it is characterized by a predicate logic theory in the general syntactic form. The situation calculus is a popular and well understood predicate logic language for reasoning about actions and their effects [25]. It serves as a foundation for the Process Specification Language (PSL) that axiomatizes a set of primitives adequate for describing the fundamental concepts of manufacturing processes (PSL has been accepted as an international standard) [13, 12]. It is used to provide a well-defined semantics for Web services and a foundation for a highlevel programming language Golog [5, 20, 21]. However, because the situation calculus is formulated in a general predicate logic, reasoning about effects of sequences of actions is undecidable (unless some restrictions are imposed on the theory that axiomatizes the initial state of the world). The first motivation for our paper is intention to overcome this difficulty. We propose to use a two-variable fragment FO2 of the first-order logic (FOL) as a foundation for a modified situation calculus. Because the satisfiability problem in this fragment is known to be decidable (it is in NE XP T IME ), we demonstrate that by reducing reasoning about effects of actions to reasoning in this fragment, one can guarantee decidability no matter what is the syntactic form of the theory representing the initial state of the world. The second motivation for our paper comes from description logics. Description Logics (DLs) [2] are a well-known family of knowledge representation formalisms, which play an important role in providing the formal foundations of several widely used Web ontology languages including OWL [15] in the area of the Semantic Web [3]. DLs may be viewed as syntactic fragments of FOL and offer considerable expressive power going far beyond propositional logic, while ensuring that reasoning is decidable [6]. DLs have been mostly used to describe static knowledge-base systems. Moreover, several research groups consider formalization of actions using DLs or extensions of DLs. Following the key idea of [8], that reasoning about complex actions can be carried in a fragment of the propositional situation calculus, De Giacomo et al. [9] give an epistemic extension of DLs to provide a framework for the representation of dynamic systems. However, the representation and reasoning about actions in this framework are strictly propositional, which reduces the representation power of this framework. In [4], Baader et al. provide another proposal for integrating description logics and action formalisms. They take as foundation the well known description logic ALCQIO (and its sub-languages) and show that the complexity of executability and projection problems coincides with the complexity of standard DL reasoning. However, actions (services) are represented in their paper meta-theoretically, not as first-order (FO) terms. This can potentially lead to some complications when specifications of other reasoning tasks (e.g., planning) will be considered because it

1

payTuit(x,y)

enroll(x,y) enrolled(x,y)

~enrolled(x,y)

student(x)

~student(x)

drop(x,y)

reset

Figure 1. Examples of transition diagrams for simple services. admit(PSN1);payTuit(PSN1,5100);enroll(PSN1,CS1) ~incoming(PSN1) ~student(PSN1) ~ y.enrolled(PSN1,y)

Figure 2.

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

A transition diagram for a composite web service.

is not possible to quantify over actions in their framework. In our paper, we take a different approach and represent actions as FO terms, but achieve integration of taxonomic reasoning and reasoning about actions by restricting the syntax of the situation calculus. Our paper can be considered as a direct extension of the well-known result of Borgida [6] who proves that many expressive description logics can be translated to two-variable fragment FO2 of FOL. However, to the best of our knowledge, nobody proposed this extension before. The main contribution of our paper to the area of service composition and discovery is the following. We show that by using services that are composed from atomic services with no more than two parameters and by using only those properties of the world which have no more than two parameters (to express a goal condition), one can guarantee that the executability and projection problems for these services can always be solved even if information about the current state of the world is incomplete. Our paper is structured as follows. In Section 3, we briefly review the Reiter’s situation calculus. In Section 4 we review a few popular description logics. In the following section 5 we discuss details of our proposal: a modified situation calculus and an extension of regression (the main reasoning mechanism in the situation calculus). Finally, in Section 6 we provide a simple example and in Section 7 we discuss briefly other related approaches to reasoning about actions.

2 Motivations Consider online web services provided by an university. Imagine that a system automates the department administrators by doing student management work online, for instance, admitting new students, accepting payments of tuition fees and doing course enrollments for students, etc. Unlike previously proposed e-services (e.g.,the eservices described in [5] or in BPEL4WS) which allow only services without parameters, we use functional symbols to represent a class of services. For example, variables, say x and y, can be used to represent any objects; the service of enrolling any student x in any course y can be specified by using a functional symbol enroll(x, y); and, the service of admitting any student x can be represented as a functional symbol admit(x), etc. The composite web services can be considered as sequences of instantiated services. For example, a sequence admit(P1 ); payT uit(P1 , 5100); enroll(P1 , CS1) represents the following composite web service for person P1 : admit her as a student, take the tuition fee $5100 and enroll her in a course CS1. The system properties are specified by using predicates with parameters. For example, the predicate enrolled(x, y) represents that a student x is enrolled in a course y. This property becomes true when service enroll(x, y) is performed and becomes false when service drop(x, y) is performed for a student x and a course y (see Figure 1). A composite web service corresponds to the composition of these instantiated transition diagrams (see Figure 2). When one describes the preconditions of the services, the effects of the services on the world, i.e., when one characterizes which properties of the

world are true before and after the execution of the services, given incomplete information about the current state of the world, the use of FO language, such as the situation calculus [25], can provide more expressive power than propositional languages. For example, assume that a student is considered as a qualified full time student if the tuition fee she paid is more than 5000 dollars and she enrolls in at least four different courses in the school. Such property can be easily described using the FO logic, and checking whether or not such property can be satisfied after execution of certain sequence of web services is equivalent to solving a projection problem. Because FOL is compact way of representing information about states and transitions between states, we want to take advantage of the expressive power of the FO logic as much as possible to reason about web services. On the other hand, as we mentioned in the introduction, we want to avoid the undecidability of the entailment problem in the general FOL. Inspired by the decidability of reasoning in many DLs (which are sub-languages of a syntactic fragment of the FOL with the restriction on the number of variables), we restrict the number of variables to at most two in the specifications of the web services to ensure the decidability of the executability and projection problems.techniques At the same time, we can take the advantage of the expressive power of quantifiers to specify compactly realistic web services (such as mentioned above). Moreover, FOL with limited number of variables, in contrast to the propositional logic, still allows us to represent and reason about properties with infinite domains (such as weight and time, etc) or with large finite domains (such as money, person, etc) in a very compact way. Two examples are given in the last section to illustrate the expressive power and reasoning about the web services.

3 The Situation Calculus The situation calculus (SC) Lsc is a FO language for axiomatizing dynamic systems. In recent years, it has been extended to include procedures, concurrency, time, stochastic actions, etc [25]. Nevertheless, all dialects of the SC Lsc include three disjoint sorts: actions, situations and objects. Actions are FO terms consisting of an action function symbol and its arguments. Actions change the world. Situations are FO terms which denote possible world histories. A distinguished constant S0 is used to denote the initial situation, and function do(a, s) denotes the situation that results from performing action a in situation s. Every situation corresponds uniquely to a sequence of actions. Moreover, notation s0  s means that either situation s0 is a subsequence of situation s or s = s0 .3 Objects are FO terms other than actions and situations that depend on the domain of application. Fluents are relations or functions whose values may vary from one situation to the next. Normally, a fluent is denoted by a predicate or function symbol whose last argument has the sort situation. For example, F (~ x, do([α1 , · · · , αn ], S0 ) represents a relational fluent in the situation do(αn , do(· · · , do(α1 , S0 ) · · · ) resulting from execution of ground action terms α1 , · · · , αn in S0 .4 The SC includes the distinguished predicate P oss(a, s) to characterize actions a 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 s iff it does not mention the predicates P oss or ≺, it does not quantify over variables of sort situation, it does not mention equality on 3

4

2

Reiter [25] uses the notation s0 v s, but we use s0  s to avoid confusion with the inclusion relation < that is commonly used in description logic literature. In this paper, we use < to denote the inclusion relation between concepts or roles. We do not consider functional fluents in this paper.

situations, and whenever it mentions a term of sort situation in the situation argument position of a fluent, then that term is s (see [25]). If φ(s) is a uniform formula and the situation argument is clear from the context, sometimes we suppress the situation argument and write this formula simply as φ, and also introduce a notation φ[s] to represent the SC formula obtained by restoring situation s back to all the fluents and/or P oss predicates (if any) in φ. It is obvious that φ[s] is uniform in s. A basic action theory (BAT) D in the SC is a set of axioms written in Lsc with the following five classes of axioms to model actions and their effects [25]. Action precondition axioms Dap : For each action function A(~ x), there is an axiom of the form P oss(A(~ x), s) ≡ ΠA (~ x, s). ΠA (~ x, s) is a formula uniform in s with free variables among ~ x and s, which characterizes the preconditions of action A. 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) completely characterizes the value of F (~ x) in the next situation do(a, s) in terms of the current situation s. The syntactic form of ΦF (~ x, a, s) is as follows: W F (~ x, do(a, s)) ≡ m (∃~ yi )(a = P osActi (~ti ) ∧ φ+ x, ~ yi , s))∨ i (~ Wk i=1 x, ~ zj , s)), F (~ x, s) ∧ ¬ j=1 (∃~ zj )(a = N egActj (~ t0 j ) ∧ φ− j (~ where for i = 1..m (j = 1..k, respectively), each ~ti (t~0 j , respectively) is vector of terms including variables among ~ x and quantified new variables ~ yi (~ zj , respectively) if there are any, each φ+ x, ~ yi , s) i (~ (φ− x, ~ zj , s), respectively) is a SC formula uniform in s who has j (~ free variables among ~ x and y ~i (~ zj , respectively) if there are any, and each P osAct(~ti ) (N egAct(~ t0 j ), respectively) is an action term that makes F (~ x, do(a, s)) true (false, respectively) if the condition − φ+ (~ x , ~ y , s) (φ x, ~ zj , s), respectively) is satisfied. i i j (~ Initial theory DS0 : It is a set of FO formulas whose only situation term is S0 . It specifies the values of all fluents in the initial state. It also describes all the facts that are not changeable by any actions in the domain. Unique name axioms for actions Duna : Includes axioms specifying that two actions are different if their names are different, and identical actions have identical arguments. Fundamental axioms for situations Σ: The axioms for situations which characterize the basic properties of situations. These axioms are domain independent. They are included in the axiomatization of any 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 most important 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. Let executable(do([α1 , · · · , α Wnn], S0 )) be an abbreviation of the formula P oss(α1 , S0 ) ∧ i=2 P oss(αi , do([α1 , · · · , αi−1 ], S0 )). Then, the executability problem is to determine whether D |= executable(do([α1 , · · · , αn ], S0 )). Planning and high-level program execution are two important settings where the executability and projection problems arise naturally. Regression is a central computational mechanism that forms the basis for automated solution to the executability and projection tasks in the SC [23, 25]. A recursive definition of the regression operator R on any regressable formula φ is given in [25]; we use notation R[φ] to denote the for-

mula that results from eliminating P oss atoms in favor of their definitions as given by action precondition axioms and replacing fluent atoms about do(α, s) by logically equivalent expressions about s as given by SSAs of sort situation in W is starting from S0 and has the syntactic form do([α1 , · · · , αn ], S0 ) where each αi is of sort action; (2) for every atom of the form P oss(α, σ) in W , α has the syntactic form A(t1 , · · · , tn ) for some n-ary function symbol A of Lsc ; and (3) W does not quantify over situations, and does not mention the relation symbols “≺” or “=” between terms of situation sort. The formula G(do([α1 , · · · , αn ], S0 )) is a particularly simple example of a regressable formula because it is uniform in do([α1 , · · · , αn ], S0 )), but generally, regressable formulas can mention several different ground situation terms. Roughly speaking, the regression of a regressable formula φ through an action a is a formula φ0 that holds prior to a being performed iff φ holds after a. Both precondition and SSAs support regression in a natural way and are no longer needed when regression terminates. The regression theorem proved in [23] shows that one can reduce the evaluation of a regressable formula W to a FO theorem proving task in 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 executability or a projection task can be reduced to a theorem proving task that does not use precondition, successor state, and foundational axioms. This is one of the reasons why the SC provides a natural and easy way to representation and reasoning about dynamic systems. However, because DS0 is an arbitrary FO theory, this type of reasoning in the SC is undecidable. One of the common ways to overcome this difficulty is to introduce the closed world assumption that amounts to assuming that DS0 is a relational theory (i.e., it has no occurrences of the formulas having the syntactic form F1 (x~1 , S0 )∨F2 (x~2 , S0 ) or ∃xF (x, S0 ), etc) and all statements that are not known to be true explicitly, are assumed to be false. In many application domains this assumption is unrealistic. Therefore, we consider a version of the SC formulated in FO2 , a syntactic fragment of the FO logic that is known to be decidable, or in C 2 an extension of FO2 (see below), where the satisfiability problem is still decidable.

4 Description Logics and Two-variable First-order Logics In this section we review a few popular expressive description logics and related fragments of the FO logic. We start with logic ALCHQI. Let NC = {C1 , C2 , . . .} be a set of atomic concept names and NR = {R1 , R2 , . . .} be a set of atomic role names. A ALCHQI role 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 inclusion axioms R1 v R2 , where R1 , R2 are ALCHQI roles. For R ∈ NR , we define Inv(R) = R− and Inv(R− ) = R, and assume that R1 v R2 ∈ RH implies Inv(R1 ) v Inv(R2 ) ∈ RH. The set of ALCHQI concepts is the minimal set built inductively from NC and ALCHQI roles using the following rules: all A ∈ NC are concepts, and, if C, C1 , and C2 are ALCHQI concepts, R is a simple role and n ∈ N, then also ¬C, C1 u C2 , and (∃>n R.C) are ALCHQI concepts. We use also some abbreviations for concepts: def

def

∃R.C = ∃≥1 R.C

C1 t C2 = ¬(¬C1 u ¬C2 ) def

def (n+1)

∀R.C = ∃ R.C)

R.¬C

def

⊥ = A u ¬A for some A ∈ NC def

(∃n R. C) = (∃6n R.C) u (∃>n R.C) > = ¬⊥ Concepts that are not concept names are called complex. A literal

3

concept is a possibly negated concept name. A TBox T is a finite set of equality axioms C1 ≡ C2 (sometimes, general inclusion axioms of the form C1 v C2 are also allowed, where C1 , C2 are complex concepts). An equality with an atomic concept in the left-hand side is a concept definition. In the sequel, we always consider TBox axioms set T that is a terminology, a finite set of concept definition formulas with unique left-hand sides, i.e., no atomic concept occurs more than once as a left-hand side. We say that a defined concept name C1 directly uses a concept name C2 with respect to T if C1 is defined by a concept definition axiom in T with C2 occurring in the right-hand side of the axiom. Let uses be the transitive closure of directly uses, and a TBox axioms set T is acyclic if no concept name uses itself with respect to T . An ABox A is a finite set of axioms C(a), R(a, b), and (in)equalities a ≈ b and a ≈ 6 b. The logic ALCQI is obtained by disallowing RBox . A more expressive logic ALCQI(t, u, ¬, |, id) is obtained from ALCQI by introducing identity role id (relating each individual with itself) and allowing complex role expressions: if R1 , R2 are ALCQI(t, u, ¬, | , id) roles and C is a concept, then R1 t R2 , R1 u R2 , ¬R1 , R1− and R1 |C are ALCQI(t, u, ¬, |, id) roles too.5 These complex roles can be used in TBox (in the right-hand sides of definitions). Subsequently, we call a role R primitive if it is either R ∈ NR or it is an inverse role R− for R ∈ NR . Two-variable FO logic FO2 is the def

τx (A) = A(x)

for A ∈ NC

def

τx (>) = x = x def

τx (¬C) = ¬τx (C)

def

τx (⊥) = ¬(x = x) def

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

def

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

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

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

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

def

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

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

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

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

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

τy,x (R) = R(y, x)

for R ∈ NR for R ∈ NR

fragment of ordinary FO logic (with equality), whose formulas only use no more than two variable symbols x and y (free or bound). Twovariable FO logic with counting C 2 extends FO2 by allowing FO counting quantifiers ∃≥m and ∃≤m for all m ≥ 1. Borgida in [6] defines an expressive description logic B and shows that each sentence in the language B without transitive roles and role-composition operator can be translated to a sentence in C 2 with the same meaning, and vice versa, i.e., these two languages are equally expressive. A knowledge base KB is a triple (R, T , A). The semantics of KB is given by translating it into FO logic with counting C 2 by the operator τ (see the table above, in which ./ ∈ {>, 6} and x/y means replace x with y). Borgida’s logic B includes all concept and role constructors in ALCQI(t, u, ¬, |, id) and, in addition, it includes a special purpose constructor product that allows to build the role C1 × C2 from two concepts C1 and C2 . This construct has a simple semantics

C1 × C2 = (R t ¬R)|C2 u ((R t ¬R)|C1 )− , where R can be any role name. Consequently, product can be eliminated. Therefore, the following statement is a direct consequence of the theorems proved in [6]. Theorem 1 The description logic ALCQI(t, u, ¬, |, id) and C 2 are equally expressive (i.e., each sentence in language ALCQI(t, u, ¬, | , id) can be translated to a sentence in C 2 , and vice versa). In addition, translation in both directions leads to no more than linear increase of the size of the translated formula. This statement has an important consequence. Gradel et. al.[11] and Pacholski et al [22] show that satisfiability problem for C 2 is decidable. Hence, the satisfiability and/or subsumption problems of concepts w.r.t. an acyclic or empty TBox in description logic ALCQI(t, u, ¬, |, id) is also decidable.6 In Section 5, we take advantage of this and use C 2 as a foundation for a modified SC.

5 Modeling Dynamic Systems in a Modified Situation Calculus In this section, we consider dynamic systems formulated in a minor modification of the language of the SC so that it can be considered as an extension to C 2 language (with situation argument for unary and binary fluents). The key idea is to consider a syntactic modification of the SC such that the executability and projection problems are guaranteed to be decidable as a consequence of the C 2 property of being decidable.7 Moreover, since the modified SC has a very strong connections with description logics, which will be explained in detail below, we will denote this language as LDL sc . First of all, the three sorts in LDL sc (i.e., actions, situations and objects) are the same as those in Lsc , except that they obey the following restrictions: (1) all terms of sort object are variables (x and y) or constants, i.e., functional symbols are not allowed; (2) all action functions include no more than two arguments. Each argument of any term of sort action is either a constant or an object variable (x or y); (3) variable symbol a of sort action and variable symbol s of sort situation are the only additional variable symbols being allowed in LDL sc in addition to variable symbols x and y. Second, any fluent in LDL sc is a predicate either with two or with three arguments including the one of sort situation. We call fluents with two arguments, one is of sort object and the other is of sort situation, (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 variables x and s only, can be considered as a changeable concept F in a dynamic system specified in LDL sc ; the truth value of F (x, s) could vary from one situation to another. Similarly, each (dynamic) role in LDL sc , say R(x, y, s) with variables x, y and s, can be considered as a changeable role R in a dynamic system specified in LDL sc ; the truth value of R(x, y, s) could vary from one situation to another. In LDL 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 never change. If they are present, they represent unchangeable taxonomic 6

def

τx,y (C1 × C2 ) = τx (C1 ) ∧ τy (C2 ) , and makes the translation from C 2 into B rather straightforward. Although constructor product is not a standard role constructor, we can use restriction constructor | in addition with t, u, ¬ and inverse role to represent it. That is, for any concepts C1 and C2 , 5

7

These standard roles constructors and their semantics can be found in [3].

4

In [3] it is shown that the satisfiability problems of concepts and subsumption problems of concepts can be reduced to each other; moreover, if a TBox T is acyclic, the reasoning problems w.r.t. T can always be reduced to problems w.r.t. the empty TBox. The reason that we call it a ”modified” SC rather than a ”restricted” SC is that we not only restrict the number of variables that can be mentioned in the SC during the formalizations of dynamic systems, but we also extend the SC with other features, such as introducing counting quantifiers and adding acyclic TBox axioms to basic action theories.

properties and unchangeable classes of an application domain. Moreover, each concept (static or dynamic) can be either primitive or defined. For each primitive dynamic concept, a SSA must be provided in the basic action theory formalized for the given system. Because defined dynamic concepts are expressed in terms of primitive concepts by axioms similar to TBox , SSAs for them are not provided. In addition, SSAs are provided for dynamic primitive roles. Third, apart from standard FO logical symbols – ∧, ∨ and ∃, with the 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 currently unknown rather than false. In this paper, the dynamic systems we 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 BAT in Lsc , and the other two (DT , DR ) are introduced to axiomatize description logic related facts and properties (see below). However, because LDL allows only two object variables, all axioms must sc conform to the following additional requirements. Action precondition axioms Dap : For each action A in LDL sc , there is one axiom of the form P oss(A, s) ≡ ΠA [s] (or P oss(A(x), s) ≡ ΠA (x)[s], or P oss(A(x, y), s) ≡ ΠA (x, y)[s], respectively), if A is an action constant (or unary, or binary action term, respectively), where ΠA (or ΠA (x), or ΠA (x, y), respectively) is a C 2 formula with no free variables ( or with at most x, or with at most x, y as the only free variables, respectively). This set of axioms characterize the preconditions of all actions. Successor state axioms Dss : For each primitive dynamic concept F (x, s) in LDL sc , a SSA is specified for F (x, do(a, s)). According to the general syntactic form of the SSAs provided in [25], without loss 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. W 0 + x(i,1,+) )[s])) ∨ x(i,0,+) ) ∧ φ+ ψF (x, a, s) ≡ ( m i (~ i=1 [∃x][∃y](a = Ai (~ W m1 − x(j,0,−) ) ∧ φ− x(j,1,−) )[s]))), F (x, s) ∧ ¬(( j=1 [∃x][∃y](a = Aj (~ j (~ where each variable vector ~ x(i,n,b) (or ~ x(j,n,b) respectively) (i = 1..m0 , j = 1..m1 , n ∈ {0, 1}, b ∈ {+, −}) represents a vector of object variables, which can be empty, x, y, hx, yi or hy, xi. Moreover, [∃x] or [∃y] represents that the quantifier included in [ ] is optional; and each φ+ x(i,1,+) ), i = 1..m0 i (~ (φ− x(j,1,−) ), j = 1..m1 , respectively), is a C 2 formula with i (~ 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 form R(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) is as follows. W 2 [∃x][∃y](a = A+ x(i,0,+) ) ∧ φ+ ψR (x, y, a, s) ≡ ( m x(i,1,+) )[s])) ∨ i (~ i (~ Wi=1 m3 − R(x, y, s) ∧ ¬(( j=1 [∃x][∃y](a = Aj (~ x(j,0,−) ) ∧ φ− x(j,1,−) )[s]))), j (~ 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 a vector of free variables, which can be either empty, x, y, hx, yi or hy, xi. Moreover, [∃x] or [∃y] represents that the quantifier included in [ ] is optional; and each φ+ x(i,1,+) ), i = 1..m2 i (~ x(j,1,−) ), j = 1..m3 , respectively), is a C 2 formula with (φ− j (~ variables (both free and quantified) among x and y.8 8

Acyclic TBox axioms DT : Similar to the TBox axioms in DL, we may also introduce a group of axioms DT to define new concepts, which are later called TBox axioms. Any group of TBox axioms DT may include two sub-classes: static TBox DT,st and dynamic TBox DT,dyn . Every formula in static TBox is a concept definition formula of the form G(x) ≡ φG (x), where G is a unary predicate symbol and φG (x) is a C 2 formula in the domain with free variable x, and there is no dynamic concept or dynamic role in it. Every formula in dynamic TBox is a concept definition formula of the form G(x, s) ≡ φG (x)[s], where φG (x) is a C 2 formula with free variable x, and there is at least one dynamic concept or dynamic role in it. All the concepts appeared in the left-hand side of TBox axioms are called defined concepts. During reasoning, we use lazy unfolding technique (see [2]) to expand a given sentence whenever we regress defined dynamic concepts. In this paper, we require that the set of TBox axioms must be acyclic to ensure the lazy unfolding approach terminates in the finite number of steps (acyclicity in DT is defined exactly as it is defined for TBox ). RBox axioms DR : Similar to the idea of RBox in DL, we may also specify a group of axioms, called RBox axioms below, to support a role taxonomy. Each role inclusion axiom R1 v R2 , if any, where R1 and R2 are primitive roles (either static or dynamic) is represented as R1 (x, y)[s] ⊃ R2 (x, y)[s]. If these axioms and included in the BAT D, then it is assumed that D is specified correctly in the sense that the meaning of any RBox axiom included in the theory is correctly compiled into SSAs. This means that one can prove by induction that D |= ∀s.R1 (x, y)[s] ⊃ R2 (x, y)[s]. Although RBox axioms are not used by the regression operator, they are used for taxonomic reasoning in the initial theory. Initial theory DS0 : It is a finite set of C 2 sentences (assuming that we suppress the only situation term S0 in all fluents). It specifies the incomplete information about the initial problem state and also describes all the facts that are not changeable over time in the domain of an application. In particular, it includes static TBox axioms DT,st as well as RBox axioms in the initial situation S0 (if any). The remaining two classes ( Σ and Duna ) are the same as those in the usual SC. After giving the definition of what the BAT in LDL sc is, we turn our attention to the reasoning tasks. Given a formula W of LDL sc in the domain D, the definition of W being regressable (called LDL sc regressable below) is slightly different from the definition of W being regressable in Lsc (see Section 3) by adding the following additional conditions: (4) any variable (free or bounded) in W is either x or y; (5) every term of sort situation in W is ground. Moreover, to avoid using new variables and assure defined dynamic concepts being handled, we modify the regression operator (which later is still denoted as R) for each LDL sc regressable formula using the following ideas: (1) whenever the operator meets a defined dynamic concept, it will replace the concept with the corresponding definition, i.e., with the right hand-side of the TBox axiom for this concept; (2) whenever the operator meets a atomic sentence whose the positions of variable x and y are different from the positions of the left hand-side of the axiom given in the basic action theory, we will switch all the appearances of x and y (both free and quantified) at the right hand-side of the axiom when replacing the atomic sentence with the right handside of the axiom in the basic actions theorem. The detailed definition can be found in [14]. We proved that using such regression operator on LDL sc regressable responding disjunctive subformula is equivalent to f alse.

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

5

formulas, regression terminates in a finite number of steps. Moreover, we also proved the following key property indicating that the projection problems and executability problems are decidable for any LDL sc regressable formulas in the modified situation calculus LDL sc . Theorem 2 (see [14] for details) Suppose W is a LDL sc regressable formula with the background basic action theory D. Then, the problem whether D |= W is decidable.

6 An Example In this section, we give an example to illustrate the basic ideas described above. Example 1 Consider some university that provides on the Web student administration and management services, such as admitting students, paying tuition fees, enrolling or dropping courses and entering grades. Although the number of object arguments in the predicates can be at most two, sometimes, we are still able to handle those features of the systems that require more than two arguments. For example, the grade z of a student x in a course y may be represented as a predicate grade(x, y, z) in the general FOL (i.e., with three object arguments). Because the number of distinct grades is finite and they can be easily enumerated as ”A”, ”B”, ”C” or ”D”, we can handle grade(x, y, z) by replacing it with a finite number of extra predicates, say gradeA(x, y), gradeB(x, y), gradeC(x, y) and gradeD(x, y) such that they all have two variables only. However, the restriction on the number of variables limits the expressive power of the language if more than two arguments vary over infinite domains (such as energy, weight, time, etc). Despite this limitation, we conjecture that many web services still can be represented with at most two variables either by introducing extra predicates (just like we did for the predicate grade) or by grounding some of the arguments if their domains are finite and relatively small. Intuitively, it seems that most of the dynamic systems can be specified by using properties and actions with small arities, hence the techniques for arity reductions mentioned above and below require no more than polynomial increase in the number of axioms. The high-level features of our example are specified as the following concepts and roles. • Static primitive concepts: person(x) (x is a person); course(x) (x is a course provided by the university). • Dynamic primitive concepts: incoming(x, s) (x is an incoming 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 true when an incoming student x pays the tuition fee). • Dynamic defined concepts: eligF ull(x, s) (x is eligible to be a full-time student by paying more than 5000 dollars tuition fee); eligP art(x, s) (x is eligible to be a part-time student by paying no more than 5000 dollars tuition); qualF ull(x, s) (x is a qualified fulltime student if he or she pays full time tuition fee and takes at least 4 courses); qualP art(x, s) (x is a part-time student if he or she pays part-time tuition and takes 2 or 3 courses). • Static role: preReq(x, y) (course x is a prerequisite of course y). • Dynamic roles: tuitP aid(x, y, s) (x pays tuition fee y in the situation s); enrolled(x, y, s) (x is enrolled in course y in the situation s); completed(x, y, s) (x completes course y in the situation s); hadGrade(x, y, s) (x had a grade for course y in the situation 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 eligible); admit(x) (the university admits student x); payT uit(x, y) (x pays tuition fee with the amount of y); enroll(x, y) (x enrolls in course y); drop(x, y) (x drops course y); enterA(x, y) (enter grade ”A” for student x in course y); enterB(x, y); enterC(x, y); enterD(x, y). The basic action theory is as follows (most of the axioms are selfexplanatory). Precondition Axioms: P oss(reset, s) ≡ true, P oss(admit(x), s) ≡ person(x) ∧ ¬incoming(x, s), P oss(payT uit(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 situation s is also enrolled(x, y, s). Moreover, in the traditional SC, the precondition 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 and action variable a. Fortunately, the number of the courses offered in a university is limited (finite and relatively small) and relatively stable over years (if we manage the students in a college-wise range or department-wise range, the number of courses may be even smaller). Therefore, we can specify the precondition for the action enroll(x, y) for each instance of y. That is, assume that the set of courses is {CS1 , · · · , CSn }, the precondition axiom for each CSi (i = 1..n) is P oss(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 omit the statements course(x) for each course available at the university in the initial theory. Successor State Axioms: The SSAs for the fluents gradeB(x, y, s), gradeC(x, y, s) and gradeD(x, y, s) are very similar to the one for fluent gradeA(x, y, s) (therefore are not repeated here), which ensures that for each student and each course there is no more than one grade assigned. incoming(x, do(a, s)) ≡ a = admit(x) ∨ incoming(x, s), student(x, do(a, s)) ≡ (∃y)(a = payT uit(x, y))∨ student(x) ∧ a 6= reset, tuitP aid(x, y, do(a, s)) ≡ a = payT uit(x, y)∨ tuitP aid(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) eligF ull(x, s) ≡ (∃y)(tuitP aid(x, y, s) ∧ y > 5000), eligP art(x, s) ≡ (∃y)(tuitP aid(x, y, s) ∧ y ≤ 5000), qualF ull(x, s) ≡ eligF ull(x, s) ∧ (∃≥4 y)enrolled(x, y, s), qualP art(x, s) ≡ eligP art(x, s) ∧ (∃≥2 y)enrolled(x, y, s) ∧(∃≤3 enrolled(x, y, s)). An example of the initial theory DS0 could be the conjunctions of the following sentences:

6

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).preP eq(y, x), (∀x)¬student(x, S0 ). We may 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 reasoning about executability problems and projection problems. However, they are useful for terminological reasonings when necessary. For instance, we may reason about ∀x.∀s.((∃≤1 y)(hadGrade(x, y, s) ∧ course(y)) ⊃ ((∃≤1 y)(gradeA(x, y, s) ∧ course(y))∨ (∃≤1 y)(gradeB(x, y, s) ∧ course(y)))). Since the truth value of such statement in fact has nothing to do with the situation argument, it is the same as the following formula represented in Description Logics. ∃≤1 hadGrade.course v (∃≤1 gradeA.course t ∃≤1 gradeB.course). Finally, we give an example of regression of a LDL sc regressable formula. R[(∃x).qualF ull(x, do([admit(P1 ), payT uit(P1 , 6000)], S0 ))] = R[(∃x).eligF ull(x, do([admit(P1 ), payT uit(P1 , 6000)], S0 ))∧ (∃≥4 y)enrolled(x, y, do([admit(P1 ), payT uit(P1 , 6000)], S0 ))] = ··· = (∃x).(∃≥4 y)enrolled(x, y, S0 ) ∧ ((∃y)R[y > 5000∧ tuitP aid(x, y, do([admit(P1 ), payT uit(P1 , 6000)], S0 ))]) = ··· = (∃x).(∃≥4 y)enrolled(x, y, S0 ) ∧ ((∃y).tuitP aid(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.qualF ull(x), and a composite web service starting from the initial situation, for example do([admit(P1 ), payT uit(P1 , 6000)], S0 ) (we denote the corresponding resulting situation as Sr ), we can check if the goal is satisfied after the execution of this composite web service by solving the projection problem whether D |= G[Sr ]. In our example, this corresponds to solving whether D |= ∃x.qualF ull(x, Sr ). We may also check if a given (ground) composite web service A1 ; A2 ; · · · ; An is possible to execute starting from the initial state by solving the executability problem whether D |= executable(do([A1 , A2 , · · · , An ], S0 )). For example, we can check if the composite web service admit(P1 ); payT uit(P1 , 6000) is possible to be executed from the starting state by solving whether D |= executable(Sr ).

7 Discussion and Future Work The major consequence of the results proved above for the problem of service composition is the following. If both atomic services and properties of the world that can be affected by these services have no more than two parameters, then we are guaranteed that even in the state of incomplete information about the world, one can always determine whether a sequentially composed service is executable and whether this composite service will achieve a desired effect. The previously proposed approaches made different assumptions: [20] as-

sumes that the complete information is available about the world when effects of a composite service are computed, and [5] considers the propositional fragment of the SC. As we mentioned in Introduction, [20, 21] propose to use Golog for composition of Semantic Web services. Because our primitive actions correspond to elementary services, it is desirable to define Golog in our modified SC too. It is surprisingly straightforward to define almost all Golog operators starting from our C 2 based SC. The only restriction in comparison with the original Golog [18, 25] is that we cannot define the operator (πx)δ(x), non-deterministic choice of an action argument, because LDL sc regressable formulas cannot have occurrences of non-ground action terms in situation terms. In the original Golog this is allowed, because the regression operator is defined for a larger class of regressable formulas. However, everything else from the original Golog specifications remain in force, no modifications are required. In addition to providing a well-defined semantics for Web services, our approach also guarantees that evaluation of tests in Golog programs is decidable (with respect to arbitrary theory DS0 ) that is missing in other approaches (unless one can make the closed world assumption or impose another restriction to regain decidability). The most important direction for future research is an efficient implementation of a decision procedure for solving the executability and projection problems. This procedure should handle the modified LDL sc regression and do efficient reasoning in DS0 . It should be straightforward to modify existing implementations of the regression operator for our purposes, but it is less obvious which reasoner will work efficiently on practical problems. There are several different directions that we are going to explore. First, according to [6] and Theorem 1,there exists an efficient algorithm for translating C 2 formulas to ALCQI(t, u, ¬, |, id) formulas. Consequently, we can use any resolution-based description logic reasoners that can handle ALCQI(t, u, ¬, |, id) (e.g., MSPASS [17]). Alternatively, we can try to use appropriately adapted tableaux-based description logic reasoners, such as FaCT++, for (un)satisfiability checking in ALCQI(t, u, ¬, |, id). Second, we can try to avoid any translation from C 2 to ALCQI(t, u, ¬, |, id) and adapt resolution based automated theorem provers for our purposes [7]. The recent paper by Baader et al [4] proposes integration of description logics ALCQIO (and its sub-languages) with an action formalism for reasoning about Web services. This paper starts with a description logic and then defines services (actions) meta-theoretically: an atomic service is defined as the triple of sets of description logic formulas. To solve the executability and projection problems this paper introduces an approach similar to regression, and reduces this problem to description logic reasoning. The main aim is to show how executability of sequences of actions and solution of the executability and projection problems can be computed, and how complexity of these problems depend on the chosen description logic. In the full version of [4], there is a detailed embedding of the proposed framework into the syntactic fragment of the Reiter’s SC. It is shown that solutions of their executability and projection problems correspond to solutions of these problems with respect to the Reiter’s basic action 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 result potentially in exponential blow-up of the theory). Despite that our paper and [4] have common goals, our developments start differently and proceed in the different directions. We start from the syntactically restricted FO language (that is significantly more expressive than ALCQIO), use it to construct the modified SC (where

7

actions are terms), define basic action theories in this language and show that by augmenting (appropriately modified) regression with lazy unfolding one can reduce the executability and projection problems to the satisfiability problem in C 2 that is decidable. Furthermore, C 2 formulas can be translated to ALCQI(t, u, ¬, |, id), if desired. Because our regression operator unfolds fluents “on demand” and uses only relevant part of the (potentially huge) TBox , we avoid potential computational problems that may occur if the TBox were eliminated in advance. The advantage of [4] is that all reasoning is reduced to reasoning in description logics (and, consequently, can be efficiently implemented especially for less expressive fragments of ALCQIO). Our advantages are two-fold: the convenience of representing actions as terms, and the expressive power of LDL sc . Because C 2 and ALCQI(t, u, ¬, |, id) are equally expressive, there are some (situation suppressed) formulas in our SC that cannot be expressed in ALCQIO (that does not allow complex roles). An interesting paper [19] aims to achieve computational tractability of solving projection and progression problems by following an alternative direction to the approach chosen here. The theory of the initial state is assumed to be in the so-called proper form and the query used in the projection problem is expected to be in a certain normal form. In addition, [19] considers a general SC and impose no restriction on arity of fluents. Because of these significant differences in our approaches, it is not possible to compare them. There are several other proposals to capture the dynamics of the world in the framework of description logics and/or its slight extensions. Instead of dealing with actions and the changes caused by actions, some of the approaches turned to extensions of description logic with temporal logics to capture the changes of the world over time [1, 2], and some others combined planning techniques with description logics to reason about tasks, plans and goals and exploit descriptions of actions, plans, and goals during plan generation, plan recognition, or plan evaluation [10]. Both [1] and [10] review several other related papers. In [5], Berardi et al. specify all the actions of e-services as constants, all the fluents of the system have only situation argument, and translate the basic action theory under such assumption into description logic framework. It has a limited expressive power without using arguments of objects for actions and/or fluents: this may cause a blow-up of the knowledge base.

Acknowledgments Thanks to the Natural Sciences and Engineering Research Council of Canada (NSERC) and to the Department of Computer Science of the University of Toronto for providing partial financial support for this research.

REFERENCES [1] Alessandro Artale and Enrico Franconi. A survey of temporal extensions of description logics. Annals of Mathematics and Artificial Intelligence, 30(1-4), 2001. [2] Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi, and Peter F. Patel-Schneider, editors. The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge Un. Press, 2003. [3] Franz Baader, Ian Horrocks, and Ulrike Sattler. Description logics as ontology languages for the semantic web. In Dieter Hutter and Werner Stephan, editors, Mechanizing Mathematical Reasoning, Essays in Honor of J¨org H. Siekmann on the Occasion of His 60th Birthday, Lecture Notes in Computer Science, vol. 2605, pages 228–248. Springer, 2005. [4] Franz Baader, Carsten Lutz, Maja Miliˆci´c, Ulrike Sattler, and Frank Wolter. Integrating description logics and action formalisms: First results. In Proceedings of the Twentieth National Conference on Artificial Intelligence (AAAI-05), pages 572–577, Pittsburgh, PA, USA, July 2005. extended version is available as LTCS-Report-05-02 from http://lat.inf.tu-dresden.de/research/reports.html.

[5] Daniela Berardi, Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, and Massimo Mecella. e-service composition by description logics based reasoning. In Diego Calvanese, Giuseppe de Giacomo, and Enrico Franconi, editors, Proceedings of the 2003 International Workshop in Description Logics (DL-2003), Rome, Italy, 2003. [6] Alexander Borgida. On the relative expressiveness of description logics and predicate logics. Artificial Intelligence, 82(1-2):353–367, 1996. [7] Hans de Nivelle and Ian Pratt-Hartmann. A resolution-based decision procedure for the two-variable fragment with equality. In A. Leitsch R. Gor´e and T. Nipkow, editors, IJCAR’01: Proceedings of the First International Joint Conference on Automated Reasoning, pages 211– 225, London, UK, 2001. Springer-Verlag, LNAI, V. 2083. [8] Giuseppe De Giacomo. Decidability of Class-Based Knowledge Representation Formalisms. Dipartimento di Informatica e Sistemistica Universita di Roma ”La Sapienza”, Roma, Italy, 1995. [9] Giuseppe De Giacomo, Luca Iocchi, Daniele Nardi, and Riccardo Rosati. A theory and implementation of cognitive mobile robots. Journal 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 Gr¨adel, Martin Otto, and Eric Rosen. Two-variable logic with counting is decidable. In Proceedings of the 12th Annual IEEE Symposium on Logic in Computer Science (LICS’97), pages 306–317, Warsaw, Poland, 1997. [12] Michael Gr¨uninger. Ontology of the process specification language. In Steffen Staab and Rudi Studer, editors, Handbook on Ontologies, pages 575–592. Springer, 2004. [13] Michael Gr¨uninger and Christopher Menzel. The process specification language (PSL): Theory and applications. AI Magazine, 24(3):63–74, 2003. [14] Yilan Gu and Mikhail Soutchanski. The two-variable situtation calculus. In Proc. of the Third European Starting AI Researcher Symposium (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. From SHIQ 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. Tools for composite web services: a short overview. SIGMOD Record, 34(2):86–95, 2005. [17] Ullrich Hustadt and Renate A. Schmidt. Issues of decidability for description logics in the framework of resolution. In R. Caferra and G. Salzer, editors, Automated Deduction, pages 191–205. SpringerVerlag, LNAI, V. 1761, 2000. [18] Hector Levesque, Ray Reiter, Yves Lesp´erance, Fangzhen Lin, and Richard Scherl. GOLOG: A logic programming language for dynamic domains. Journal of Logic Programming, 31:59–84, 1997. [19] Yongmei Liu and Hector J. Levesque. Tractable reasoning with incomplete first-order knowledge in dynamic systems with context-dependent actions. In Proc. IJCAI-05, Edinburgh, Scotland, August 2005. [20] Sheila McIlraith and Tran Son. Adapting Golog for composition of semantic web services. In D. Fensel, F. Giunchiglia, D. McGuinness, and M.-A. Williams, editors, Proceedings of the Eighth International Conference on Knowledge Representation and Reasoning (KR2002), pages 482–493, Toulouse, France, April 22-25 2002. Morgan Kaufmann. [21] Srini Narayanan and Sheila McIlraith. Analysis and simulation of web services. Computer Networks, 42:675–693, 2003. [22] Leszek Pacholski, Wiesław Szwast, and Lidia Tendera. Complexity of two-variable logic with counting. In Proceedings of the 12th Annual IEEE Symposium on Logic in Computer Science (LICS-97), pages 318–327, Warsaw, Poland, 1997. A journal version: SIAM Journal on Computing, v 29(4), 1999, p. 1083–1117. [23] Fiora Pirri and Ray Reiter. Some contributions to the metatheory of the situation calculus. Journal of the ACM, 46(3):325–364, 1999. [24] Marco Pistore, AnnaPaola Marconi, Piergiorgio Bertoli, and Paolo Traverso. Automated composition of web services by planning at the knowledge level. In Leslie Pack Kaelbling and Alessandro Saffiotti, editors, Proceedings of the Nineteenth International Joint Conference on Artificial Intelligence (IJCAI05), pages 1252–1259, Edinburgh, Scotland, UK, July 30-August 5 2005. http://ijcai.org/papers/1428.pdf. [25] Raymond Reiter. Knowledge in Action: Logical Foundations for Describing and Implementing Dynamical Systems. The MIT Press, 2001. [26] Evren Sirin, Bijan Parsia, Dan Wu, James Hendler, and Dana Nau. HTN planning for web service composition using SHOP2. Journal of Web Semantics, 1(4):377–396, October 2004.

8

A Service Selection Model to Improve Composition Reliability Natallia Kokash 1 differs from the existing works in two aspects. First, it is well-known that good average statistics do not prevent from unexpected service faults. We study the problem of service selection assuming their probable failures. The solution is represented by several compositions able to satisfy given constraints on quality parameters and to reduce fault recovery expenses. Second, we use a single quality measure, that, though, takes into consideration the correlation between service reliability and other parameters. The paper is structured as follows. Section 2 discusses related work. In section 3, quality and web service composition models are outlined. Section 4 introduces a compound quality measure that characterizes reliability of redundant service compositions. Web service selection mechanism we propose is presented in Section 5. Finally, conclusions and future work are sketched in Section 6.

Abstract. One of the most promising advantages of web service technology is the possibility of creating added-value services by combining existing ones. A key step for composing and executing services lies in the selection of the individual services to use. Much attention has been devoted to appropriate selection of service functionalities, but also the non-functional properties of the services play a key role. Due to ever changing business environment, service users are not guaranteed from unexpected service faults. Service composition can compensate the deficiencies of constituent components aggregating a redundant number of them for individual tasks. This paper proposes a service selection strategy targeting at minimizing the impact of atomic service failure on the quality of service of compositions.

1 Introduction 2 Related Work

Service-Oriented Architecture (SOA) is an upcoming organizational model aiming at simplifying large-scale business operations by consumption of ready-to-use services. The most prominent realization of SOA is currently in the area of web services. Web services are loosely-coupled, platform-independent, self-describing software components that can be published, located and invoked via the web infrastructure using a stack of standards such as SOAP, WSDL and UDDI [12]. Composition of web services is probably the most interesting challenge spawned by this paradigm. Many efforts have been devoted to development of automatic or semi-automatic service composition mechanisms [1] [10] [16] [15]. We are striving for runtime composition, when a composer automatically searches, binds and executes available web services to satisfy some user request. Such a scenario is hardly feasible for a large spectrum of applications. Automatic service compositions are error prone. State-of-the-art techniques are not mature enough to guarantee a common semantic of the involved operations. Testing, adaptation, verification and validation processes are required. However, statically composed services, able to accomplish some generalized request classes (e.g., user trip planning), can presume manifold alternative components for each subgoal and practice dynamic switching between them. A set of services to satisfy a particular user request is selected depending on conditions like Quality of Service (QoS) parameters, service provider policy or user preferences. Several approaches for runtime selection of component services have been developed [7] [17] [18]. They tend to consider multiple quality factors and search for a solution that optimizes weighted composition of their average values under user constraints. In this paper, we propose a novel service selection strategy. Our approach 1

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

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

QoS Throughput Capacity Latency Response time Availability Reliability Reputation Execution cost

QoS factors of web services [13]

Description The number of requests served in a given time period. A limit of concurrent requests for guaranteed performance. The round-trip time between client request and service response. The time taken by a service to process its sequence of activities. The probability that a service is available. Stability of a service functionality, i.e., ability of a service to perform its functions under stated conditions The average rate of the service reported by clients. The amount of money for a single service execution.

Level Agreement (SLA) defines the agreed level of performance for a particular service between a service provider and a service user. The Web Service Level Agreement (WSLA) project [6] is targeted at defining and monitoring SLAs for web services. SLA parameters can be measured with different metrics, including composite ones like maximum response time or average availability. Composite metrics are specified byfunctions which are executed during the predefined time

Department of Information and Communication Technology, University of Trento, Via Sommarive, 14, 38050 Trento, Italy, email: [email protected]

9

intervals, specified byschedules. Sherchan et al. [14] report the relevance of recent service performance measurements. Service quality parameters depend on manifold factors which should be taken into account at the early stages of development. Menasce et al. [11] provide a methodology for planning service capacity. Knowledge about the number of potential users, frequency of service invocations and their time distributions is essential for the analysis. An accurate capacity planning can be quite problematic because of factor uncertainty or limited budget. As a consequence, a signific ant number of troublesome services could appear.

to analyze the detected fault and put the system into a correct state. The second one returns the system into a previous fault-free state without requiring detailed knowledge of the fault. Workflow systems rely intensely on backward error recovery if the resources are under the control of a single domain. Forward recovery is extensively used to handle errors in composite web services. Chafleet. al [5] propose a mechanism for fault propagation and recovery in decentralized service orchestrations. Decentralized architecture results in additional complexity requiring fault propagation between partitions executed independently.

2.2 Quality of Web Service Compositions

3 Web Service Composition Model

Service compositions that embed low-quality services inherit all their drawbacks. This poses a big challenge for the software developers building new systems on the basis of available components. Cardoso et al. [4] describe the model that allows to predict quality of service for workflows based on atomic service QoS attributes. One can compensate composition deficienc y if many services with compatible functionality exist. Several approaches have been proposed for quality-aware service selection. Zeng et al. [18] consider the service selection task as a global optimization problem. Linear programming is applied to find the solution that represent the service composition optimizing the target function. The latter is defined as a linear combination of fi ve parameters: availability, successful execution rate, response time, execution cost and reputation. If the global characteristics (e.g., the total amount of money to accomplish the user goal), are not restricted, the optimal solution can be found by modified Dijkstra’s algorithm searching on the graph of available compositions [8]. Martin-Diaz et al. [7] propose a constraint programming solution for procurement of web services whose demands and offers are temporal-aware. In [3] the problem is modelled as a mixed integer linear program where both local and global constraints are specified. Yu and Lin [17] modelled the service selection as a complex multi-choice multi-dimension 0-1 knapsack problem. Practice of offering different quality levels by services was taken into consideration. The above solutions depend strongly on the user weights assigned to each parameter. However, it is not trivial for a user to establish them in right way. An example in Table 2 demonstrates limitations of the algorithm in [18]. Let w1 = 0.6 and w2 = 0.4 reflectthe user scores for response time and availability, correspondingly. After scaling and weighting phases service s1 will be chosen. However, the services have a small difference in response time and a huge diversity in availability rate. As a fast remedy, the intuition about absolute QoS values should be involved, e.g., from 0 to 100% for availability and from 0 to timeout ms for response time. The principal drawback of the approach is that the cross-impact of different quality parameters is not considered.

As opposed to the discussed service selection approaches we do not consider multiple QoS factors. Service reputation is excluded due to its subjective nature. High reputation of elementary services does not imply high reputation of their compositions due to potential problems with input data and effect/precondition satisfaction that cannot be fully verified at the planning phase. We do not consider the nature of web 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 is considered to be successful if the user goal is satisfied or we can proceed along with an execution of a composite service, i.e., (1) a constituent service was available, (2) the successful response message was received within an established timeout, (3) no errors were detected automatically during the output and effects checking, (4) preconditions of a subsequent service were satisfied. Along with the probability of success we often use the probability of failure p(s) = 1 − p(s). The other relevant parameters are response time qtime (s) and execution cost qcost (s) of service s. A composite web service can be defined in terms of the standard BPEL (stands for Business Process Execution Language) [2] or other composition languages [9]. Services are composed by the following three 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 happens in one of the parallel services, we suppose it will be correctly forwarded to the end of partition [5]. After that we should decide whether the whole parallel composition is failed or only the erroneous branch has to be recovered. For the sake of simplicity we will not consider parallel compositions here. Since we are mostly interested in the non-functional qualities, parallel compositions can be approximately reduced to sequential ones as follows: for service c = (s1 |s2 ) its execution cost will be

Table 2. QoS-aware WS selection [18]

s1 s2

Response time (ms) Original Scaled 1 1 2 0

Availability (%) Original Scaled 10 0 100 1

Result w = (0.6, 0.4) 0.6 0.4

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

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

qtime (c) = max(qtime (s1 ), qtime (s2 )), probability of success p(c) = p(s1 )p(s2 )

10

4

Fault-tolerant Service Compositions

4.1 Fault Recovery

Figure 1.

Existing service composition selection models do not take into account unpredictable service faults. The problem cannot be fully resolved by discarding the failed service. The time for finding a new solution from scratch increases latency for the requests arrived in the system. We propose to choose several configurations with good qualities at the selection stage. If a failure occurs in the chosen configuration, another configuration can be switched into.

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 end points). Nodes denote states T = {tj |j = 1, ..., n} and edges are labelled to represent available web services S = {si |i = 1, ..., m}. Generally, multiple edges between two nodes are permitted. The processing of a user request begins from the start state t0 . In the end state t the user goal is accomplished. These two states are welldefined for a given class of problems. It is assumed that all web services have deterministic behavior. A graph G = (T, S) is called a composition graph (see Figure 1). Note that branching in the composition graph corresponds to choice operator. Further, tail[si ] will denote a tail and head[si ] a head of an edge si . Let also din [tj ] and dout [tj ] refer to input and output degree of a state tj , correspondingly.

Figure 2.

Figure 3.

Execution plan

In Figure 3, a possible execution plan is shown. A tuple htj , ci i with an incoming edge ak means that configuration ci is started from state tj after event ak . In this example a1 means any failure 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 recovery actions can be established automatically based on the analysis of the dependency between configurations. In more complicated scenarios the events like input/output is not correct/complete, preconditions/postconditions are not satisfied, message is lost, exception is raised by a service, connection error, timeout is expired, SLA is violated, etc., can require different reactions. At this point we can start analyzing the error types in order to choose the optimal system behavior.

4.2 Failure Risk

Configuration tree

Let c = (s1 ; s2 ; ...; sk ) be a sequential composition with the only return point head[s1 ]. If a service si fails a new configuration can be started from state head[s1 ]. The results of services {s1 , s2 , ..., si } will not be used whereas their response time and execution cost increase the total expenses to satisfy a user request. We refer to these expenses as to the loss function of a service si failure. There are no reasons to impose penalties on services {s1 , ..., si−1 } since they are not responsible for errors of service si . We propose a service selection strategy based on the analysis of failure risks and targeted at decreasing the expected loss in such a scenario. Failure risk is a characteristic considering probability that some fault will occur and the resulting impact of this fault on the composite service. For an atomic service si it equals

A composition with choice operators can be separated into several sequential compositions, called configur ations, that correspond to paths between start and end states in a composition graph. Two configurations are independent if they do not have common states except start and end ones, and dependent otherwise. All possible configurations can be shown on theconfigur ation tree(see Figure 2). The start state of a composition graph corresponds to the start state of the associated configuration tree, and nodes with the same labels have the same output degree. Definition 1 Node ti of a composition graph G is a return state if either it is the start state or its outdegree dout (ti ) > 1.

r(si ) = p(si )q(si ). Service s1 is considered to be better than service s2 if it has a smaller failure risk r(s1 ) < r(s2 ). Within the sequential composition c = (s1 ; ...; sk ), k > 1, the risk of a service si failure is measured as

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

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

11

where

i−1 Y

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

mentioned parameters. We do not strictly require that the loss function should be linear. So, we can measure the response time of a composite web service with a certain probability as follows: Let P1 (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 respond within time t0 . Letting p1 (t) and p2 (t) be the corresponding probability density functions, p(t) can be calculated as a convoluR tion p(t) = p1 (t − τ )p2 (τ )dτ and P (t ≤ t0 ) can be obtained by

p(sj )p(si )

j=1

is the probability of composition failure while service si is being executed, and q(s1 ; ...; si ) =

i X

q(sj )

j=1

is the loss function of this failure. Since for a sequential composition all services should be invoked to accomplish a task, we exploit a total risk value which for a k-service long chain equals R(c) = R(s1 ; ...; sk ) =

k X

taking corresponding distribution P (t ≤ t0 ) =

5 Web Service Selection Methodology r(s1 ; ...; si ).

(1)

5.1

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

Objectives

It is reasonable to assume that an SLA with the end user is established in such a way that available service configurations can satisfy the constraints on response time and execution cost provided the normal conditions, i.e., that the services are not overloaded and no failures befall. However, the unexpected faults of component services lead to resource loss and may cause the violation of negotiated parameters. If there is reserve of the resources (the maximum budget for a task is not reached and there is time left before task execution deadline), a user task can be completed by another configuration . Our objective is to choose an execution plan (see Figure 3) that maximizes composition reliability, which is actually defined by the probability to accomplish a user request within established time and cost boundaries. The problem of increasing service reliability differs from the search of a single configuration with optimal quality parameters. For a single-objective function the latter one can be formalized as selection of a path (s1 ; ...; sk ) between the start and end states that maximizes the following target function:

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

p(s1 ; ...; si ) =

p(t)dt.

0

i=1

where

Rt0

p(sj ).

j=1

The choice composition fails if all invoked services fail. Obviously, the better candidates should be tried first. The question then is how many services to consider. We propose to include a new candidate if it does not increase the total failure risk for the choice composition, i.e. R(c) = R(s1 + ... + sl ) = min r(s1 + ... + si ). (2) i=1,l

Finally, the failure risk of a composition c = (c1 ; c2 ), where c1 = (s1 ; ...; sk ) is a sequential composition and c2 = (s01 + ... + s0l ) is a choice one, can be computed as

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

k Q

i=1

p(si )(q max −

k P

q(si )),

i=1

where q max defines the resource limit, taken from an SLA (or chosen big enough to guarantee the positive value of f (c)). Such a configuration can be found in time O(m), where m is a number of available web services, by searching of a path in a configu ration graph optimizing the formula above. However, practical problems rarely have only one objective. The simplest multi-objective problems focus on two criteria. This subclass of problems is known as dual criteria optimization. The basic approach is to take the less important parameter as objective function provided that the most important criterion meets some requirements. We identify two basic dimensions, namely, response time and execution cost. Although it is hard to predict which of them is more important we suppose that for a provider of composite web services focus should be put on response time. Usually, the internal structure of services is hidden from the end-user, so (s)he expects to pay the fix ed price for a single service execution (provided the same quality level). At the same time, service delays can be indemnified by penalties. On conditions that response time constraint is satisfied, a provider can optimize its own expenses.




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 to execution cost. If the user preferences are given, it can incorporate both of them: q(s) = f (qtime , qcost ). Assuming that f is a linear combination, we get q = w1 qtime + w2 qcost | w1 + w2 = 1, 0 ≤ w1 , w2 ≤ 1. For simplicity we supposed that the money for the invocation of a failed service s are not payed back and the time to detect the error does not differ significantly from the usual service response time. If this 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 penalty payed by the provider of a failed service. Failure risk is a compound measure considering probability of constituent service failures, their response time and/or execution cost along with the structure of a configuration tree. Intuitively, configurations with frequent return points are more preferable. However, the composition selection will depend on the balance between all

5.2 Failure Risk Evaluation Algorithm In this section we present our risk evaluation model for composite web services.

12

To simplify the explanation of the proposed algorithm we will use the notion of graph contraction. The contraction of an edge (vi , vj ) of a directed graph is the directed graph obtained by replacing two nodes vi and vj with a single node v such that v is a head of the edges incoming to the original vertices and a tail of the edges outgoing from them. The contraction of a graph is a process of transforming the graph by applying the operation of edge contraction. A sequential composition (s1 ; ...; sk ), k > 0, can be seen as an elementary service with the failure risk obtained by formula (1) (see Figure 4).

Figure 4.

(2), and this information is transmitted to the precedent edges. Then, we repeat sequential composition replacement again, and so on, terminating if no more composite services are found in graph G0 . Algorithm 1. Failure Risk Evaluation (FRE) 1 G0 ← G, G0 = (T 0 , S 0 ) 2 while |S 0 | ≥ 1 do 3 Sequential(G0 ) 4 Choice(G0 ) Sequential(G0 ) 1 for all si | dout [head[si ]] = 0 do 2 if (dout [tail[si ]] = 1) and (tail[si ] 6= t0 ) then 3 for all sj | head[sj ] = tail[si ] do 4 stack[sj ] ← stack[si ] ← sj 5 S 0 = S 0 \si 6 else //tail[si ] is a return point 7 s ← sequential composition of services stack[si ] 8 remember R(s) as a weight of the edge si in graph G 9 S 0 ← S 0 \si ∪ s 0 Choice(G ) 1 for all ti | (dout [ti ] > 1) ∪ (∀tk ∈ adj[ti ], dout [tk ] = 0) do 2 s ← choice composition of services {sj } = {(ti , tk ), | ∀tk } 3 for all sj | head[sj ] = ti do 4 stack[sj ] ← s 5 S 0 ← S 0 \{si }

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 the paths we will get a reduced tree, where each node is either a return point or the end state, still unambiguously representing all possible configurations (see Figure 5). Such a tree is called acontracted configur ation tree.

Proposition 1 Given a composition graph G = (T, S), the algorithm FRE measures the failure risks of the composite services defined by the subtrees of return points in polynomial time from number of available web services. A proof follows from the next observations:

Figure 5.

Sequential(G0 ): The information about each service si , | dout [tail[si ]] = 1, is pushed into din [tail[si ]] stacks and can be processed in time O(1) later. So, for any state tail[si ], a time O(din [tail[si ]]) is required and this state will not be considered again by this function. Summing up by all states Pnwe get the process time of all sequential compositions O( i=1 din [tail[si ]]) = O(m). Choice(G0 ): For each state ti time mdout [ti ] ln(dout [ti ]) is required to calculate the failure risk and din [ti ] to transmit this information for the precedent services. After that its outgoing edges are deleted and it will not be considered again. Hence, the processing in time Pn of all choice compositions can be
accomplished O (d [t ] + mdout [ti ] ln(dout [ti ]) = O(m2 ln(m)). i=1 in i

Contracted configuration tree

Any choice composition (s1 + ... + sl ), l > 0, can be seen as an elementary service with the failure risk obtained by formula (2). However, we can calculate failure risks of composite services with alternative components only if the failure risks of the latter ones are known, which, in their turn, can be composite as well. The above observations define our failure risk evaluation algorithm (see Algorithm 1). Given a composition graph, it computes the failure risks of composite services defined by the subtrees of any return point. Given these values, a weighted contracted configuration tree can be formed where edges with smaller weights represent the most promising directions. For each composite service si let stack[si ] be a structure where QoS parameters of constituent services are accumulated. Starting from the end state we gradually contract edge chains and partitions assigning failure risks to the corresponding services as has been discussed in Section 4.2. The end state t is the only point satisfying the condition dout [t] = 0 at the initial step of the algorithm. Since a composition graph is acyclic, after removing of an edge si we again will have the states without outgoing edges. When we reach a return point, the chain in the stack of si is contracted and its failure risk is measured by (1). Provided that no more sequences can be processed, the algorithm switches into choice compositions. Each choice composition is replaced by a service with the failure risk computed by

A composition configuration can be chosen by a simple greedy heuristic that selects a service with the least failure risk in any return state. In case of a service failure, gradual change is preferable to sudden, large-scale switching into other configuration since we maximally reuse the results of already invoked services, that is, a composite service should go back to the nearest return point and complete the job by ”attaching”a new configuration. The alternative choices with poor quality (i.e., ones that increase the total failure risk) are excluded from the calculation of failure risk of choice composition. However, such services still can be invoked to recover a failure if there are no better alternatives and the loss of rollback to the next return point is significant.

6

Concluding Remarks and Future Work

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

13

the Internet, web service compositions imply a long list of potential risks, varying from security threats to economic unprofitableness. In such conditions self-adaptivity and redundancy are desirable composition qualities traded against development cost and performance efficienc y. We proposed a model for selecting web services that aims at increasing the reliability of service compositions. We introduced the notion of failure risk for web services and proposed a composition failure risk evaluation methodology. Further, we brieflydescribed the selection algorithm based on local analysis of promising configurations. Several important issues have been left out of the scope of this paper. Careful study of parallel service compositions and dependability between different configu rations is needed. Comprehensive experiments should be carried out in order to characterize the effectiveness of our model. Here we pursued the goal of failure risk minimization provided that a request should be executed within some constraints on time and cost, but without intention to minimize these expenses. The problem of finding an execution plan that maximizes the probability to fulfill the task and spend minimal resources can be tackled in the same manner. In some cases we can distinguish permanent faults and temporal faults (e.g., intermittent server crashes). The latter are characterized by time to repair. It can be reasonable to repeat the invocation of the same service instead of switching into an alternative configuration. We intend to deeper investigate the optimization problems related to usage of web service compositions. As a future work we are planning to look into the perspectives of using advanced scheduling policies. Real-life conditions such as limited service capacity, failures, execution deadlines, provider vs. client interests, etc., transform development of reliable composite services into a challenging task. Static selection models can be useful if the chosen services require significant adaptation efforts and involvement of alternative ones is not feasible or expensive. In dynamic scenarios the end-user would prefer a fast service despite of its low average availability if it is available at the moment of invocation, or a slower service provided that the faster one is overloaded.

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.: ”Business Process 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 Guarantee in Web Service Selection,” IEEE International Conference on Web Services, 2005, pp. 805–806. [4] Cardoso, J., Sheth, A., Miller, J., Arnold, J., Kochut, K.: ”Quality of service for workflows and web service processes”, Journal of Web Semantics, Vol. 1, No. 3, 2004, pp. 281–308. [5] Chafl,G., Chandra, S., Kankar, P., Mann, V.: ”Handling Faults in Decentralized Orchestration of Composite Web Services”, International Conference 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 Approach to Temporal-Aware Procurement of Web Services”, International Conference on Service-Oriented Computing, 2005, pp. 170–184. [8] Gu, X., Chang, R.: ”OoS-Assured Service Composition in managed Service Overlay Networks”, IEEE International Conference on Distributed Computing Systems, 2003. [9] Kokash, N., D’Andrea, V.: ”ServiceOriented Computing and Coordination Models”, Proceedings of Challenges in Collaborative Engineering Workshop, 2005, pp. 95–103. [10] Lazovik, A., Aiello, M., Papazoglou, M.: ”Planning and monitoring the execution of web service requests”, International Conference on Service-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”, ACM SIGecom Exchanges, Vol. 4, No. 1, 2003, pp. 1–10. [14] Sherchan, W., Krishnaswamy, Sh., Loke, S-W.: ”Relevant Past Performance for Selecting Web Services”, International Conference on Quality Software, 2005, pp. 439–445. [15] Srivastava, B., Koehler, J., ”Web Service Composition - Current Solutions and Open Problems”, Proceedings of ICAPS Workshop on Planning for Web Services, 2003. [16] Sirin, E., Hendler, J., Parsia, B.: ”Semi-automatic Composition of Web Services 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 Complex Services with Multiple QoS Constraints”, International Conference on Service-Oriented Computing, 2005, pp. 130–143. [18] Zeng, L., Benatallah, B., et al.: ”QoS-aware Middleware for Web Services Composition”, IEEE Transactions on Software Engineering, Vol. 30, No. 5, 2004, pp. 311–327.

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

14

Abduction for Specifying and Verifying Web Service and Choreographies Federico Chesani, Paola Mello, Marco Montali 1 Marco Alberti, Marco Gavanelli, Evelina Lamma, Sergio Storari 2 of agents and compositions of Web Services, although defined and designed in different contexts, share the following features:

Abstract. Global choreographies have been recently proposed as a way for specifying the overall behaviour of a system composed of heterogeneous web services. In this work, we propose an abductive framework based on computational logic to specify both choreographies and web service interface behaviours. One of the main motivations for using computational logic is that its operational counterpart provides a proof-theoretic support able to verify, from different viewpoints, the conformance of services designed in a cooperative and incremental manner. We show how it is possible to specify both the choreography and the web service interface behaviours (restricted to the conversation aspects) using a uniform formalism based on abductive logic programs. Then, we provide a definition of conformance, and show how, by using an abductive proof procedure, it is possible to automatically verify the conformance of a given web service w.r.t. a certain choreography.

• They describe a collaboration between a collection of parties in order to achieve a common goal. • They should capture the interactions in which the participants engage to achieve this goal. • They should capture the dependencies between interactions (control-flow dependencies, message correlations, time constraints, etc.) by expressing global interaction protocols. • They should capture interactions from a global perspective and, therefore, they should not describe any internal action that does not directly result in an external, visible effect. • Protocols should be expressed, if possible, in a formal language. In this work, we investigate the feasibility of using an abductive framework grounded on computational logic, defined in the context of MAS for Global Computing, for modelling both choreographies and behavioural interfaces of Web Services. We build upon the SCIFF framework, developed in the area of MAS for specification and verification of interaction in open agent societies. In SCIFF, a social specification is meant to specify the observable agent behaviour, rather than the agents’ internals or policies. SCIFF has been used for expressing social semantics of agent communication languages [1], and a number of interaction protocols. We propose a framework, called Al LoWS (Abductive Logic Webservice Specification), where both Web Services and choreographies are modelled as abductive logic programs. In Al LoWS, we exploit the SCIFF proof procedure to formally prove conformance of the participating Web Services to a choreography specification, by identifying sets of abduced hypotheses which satisfy both the specifications and the formal definition of conformance. In this way, we statically analyse the behaviour of choreographies and individual Web Services, and prove a priori conformance.

1 INTRODUCTION The recent and fast growth of network infrastructures, such as the Internet, is spawning a new range of scenarios and emerging paradigms for distributed computing. One of them is Service Oriented Computing, which finds its origin in object-oriented and component computing. Web service technology is an important instance of Service Oriented Computing aiming at facilitating the integration of new applications, avoiding difficulties due to different platforms, languages, etc. Service composition - building complex services from simpler ones - requires methodologies in order to verify, for instance, whether the communicative behaviour (Behavioural Interface) of an existing service conforms to the interaction rules (a choreography) and, thus, whether the service in question would be able to play a given role in that choreography. From the Web Service technology viewpoint a fundamental requirements [4] is to provide tools to validate conformance to choreography descriptions to ensure interoperability, to enable static or dynamic verification of choreographies and to ensure that the local behaviour of participants conforms to the choreography specification. To this purpose, it is crucial to formalize both choreographies and (behaviour interfaces of) Web Services by using formal languages that provides these validation capabilities. In the Multi-Agent Systems (MAS) community, on the other hand, there is a wide literature about checking compliance of agents to social rules, both at run-time and at design-time. Baldoni et al. [3] first recognised the similarities in the two areas. In particular, societies 1 2

2

Al LoWS: AN ABDUCTIVE FRAMEWORK

The framework we propose, Al LoWS (Abductive Logic Web-service Specification), is based on Abductive Logic Programming (ALP [14]), and in particular it is derived from the SCIFF framework, developed in the SOCS project for open societies of agents [1]. As we demonstrate in the following, the language is expressive enough to specify typical choreographies and web services. The operational semantics of the language is used for the verification of conformance of a web service to a choreography. In Al LoWS, the behaviour of the web services is represented by means of events. Since we focus on the interactions between web

DEIS, University of Bologna ENDIF, University of Ferrara

15

services, events always represent exchanged messages. The syntax is the same used in [3]: a message is described by the term mx (Sender, Receiver, Content), where mx is the type of message, and the arguments retain their intuitive meaning. Al LoWShas two types of events: happened events (denoted by the functor H) and expected events (denoted by E, and also called expectations). Both are abducible, and represent hypotheses on, respectively, which events have happened and which are expected to happen: H(mx (. . .), Tx ), expresses the fact that a message mx has been exchanged between two peers at time Tx , whereas E(mx (. . .), Tx ) says that the message mx is expected to be exchanged at time Tx . In this paper, the time parameter may be omitted when non essential. Choreographies and web services are specified by imposing a relation between happened and expected events by means of an abductive logic program, as explained in Sections 2.1 and 2.2.

2.1 Specification of a Choreography A choreography describes, from a global viewpoint, what are the patterns of communication, or interactions, allowed in a system that adopts such choreography [4]. The choreography specification defines the messages that are allowed: it is not possible to exchange other messages than the ones specified, and in a defined order. The choreography also enlists the participants, the roles the participants can play, and other knowledge about the web service interaction. We specify a choreography by means of an abductive logic program. An abductive logic program [14] is a triple hP, A, ICi, where P is a logic program, A is a set of distinguished predicates named abducibles, and IC is a set of integrity constraints. Reasoning in abductive logic programming is usually goal-directed (being G a goal), and corresponds to find a set of abduced hypotheses ∆ built from predicates in A such that P ∪ ∆ |= G and P ∪ ∆ |= IC. Suitable proof procedures (e.g., Kakas-Mancarella [15], IFF [12], SLDNFA [7], etc.) have been proposed to compute such set ∆, in accordance with the chosen declarative semantics. A choreography specification Pchor is defined by the tuple:

Figure 1. UML activity-chart of a simple choreography

quantity Q is higher than zero, then Supplier notifies the bill to Customer, and a shipment order is sent to W arehouse. Otherwise the interaction terminates, since there is no good available for buying. The specification in terms of IC chor is given by Eq. (1-5): in particular, Eq. 4 shows how to express alternative behaviours whose selection is dependent by the content of previous messages, and it shows how to express concurrency of actions. It specifies that, after communicating the available quantity Q of Good to Customer, and if Q > 0, then Supplier should notify the bill to Customer, and a shipment order to W arehouse. In Al LoWS, the condition Q > 0 is intended as a constraint a` la CLP (Constraint Logic Programming, [13]); CLP constraints can also be used to impose an order between messages, by imposing relations on the time instants the events are expected. →

Pchor ≡ hKBchor , Echor , IC chor i • KBchor is the Knowledge Base, • Echor is the set of abducible predicates, and • IC chor is the set of Choreography Integrity Constraints.

H(request(Customer, Supplier, Good), Tr ) E(query(Supplier, W arehouse, Good), Tq ) ∧ Tq > Tr .

(1)

H(query(Supplier, W arehouse, Good), Tq ) E(answer(W arehouse, Supplier, Good, Q), Ta ) ∧ Ta > T q .

(2)

H(answer(W arehouse, 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, W arehouse, Good), Ts ) ∧ T b > T p ∧ Ts > T p .

(4)

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

(5)

→

→

KBchor specifies declaratively pieces of knowledge of the choreography, such as role descriptions and the list of participants. It is expressed in the form of clauses (a logic program) that may also contain in their body expectations about the behaviour of participants. The abducible predicates are those that can be hypothesized in our framework, namely happened events (H) and expectations (E). Choreography Integrity Constraints are forward rules, of the form body → head, whose body can contain literals and (happened and expected) events, and whose head is a conjunction of expectations. The syntax of IC chor is the same defined for the SOCS Integrity Constraints [1], but in Al LoWS we do not use negative expectations and negation (¬), since they are not needed. Consider the simple choreography in Fig. 1, where a multi-party interaction is shown as a UML activity diagram. The interaction is initiated by a Customer that asks the Supplier for a certain good. The Supplier queries the W arehouse for the available quantity of that good, and forwards the answer to the Customer. Then, if the

→

→

2.2 Specification of a Web Service Interface Behaviour Uniformly to the specification of a choreography, we define the interface behaviour of a web service as an Abductive Logic Program. We restrict our specification to the communicative aspects of the web service. A Web Service Interface Behaviour Specification Pws is an Abductive Logic Program, represented with the triple Pws ≡ hKBws , Ews , IC ws i

16

• KBws is the Knowledge Base of the Web Service, • Ews is the set of abducible predicates, and • IC ws is the set of Integrity Constraints of the web service.

Conformance can be based on the observation of the relations between the allowed interactions, and the behaviours expected both by the choreography and the web service. Based on the current interaction status, the choreography will prescribe a coherent set of possible evolutions. Each evolution contains the expectations of the choreography on the behaviour of the participants: some expectations are about the web service ws under testing, while others will concern the behaviour of the other participants. The set of expectations of the choreography will be indicated in the following with EXPchor . Analogously, each web service participating in the choreography has expectations on the behaviour of the other peers: after a question it will expect a reply, or after sending a bill, it will expect a payment. Also, the web service might have expectations about its own behaviour, expressing the intention to perform some actions. The set of expectations of a web service ws is denoted by EXPws . We will often write EA (. . .) as a shortcut for E(. . .) ∈ EXPA . The compliance of a web service is based on the compliance of single interactions: a web service is compliant if all the interactions it can possibly generate belong to the choreography specification. Note however that it is not necessary to check a full interaction history: as soon as a violation is detected, the subsequent (possibly, infinite) evolutions are of no interest. We focus on the interactions of total agreement: those histories (i.e., sequences of happened events) for which all actions expected both by the choreography and by the the web service under observation are indeed considered as happened.

KBws and IC ws are completely analogous to their counterparts in the choreography specification, except that they represent an individual, rather than global, perspective: they represent, respectively, the declarative knowledge and the policies of the web service. Ews is the set of abducible predicates: as for the choreographies, it contains both expectations and happened events. The expectations in Ews can be divided into two significant subsets: • expectations about messages where ws is the sender (of the form Ews (mx (ws, A, Content))), i.e., actions that ws intends to do; • expectations about messages uttered by other participants to ws (of the form Ews (mx (A, ws, Content)), with A 6= ws), which can be intended as the messages that ws is able to understand.

Definition 1 Given the abductive program hKBU , EU , IC U i,

(a)

• KBU , KBchor ∪ KBws • EU , Echor ∪ Ews • IC U , IC chor ∪ IC ws

(b)

an interaction is a pair (HAP, EXP) where HAP is a set of atoms built with predicate H, and EXP is a set of atoms build with predicates in EU such that

Figure 2. Example of behavioural interfaces

In Fig. 2(a) the communicative part of the interface behaviour of a web service is represented as UML activity diagrams. The corresponding translation in terms of IC ws is given by Eq. (6). →

H(query(Supplier, W arehouse, Good), Tq ) E(answer(W arehouse, Supplier, Good, Q), Ta ) ∧Ta > Tq .

KBU ∪ HAP ∪ EXP

|=

G

(7)

KBU ∪ HAP ∪ EXP

|=

IC U

(8)

Total Agreement Interactions are the minimal interactions (HAPpy , EXPpy ) for which KBU ∪ HAPpy ∪ EXPpy |= IC tot

(6)

where IC tot contains the following implications

3 CONFORMANCE Intuitively, conformance is the capability of a web service to interact with the other peers according to a choreography. A web service ws will be conformant to a choreography if it complies to the choreography in all possible interactions. Although intuitive, such definition is not directly usable for automatic verification, as it does not specify which actions the web service will be able to perform, and how the other peers will behave. We assume the web service will act according to its own specifications, Pws , and that the other peers will behave as defined in the choreography specification Pchor . For instance, in Fig. 2(a) and 2(b) two possible interface behaviours are shown: while the latter shows a web service conformant for the role of Customer in the choreography, the former represents a web service that would play the role of W arehouse, but it is not conformant to that role w.r.t. the specified choreography. In particular, the non-conformance is given by the fact that the warehouse web service does not accept the possible incoming ship order message.

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 depends on the property of the web service we want to prove. Conditions (7) and (8) specify the abductive EXP. Note that for each HAP there could be more EXP that satisfy conditions (7) and (8). Condition (9) imposes that total agreement interactions contain in the history only messages that were expected by both the choreography and the web service. Condition (10) tackles multi-party protocols, and requires that any dialogue between other peers (apart from ws) does evolve as specified in the choreography. We can now provide a definition of conformance based on the total agreement interactions, selecting those that indeed respect the choreography and web services specifications.

17

The verification of the conformance of a web service Pws to a choreography Pchor is performed in two steps.

Definition 2 (∃-Conformance) A web service specification Pws is existentially conformant to a choreography specification Pchor if there exists at least one total agreement interaction (HAPpy , 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)

Generation of total agreement interactions. The first step is to build total agreement interactions. This is done by applying the generative version of SCIFF to the abductive program of Def. 1, with the additional integrity constraints (9) and (10), i.e.:

Definition 3 (∀-Conformance) A web service specification Pws is universally conformant to a choreography specification Pchor if for all pairs (HAPpy , EXPpy ) of Def. 1 the conditions (11-12) hold.

hKBU , EU , IC tot i SCIFF is sound and complete for the so-called allowed programs, i.e., under some syntactic restrictions that are satisfied by the programs of Al LoWS. It can be trivially proven that declaring the H predicate as abducible and adding integrity constraints (such as (9) and (10)) does not undermine the results, so the version exploited in Al LoWS is sound and complete as well. Thanks to these results, the non-failure leaf nodes of the proof tree are exactly the total agreement interactions. Thus, if this computation fails, there exists no total agreement interaction, so the Web Service is not ∃-conformant.

Condition (11) requires that if ws had an expectation about sending a message, the corresponding event should have happened. If this event is not present in HAPpy , from Def. 1 we can infer that the event was unexpected from the choreography viewpoint. This situation corresponds to the case where ws is determined to utter a message that is not envisaged by the choreography: in this case there is not conformance between ws and the choreography. Condition (12) requires that every message expected by the choreography indeed happens. Together with conditions (9) and (10), this means that all expectations involving the web service under testing are matched by a corresponding expectation of the web service. This condition is false if there exists an expectation of the choreography without a corresponding expectation from the web service, i.e., either if the ws may receive (during interactions approved by the choreography) a message it is not able to understand, or if the web service failed to to utter a message that the choreography expects. For symmetry reasons, one would expect also a rule about the satisfaction of a web service’s expectation on the behaviour of other peers. Such a rule is not necessary, because in this case either the interaction is considered successfully finished by the choreography (and in this case we consider conformant the web service), or ws will be expected to perform some further interaction, that will remain unfulfilled from the choreography viewpoint (and the non conformance will be detected by one of the rules (11-12)). When Definitions 2 and 3 hold together for a web service ws, we say that ws is conformant. Let us see how conformance can be tested.

Verification of total agreement histories The second step is to perform a SCIFF derivation to check if all the total agreement interactions generated in the previous step respect the conditions in Def. 2. In this phase we adopt the original version of SCIFF, where H is not declared as abducible but it is a predicate defined by the atoms in the set HAPpy (generated in the previous step). In this phase, we test that in each non-failure leaf node the (11) and (12) hold. The Web Service is universally conformant to the choreography if and only if such test succeeds on all the non-failure leaf nodes.

5

A CONFORMANCE TEST EXAMPLE

We discuss here only the conformance test of the Warehouse, and show how Al LoWS detects non conformance. We start the conformance test by providing as Goal expectations about the events initiating the interaction: G ≡ {Echor (request(Customer, Supplier, Good), Tr ), (13) Ews (query(Supplier, W arehouse, Good), Tq ).}

4 CONFORMANCE TEST Al LoWS uses the SCIFF proof procedure for proving conformance. SCIFF is an abductive proof procedure developed for on-the-fly conformance checking in MASs [2]. It takes as input an initial history of happened events HAPi and generates the expected behaviour of the agents (EXP) while accepting on-line further events. SCIFF consists of a sequence of transitions; when it reaches quiescence in nonfailure nodes, it has a successful derivation, indicated with

If we apply the generation step described in Sect. 4, we obtain the total agreement interactions. We show one of the outcomes in Fig. 3. Then, by applying the second step of the conformance test, it results that this total agreement set is not ∃-conformant, since the expectation Echor (shipOrder(Supplier, W arehouse, Good), Ts ) does not have the corresponding happened event, as required by Eq. 12. In fact the choreography specifies that Supplier should sent a shipment order to W arehouse; unfortunately, the latter is not able to understand the order (it does not expect such message), and the choreography expectation does not have the corresponding happened event.

f

KBHAPi `HAP EXP G where G is the goal of the society, HAPf is the final history at the quiescence, and EXP is the set of generated expectations. In order to perform a priori conformance checking, we need to generate sets of events. We therefore developed a generative version of SCIFF, which is able to produce the happened events, instead of just taking them as input. We declared H as an abducible predicate and added the integrity constraints (9) and (10). In this way, we have that KB `EXP∪HAP G

6

DISCUSSION AND RELATED WORK

While a detailed comparison of the SCIFF language with other languages for web service and choreography specification is, to date, ongoing work, we believe that the language provides sufficient expressivity for a wide range of applications, and ro express typical constructs found in other specification languages, such as WSCDL [17]. For example, the integrity constraints in Eq. (14)

i.e., a SCIFF derivation provides the set of happened events as output of the abduction process.

18

EXPpy

HAPpy

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

H(request(C, S, Good), Tr )

Echor (send(S, C, Bill), Tb ) Echor (shipOrder(S, W, Good), Ts ) Echor (pay(C, S, Bill), Tp )

the single web service. But, while in [3] a global interaction protocol is represented as a finite state automation, we claim that the formalisms and technologies developed in the area of Computational Logic in providing a declarative representation of the social knowledge, could be applied also in the context of choreographies with respect to the conversation aspects and conformance checking of Web Services. This paper can be considered as a first step in this direction. For example, a difference between our work and [3] can be found in the number of parties as they can manage only 2-party choreographies while we do not impose any limit. We also manage concurrency, which they do not consider at the moment. Another similar work is described in [5]. In this work, authors focus on two-party choreographies involving each one a requester and a provider (named service conversations) and formulate some requirements for a modelling language suitable for them. The requirements include genericity, automated support, and relevance. The authors argue that state machines satisfy these requirements and sketch an architecture of a service conversation controller capable of monitoring messages exchanged between a requester and provider in order to determine whether they conform to a conversation. An example of use of Petri nets for the formalization of choreographies is discussed in [8]. Four different viewpoints (interface behaviour, provider behaviour, choreography, and orchestration) and relations between viewpoints are identified and formalised. These relations are used to perform (global) consistency checking of multiviewpoint service designs thereby providing a formal foundation for incremental and collaborative approaches to service-oriented design. Our proposal is limited to a deep analysis of the relation between choreographies and behaviour interfaces but deal with both “a priori” and “run-time” conformance. Foster et al. [11] propose a model-based approach to verify a given service composition can successfully execute a choreography, in particular with respect to the obligations imposed on the services by a choreography. The web service specifications and the choreography are translated to FSP algebra and checked by model checking techniques. The main difference with respect to our work is that Foster et al. check a whole service composition against a choreography, while we only check a single web service, assuming that the others are conformant. Another notable difference is in the adopted formal approaches (abduction in our case, model checking in theirs). In [9, 10], the authors apply a formalism based on computational logic to the a priori conformance in the MAS field. Their formalism is similar to the one we propose, but they restrict their analysis to a particular type of protocols (named shallow protocols). Doing this, they address only 2-party interactions, without the possibility of expressing conditions over the content of the exchanged messages, and without considering concurrency. The use of abduction for verification was also explored in other work. Noteworthily, Russo et al. [16] use an abductive proof procedure for analysing event-based requirements specifications. Their method uses abduction for analysing the correctness of specifications, while our system is more focussed on the check of compliance/conformance of a set of web services.

H(query(S, W, Good), Tq ) H(answer(W, S, Good, Q), Ta ) H(provide(S, C, Q), Tp ) ∧Q > 0 H(send(S, C, Bill), Tb ) H(pay(C, S, Bill), Tp )

Figure 3. A total agreement interaction generated during the first step of the conformance test.

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

(14)

H(b, Tb ) → E(a, Ta ) ∧ Ta > Tb represent a loop, where the event a can be followed by the event b and another occurrence of a, or by an event c. The integrity constraint in Eq. (15) H(a, Ta ) ∧ c → E(b, Tb ) ∧ Tb > Ta

(15)

has an operational semantics similar to that of a workunit: when the event a happens, the expectation b will be raised only when the predicate c, which represents a condition, becomes true. One limitation of our language stands in the current difficulty to represent the operator of unconditional choice in choreographies. An interesting observation is that the SCIFF integrity constraints can be interpreted, both declaratively and operationally, as reactive rules: they specify that, if a state of affairs (i.e., a combination of events) occurs, then an individual web service, or a composition of web services, should behave in some way. We follow Bry and Eckert [6] in believing that reactive rules are a suitable declarative and operational formalism to specify web systems. In particular, out of Bry and Eckert’s Twelve Theses, the SCIFF language fulfills: • the first (“High level reactive languages are needed on the Web”): the SCIFF languages abstracts away from the low level transport and communication protocols; • the second (“Reactive Web rules should be processed locally and act globally through event-based communication”): a SCIFF based web service is only observable in its communicative acts, while the reasoning process that generates those acts remains hidden; • the sixth (“A data-driven, incremental evaluation of event queries is the approach of choice”): operationally, the SCIFF integrity constraints are resolved incrementally, while new events are processed. A number of languages for specifying service choreographies and testing “a priori” and/or “run-time” conformance have been proposed in the literature. Two examples of these languages are represented by state machines [5] and Petri nets [8]. Our work is highly inspired by Baldoni et al. [3]. We adopt, like them, a Multi-agent Systems point of view, in defining a priori conformance in order to guarantee interoperability. As in [3], we give an interpretation of the a priori conformance as a property that relates two formal specifications: the global one determining the conversations allowed by the choreography and the local one related to

7

CONCLUSIONS AND FUTURE WORK

Starting from theory and tools for protocol conformance and compliance verification in the research area of multi-agent systems, we propose a formal framework based on computational logic (and, in particular, based on abduction) that can be used for specifying behaviour of web services both from a global and local viewpoint.

19

In Al LoWS, the use of computational logic provides us a rich and flexible formal language for expressing choreographies. Abductive Integrity Constraints, in fact, differently from traditional formalisms such as finite state-machines, allow us to specify protocols without describing each legal state of the interaction. IC s allow us to include extra integrity constraints that in semi-formal models are usually left implicit. Moreover, the explicit representation of time and other parameters within the constraints allows to handle synchronization, roles and, in general, conditions related to the content of messages. For instance, we have shown that multi-party interactions and concurrency can be tackled. Within the Al LoWS framework we formalize the notion of a priori conformance similar to the one presented in [3], and show that a proof-theoretic approach can be exploited to perform the conformance test. To this purpose a suitable proof procedure derived from SCIFF [2] is presented, in order to automatically check conformance at design-time. In future work, we intend to extend the set of interaction patterns supported by Al LoWS. Moreover, we are aware that exploitation of this language should be based on a graphical language, which supports user convenience in capturing specifications, model verification and validation. To this purpose we are developing a visual language for expressing global protocols and a program for its automatic translation into IC s . Ongoing work on the Al LoWS framework includes a detailed comparison with other languages for choreography specification, such as WS-CDL, and the implementation, and performance tests, of specific case studies.

[9] U. Endriss, N. Maudet, F. Sadri, and F. Toni, ‘Protocol conformance for logic-based agents’, in Proceedings of the Eighteenth International Joint Conference on Artificial Intelligence, Acapulco, Mexico (IJCAI03), eds., G. Gottlob and T. Walsh. Morgan Kaufmann Publishers, (August 2003). [10] Ulle Endriss, Nicolas Maudet, Fariba Sadri, and Francesca Toni, ‘Logic-based agent communication protocols’, in Advances in Agent Communication, ed., F. Dignum, volume 2922 of LNAI, 91–107, Springer-Verlag, (2004). [11] Howard Foster, Sebastian Uchitel, Jeff Magee, and Jeff Kramer, ‘Model-based analysis of obligations in web service choreography’, in Proceedings of the International Conference on Internet and Web Applications and Services (ICIW 2006), Guadeloupe French Caribbean, (2006). IEEE Computer Society Press. [12] T. H. Fung and R. A. Kowalski, ‘The IFF proof procedure for abductive logic programming’, Journal of Logic Programming, 33(2), 151–165, (November 1997). [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, and F. Toni, ‘Abductive Logic Programming’, Journal of Logic and Computation, 2(6), 719–770, (1993). [15] A. C. Kakas and P. Mancarella, ‘On the relation between Truth Maintenance and Abduction’, in Proceedings of the 1st Pacific Rim International Conference on Artificial Intelligence, PRICAI-90, Nagoya, Japan, ed., T. Fukumura, pp. 438–443. Ohmsha Ltd., (1990). [16] A. Russo, R. Miller, B. Nuseibeh, and J. Kramer, ‘An abductive approach for analysing event-based requirements specifications’, in Logic Programming, 18th International Conference, ICLP 2002, ed., P.J. Stuckey, volume 2401 of Lecture Notes in Computer Science, pp. 22– 37, Berlin Heidelberg, (2002). Springer-Verlag. [17] W3C. Web services choreography description language version 1.0. Home Page: http://www.w3.org/TR/ws-cdl-10/.

Acknowledgements This work has been partially supported by the MIUR PRIN 2005 projects Specification and verification of agent interaction protocols and Vincoli e preferenze come formalismo unificante per l’analisi di sistemi informatici e la soluzione di problemi reali.

REFERENCES [1] Marco Alberti, Federico Chesani, Marco Gavanelli, Evelina Lamma, Paola Mello, and Paolo Torroni, ‘The SOCS computational logic approach for the specification and verification of agent societies’, in Global Computing: IST/FET International Workshop, GC 2004 Rovereto, Italy, March 9-12, 2004 Revised Selected Papers, eds., Corrado Priami and Paola Quaglia, volume 3267 of Lecture Notes in Artificial Intelligence , 324–339, Springer-Verlag, (2005). [2] Marco Alberti, Marco Gavanelli, Evelina Lamma, Paola Mello, and Paolo Torroni, ‘The sciff abductive proof-procedure’, in Proceedings of the 9th National Congress on Artificial Intelligence, AI*IA 2005 , volume 3673 of Lecture Notes in Artificial Intelligence , pp. 135–147. Springer-Verlag, (2005). [3] Matteo Baldoni, Cristina Baroglio, Alberto Martelli, Viviana Patti, and Claudio Schifanella, ‘Verifying the conformance of web services to global interaction protocols: A first step’, in EPEW/WS-FM, eds., Mario Bravetti, Le¨ıla Kloul, and Gianluigi Zavattaro, volume 3670 of Lecture Notes in Computer Science. Springer, (2005). [4] A. Barros, M. Dumas, and P. Oaks, ‘A critical overview of the web services choreography description language (ws-cdl)’, BPTrends, (2005). [5] B. Benattallah, F. Casati, F. Toumani, and R. Hamadi, ‘Conceptual modeling of web service conversations’, 2681, 449–467, (2003). [6] Franois Bry and Michael Eckert, ‘Twelve theses on reactive rules for the web’, in Proceedings of the Workshop on Reactivity on the Web, Munich, Germany, (March 2006). [7] M. Denecker and D. De Schreye, ‘SLDNFA: an abductive procedure for abductive logic programs’, Journal of Logic Programming, 34(2), 111–167, (1998). [8] R. Dijkman and M. Dumas, ‘Service-oriented design: A multiviewpoint approach’, International Journal of Cooperative Information Systems, 13(4), 337–378, (2004).

20

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 specialization, 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 compositions, and that can be reused in the construction of larger or extended 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

2

PROBLEM FORMULATION

Our goal is to define a web service composer system and framework. This web service composer system will both be able to provide (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 structured 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 composite 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 (operations, 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 repository or matching engine, taking in charge the matching of a selection 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 process with a given semantic description. We will also assume that our system does not create new compositions 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 composite 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, semantic descriptions may not span over several web services “slots” in their hosting abstract web service).

1 INTRODUCTION A web service is a software system designed to support interoperable 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 services in the past few years. A large part of these studies has been dedicated to web services composition. The original idea of “service 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 applications 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 useful “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 particular 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 approach, 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. Section 2 gives our problem formulation, illustrated by an example scenario in section 3. Section 4 presents and discusses our approach 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

21

The motivations behind this concept are two fold:

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 previous 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 semantic descriptions TravelTicket, HotelBooking and CarRental, with the global inputs origin, destination, period, and the same outputs as the two previous composite web services.

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. Concrete composite web service WS1

WS3

WS2

WS4

Abstract composite web service

generalization

WS1

D3

D2

WS4

Figure 1. Abstract and concrete composite web service example Outputs

Inputs

Figure 1 shows an abstract composite web service; without detailing structural information, constructed by substituting two web services in a concrete specialization, WS2 and WS3, by two abstract descriptions D2 and D3. However, care must be taken when defining such abstract compositions, as stated by Melloul and Fow in [1]: a too abstract composite 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 contain only fixed (resolved at composition time) web service references: 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 composite web service, that we will define as “stable” composite web services, with respect to a given user request, and evaluation criteria such as validity, pertinence, availability, and robustness, by utilizing the information about the structure and usage of composite 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.

period

eurostar

paradise hotel

Paris London

car2

train ticket hotel book. car rental

Figure 2. UML activity diagram of TravelToLondonFromParis Outputs

Inputs period origin

TravelTicket to London

HotelBooking car2

train ticket hotel book. car rental

Figure 3. UML activity diagram of TravelToLondon

Inputs period origin dest.

TravelTicket

HotelBooking CarRental

Outputs train ticket hotel book. car rental

Figure 4. UML activity diagram of DirectTravel

3

TRAVEL AGENCY EXAMPLE Inputs period origin dest.

We use the classical travel agency example, since it involves several 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 London), 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);

HotelBooking TravelTicket

’ DirectTravel

Outputs train ticket hotel book. car rental

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.

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.

22

4 4.1

4.2 Immune system metaphor for our web service composition reuse problem

IMMUNE SYSTEM INSPIRED APPROACH A simplified view of immune systems

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 represent 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 memory 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.

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 substance is called a pathogen, and is recognized by the immune system 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 antibodies released from the immune cells (lymphocytes: B-cells and T-cells). The binding of an antigen to the different antibodies requires that portions of the two structures have complementary shapes that can closely approach each other. The area on an antigen where it has contact with an antibody is called an epitope. The corresponding area on an antibody is called a paratope. 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 encounters an antigen for the first time. A number of antibodies will be produced by the immune system in response to the infection, 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 antigen 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 produce antibodies that are specific to the invading antigen. x The Affinity Maturation process that guarantees that the immune system becomes increasingly better at the task of recognising 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 remains 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 response. 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.

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

23

4.4

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 composite definition itself, i.e. the structural constructs linking the referenced 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 dependencies 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 abstractions. 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 information 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.

Relations : Composition dependency Usage (relative affinity) Generalization

0..* matches

0..*

Composite

Web Service

uses

instantiates

Concrete Composite

Car2

Coconut Hotel TravelToLondon TravelToLondon -FromFrance

Airplane2

Eurostar

Airplane3

TravelToLondonFromGermany

TravelToLondonFromParis Paradise Hotel

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 potential 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: generalization 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 specialization. Relative affinity links can be seen as a potential composition 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.

matches

generalization

Abstract Composite

IndirectTravel

DirectTravel

1 described by Semantic described by description 1

needs

Application to the Travel Agency example

Elementary Web Service

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:

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 includes the automatic specialization, the relative affinity update, and the affinity maturation steps. As stated in section 2, we consider that a user request is equivalent 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.

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.

24

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. Web Service Composer System

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 between 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.

User AX request (semantic description)

semantic matching

WS1

AY

X

automatic specialization ordering and presentation affinity maturation

Y

WS2

WS4

choose a concrete CWS

WS3

execute CWS Figure 10. Relative affinity update example

update relative affinity values

get results…

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 generated with a numeric value of relative affinity.

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 composite is executed by the system, and the relative affinity values are updated. The affinity maturation will possibly elect the new concrete 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 automatic specializations.

4.5.1

4.5.2

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 identified 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 affinity value calculated by the system, also used to order the propositions 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.

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:

aff r ( c, a )

freq succ frequsage

Affinity maturation

Definition 2 Global Affinity. The global affinity value represents 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:

(1) n

m

¦¦D aff g ( C )

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.

i 1

ij

aff r ( c i , a i j )

j 1

(2)

n

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.

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

25

Definition 3 Virtual composite. A virtual composite is a composite 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.

different, ParadiseHotel is still applicable to the semantic description HotelBooking included in TravelToLondon. Thus, the composer 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 repository, and can now be used directly.

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.

A2

a12

a 22

a 32

4.6

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 involving 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.

relative affinity generalization semantic descr.

A1

c1

a 12

a 31

C

c1

c2

c3

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) + 2 1 2 22affr(c2, a2 ) + 31affr(c3, a3 ) + 32affr(c3, a3 )) / 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 directly 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 immune 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

Exploration / exploitation ratio

4.7

Discussion

The semantic level and matching mechanism are not covered in this paper. However the language and ontology used for the semantic descriptions is indeed very important for our approach to work properly: the language used should allow designers to define abstract 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. Assuming 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.

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 TravelToLondonFromFrance. However, we also assume that TravelToLondonFromParis and TravelToLondonFromGermany have been used largely with success, so that the relative affinity of ParadiseHotel with respect to the abstract composite TravelToLondon is higher than that of CoconutHotel. Although the context is slightly

26

The affinity functions used in our approach does not define any absolute confidence value associated to each web service or composite 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

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 specializations 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 internal structure of web service composite in the relative affinity function (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 heterogeneity. 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 correspond to the spreading and cloning of memory cells into our blood.

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 generalization/specialization relations suggest an object-oriented inheritance 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 inheritance are discussed and a workflow class definition language is proposed. In [5], Kappel and Lang present a workflow class specification, 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 developed by inheriting the functionality of basic workflow classes. Our generalization relation, however, is defined by the substitution, 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 services composition in that it focuses on reusing existing abstract composites that can be specialized into particular concrete composites, 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 crossusage, the affinity relations, and structural meta-information, the composition and generalization relations.

6

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 198. (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, ‘Workflow 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 Services 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).

CONCLUSION AND FUTURE WORKS

In this paper we have proposed an approach to deal with composite web service reuse and automatic specialization by children component substitution, inspired by the human body immune system. The shape correspondence between the antigen epitopes and the antibody paratopes is represented in our system by a relative affinity

27

Designing Security Requirements Models through Planning Volha Bryl and Fabio Massacci and John Mylopoulos and Nicola Zannone 1 matic) transformation from one system model to another. Tools supporting MDA exist and are used in the Rational Unified Process for software development in UML. Yet, the state-of-the-art is still not satisfactory [30]. Such approaches only cover part of the work of the designer. We advocate that there is another activity where the support of automation could be most beneficial [20]:

Abstract. The quest for designing secure and trusted software has led to refined Software Engineering methodologies that rely on tools to support the design process. Automated reasoning mechanisms for requirements and software verification are by now a well-accepted part of the design process, and model driven architectures support the automation of the refinement process. We claim that we can further push the envelope towards the automatic exploration and selection among design alternatives and show that this is concretely possible for Secure Tropos, a requirements engineering methodology that addresses security and trust concerns. In Secure Tropos, a design consists of a network of actors (agents, positions or roles) with delegation/permission dependencies among them. Accordingly, the generation of design alternatives can be accomplished by a planner which is given as input a set of actors and goals and generates alternative multi-agent plans to fulfill all given goals. We validate our claim with a case study using a state-of-the-art planner.

“Exploring alternative options is at the heart of the requirements and design processes.” Indeed, in most SE methodologies the designer has tools to report and verify the final choices (be it goal models in KAOS, UML classes, or Java code), but not actually the possibility of automatically exploring design alternatives (i.e. the potential choices that the designer may adopt for the fulfillment of system actors’ objectives) and finding a satisfactory one. Conceptually, this automatic selection of alternatives is done in deductive program synthesis: theorem provers select appropriate axioms to establish the system goal. Instead, we claim that the automatic selection of alternatives should and indeed can be done during the very early stages of software development. After all, the automatic generation of alternatives is most beneficial and effective during these stages. There are good reasons for this claim. Firstly, during early stages the design space is large, and a good choice can have significant impact on the whole development project. Supporting the selection of alternatives could lead to a more thorough analysis of better quality designs with respect to security and trust. Secondly, requirements models are by construction simpler and more abstract than implementation models (i.e. code). Therefore, techniques for automated reasoning about alternatives at the early stages of the development process may succeed where automated software synthesis failed. Since our overall goal is to design a secure system we have singled out the Secure Tropos methodology [16] as the target for our work. Its primitive concepts include those of Tropos and i* [7], but also concepts that address security concerns, such as ownership, permission and trust. Further, the framework already supports the designer with automated reasoning tools for the verification of requirements as follows:

1 Introduction The design of secure and trusted software that meets stakeholder needs is an increasingly hot issue in Software Engineering (SE). This quest has led to refined Requirements Engineering (RE) and SE methodologies so that security concerns can be addressed during the early stages of software development (e.g. Secure Tropos vs i*/Tropos, UMLsec vs UML, etc.). Moreover, industrial software production processes have been tightened to reduce the number of existing bugs in operational software systems through code walkthroughs, security reviews etc. Further, the complexity of present software is such that all methodologies come with tools for automation support. The tricky question in such a setting is what kind of automation? Almost fifty years ago the idea of actually deriving code directly from the specification (such as that advocated in [22]) started a large programme for deductive program synthesis,2 that is still active now [5, 11, 25, 29]. However, proposed solutions are largely domainspecific, require considerable expertise on the part of their users, and in some cases do not actually guarantee that the synthesized program will meet all requirements stated up front [11]. Another approach is to facilitate the work of the designer by supporting tedious aspects of software development by automating the design refinement process. This approach underlies Model Driven Architectures (MDA) [27], which focuses on the (possibly auto1 2

1. Graphical capture of the requirements for the organization and the system-to-be, 2. Formal verification of the functional and security requirements by • completion of the model drawn by the designer with axioms (a process hidden to the designer);

University of Trento, Italy, email: {bryl,massacci,jm,zannone}@dit.unitn.it A system goal together with a set of axioms are specified in a formal specification language. Then the system goal is proved from the axioms using a theorem prover. A program for achieving the goal is extracted from the proof of the theorem.

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

28

though their name does not mention security, they are generally regarded as part of the overall security framework. Secure Tropos uses the concepts of actor, goal, task, resource and social relations for defining entitlements, capabilities and responsibilities of actors. An actor is an intentional entity that performs actions to achieve goals. A goal represents an objective of an actor. A task specifies a particular sequence of actions that should be executed for satisfying a goal. A resource represents a physical or an informational entity. Actors’ desires, entitlements, capabilities and responsibilities are defined through social relations. In particular, Secure Tropos supports requesting, ownership, provisioning, trust, and delegation. Requesting identifies desires of actors. Ownership identifies the legitimate owner of a goal, a task or a resource, that has full authority on access and disposition of his possessions. Provisioning identifies actors who have the capabilities to achieve a goal, execute a task or deliver a resource. We demonstrate the use of these concepts through the design of a Medical IS (Information System) for the payment of medical care.3

In this framework (as in many other similar RE and SE frameworks) the selection of the alternatives is left to the designer. We will show that we can do better. Indeed, in Tropos (resp. Secure Tropos) requirements are conceived as networks of functional dependencies (resp. delegation of execution) among actors (organizational/human/software agents, positions and roles) for goals, tasks and resources. Every dependency (resp. delegation of execution) also involves two actors, where one actor depends on the other for the delivery of a resource, the fulfillment of a goal, or the execution of a task. Intuitively, these can be seen as actions that the designer has ascribed to the members of the organization and the system-to-be. As suggested by Gans et al. [14] the task of designing such networks can then be framed as a planning problem for multi-agent systems: selecting a suitable possible design corresponds to selecting a plan that satisfies the prescribed or described goals of human or system actors. Secure Tropos adds to the picture also the notion of delegation of permission and various notions of trust. In this paper we show that it is possible to use an off-the-shelf planner to select among the potential dependencies the actual ones that will constitute the final choice of the requirements engineer. If a planner is already able to deliver good results then this looks a promising avenue for transferring the technique to complex industry-level case studies where a customized automated reasoning tool might be very handy. At the same time, if the problem is not trivial, not all planners will be able to deliver and indeed this turned out to be the case. The techniques we use are sufficiently powerful to cope with security requirements as well as functional requirements, but we concentrate here on their applicability to a security setting where an automated support for the selection of potentially conflictingalternatives is more urgent. The application of the same planning techniques to the 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 noted by Herbert Simon in his lecture on a “Science of Design” [31] what makes humans effective (in comparison to machines) is their ability to identify a satisficing design as opposed to an optimal one. Of course, we assume that the designer remains in the loop: designs generated by the planner are suggestions to be refined, amended and approved by the designer. The planner is a(nother) support tool intended to facilitate the design process. The rest of the paper is structured as follows. Section 2 explains Secure Tropos concepts and describes the requirements verification process. In Sections 3, 4 and 5 the planning approach to the system design is introduced and explained, while in Section 6 the implementation of our approach is presented. Finally, in Sections 7 and 8 a brief overview of related work is presented and conclusions are drawn.

Example 1 The Health Care Authority (HCA) is the “owner” of the goal provide medical care; that is, it is the only one that can decide who can provide it and through what process. On the other hand, Patient wants this goal fulfilled. This goal can be AND-decomposed into two subgoals: provisioning of medical care and payment for medical care. The Healthcare Provider has the capability for the provisioning of medical care, but it should wait for authorization from HCA before doing it. Delegation of execution is used to model situations where an actor (the delegator) delegates the responsibilities to achieve a goal, execute a task, or deliver a resource to another actor (the delegatee) since he does not have the capability to provide one of above by himself. It corresponds to the actual choice of the design. Trust of execution represents the belief of an actor (the trustor) that another actor (the trustee) has the capabilities to achieve a goal, execute a task or deliver a resource. Essentially, delegation is an action due to a decision, whereas trust is a mental state driving such decision. Tropos dependency 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, Secure Tropos introduces also relations involving permission. Delegation of permission is used when in the domain of analysis there is a formal passage of authority (e.g. a signed piece of paper, a digital credential, etc.). Essentially, this relation is used to model scenarios where an actor authorizes another actor to achieve a goal, execute a task, or deliver a resource. It corresponds to the actual choice of the design. Trust of permission represents the belief of an actor that another actor will not misuse the goal, task or resource.

2 Secure Tropos Example 2 The HCA must choose between different providers for the welfare management for executives of a public institution. Indeed, since they have a special private-law contract, they can qualify for both the INPDAP and INPDAI4 welfare schemes. The INPDAP scheme requires that the Patient partially pays for medical care (with a ticket) and the main cost is directly covered by the HCA. On the contrary, the INPDAI scheme requires that the Patient pays

Secure Tropos [16] is a RE methodology for modeling and analyzing functional and security requirements, extending the Tropos methodology [7]. This methodology is tailored to describe both the systemto-be and its organizational environment starting with early phases of the system development process. The main advantage of this approach is that one can capture not only the what or the how, but also the why a security mechanism should be included in the system design. In particular, Secure Tropos deals with business-level (as opposed to low-level) security requirements. The focus of such requirements includes, but is not limited to, how to build trust among different partners in a virtual organization and trust management. Al-

3 4

29

An extended description of the example is provided in [4]. INPDAP (Istituto Nazionale di Previdenza per i Dipendenti dell’Amministrazione Pubblica) and INPDAI (Istituto Nazionale di Previdenza per i Dirigenti di Aziende Industriali) are two Italian national welfare institutes.

Figure 1. Secure Tropos model

in advance the full cost of medical care and then gets the reimbursement. Once an institution has decided the payment scheme, this will be part of the requirements to be passed onto the next stages of system development. Obviously, the choice of the alternative may have significant impacts on other parts of the design.

3 Design as Planning So far the automated reasoning capabilities of Secure Tropos are only able to check that subtle errors are not overlooked. This is rather unsatisfactory from the point of view of the designer. Whereas he may have a good understanding of possible alternatives, he may not be sure which is the most appropriate alternative for the case at hand. This is particularly true for delegations of permission that need to comply with complex privacy regulations (see [23]).

Figure 1 summarizes Examples 1 and 2 in terms of a Secure Tropos model. In this diagram, actors are represented as circles and goals as ovals. Labels O, P and R are used for representing ownership, provisioning and requesting relations, respectively. Finally, we represent trust of permission and trust of execution relationships as edges respectively labelled Tp and Te. Once the modeling phase is concluded, Secure Tropos provides mechanisms for the verification of the model [16]. This means that the design process iterates over the following steps:

Example 3 Figures 2(a) and 2(c) present fragments of Figure 1, that point out the potential choices of the design. The requirements engineer has identified trust relations between the HCA and INPDAP and INPDAI. However, when passing the requirements onto the next stage only one alternative has to be selected because that will be the system that is chosen. Figures 2(b) and 2(d) present the actual choices corresponding to the potential choices presented in Figures 2(a) and 2(c), respectively.

• model the system; • translate the model into a set of clauses (this is done automatically); • verify whether appropriate design or security patterns are satisfied by the model.

Here, we want to support the requirements engineer in the selection of the best alternative by changing the design process as follows: • Requirements analysis phase

Through this process, we can verify the compliance of the model with desirable properties. For example, it can be checked whether the delegator trusts that the delegatee will achieve a goal, execute a task or deliver a resource (trust of execution), or will use a goal, task or resource correctly (trust of permission). Other desirable properties involve verifying whether an actor who requires a service, is confident that it will be delivered. Furthermore, an owner may wish to delegate permissions to an actor only if the latter actually does need the permission. For example, we want to avoid the possibility of having alternate paths of permission delegations. Secure Tropos provides support for identifying all these situations. Secure Tropos has been used for modeling and analyzing real and comprehensive case studies where we have identified vulnerabilities affecting the organizational structure of a bank and its IT system [24], and verified the compliance to the Italian legislation on Privacy and Data Protection by the University of Trento [23].

– System actors along with their desires, capabilities and entitlements, and possible ways of goal decomposition are identified. – Trust relationships among actors both in terms of execution and permission are defined. • Design phase – The space of design alternatives is automatically explored to identify delegation of execution/permission. – Depending on the time/importance of the goal the designer may settle for satisficing solutions [31] or ask for an optimal solution. To support the designer in the process of selecting the best alternative we advocate a planning approach which recently has proved to be applicable in the field of automatic Web service composition [6].

30

often used to describe the planning domain with conjunctions of literals5 specifying the states of the system. We find this representation particularly useful for modeling real case studies. Indeed, when considering security requirements at enterprise level, one must be able to reason 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 specifying:

(a) Potential choices

• • • •

(b) Actual choice

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 state of the system in terms of actor and goal properties, and social relations among actors. We use • AND/OR decomposition to describe the possible decomposition of a goal; • provides, requests and owns to indicate that an actor has the capabilities 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 of permission relations, respectively.

(c) Potential choices

The desired state of the system (or goal of the planning problem) is described through the conjunction of predicates done derived from the requesting relation in the initial state. Essentially, for each request(a,g) we need to derive done(g). By contrast, an action represents an activity to accomplish a goal. We list them in Table 2 and define them in terms of preconditions and effects as follows.

(d) Actual choice Figure 2. Design Alternatives

Satisfy. The satisfaction of goals is an essential action. Following the definition of goal satisfaction given in [16], we say that an actor satisfies a goal only if the actor wants and is able to achieve the goal, and – last but not least – he is entitled to achieve it. The effect of this action is the fulfillment of the goal. DelegateExecution. An actor may not have enough capabilities to achieve assigned goals by himself, and so he has to delegate their execution to other actors. We represent this passage of responsibilities through action DelegateExecution. It is performed only if the delegator requires the fulfillment of the goal and trusts that the delegatee will achieve it. Its effect is that the delegator does not worry any more about the fulfillment of this goal after delegating it since he has delegated its execution to a trusted actor. Furthermore, the delegatee takes the responsibility for the fulfillment of the goal and so it becomes a his own desire. Notice that we do not care how the delegatee satisfies the goal (e.g. by his own capabilities or by further delegation). It is up to the delegatee to decide it. DelegatePermission. In the initial state of the system, only the owner of a goal is entitled to achieve it. However, this does not mean that he wants it or has the capabilities to achieve it. On the contrary, in the system there may be some actors that want that goal and others that can achieve it. Thus, the owner could decide to authorize trusted actors to achieve the goal. The formal passage of authority takes place when the owner issues a certificate

The basic idea behind the planning approach is to automatically determine the course of actions (i.e. a plan) needed to achieve a certain goal where an action is a transition rule from one state of the system to another [34, 28]. Actions are described in terms of preconditions and effects: if the precondition is true in the current state of the system, then the action is performed. As consequence of the action, the system will be in a new state where the effect of the action is 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 the system), and the set of possible actions that actors can perform, the solution of the planning problem is the (not necessarily optimal) sequence of actions that allows the system to reach the desired state from the initial state. In order to cast the design process as a planning problem, we need to address the following question: which are the “actions” in a software design? When drawing the Secure Tropos model, the designer assigns the execution of goals from one actor to another, delegates permission and – last but not least – identifies appropriate goal refinements among selected alternatives. These are the actions to be used by the planner in order to fulfill all initial actor goals.

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

5

31

Let p be a predicate symbol with arity n, and t1 , . . . , tn be its corresponding arguments. p(t1 , . . . , tn ) is called an atom. The expression literal denotes an atom or its negation.

Goal Properties AND decompositionn (g : goal, g1 : goal, . . . , gn : goal) OR decompositionn (g : goal, g1 : goal, . . . , gn : goal) Actor Properties provides(a : actor, g : goal) requests(a : actor, g : goal) owns(a : actor, g : goal) Actor Relations trustexe(a : actor, b : actor, g : goal) trustper(a : actor, b : actor, g : goal)

Table 1. Primitive Predicates

Basic Actions DelegateExecution(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) Absence of Trust Negotiate(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)

Table 2. Actions

that authorizes another actor to achieve the goal. We represent the act of issuing a permission through action DelegatePermission which is performed only if the delegator has the permission on the goal and trusts that the delegatee will not misuse the goal. The consequence of this action is to grant rights (on the goal) to the delegatee, that, in turn, can re-delegate them to other trusted actors. AND/OR Refine. An important aspect of Secure Tropos is goal refinement. In particular, the framework supports two types of refinement: OR decomposition, which suggests the list of alternative ways to satisfy the goal, and AND-decomposition, which refines a goal into subgoals which all are to be satisfied in order to satisfy the initial goal. We introduce actions AND Refine and OR Refine. Essentially, AND Refine and OR Refine represent the action of refining a goal along a possible decomposition. An actor refines a goal only if he actually need it. Thus, a precondition of AND Refine and OR Refine is that the actor requests the fulfillment of the initial goal. A second precondition determines the way in which the goal is refined. The effect of AND Refine and OR Refine is that the actor who refines the goal focuses on the fulfillment of subgoals instead of the fulfillment of the initial goal.

organizations [9]. Trust is used to build collaboration between humans and organizations since it is a necessary antecedent for cooperation [1]. However, common sense suggests that fully trusted domains are simply idealizations. Actually, many domains require that actors who do not have the capabilities to fulfill their objectives, must delegate the execution of their goals to other actors even if they do not trust the delegatees. Accordingly, much work in recent years has focused on the development of frameworks capable of coping with lack of trust, sometimes by introducing an explicit notion of distrust [14, 17]. The presence (or lack) of trust relations among system actors particularly influences the strategies to achieve a goal [21]. In other words, the selection of actions to fulfill a goal changes depending on the belief of the delegator about the possible behavior of the delegatee. In particular, if the delegator trusts the delegatee, the first is confident that the latter will fulfill the goal and so he does not need to verify the actions performed by the delegatee. On the contrary, if the delegator does not trust the delegatee, the first wants some form of control on the behavior of the latter. Different solutions have been proposed to ensure for the delegator the fulfillment of his objectives. A first batch of solutions comes from transaction cost economics and contract theories that view a contract as a basis for trust [35]. This approach assumes that a delegation must occur only in the presence of trust. This implies that the delegator and the delegatee have to reach an agreement before delegating a service. Essentially, the idea is to use a contract to define precisely what the delegatee should do and so establish trust between the delegator and the delegatee. Other theories propose models where effective performance may occur also in the absence of trust [12]. Essentially, they argue that various control mechanisms can ensure the effective fulfillment of actors’s objectives. In this paper we propose a solution for delegation of execution that borrows ideas from both approaches. The case for delegation of permission is similar. The process of delegating in the absence of trust is composed of two phases: establishing trust and control. The establishing trust phase consists of a sequence of actions, namely Negoti-

In addition to actions we define axioms in the planning domain. These are rules that hold in every state of the system and are used to complete the description of the current state. They are used to propagate actor and goal properties along goal refinement: a goal is satisfied if all its AND-subgoals or at least one of the OR-subgoals are satisfied. Moreover, axioms are used to derive and propagate entitlements. Since the owner is entitled to achieve his goals, execute his tasks and access his resources, we need to propagate actors’ entitlements top-down along goal refinement.

5 Delegation and Contract Many business and social studies have emphasized the key role played by trust as a necessary condition for ensuring the success of

32

Planner DLVK IPP 4.1 CPT 1.0 SGPLAN SATPLAN LPG-td

Release 2005-02-23 2000-01-05 2004-11-10 2004-06 2004-10-19 2004-06

URL http://www.dbai.tuwien.ac.at/proj/dlv/K/ http://www.informatik.uni-freiburg.de/ koehler/ipp.html http://www.cril.univ-artois.fr/ vidal/cpt.en.html http://manip.crhc.uiuc.edu/programs/SGPlan/index.html http://www.cs.washington.edu/homes/kautz/satplan/ http://zeus.ing.unibs.it/lpg/

Table 3. Comparison among planners

hhhh h Planner Requirement hhh h 1 2 3

DLVK

IPP X

CPT X

X

X

X

SGPLAN X X

SATPLAN X X

LPG-td X X X

Table 4. Comparison among planners

ate and Contract. In Negotiate the parties negotiate the duties and responsibilities accepted by each party after delegation. The postcondition is an informal agreement representing the initial and informal decision of parties to enter into a partnership. During the execution of Contract the parties formalize the agreement established during negotiation. The postcondition of Contract is a trust “undersuspicion” relation between the delegator and the delegatee. Once the delegator has delegated the goal and the delegatee has fulfilled the goal, the first wants to verify if the latter has really satisfied his objective. This control is performed using action Evaluation. Its postcondition is the “real”fulfillment of the goal. To support this solution we have introduced some additional actions (last part of Table 2) to distinguish the case in which the delegation is based on trust from the case in which the delegator does not trust the delegatee. Sometimes establishing new trust relations might be more convenient than extending existing trust relations. A technical “side-effect” of our solution is that it is possible to control the length of trusted delegation chains. Essentially, every action has a unit cost. Therefore, refining an action into sub-actions corresponds to increasing the cost associated with the action. In particular, refining the delegation action in absence of trust guarantees that the framework first tries to delegate to trusted actors, but if the delegation chain results too long the system can decide to establish a new trust relation rather than to follow the entire trust chain. Need-to-know property of a design decision states that the owner of a goal, a task or a resource wants that only the actors who need permission on its possession are authorized to access it. Essentially, only the actor that achieves a goal, executes a task or delivers a resource, and the actors that belong to the delegation of permission chain from the owner to the provider should be entitled to access this goal, task or resource. Thus, we want to obtain a plan where only the actions that contribute to reaching the desired state occur, so that if any action is removed from the plan it no longer satisfies the goal of the planning problem. This approach guarantees the absence of alternative paths of permission delegations since a plan does not contain any redundant actions.

6

property by construction, that is, the planner should not produce redundant plans. Under non-redundant plan we mean that, by deleting an arbitrary action of the plan, the resulting plan is no more a “valid” plan (i.e. it does not allow to reach the desired state from the initial state). 2. The planner should use PDDL (Planning Domain Definition Language) [15], since it is becoming the “standard”planning language and many research groups work on its implementation. In particular, the planner should use PDDL 2.2 specifications [10], since this version support features, such as derived predicates, that are essential for implementing our planning domain. 3. The planner should be available on both Linux and Windows platforms as our previous Secure Tropos reasoning tool works on both. Table 4 presents a comparison among the planners we have considered with respect to above requirements. Based on such requirements, we have chosen LPG-td, a fully automated system for solving planning problems, supporting PDDL 2.2. Figure 3 shows the specification of actions Satisfy and DelegatePermission in PDDL 2.2. We have applied our approach to the Medical IS case study presented in Figure 1. The desired state of the system is obviously one where the patient gets medical care. The PDDL 2.2 specification of the planning problem is given in [4]. Figure 4 shows the optimal solution (i.e. the plan composed of the fewer number of actions than any other plan) proposed by LPG-td. However, this was not the first choice of the planner. Before selecting this plan, the planner proposed other two sub-optimal alternatives (see [4] for a discussion). It is interesting to see that the planner has first provided a solution with INPDAP, then a solution with INPDAI, and then, finally , a revised solution with INPDAP. A number of other experiments were conduced to test the scalability of our approach. The results are reported in [4].

7 Related Work In recent years many efforts have addressed the integration of security with the system development process, in particular during early requirements analysis. In this setting, many researchers have recognized trust as an important aspect of this process since trust influences the specification of security and privacy policies. However, very few requirements engineering methodologies introduce trust concerns during the system development process. Yu et al. [36]

Using the Planner

In the last years many planners have been proposed (Table 3). In order to choose one of them we have analyzed the following requirements: 1. The planner should produce solution that satisfy need-to-know

33

(: 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)))

(: action DelegatePermission : parameters (?a ?b − actor ?g − goal) : precondition (and (trustper ?a ?b ?g) (has per ?a ?g)) : effect (and (has per ?b ?g)))

(a) Satisfy

(b) DelegatePermission Figure 3. Actions’ Specification

DelegateExecution Pat HP ProvideMC AND Refine HP ProvideMC ProvisioningMC PaymentMC DelegatePermission HCA HP ProvisioningMC Satisfy HP ProvisioningMC DelegateExecution HP HCA PaymentMC DelegateExecution HCA INPDAP PaymentMC AND Refine INPDAP PaymentMC PaymentTicket PaymentHCA DelegateExecution HCA INPDAP PaymentHCA Satisfy HCA PaymentHCA OR Refine INPDAP PaymentTicket PaymentTicketINPDAP PaymentTicketHP DelegatePermission HCA INPDAP PaymentTicketINPDAP Satisfy INPDAP PaymentTicketINPDAP

Figure 4. The optimal solution

model trust by using the concept of softgoal, i.e. a goal having no clear definition for deciding whether it is satisfied or not. However, this approach considers trust as a separate concept from security and does not provide a complete framework to consider security and trust throughout the development process. Haley et al. [18] propose to use trust assumptions, problem frames, and threat descriptions to aid requirements engineers to define and analyze security requirements, and to document the decisions made during the process. Other approach focus on security requirements without taking into account trust aspect. van Lamsweerde et al introduce the notion of antigoals for representing the goals of attackers [33]. McDermott et al. define abuse case model [26] to specify the interactions among actors, which results are harmful to some actors. Similarly, Sindre et al. 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 by Object Management Group, is a framework for defining software design methodologies. Its central focus is on the model transformation, for instance from the platform-independent model of the system to platform-specific models used for implementation purposes. Models are usually described in UML, and the transformation is performed in accordance with the set of rules, called mapping. Transformation could be manual, or automatic, or mixed. Among the proposals on automating a software design process the one of Gamma et al. on design patterns [13] has been widely accepted. A design pattern is a solution (commonly observed from practice) to the certain problem in the certain context, so it may be thought as a problem-contextsolution triple. Several design patterns can be combined to form a solution. Notice that it is still the designer who makes the key decision on what pattern to apply to the given situation. The field of AI planning has been making advances during the last decades, and has found a number of applications (robotics, process planning, autonomous agents, Web services, etc.). There are two basic approaches to the solution of planning problems [34]. One is graph-based planning algorithms [2] in which a compact structure

called a Planning Graph is constructed and analyzed. While in the other approach [19] the planning problem is transformed into a SAT problem and a SAT solver is used. An application of the planning approach to requirements engineering is proposed by Gans et al. [14]. Essentially, they propose to map trust, confidence and distrust described in terms of i* models [36] to delegation patterns in a workflow model. Their approach is inspired by and implemented in ConGolog [8], a logic-based planning language. In this setting, tasks are implemented as ConGolog procedures where preconditions correspond to conditionals and interrupts. Also monitors are mapped into ConGolog procedures. They run concurrently to the other agent tasks waiting for some events such as task completion and certificate expiration. However, focus of their work is on modeling and reasoning about trust in social networks, rather than on secure design.

8 Conclusions We have shown that in our extended Secure Tropos framework it is possible to automatically support the designer of secure and trusted systems also in the automatic selection of design alternatives. Our enhanced methodology allows one to: 1. Capture through a graphical notation the requirements for the organization and the system-to-be. 2. Verify the correctness and consistency of functional and security requirements by • completion of the model drawn by the designer with axioms (a process hidden to the designer), • checking the model for the satisfaction of formal properties corresponding to specific security or design patterns. 3. Automatically select alternative solutions for the fulfillment of functional and security requirements by • transformation of the model drawn by the designer into a planning problem (a process hidden to the designer),

34

[18] Charles B. Haley, Robin C. Laney, Jonathan D. Moffett, and Bashar Nuseibeh, ‘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 partial goal satisfaction for requirements and design engineering’, 29(6), 53– 62, (2004). [21] Niklas Luhmann, Trust and Power, Wisley, 1979. [22] Zohar Manna and Richard Waldinger, ‘A Deductive Approach to Program Synthesis’, ACM Transactions on Programming Languages and Systems, 2(1), 90–121, (1980). [23] Fabio Massacci, Marco Prest, and Nicola Zannone, ‘Using a Security Requirements Engineering Methodology in Practice: The compliance with the Italian Data Protection Legislation’, 27(5), 445–455, (2005). [24] Fabio Massacci and Nicola Zannone, ‘Detecting Conflicts between Functional and Security Requirements with Secure Tropos: John Rusnak and the Allied Irish Bank’, Technical Report DIT-06-002, University of Trento, (2006). [25] Mihhail Matskin and Enn Tyugu, ‘Strategies of Structural Synthesis of Programs and Its Extensions’, 20, 1–25, (2001). [26] J. McDermott and C. Fox, ‘Using Abuse Case Models for Security Requirements 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 Construction for Deductive Synthesis’, 12(4), 393–414, (2005). [30] Ragnhild Kobro Runde and Ketil Stølen, ‘What is model driven architecture?’, Technical Report UIO-IFI-RR304, Department of Informatics, University of Oslo, (March 2003). [31] Herbert A. Simon, The Science of the Artificial, MIT Press, 1969. [32] Guttorm Sindre and Andreas L. Opdahl, ‘Eliciting security requirements 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: Attack Generation 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’, Organization Studies, 26(6), 813–840, (2005). [36] Eric S. K. Yu and Lin Liu, ‘Modelling Trust for System Design Using the i* Strategic Actors Framework’, volume 2246, pp. 175–194, (2001).

• automatic identification of an alternative satisficing the goals of the various actors by means of planner. In this paper we show that this is possible with the use of an offthe-shelf planner to generate possible designs for not trivial security requirements. Of course, we assume that the designer remains in the design loop, so the designs generated by the planner are seen as suggestions to be refined, amended and approved by the designer. In other words, the planner is a(nother) support tool intended to facilitate the design process. Our future work includes extending the application of this idea to other phases of the design and towards progressively larger industrial case studies to see how far can we go without using specialized solvers.

ACKNOWLEDGEMENTS We thank Alfonso Gerevini and Alessandro Saetti for the support on the use of LPG-td. This work was partly supported by the projects RBNE0195K5 FIRB-ASTRO, RBAU01P5SS FIRBSECURITY, 016004 IST-FP6-FET-IP-SENSORIA, 27587 IST-FP6IP-SERENITY, 27004 IST-FP6-STREP-S3MS, 2003-S116-00018 PAT-MOSTRO, 1710SR-B/P PAT-STAMPS.

REFERENCES [1] Robert Axelrod, The Evolution of 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 alternatives’, Technical Report DIT-06-006, University of Trento. [4] Volha Bryl, Fabio Massacci, John Mylopoulos, and Nicola Zannone, ‘Designing security requirements models through planning’, Technical Report 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 as planning’, (2003). [7] Jaelson Castro, Manuel Kolp, and John Mylopoulos, ‘Towards Requirements-Driven Information Systems Engineering: The Tropos Project’, 27(6), 365–389, (2002). [8] Giuseppe de Giacomo, Yves Lesp´erance, and Hector J. Levesque, ‘ConGolog, a concurrent programming language based on the situation calculus’, 121(1-2), 109–169, (2000). [9] Peter Drucker, Managing the Non-Profit Organization: Principles and Practices, HapperCollins Publishers, 1990. [10] Stefan Edelkamp and Jorg Hoffmann, ‘Pddl2.2: The language for the classical part of the 4th international planning competition’, Technical Report 195, University of Freiburg, (2004). [11] Thomas Ellman, ‘Specification and Synthesis of Hybrid Automata for Physics-Based Animation’, pp. 80–93, (2003). [12] Michael J. Gallivan, ‘Striking a balance between trust and control in a virtual organization: a content analysis of open source software case studies’, 11(2), 277, (2001). [13] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. [14] G. Gans, M. Jarke, S. Kethers, and G. Lakemeyer, ‘Modeling the Impact of 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 Domain Definition Language’, (1998). [16] Paolo Giorgini, Fabio Massacci, John Mylopoulos, and Nicola Zannone, ‘Modeling Security Requirements Through Ownership, Permission and Delegation’, pp. 167–176, (2005). [17] Paolo Giorgini, Fabio Massacci, John Mylopoulos, and Nicola Zannone, ‘Modelling Social and Individual Trust in Requirements Engineering Methodologies’, volume 3477, pp. 161–176, (2005).

35

Formal Development of Web Services ¨ 2 Antonella Chirichiello1 and Gwen Salaun ularly with regards to the current WSDL technology, see WS-CDL [26] as an example of proposal in this direction). The restriction of the service visibility to their public interfaces is a common situation in software engineering due to the black-box feature of components. Orchestration is a specific case of service development which aims at solving more complex tasks by developing a new service (often called orchestrator) using existing services by exchanging messages with them.

Abstract. Formal methods are helpful for many issues raised in the web services area. In this paper, we advocate the use of process algebra as a first step in the design and development of executable web services. Verification tools can be used to validate the correct execution of such formal descriptions. We define some guidelines to encode abstract specifications of services-to-be written using these calculi into executable web services. As a back-end language, we consider the orchestration language BPEL. We illustrate our approach through the development of a simple e-business application.

abstract layer

concrete layer

Process Algebra

Web services (WSs) are network-based software components deployed and then accessed through the internet using standard interface description languages and uniform communication protocols. Each service solves a precise task, and may communicate with other services by exchanging messages based on XML standards. Formal methods provide an adequate framework (many specification languages and reasoning tools) to describe WSs at an abstract level and then to tackle interesting issues, in particular their (automatic) composition or correct development. Different proposals have emerged recently to abstractly describe WSs and cope with these questions, most of which are grounded on transition system models (Labelled Transition Systems, Mealy automata, Petri nets, etc) [2, 16, 21, 13, 17]. However, very few approaches have been proposed to help the design and then development of WSs, especially from this kind of abstract descriptions (as done in the classical software engineering life cycle to develop software systems). In this paper, we advocate the use of process algebra (PA) [3] (e.g., CCS, π-calculus, LOTOS, Promela) as a starting point to develop WSs. PA is a simple, abstract and formally-defined notation to describe the exchange of messages between WSs, and to reason on the specified systems. Central to our approach is the definition of a mapping between abstract processes and executable services (implementations and their associated interfaces) as sketched in Figure 1. The use of PA for development purposes may be considered in two ways: (i) encoding means specifying abstractly the new service and its interactions with the other participants, and then translating it into an executable language, (ii) reverse engineering means extracting an abstract representation from the service implementation (accordingly the developer implements directly the service using an executable language) to validate its behaviour with respect to its mates. In both situations, we assume that the existing WSs (compared to the one(s) under development) have behavioural interfaces from which abstract descriptions can be obtained (prospective hypothesis partic1 2

DIS - Universit`a di Roma “La Sapienza”, Italy, [email protected] INRIA Rhˆone-Alpes, VASY Project, France, [email protected]

refinement

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

+ Editing and reasoning tools (CWB−NC, CADP, SPIN...)

reverse engineering

interface

1 Introduction

(WSDL, WS−CDL...)

mapping Executable Code (BPEL, JAVA...)

+ Development environment (BPEL Process Manager, J2EE, .NET...)

Figure 1. Overview of our approach

This paper focuses on the encoding of PA into executable code. In this case, PAs are especially worthy as a first description step because they enable us to analyse the problem at hand, to clarify some points, and to sketch a (first) solution using an abstract language (then dealing only with essential concerns). Therefore, from such a formal description of one or more services-to-be, verification tools can be used to validate their correct execution and, if necessary, to verify and ensure relevant temporal properties such as safety and liveness ones [18]. Regarding the WS(s) to be implemented (compared to the other ones which are viewed as behavioural interfaces), we concentrate ourselves, at the concrete level, on WSDL interfaces and BPEL services. We chose these technologies because they are well-known standards of widespread use and because BPEL is process-oriented therefore making the encoding tractable. Depending on the expressiveness of the process algebra used in the initial step, we can obtain either running BPEL code or just skeletons of code to be complemented. We emphasize that a formal encoding/development (preserving semantics between both levels) is not achieved yet since BPEL does not have a widely accepted formal semantics. The organization of this paper is as follows. We start with a short introduction of process algebra in Section 2. Section 3 focuses on formal verification, and we emphasize which kind of check can be performed on abstract descriptions of services. Section 4 defines guidelines formalising the encoding of process algebra into BPEL. Section 5 describes an example of e-business application in which all the steps advocated in our approach are successively coped with: analysis, formal description, verification, encoding of processes in BPEL services. Finally, in Section 6 we draw up some concluding remarks.

email: email:

36

First, processes may be parameterized with a list of formal parameters (local variable declaration V D). Actions may be extended with value passing to exchange values: an emission OACT may be parameterized with possible data terms, whereas a reception IACT may be parameterized with variables. A behaviour may be preceded by a guard GRD, and is therefore executed only if the guard condition is true.

2 Process Algebraic Descriptions of Services PAs [3] are abstract languages useful to specify dynamic behaviours (sequentiality, concurrency, parallelism, etc). Processes defined using them may communicate together by exchanging messages. These calculi are formalized either axiomatically with algebraic laws which can be used to verify term equivalences, operationally using a semantics based on Labelled Transition Systems, or denotationally defining the meaning of basic entities (and of their composition) using functions. These formalisms are most of the time tool-equipped, enabling one to simulate possible evolutions of processes, to generate test sequences, to check properties (e.g., to ensure that a bad situation never happens), to minimize behaviours, to verify equivalences, etc. As claimed in a previous work [23], PAs are adequate to describe WSs, because they focus on description of behaviours and so, they are appropriate to specify the exchange of messages between services. Compared to automata-based approaches, its main benefit is its expressiveness, mostly due to the existence of numerous PAs enabling one to choose the most adequate formalism depending on the aspects of services to be captured. Compared to Petri nets, PA constructs make it possible to specify composition due to their compositionality property which allows for the definition of more complex behaviours from simple ones. Finally, textual notations are more adequate for describing and reasoning on real-size problems. The large number of process calculi (CCS, TCSP, LOTOS, πcalculus, Promela, etc) and accompanying tools (CWB-NC, CADP, MWB, SPIN, etc) offer a wide panel of expressiveness to deal with valuable issues in the WS area. In this section, our goal is not to introduce a precise algebra, but to present the common constructs appearing in most of them.

Processes. A process is composed of an identifier ID, a list of actions AD, a list of local parameters V D, and its behaviour BHV . The process body is built using the behavioural constructs described above, thus more complicated behaviours can be built from basic ones because PAs are compositional languages. The identifier is useful to refer to the behaviour of the process, and particularly to instantiate or call it recursively. Note that recursive calls may be used to update local variables. In this paper, we illustrate the writing of service specification using the LOTOS calculus. To make the reading of the forthcoming pieces of specification easier, we give in Table 1 the correspondence between the PA abstract operators mentioned above and the LOTOS ones. Abstract constructs OACT IACT EN D IN T SEQ CH P AR HID DD GRD ID,AD,V D,BHV

Actions and interactions. The basic concept to build dynamic behaviours (or processes) is the so-called action. Actions are either emissions or receptions, denoted respectively OACT (Output ACTions) and IACT (Input ACTions) in the sequel. Two (or more) processes can evolve in parallel and synchronize themselves when they are ready to evolve along the same action name; the basic matching is one sender and one receiver. Different communication models may be considered involving variants such as asynchronous vs synchronous communication, or binary vs n-ary communication.

act!v act?x:t exit τ act;B B1 []B2 B1 |[sync-actions]|B2 hide a1 , ..., an in B algebraic specifications [bool-exp] → B

P [action-list](var-list):= B

Table 1. Correspondence between abstract and LOTOS constructs

3 Verification

Behavioural constructs. First, a termination EN D indicates the end of a behaviour. An hidden or internal action IN T may be used to make abstract some possible pieces of behaviours corresponding to internal evolutions. The hide HID operator is sometimes used to make explicit the hiding of some actions to the environment of the process. The usual three main constructs are the sequence SEQ proposing the execution of an action followed by a behaviour, the nondeterministic choice CH between two behaviours (sometimes, internal and external choices are used to distinguish the source of the choice), and the parallel composition P AR (and all its underlying variants like full synchronization or interleaving) meaning parallel evolution and synchronization among several processes. Many dynamic operators may be used and appear in existing calculi: interruption, sequential composition, or compensation and exception handling for constructs more related to WSs issues [5]. Data descriptions. Data DD are not always described within PA (this is not the case in basic CCS, for instance). Different levels of representation exist, for example in Promela, basic datatypes (integers, boolean) may be handled and one advanced construct (array) is available. A more expressive calculus is LOTOS which allows the representation of expressive data using algebraic specifications [9]. Data terms appear at different places within dynamic behaviours.

LOTOS constructs

The major interest of using abstract languages grounded on a clear semantics is that tools can be used to check that a system matches its requirements and works properly. Model checking [7] is the preferred technique at this level (especially compared to the theorem proving alternative [14]) because it works with automata-based models (underlying models of process-algebraic notations), and proofs are completely automated (press-button technology). Process algebras are equipped with state-of-the-art verification tools, such as the SPIN model checker [15] or the CADP toolbox [12], and hence are adequate to any kind of press-button check. Reasoning abilities are strongly related to the service visibility level. In any case (reverse engineering or encoding of abstract processes into code), interface description languages have to be expressive enough to make the verification steps possible. As far as web services specificities are concerned (components deployed on the web, composed to work out precise requests, and interacting as automatically as possible), this kind of tools can help in three cases: (i) checking that two processes are in some precise sense equivalent – one process is typically a very abstract one expressing the speci-

37

follows the structure of the introduction to PA done in Section 2. For each PA concept (actions, interactions, dynamic operators, data descriptions, processes), we describe how it can be encoded into BPEL and we illustrate with pieces of XML code. Here, we refer to PA and its underlying constructs in a general way, even though we illustrate with pieces of LOTOS specification. We validated our approach on many examples of such encodings. The BPEL code obtained after translation was developed and deployed using the Oracle BPEL Process Manager 2.0 [1].

fication of the problem, while the other is closer to the implementation level; (ii) checking that a process verifies desirable properties – e.g. the property that the system will never reach some unexpected state; (iii) checking that interfaces of several services are compatible so that they can interact together and end in a correct termination state. Intuitively, two processes or services are considered to be equivalent if they are indistinguishable from the viewpoint of an external observer interacting with them. This notion has been formally defined in the process algebra community [20], and several notions of equivalence have been proposed such as trace equivalence, observational equivalence, branching equivalence, or strong bisimulation. In our opinion, branching equivalence [25] is the most relevant one in the context of web services. Indeed, branching equivalence is the strongest of the weak equivalences, although, unlike strong equivalence, it does not require a strict matching of τ transitions. In [23], we show how such equivalence notions can be used to check compatibility between services and then to ensure the correctness of a composition. The properties of interest in concurrent systems typically involve reasoning on the possible scenarios that the system can go through. An established formalism for expressing such properties is given by temporal logics like CTL? [18]. These logics present constructs allowing to state in a formal way that, for instance, all scenarios will respect some property at every step, or that some particular event will eventually happen, and so on. The most noticeable kinds of properties one may want to ensure are:

Actions and interactions. The basic piece of behaviour in PA, the so-called action, is translated into WSDL using messages which are completely characterized by the message, portType, operation and partnerLinkType tags. An abstract reception is expressed in BPEL using the receive activity or the pick activity with one onMessage tag. For example, the LOTOS code request?x:Nat denotes the reception of an integer value and the corresponding BPEL code is

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

At the abstract level, an emission followed immediately by a reception may be encoded using the BPEL synchronous or two-way invoke activity, performing two interactions (sending a request and receiving a response). On the other side, the complementary reception/emission is written out using a receive activity (or a pick activity with one onMessage tag) followed by a reply one. As an example, let us consider two interacting processes exchanging an integer value. The emission and the following reception is written in LOTOS as request!x; result?y:Nat, and the corresponding BPEL code is

Last but not least, compatibility between two web services depends not only on static properties like the correct typing of their message parameters, but also on their dynamic behaviour. Providing a simple description of the service behaviour based on process-algebraic or automata-based formalisms can help detecting many subtle incompatibilities in their interaction. Moreover, this compatibility checking can to a large extent be automated if we define the notion of compatibility in a sufficiently formal way. In [4], we propose and compare a number of formal definitions of the compatibility notion, and we illustrate them on simple examples.



While, on the other side of the communication, the reception followed by the emission request?x:Nat; result!x+z in LOTOS is translated into BPEL as follows

...

with the same name of port type and operation. We emphasize that the abstract term x+z does not appear in the BPEL code, because it

38

hidden from an external (or user) point of view, or not if one wants to make them reusable. Finally, we note that many additional behavioural constructs exist among all the existing PA, which would be used and encoded afterwards into BPEL. We have already studied some of them and their translation is not always straightforward, although often tractable. However, it would be too long to comment all these constructs in this paper. Data descriptions. Three levels of data representation in PA have to be encoded into BPEL: type and operation declarations DD, local variable declarations V D, data management in dynamic behaviours (guards GRD and parameters of actions IACT and OACT ). As far as DD datatype definitions are concerned, types are described using XML Schema in the WSDL files. Elements in the Schema are either simple (many built-in types are already defined, e.g., integer, string, boolean) or more complex (e.g., list, set, etc, built using the complexType tag). Considering LOTOS algebraic specifications, correspondence is simple because such constructs are shared at both levels. We introduce below a simple datatype defining a product characterized by an identifier and a quantity in LOTOS

was replaced by the variable y denoting the result of the term, and which has to be assigned beforehand to y using an assign tag. As far as the number of participants to a communication is concerned, let us remark that binary interactions are encoded straightforwardly in BPEL (due to its peer-to-peer interaction model) whereas multi-party communications are expressed in BPEL decomposing it in as many successive two-party communications as needed. Behavioural constructs. The sequence SEQ matches the sequence activity. The abstract termination EN D corresponds to the end of the main sequence in BPEL. For example, the following piece of LOTOS specification request!x; result?y:Nat; exit corresponds in BPEL to

An hidden action IN T is translated into BPEL as a local evolution of a WS which is not visible from an external point of view. Accordingly, it corresponds to one (or more) assign statement. It may also correspond to a communication of the web service at hand with another party but not visible from outside. The HID construct making hidden actions explicit in PA is mapped in BPEL as the hiding of each concerned action (possibly involved in a communication with other partners, then not visible from outside). The choice CH is translated using either the switch activity, defining an ordered list of case or the pick activity, defining a set of activities fired by a message reception. Branches of a choice CH involve emissions and receptions, possibly preceded by guards. In case of a choice among emissions, nondeterminism existing at the abstract level has to be removed. If guards are present, the encoding is straightforward using as many case tags as needed, and the otherwise tag may be used to translate mutually exclusive conditions. Without guards, determinism may be introduced in two ways: (i) adding a pick activity and then defining different messages whose arrival indicates the behaviour to be fired, (ii) using aswitch activity defining case conditions involving for instance values provided beforehand, each condition firing a possible emission. A choice among receptions without guards is straightforwardly translated with a pick: whenever a message comes, it is received on the correct port. In presence of guards, the translation is trickier because a pick activity cannot be introduced within a case one (this is a BPEL limitation). However, it can be achieved reversing the reception and the guard evaluation. The result in BPEL for each branch is a pick with an onMessage tag preceding a switch activity used to test the condition and then to execute the behaviour if the guard is true. A choice involving emissions and receptions (without guards) is translated into BPEL using a pick with one onMessage tag for each branch appearing at the abstract level. In case of an emission, it should be determinized beforehand (as explained in the case involving only emissions), and in case of reception it corresponds to a message coming from a partner. In presence of guards, we can reuse translation rules mentioned before: using a switch for an emission, using a pick and then a switch for a reception. The parallel composition P AR is used in two different cases: (i) it describes a composition of interacting services; (ii) it may be used internally to a service to represent two pieces of behaviour which has to be carried out in different threads with possible interactions. In both cases, each operand of the parallel composition is encoded as one BPEL service meaning that for the case (ii), the architecture of the whole is not preserved. However, it is not a problem because WSs are defined in a compositional way, and such auxiliary WSs can be

type PRODUCTREQUEST is NATURAL, STRING sorts ProductRequest opns conspr (*! constructor *): String, Nat -> ProductRequest productId: ProductRequest -> String quantity: ProductRequest -> Nat ... endtype

The corresponding definition in XML Schema as appearing in the WSDL file is ...

DD allows to define types but also operations on them. Such abstract operations may be encoded into BPEL following different ways. First, they can be defined within XPath expressions; several kinds of functions may be called at this level such as core XPath functions, BPEL XPath functions or custom ones. XPath expressions appear in the assign activity. They simplify the extraction of information from elements or the storage of a value into a variable. Complex data manipulation may also be written using XSLT, XQuery or JAVA (e.g., JAVA exec tags enable one to insert Java code into BPEL code). Another way to describe data operations is to use a database and adequate queries to access and manipulate stored information. As regards to data appearing in behaviours, we gather on one hand IACT and V D because they just involve variables, and on the other hand OACT and GRD because they deal with data terms. First of all, we recall that action parameters in PA for emissions and receptions (IACT and OACT ) are translated using the message tag (in the WSDL file). Eachpart tag matches a parameter of an action.

39

BPEL variables are used to encode variables appearing in IACT and V D. They are defined using the variable tag (global when defined before the activity part) and their scope may be restricted (local declarations) using a scope tag. If necessary, local or global variables may be initialized using an assign after their declaration.



At a lower level, each abstract process is usually made up of three parts: action declarations AD, process parameters V D, and its behaviour BHV (body of the process). AD are encoded using messages / operations / port types / partner link types in the WSDL file and variables in BPEL. V D corresponds to variables in BPEL and BHV is encoded using BPEL activities. For instance, the definition of a process Adder using two actions request and result, parameterized with variable z is expressed in LOTOS as

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

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

and it can be translated into BPEL as ... ... ...

Now, regarding terms appearing in OACT and GRD, an emission send(y) means that the data expression (e.g., x+z below) has to be built and assigned to variable y before sending using an assign tag, and more precisely the copy tag. As far as GRD is concerned, guards are defined in BPEL using thecase tag of the switch construct. For example, the LOTOS code [x result!x+z; ... is translated into BPEL as

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





or ...

In practical applications, such instantiations are often customers filling in forms on-line, and thus requesting some services on the web. The regular way to encode PA recursive process calls is related to the notion of transaction. A transaction could be defined as a complete execution of a group of interacting WSs working out a precise task. In this context, one execution of a process is enough, therefore abstract recursive behaviours are encoded as non recursive services (each transaction corresponds to a new invocation then instantiation of each involved service). Such an encoding is illustrated in Section 5. In the case of an abstract choice among different behaviours, some of them ending with recursive calls and other ones ending with exits, the while activity may be used. The condition of the while is computed from guards of behaviours ending with exits (conjunction of guard negations).

We emphasize that data are not available in every process algebra. Since they are essential in BPEL, it seems convenient to use a process algebra expressive enough to specify data descriptions. Otherwise, they are directly encoded at the concrete level enhancing the BPEL skeletons obtained from the purely dynamic description. Processes. As mentioned before, abstract processes are encoded as BPEL services. A global abstract system is described using a main behaviour made up of instantiated processes composed in parallel and synchronizing together (they are not obliged to synchronize on all actions). Let us observe that the main specification (P1 |P2 |...|Pn ), (| denoting a parallel composition) does not match a BPEL process. The correspondence is that each abstract instantiated process (Pi ), belonging to the global system mentioned previously, matches a BPEL WS. However, the architecture of the specification is not always preserved. In specific cases (parallel behaviours within a process), it might be necessary to define additional services. The set of messages is not defined explicitly in BPEL, but the correspondence between interacting services is made explicit using the partner link declaring on which partner link type services interact, and their role in the communication (see below such an interaction definition between an adder and a requester).

5 Application: a Stock Management System Many services involved in e-business applications may be developed following our approach: auction bargaining, on-line sales (books, CDs, DVDs, flowers, etc), banking systems (own account management for instance), trip organizations, (car) renting, request engines, (hotel, show, etc) reservations, any kind of on-line payment, etc. Such

40

a formal-based development is of interest to save time (then money), then to respect deadlines, and to favour the correctness of the result. In this section, our goal is to focus on an example and to show how following our approach (analysis, specification, verification, encoding, running code) we can design and develop executable WSs. The comprehensive specification written in LOTOS and all the WSDL and BPEL files encoded for this example are available on-line at this URL (demo 40):

Local Store 1

okS v nokS

request

ok v nok

Local Store 2

Local Store 3

requestS

okS v nokS

request ok v nok

Central Store

Supplier 2

requestS

okS v nokS

request ok v nok

Supplier 1

requestS

Supplier 3

http://www.inrialpes.fr/vasy/cadp/demos.html Figure 3. Overview of the service-to-be and its mates

5.1 Informal requirements and analysis For the sake of comprehension, we choose a simple problem. Let us imagine that a chain of supermarkets (called local stores in the following) have to be supplied with goods (or products) every day (or as soon as needed, it depends on the local policy). All the needed goods are centralized in a central store whose role is to supply all the local stores when they request something. This central store has to be supplied as well by suppliers particularly dedicated to a specific product (e.g., vegetables or cold food). Our goal herein is to develop the web service corresponding to the central store assuming the existence of services describing local stores and suppliers. It is obvious that many local stores and suppliers can interact with one central store (even if afterwards several instances of central stores could be created). Local stores and suppliers are viewed through their public interfaces that we assume represented using a simple behavioural description. It is out of scope here to introduce an adequate language for interface description. In this section, we introduce them using transition systems with parameterized actions. A local store (Fig. 2) sends a request (an identifier id and a quantity qt) to acquire a certain amount of a product, and waits for an acceptance or a refusal. Similarly, a supplier receives a request and replies depending on its ability to satisfy the request. Local store

type STOCK is NATURAL, BOOLEAN sorts Stock opns empty (*! constructor *) : -> Stock add (*! constructor *) : Nat, Nat, Stock -> Stock increase : Nat, Nat, Stock -> Stock ...

From the local store and supplier automata describing their public interfaces, LOTOS specifications are easily generated making the reasoning steps possible. For the lack of space, here we focus only on the central store process. This process has two possible behaviours: (i) it receives a request from a local store and it replies depending on the availability of the required quantity in the stock, (ii) in case of the existence in the stock of a product whose quantity is less than a threshold (to be defined arbitrarily), a request (the identifier and a quantity, let us say 5 for example) is sent to a supplier and a reply received. The stock is updated in case of delivery or restocking using adequate operations (decrease and increase).

Supplier

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) ) )

requestS?id?qt

request!id!qt okS

ok nok

CADP is helpful to validate specifications. We start with the description of the data part. We represent a stock as a set of couples (id,qt) with two constructors (empty and add) to build it. Some operations allow to access and update a stock, such as the increase operation which increments the quantity of a product.

nokS

Figure 2. Behavioural interfaces: local store and supplier

A central store may receive requests from local stores and replies depending on the availability of that product in its stock. It also has to supply its stock and then should request possible missing products to a supplier which answers depending on its ability to satisfy the request. As a simplified version, stocks can be viewed as sets of couples, each couple containing a product identifier and a quantity. A pictorial representation of all the interacting services is given in Figure 3.

5.2 Specification and validation LOTOS is appropriate to describe abstractly the system particularly thanks to its expressiveness (data and behaviours) and its toolbox

41

Recursive calls are encoded as exits into the BPEL code. In the case at hand, we introduce the transaction notion corresponding to a request posted by a local store and to a reply depending on the availability of the product in the database. Thus, such a transaction is instantiated every time that a new request is received. In the LOTOS specification, recursive calls are accompanied of stock updates. This is done in BPEL updating the database before the service completes.

endproc

To validate this new service, several verification steps can be performed using CADP to ensure a correct processing of the interacting processes. Several mistakes in the specification have been found out (in the design, in the interaction flows, in the data description and management). Simulation has helped to clarify misunderstandings in the analysis of the problem at hand. Proofs were verified usingE VAL UATOR [19] (an on-the-flymodel checker part of CADP) which can be used to ensure safety, liveness and fairness properties written in µ-calculus. Due to the simplicity of the problem at hand, we particularly check the absence of deadlock, and liveness properties ensuring for example that the firing of every request gate (also checked with requestS) is either followed by an acceptance or a refusal.

Sample of BPEL. Our goal in this part is to introduce the skeleton of the BPEL code describing interactions between the central store and the local store. The central store service was implemented through a BPEL service, its WSDL interface, a database and a Java class containing the useful methods to interact with the databases. For experimentation purposes, some other services were encoded (local stores and suppliers) using the same technologies.

[true* . "request!*"] true

... ... ...

5.3 Translation into BPEL In this subsection, our goal is to emphasize how previous guidelines are used to encode abstract processes written in LOTOS herein into BPEL. We explain this translation through a sample of the BPEL code implemented for the central store. Development environment. The Development was carried out using Oracle BPEL Process Manager 2.0, BPEL Console, BPEL Designer [1]. The process manager provides an infrastructure for deploying, executing and managing BPEL processes. The console is useful to test the deployed BPEL services. The designer makes it possible to build BPEL code from a developer-friendly visual tool, and to validate and pack BPEL processes. Data have been described using a Microsoft Access relational database (it is obvious that any DBMS could be used at this level). The package java.sql was helpful to access the database and the driver JDBC-ODBC to make the connection between Java classes and the database. We use the Java exec activity to insert Java code into BPEL code so as to call the Java methods defined to access and update the database. Following the guidelines. Let us focus on the first half of the central store (the interaction with the local store) we specified previously in LOTOS. We overview how the constructs involved in this behaviour are expressed in BPEL. Firstly, LOTOS emissions and receptions (gates, variables and types) are encoded in the WSDL file. Note that the ok and nok actions have been encoded into BPEL using the same name of message but both branches are distinguished by the value of its Boolean parameter (true in case of availability, false otherwise). Each stock is encoded as a simple table with two fields (identifier , quantity). A Java class has been encoded and contains methods to access and update correctly each database (using SQL queries), e.g., to test the availability of a product. We highlight that the central store handles one request after the other. Thereby, it possibly updates the database at the end of each transaction and concurrent accesses to the base are then discarded. The LOTOS sequence is directly translated using the sequence activity. The reception and the emission in this part of the central store are translated as a pick activity with one onMessage tag followed by a reply. The choice is composed of two branches with guards and emissions (without parameters), consequently a switch activity is employed to translate this LOTOS behaviour, and each branch is implemented using a case activity with guards corresponding to queries on the database.

42

[2] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella, ‘Automatic Composition of E-services That Export Their Behavior’, in Proc. of ICSOC’03, volume 2910 of LNCS, pp. 43–58, Italy, (2003). Springer-Verlag. [3] Handbook of Process Algebra, eds., J. A. Bergstra, A. Ponse, and S. A. Smolka, Elsevier, 2001. [4] L. Bordeaux, G. Sala¨un, D. Berardi, and M. Mecella, ‘When are two Web Services Compatible?’, in Proc. of TES’04, ed., M.-C. Shan et al., volume 3324 of LNCS, pp. 15–28, Canada, (2004). Springer-Verlag. [5] M. Butler and C. Ferreira, ‘An Operational Semantics for StAC, a Language for Modelling Long-Running Business Transactions’, in Proc. of COORDINATION’04, volume 2949 of LNCS, pp. 87–104, Italy, (2004). Springer-Verlag. [6] A. Chirichiello and G. Sala¨un, ‘Encoding Abstract Descriptions into Executable Web Services: Towards a Formal Development.’, in Web Intelligence 2005 (WI’05), eds., A. Skowron, R. Agrawal, M. Luck, T. Yamaguchi, P. Morizet-Mahoudeaux, J. Liu, and N. Zhong, pp. 457– 463. IEEE Computer Society, (2005). [7] E. M. Clarke, O. Grumberg, and D. Peled, Model Checking, The MIT Press, 2000. [8] D. Cooney, M. Dumas, and P. Roe, ‘GPSL: A Programming Language for Service Implementation.’, in FASE’06, eds., L. and R. Heckel, volume 3922 of LNCS, pp. 3–17. Springer, (2006). [9] H. Ehrig and B. Mahr, Fundamentals of Algebraic Specification 1: Equations and Initial Semantics, volume 6 of EATCS Monographs on Theoretical Computer Science, Springer-Verlag, New-York, 1985. [10] H. Foster, S. Uchitel, J. Magee, and J. Kramer, ‘Model-based Verification of Web Service Compositions’, in Proc. of ASE’03, pp. 152–163, Canada, (2003). IEEE Computer Society Press. [11] X. Fu, T. Bultan, and J. Su, ‘Analysis of Interacting BPEL Web Services’, in Proc. of WWW’04, USA, (2004). ACM Press. [12] H. Garavel, F. Lang, and R. Mateescu, ‘An Overview of CADP 2001’, EASST Newsletter, 4, 13–24, (2001). Also available as INRIA Technical Report RT-0254. [13] R. Hamadi and B. Benatallah, ‘A Petri Net-based Model for Web Service Composition’, in Proc. of ADC’03, volume 17 of CRPIT, Australia, (2003). Australian Computer Society. [14] J. Harrison, ‘Verification: Industrial Applications’. Lecture at 2003 Marktoberdorf Summer School, USA. [15] G. Holzmann, The SPIN Model-Checker: Primer and Reference Manual, Addison-Wesley, 2003. [16] R. Hull, M. Benedikt, V. Christophides, and J. Su, ‘E-Services: a Look Behind the Curtain’, in Proc. of PODS’03, pp. 1–14, USA, (2003). ACM Press. [17] A. Lazovik, M. Aiello, and M. P. Papazoglou, ‘Planning and Monitoring the Execution of Web Service Requests’, in Proc. of ICSOC’03, volume 2910 of LNCS, pp. 335–350, Italy, (2003). Springer-Verlag. [18] Z. Manna and A. Pnueli, Temporal Verification of Reactive Systems: Safety, Springer, 1995. [19] R. Mateescu and M. Sighireanu, ‘Efficient On-the-Fly Model-Checking for Regular Alternation-Free Mu-Calculus’, Science of Computer Programming, 46(3), 255–281, (2003). [20] R. Milner, Communication and Concurrency, International Series in Computer Science, Prentice Hall, 1989. [21] S. Narayanan and S. McIlraith, ‘Analysis and Simulation of Web Services’, Computer Networks, 42(5), 675–693, (2003). [22] M. Pistore, M. Roveri, and P. Busetta, ‘Requirements-Driven Verification of Web Services’, in Proc. of WS-FM’04, volume 105 of ENTCS, pp. 95–108, Italy, (2004). [23] G. Sala¨un, L. Bordeaux, and M. Schaerf, ‘Describing and Reasoning on Web Services using Process Algebra’, in Proc. of ICWS’04, pp. 43–51, San Diego, USA, (2004). IEEE Computer Society Press. [24] G. Sala¨un, A. Ferrara, and A. Chirichiello, ‘Negotiation among Web Services using LOTOS/CADP’, in Proc. of ECOWS’04, volume 3250 of LNCS, pp. 198–212, Germany, (2004). Springer-Verlag. [25] R. J. van Glabbeek and W. P. Weijland, ‘Branching Time and Abstraction in Bisimulation Semantics’, Journal of the ACM, 43(3), 555–600, (1996). [26] W3C, Web Services Choreography Description Language Version 1.0. Available at http://www.w3.org/TR/2004/WD-ws-cdl-10-2 0040427/.

...

Implementing WSs in BPEL using all the necessary technologies (Java, databases, BPEL Process Manager) is not so simple. Nevertheless, with a minimum knowledge of such technologies, WSs can be implemented and deployed easily and rather quickly (depending of course on the size of the application) following our approach.

6 Concluding Remarks Development of web services distributed on the web is a recent issue and the need of formal approaches to ensure a smooth and validated process is obvious for many e-business applications. In this paper, we advocated such an approach starting from simple and abstract descriptions of processes and ending with executable web services implemented in BPEL. The two main contributions of our proposal are first a simplified development thanks to guidelines enabling one to encode abstract processes into executable ones. Secondly, validation steps are made possible through the use of formal reasoning tools, which usually accompany process algebra, thereby enabling one to detect possible errors and flaws at an early stage. In comparison with some related works [11, 22, 10, 21] dealing with mappings between abstract and concrete descriptions of WSs, we do not argue for a reverse engineering direction for the mapping but we propose a method to develop WSs. A judicious choice of our abstract language (e.g. LOTOS) makes the specification of advanced data descriptions and operations on them possible at the abstract level (more complex than in [11] where operations cannot be modelled as an example) as well as at the executable one. Our method was used to develop and deploy running WSs, consequently it has not remained at a conceptual level as it is most of the time the case. We emphasize that a formal encoding (preserving semantics between both levels) is not achieved yet since BPEL does not have a widely accepted formal semantics. The proposed encoding makes it possible to obtain running BPEL processes from abstract specifications. However, tricks and choice implementations are needed, due to the limitations of BPEL as executable language, especially regarding the way interactions among processes are managed, or activities combined. BPEL, like many other web service programming languages, facilitates the development of services that engage in concurrent interactions. Anyway, as pointed out in [8], it fails to address more complex scenarios that go beyond simple sequences of requests and responses or that involve many participants. In particular, BPEL cannot deal with one-to-many interactions with partial synchronization among the partner services, especially when these services are not known in advance. As regards these BPEL limitations, we would like to apply our approach to another target language such as GPSL [8] which seems more suitable to the implementation of services. Acknowledgments. The authors thank Lucas Bordeaux and Marco Schaerf for judicious comments they made on this work. This work is partially supported by Project ASTRO funded by the Italian Ministry for Research under the FIRB framework (funds for basic research).

REFERENCES [1] Oracle BPEL Process Manager 2.0. Available at http://www.oracle.com/technology/products/ias/bpel/.

43

Implicit vs. Explicit Data-Flow Requirements in Web Service Composition Goals Annapaola Marconi1 and Marco Pistore2 and Paolo Traverso3 requirements. Implicit data-flow requirements, see, e.g., [10], are a set of rules that specify how to combine the functions computed by the component services to transform incoming messages into outgoing messages. A composition goal contains references to such rules and functions. They implicitly define the required constraints among exchanged data. Consider, for instance, a virtual travel agency that composes two component services, a flight and a hotel reservation service. An implicit data flow requirement for the composition can state that the price of the offer to the customer should be computed on the basis of the costs of the hotel and of the flight. The cost in the offer can be specified formally as a function that composes two components’ cost functions in some desired way. This requirement implicitly specifies a data flow from the (flightand hotel) messages of the components to the composed service, the agency service. The composition task should determine from this specification which messages and which data should be sent from a service to another. Explicit data-flow requirements are a set of explicit specifications on how the composition should manipulate messages and route them from/to components. The composition goal consists in a set of constraints that directly and explicitly define the valid routings and manipulations of messages that the composition can perform. These constraints 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 existing services are modeled as nodes, the paths in the graph defin e the possible routes of the messages, and the arcs define basic manipulations of these messages performed by the orchestrator. For instance, an explicit data flow requirement for a virtual travel agency is that the hotel service output message with the data about the cost of the flightas well as the flightoutput message with the data for the cost of the hotel should be input to the composed virtual travel agency. In this paper, we present the two approaches, show how they can be used to specify data-flow requirements within a state-of-the-art automated composition framework [11, 12, 10] and finally compare them wrt their efficienc y and usability. The rest of the document is organized as follows. In Section 2 we describe the problem of web service composition and we illustrate the necessity to define complex data flow requirements. In Section 3 we brieflyrecall both explicit and implicit data-flow requirements modeling approaches. In Section 4 we discuss how they can be 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 final remarks.

Abstract. While several approaches to the automated composition of Web services have been proposed in the literature, so far very few of them take into account a key aspect of the composition problem: how to specify data-flow requirements, i.e. requirements on data that are exchanged among component services. In this paper we present two different ways to specify composition requirements on exchanged data. Implicit data-flow requirements are a set of rules that specify how the functions computed by the component services are to be combined by the composite service. They implicitly define the required constraints among exchanged data.Explicit data-flow requirements are a set of explicit specifications on how the composition should manipulate messages and route them from/to components. We integrate the two specification languages within a state of the art framework for the automated synthesis of compositions. We compare them through an experimental evaluation, both from the point of view of efficienc y and scalability as well as from that of practical usability. Keywords: Web Service Composition Requirements, Modeling Languages, Automated Planning

1 Introduction Service composition is one of the fundamental ideas underlying Web services and service oriented applications: composed services perform new functionalities by interacting with component services that are available, e.g., on the Web. The automated synthesis of composed services is one of the key tasks that can significantly support the design and development of service oriented applications. Several methods have been proposed to cope with the automated synthesis of composed services (see, e.g., [7, 8, 4, 2, 11, 10]). In these approaches, given a set of available component services, composition requirements specify the desired behaviors that should be enforced on the component services, and the composition task corresponds to the synthesis of a composition, e.g., a new service, or a set of constraints on the behaviors of existing services, that realizes the desired behavior. However, most of the approaches that have been proposed so far do not take into account a key aspect of the composition problem: the specification ofdata-flow requirements, i.e. requirements on data that are exchanged among component services. This is a significant and challenging problem, since, in real life scenarios, business analysts and developers need a way to express complex requirements on the exchanged data. Moreover, to make the automated composition an effective and practical task, the requirements specification should be easy to write and to understand for the analyst. Surprisingly, very little effort has been devoted in the literature to address this problem. In this paper we present and discuss two different approaches addressing the problem of specifying and using composition data flow 1 2 3

2 Web Service Composition: The P&S Scenario With automated composition of Web Services we mean the generation of a new composite service that interacts with a set of existing component services in order to achieve given composition requirements. We assume that the component services are described through a complex interaction protocol defined in BPEL 4 WS (Business Process Execution Language for Web Services) [1], even if the described

ITC-irst, Trento, Italy, email: [email protected] University of Trento, Italy, email: [email protected] ITC-irst, Trento - Italy, email: [email protected]

44

PRODUCER SERVICE

SHIPPER SERVICE

START

START ? request(item, location)

? request(size, location)

? request(item)

cost := costOf(item) size := sizeOf(item) delay := delayOf(item)

! not_avail

CUSTOMER SERVICE

START

cost := costOf(size, location) ! not_avail

NOT_AVAIL

NOT_AVAIL

? offer(cost, delay)

? not_avail

delay := delayOf(size, location)

NOT_AVAIL

? nack

!offer(cost, delay)

!offer(cost, size, delay)

? ack SUCC

CANCELED ? nack

CANCELED

? nack

? ack

? ack

CANCELED

SUCC

Figure 1.

SUCC

The Purchase and Ship component services

approach does not depend on the specific aspects of the BPEL 4 WS language. BPEL 4 WS is an industrial language for the specification and execution of business processes made available through Web services. BPEL 4 WS provides an operational description of the (stateful) behavior of web services on top of the service interfaces defined in their WSDL specifications. A BPEL 4 WS description identifies the partners of a service, its internal variables (together with their type specification), and the operations that are triggered upon the invocation of the service by some of the partners. Operations include assigning variables (possibly using internal functions), invoking other services and receiving responses, forking parallel threads of execution, and nondeterministically picking one amongst different courses of actions. Standard imperative constructs such as if-then-else, case choices, and loops, are also supported. In this section we illustrate the problem of automated composition of Web services on the Purchase and Ship case study introduced in [11, 10]. We will focus in particular on the problem of specifying the requirements of such a composition.

3. P&S asks the Shipper for the price and time needed to transport an object of such a size to l; 4. P&S sends the Customer an offer which takes into account the overall cost (plus an added cost for P&S) and time to achieve its goal; 5. the Customer sends a confirmation of the order, which is dispatched by P&S to Shipper and Producer. This is however only the normal case, and other interactions should be considered, e.g., for the cases the producer and/or delivery services are not able to satisfy the request, or the user refuses the final offer. Figure 2 shows a possible implementation of the P&S composite service handling all the possible component service interactions 4 .

PURCHASE&SHIP SERVICE

? C.request(item, location)

!P.request(item)

Example 1 (Purchase and Ship) The Purchase and Ship (P&S from now on) example consists in providing a furniture purchase and ship service by combining two independent existing services, a furniture producer Producer and a delivery service Shipper. This way, the Customer, also described as a service, may directly ask the composite service P&S to purchase a given item and deliver it at a given place (for simplicity, we assume that the shipment origin is fixed and leave it implicit). The interactions with the existing services have to follow specific protocols. For instance, the interactions with the Shipper start with a request for transporting a product of a given size to a given location. This might not be possible, in which case the requester is notified, and the protocol terminates with failure. Otherwise, a cost and delivery time are computed and sent back to the requester. Then the Shipper waits for either an acceptance or a refusal of the offer from the invoker. In the former case, a delivery contract has been defined and the protocol terminates with success, while it terminates with failure in the latter case. Similar protocols are defined also for Producer and Customer. Figure 1 shows the interaction protocols of the component services. A typical interaction could be as follows:

? 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)

cost := addCost(prod_cost, ship_cost) ! P.nack

delay := addDelay(prod_delay, ship_delay)

! C.not_avail

! C.offer(cost, delay)

? C.nack

Figure 2.

? C.ack

! P.nack

! P.ack

! S.nack

! S.ack

The Purchase and Ship composite service

Given the description of the component services and of the customer interface, the next step towards the definition of the automated

1. the Customer asks P&S for an item i that he wants to be transported at location l; 2. P&S asks the Producer for the size, the cost, and how much time does it take to produce the item i;

4

45

In Figure 2 and in all presented examples, we shorten Customer with C, Producer with P, and Shipper with S.

composition domain is the formal specification of the composition requirements. As we will see from the examples presented in the rest of this section, even for simple case studies we need a way to express requirements that define complex conditions, both for what concerns the control flow and for the data exchanged among the component services.

Moreover, the cost proposed to the customer must be the sum of the costs offered by the Producer and by the Shipper services plus some additional fee for the P&S service. Similarly for the computation of the delay of the P&S. The example shows that, even for naive composition problems, we need a way to express different forms of data flow requirements: from simple data links between incoming and outgoing message parts (e.g., forwarding the information received by the customer about the location to the Shipper service), to the specification of complex data manipulation (e.g., when computing the overall service cost).

Example 2 (Control-flow requirements) The P&S has the goal to “sellhome-delivered furniture” . This means that we want to reach a situation where the customer has confirmed an order and the service has confirmed the corresponding sub-orders to producer and shipper. However, it may be the case that there are no available items (or no available shipments) satisfying the customer request, or that the customer doesn’t like the proposed offer and thus refuses it. We cannot avoid these situations, therefore we cannot ask the composite service to guarantee this requirement. Moreover, in case this requirement cannot be satisfied, we do not want theP&S to order an item (nor a shipment) without being sure that our customer accepted the offer, as well as we do not want displeased customers that have confirmed orders which will never be fulfilled. Thus, our global termination requirement would be something like: do whatever is possible to ”sell home-delivered furniture” and if something goes wrong guarantee that there are ”nosingle commit”.

3

Modeling Data Flow Requirements

In this section we present two different approaches, implicit vs explicit, to the specification of data-flow requirements. The former exploits the knowledge level model for web services presented in [10], while the latter uses the data-flow requirements modeling language proposed in [6].

3.1

Implicit Data Flow Requirements: Knowledge Base

The specification of the data-flow requirements within the knowledge level composition approach [10] exploits the semantic annotations in the abstract process descriptions of the component services. Such annotations specify how incoming messages are manipulated within the component service (by means of internal functions and assignments) to obtain outgoing messages. For instance, in the Shipper service protocol of Figure 1, the semantic annotation cost := costOf(size, location) models the fact that the Shipper obtains the cost of the shipment by means of its internal function costOf applied on the size and location information received in the customer request. In the following example we show how the specification of the implicit data-flow requirements exploits the functions of the component services and uses additional functions specifying how the data computed by the components need to be combined in the composite service.

Modeling composition requirements requires to express recovery conditions and preferences among subgoals (’mandatory’ and ’desired’). In previous works [11, 12, 10], we have proposed to model control-flow requirements exploiting the E AGL E specification language [3]. E AGL E is a temporal logics with preferences: its operators are similar to CTL operators, but their semantics, formally defined in [3], takes into account the notion of preference and the handling of failure when subgoals cannot be achieved. An example of an E AGL E requirement is given in the following example. Example 3 The E AGL E formalization of the control-flow requirements in Example 2 is the following. TryReach C.SUCC ∧ S.SUCC ∧ P.SUCC Fail DoReach

Example 5 (Implicit data flow requirements) A possible specification of the data-flow composition requirements in Example 4 is the following:

(C.NOT AVAIL ∨ C.CANCELED) ∧ (P.NOT AVAIL ∨ P.CANCELED) ∧ (S.START ∨ S.NOT AVAIL ∨ S.CANCELED)

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))

The goal is of the form “TryReach c Fail DoReach d”. TryReach c requires a service that tries to reach condition c, in our case the condition “sell home-delivered furniture”. During the execution of the service, a state may be reached from which it is not possible to reach c, e.g., since the item is not available. When such a state is reached, the requirement TryReach c fails and the recovery condition DoReach d, in our case “no single commit”, is considered.

The goal declares that the offered cost must be obtained by applying the function addCost to the costs offered by the producer and the shipper (and similarly for the offered delay).

To express the desired properties of the service to synthesize, the control-flow requirement of Examples 2 and 3 has to be completed with requirements on the data flow.

Within this approach the data-flow requirements specify how the messages to be sent must be obtained by composing functions of the component services and of the new composite service. These requirements implicitly constrain the message exchanges that must occur with the component services and the internal data manipulation that the composite service must perform. Given a data-flow composition goal, we automatically generate its knowledge level representation. This declares what the composite service must know and how goal variables and functions must be related with the variables and functions of the component services.

Example 4 (Data-flow requirements) In order to provide consistent information, the P&S service needs to exchange data with the components and its customer in an appropriate way. For instance, when invoking the Producer service, the information about the item must be the same one that the P&S received in the customer request. Similarly, the information sent to the Shipper service about the location must be that obtained from the customer, while the information about the location must be that received from the Producer service.

46

In [10] we formally defined the knowledge level model in terms of a suitable knowledge base (from now on KB), of which we recall here the definition.

from component services). This includes several important aspects: whether an input message can be used several times or just once, how several input messages must be combined to obtain an output message, whether all messages received must be processed and sent or not, etc.. In the following we will brieflydescribe the basic elements of the language, show how they can be composed to obtain complex expressions and provide an intuitive semantics (for further details see [6]).

Definition 1 (Knowledge Base) A knowledge base KB is a set of propositions of the following form: • KV (x) where x is a variable with an abstract type; • K(x = v) where x is an enumerative variable and v is one of its possible values; • K(x = y) where x and y are two variables with the same type; • K(x = f (y1 , . . . , yn )) where x, y1 , . . . , yn are variables with an abstract type and f is a function compatible with the types of x, y1 , . . . , yn .

• Connection Node






A connection node can be external or internal. An external connection node is associated to an output (or an input) external port. Intuitively, an external input (output) node characterizes an external source (target) of data and it is used to exchange data with the outside world. • Identity It is connected to one connection node in input and one node in output. It forwards data received from the input node to the output node. The graphical notation for the data-flow identity element id(a)(b), with input node a and output node b, is the following:

With K(p) we mean that we know that proposition p is true and with KV (x) that we know the value of the variable x. Example 6 To obtain the knowledge level data-flow requirements, we flatten the functions introducing auxiliary variables until only basic propositions are 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

a

!

b

• Operation It is related to a function definition, is connected to as many input nodes as the number of function parameters and only to one output node corresponding to the function result. When it receives data from all the input nodes, it computes the result and forwards it to the output channel. The graphical notation for the data-flow operation element oper[f](a,b)(c) characterizing function f, with input nodes a and b and output node c, is the following:

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, and goal.user loc; and the goal functions goal.addCost(Cost, Cost):Cost and goal.addDelay(Time, Time):Time.

a b     

f

  c

The goal can then be automatically translated into its corresponding knowledge level goal:

• Fork It is connected to a node in input and to as many nodes as necesK(C.cost = goal.added cost)∧ sary in output. It forwards data received on the input node to all K(C.delay = goal.added delay)∧ the output nodes. The graphical notation for the data-flow fork elK(goal.added cost = goal.addCost(goal.prod cost, goal.ship cost))∧ ement fork(a)(b,c), with input node a and output nodes b and c, K(goal.added delay = goal.addDelay(goal.prod delay, goal.ship delay))∧ is the following: 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)

b a c

• Merge It is connected to one node in output and as many nodes as necessary in input. It forwards data received on some input node to the output node. It preserves the temporal order of data arriving on input nodes (if it receives data on two or more input nodes at the same time, the order is nondeterministic). We represent the dataflow merge element merge(a,b)(c), with input nodes a and b and output node c as:

The knowledge-level representation of the data-flow composition requirements defines therefore a knowledge base, that we call the knowledge base of the goal. Intuitively, this knowledge base specifies what the new composite service must know at the end of its execution.

 a b

3.2 Explicit Data Flow Requirements: Data Net

c

• Cloner It is connected to one node in input and one node in output. It forwards, one or more times, data received from the input node to the output node. The data-flow cloner element clone(a)(b), with input node a and output node b is represented as:

The aim of the data flow modeling language presented in [6] is to allow the specification of complex requirements concerning data manipulation and exchange. In particular, data flow requirements specify explicitly how output messages (messages sent to component services) must be obtained from input messages (messages received

47

a

In [6] we formally define when an execution ρ is accepted by a I O data net D = hNext , Next , Nint , D, V i using regular expressions 5 . We recall here some basic aspects, please refer to [6] for complete details. We require that for each identity element id(a)(b) in D !∗ X Π{a,b} (ρ) = ha, vi · hb, vi

b

+

• Filter It is connected to one node in input and one node in output. When it receives data on the input node it either forwards it to the output node or discards it. We represent the data-flow filter element filt(a)(b), having input node a and output node b as: a

?

v∈V

and for each operation element oper[f](a,b)(c) in D

b

The diagram obtained by suitably composing data-flow elements by means of connection nodes is called data net (see Figure 3). A data net is characterized by a set of external connection nodes associI , a set of external connection nodes associated ated to input ports Next O to output ports Next , a set of internal connection nodes Nint , a set of data-flow elements D and a set of data values V . Given a data-flow element d we denote with in nodes(d) the set of input connection nodes of d and with out nodes(d) the set of output connection nodes of d.

Π{a,b,c} (ρ) = X

(ha, vi · hb, wi + hb, wi · ha, vi) · hc, f (v, w)i

v,w∈V

!∗

and for each fork element fork(a)(b,c) in D Π{a,b,c} (ρ) = X

Definition 2 (Data Net) I O A data net D is a tuple hNext , Next , Nint , D, V i where:

v∈V

I • for each n ∈ Next there exists a unique data-flow element d ∈ D s.t. n ∈ in nodes(d); O • for each n ∈ Next there exists a unique data-flow element d ∈ D s.t. n ∈ out nodes(d); • for each n ∈ Nint there exists a unique data-flow element d1 ∈ D s.t. n ∈ in nodes(d1 ) and there exists a unique data-flow element d2 ∈ D s.t. n ∈ out nodes(d2 ); I • for each d ∈ D, in nodes(d) ⊆ Next ∪ Nint and O out nodes(d) ⊆ Next ∪ Nint .

ha, vi · (hb, vi · hc, vi + hc, vi · hb, vi)

!∗

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 communication partners. In particular, as shown in the data net of Figure 3, external connection nodes are associated to input (or output) ports which model BPEL 4 WS messages, or message parts, which are used to store data received (or sent) by the process while interacting with other services. Since the behavioral aspect we are interested in concerns the data flow among the process and its partners, we characterize an execution of a BPEL 4 WS process W , denoted with exec(W ), as the set of all possible ordered sequence of input/output messages (or message parts) received and sent by the process from its activation to its termination. Notice that each message carries both the information about the external port on which it has been sent/received and about its content (value).

A possible specification of the data net for the Purchase and Ship example is presented in Figure 3, which we will (partially) explain in the following example. Example 7 The fir st data-flow requirement from the top id(C.request.item)(P.request.item)

specifies that theitem information sent to the Producer must be obtained from the request received from the Customer. The last requirement

Definition 3 (data net satisfiability) I O Let W be a BPEL 4 WS process and D = hNext , Next , Nint , D, V i a data net. We say that W satisfies D when for each process execution ρW ∈ exec(W ) there exists an accepting execution ρ of D such that ΠNext (ρ) = ρW .

oper[addDelay](P.offer.delay, S.offer.delay)(C.offer.delay)

specifies that the P&S must apply its internal function addDelay on the delay received in the offers from the Producer and from the Shipper to obtain the delay to be sent in the offer to the Customer. And so on.

4 The Automated Composition Framework In this section we show how both the implicit and explicit data-flow requirement specification approaches can be integrated in a general framework for the automated composition of Web services. The work in [11] (see also [12]) presents a formal framework for the automated composition of web services which is based on planning techniques: component services define the planning domain, composition requirements are formalized as a planning goal, and planning algorithms are used to generate the composite service. The framework of [11] differs from other planning frameworks since it assumes an asynchronous, message-based interaction between the domain (encoding the component services) and the plan (encoding

The semantics of a data net model is given in terms of the accepted executions of the data net D, which define the valid sequences of messages exchanged by the composite service with the component services. I O Formally, given a data net D = hNext , Next , Nint , D, V i, we denote with Next the sets of all external connection nodes, formally I O Next = Next ∪ Next . An event e of D is a couple hn, vi, where n ∈ Next ∪ Nint , and v ∈ V , which models the fact that the data value v passes through the connection node n. An execution ρ of D is a finite sequence of eventse0 , ..., en . Given an execution ρ we define it’s projection on a set of connection nodes N ⊆ Next ∪ Nint , and denote it with ΠN (ρ), the ordered sequence e00 , ..., e0m representing the events in ρ on a node in N .

5

48

We use notation Σv∈V to express alternatives that range over all the possible values v ∈ V that can flow through the net.

   

C.request.location

 

!

C.request.item

      P.offer.cost   S.offer.cost      P.offer.delay   S.offer.delay P.offer.size

!





!

  

addDelay



S.request.size



C.offer.cost

C.offer.delay

The data net for the Purchase and Ship composition scenario

Given this, we can characterize formally an automated synthesis problem.

the composite service). We now recall the most relevant features of the framework defined in [11]. The planning domain is modeled as a state transition system (STS from now on) which describes a dynamic systems that can be in one of its possible states (some of which are marked as initial states and/or as final states) and can evolve to new states as a result of performing some actions. Actions are distinguished in input actions, which represent the reception of messages, output actions, which represent messages sent to external services, and internal actions, which represent internal evolutions that are not visible to external services, i.e., data computation that the system performs without interacting with external services. A transition relation describes how the state can evolve on the basis of inputs, outputs, or internal actions.

Definition 6 (Automated Synthesis) Let Σ be a state transition system, and let ρ be an E AGL E formula defining a composition requirement. The automated synthesis problem for Σ and ρ is the problem of finding a state transition systemΣc such that Σc . Σ |= ρ. The work in [11] shows how to adapt to this task the “Planning as Model Checking” approach, which is able to deal with large nondeterministic domains and with requirements expressed in E AGL E. It exploit powerful BDD-based techniques developed for Symbolic Model Checking to efficiently explore domainΣ during the construction of Σc .

Definition 4 (state transition system (STS)) A state transition system Σ is a tuple hS, S 0 , I, O, A, R, Fi where: • • • • • • •

S.request.location



addCost

Figure 3.

P.request.item

S is the finite set of states; S 0 ⊆ S is the set of initial states; I is the finite set of input actions; O is the finite set of output actions; A is the finite set of internal actions; R ⊆ S × (I ∪ O ∪ A) × S is the transition relation; F ⊆ S is the set of accepting states.

4.1

Integrating implicit data-flow requirements

In the following we will show how BPEL 4 WS processes can be automatically translated into their knowledge level models and how these can be used, together with the data-flow requirements specification, to obtain the composition domain at the knowledge level (for an exhaustive description of the approach see [10]). The main characteristic of the knowledge level approach is the possibility to model data at an abstract level (paying no heed to the actual data exchanged between processes) and thus to efficiently perform complex reasoning on data manipulation and flow among the considered services. As we have shown in [6], BPEL 4 WS processes can be modeled as STSs (see Definition 4). We omit the formal definition of the translation, which can be found at http://astroproject.org. Intuitively, input actions of the STS represent messages received from the component services, output actions are messages sent to the component services, internal actions model assignments and other operations which do not involve communications, and the transition relation models the evolution of the service. This modeling doesn’t capture explicitly data transformation within the process, since the only effect of a transition is the evolution of the process state. In [10] we have shown how this model can be extended to capture data manipulation by adding a proper knowledge base to each state in the STS. Intuitively, the knowledge base of each component service is obtained from the variables, types and functions of the service. The knowledge-level composition domain Σk is obtained by combining the knowledge bases of the component services and the knowledge base of the goal, by instantiating the input and output actions of the component services on goal variables, and by adding the private actions obtained by applying goal functions to goal variables. Each state of Σk models both the evolution of the services

The automated synthesis problem consists in generating a state transition system Σc that, once connected to Σ, satisfies the composition requirement. We now recall the definition of the state transition system describing the behavior of Σ when connected to Σc . Definition 5 (Controlled system) Let Σ = hS, S 0 , I, O, A, R, Fi and Σc = 0 hSc , Sc , Ic , Oc , A, Rc , Fc i be two state transition systems such that I = Oc and O = Ic . The state transition system Σc . Σ, describing the behaviors of system Σ when controlled by Σc , is defined as follows: Σc . Σ = hSc × S, Sc0 × S 0 , I, O, A, Rc . R, Fc × F , i where: h(sc , s), a, (s0c , s0 )i ∈ (Rc . R), if hsc , a, s0c i ∈ Rc and hs, a, s0 i ∈ R In an automated synthesis problem, we need to generate a Σc that guarantees the satisfaction of a composition requirement ρ . This is formalized by requiring that the controlled system Σc . Σ must satisfy the goal ρ, written Σc . Σ |= ρ. In [11], ρ is formalized using the E AGL E language that we already introduced in Section 2 for specifying the control flow. The definition of whether ρ is satisfied is given in terms of the executions that Σc . Σ can perform.

49

W1 , ..Wn and a data net D, modeling the data-flow composition requirements, we encode each component service Wi as a STS ΣWi and the data net D as a STS ΣD . The composition domain Σ for the automated composition problem is the synchronized product of all these STSs. Formally, Σ = ΣD k ΣW1 k .. k ΣWn . The planning goal ρ is the E AGL E formalization of the composition control-flow requirements. We enrich ρ by requiring that Σ is in an accepting state. Given the domain Σ and the planning goal ρ we can apply the approach presented in [11] to generate a controller Σc , which is such that Σc . Σ |= ρ. Once the state transition system Σc has been generated, it is translated into BPEL 4 WS to obtain the new process which implements the required composition. The translation is conceptually simple; intuitively, input actions in Σc model the receiving of a message from a component service, output actions in Σc model the sending of a message to a component service, internal actions model manipulation of data by means of expressions and assignments.

(process states) and the evolution of the data knowledge (knowledge base). The execution of a transition affects not only the states of the processes but also the knowledge base according to the data transformation performed. The planning goal ρ is the E AGL E formalization of the composition control-flow requirements. We enrich ρ by adding to the TryReach part the knowledge level data-flow requirements (knowledge base of the goal, see Example 6). Given the domain Σk described above, we can apply the approach presented in [11] and obtain a deadlock free Σc that controls Σk by satisfying the composition requirements g. Despite of the fact that the synthesized controller Σc is modelled at the knowledge level, its elementary actions model communication with the component services (sending and receiving of messages) and manipulation of goal variables; given this, it is straightforward to obtain the executable BPEL 4 WS composite service from Σc .

5

4.2 Integrating explicit data-flow requirements

Comparison of the two approaches

In this section we compare the two proposed approaches from a technical point of view, from the point of view of the performance, and for what concerns the usability. The two approaches present similar characteristics. First of all both of them extend the automated composition framework proposed in [11, 12]. Moreover, they adopt the same strategy to encode data manipulation and exchange at an abstract level in the composition domain: introducing goal variables (which model variables of the new composite BPEL 4 WS process) and encoding data-flow requirements as constraints on the operations that can be performed on goal variables. A first difference can be seen in the way they extract these variables and constraints: the knowledge-level approach obtains them by flattening the data-flow goal, while the other approach directly obtains them from the data net, where they are explicitly defined. However, the main difference lies in the way the two approaches reason on goal variables: the implicit approach encodes the knowledge on the equalities between these variables (knowledge base) in the states of the composition domain and uses this information to check whether the goal is satisfied; while the data net based approach doesn’t explicitly encode data within the composition domain (states simply model the evolution of the processes) and introduces new STSs modeling the synchronization between operations that manipulate goal variables. This difference is reflectedin the complexity of the obtained composition domain, which in the knowledge level approach is much heavier. In order to test the performance of the proposed approaches, we have conducted some experiments on problems extracted from realistic web service domains. One of these is the P&S example, which we use as a reference example throughout this paper. This is a quite simple example: the interactions among the components and the composite service are quite straight and the data-flow requirements are pretty simple. The other scenario we considered is the Virtual Travel Agency (VTA) example (for further details see [6]). This composition problem requires a high degree of interleaving between components (to achieve the goal, it is necessary to carry out interactions with all component services in an interleaved way) and both the knowledge base of the goal and the data net are much more complex (due to the number of functions and to the need of manipulating data in a complex way). The results (see Table 1) are not surprising: the knowledge level approach shows worse performances both for the model construction time (obtaining the composition domain) and composition time (synthesizing the controller and emitting the BPEL 4 WS process). This results come straight from the different encodings: the knowledge level encoding is much more

As we have seen in previous sections, a data net D of a particular composition problem specifies how messages received from the component services can be used by the new composite process to obtain outgoing 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 the component services, output actions represent messages sent by the component services and internal actions represent assignments that the composite process performs on its internal variables. We assume that, in the BPEL 4 WS specification of the composite service, a variable will exist for each connection node in D; variables associated to external connection nodes are those used by the new composite process to store received messages and to prepare the messages to be sent, while variables associated to internal connection nodes are those used to manipulate messages by means of internal functions and assignments. Then ΣD defines constraints on the possible operations that the composite process can perform on these variables. A nice feature of our approach is that this can be done compositionally, i.e., a “small”automaton can be associated to each element of the data net, and STS ΣD is obtained as the synchronized product of all these small automata. More precisely, for each output operation of a component service which is associated to some external input port in the data net we define a STS which represents the sending of the message (as an output action) and the storing of all message parts (as internal actions). Similarly, for each input operation of a component service which is associated to some external output port in the data net we define a STS which represents the storing of all message parts (as internal actions) and the reception of the message (as an input action).Finally, we define a STS for each data-flow element of the data net. These STSs have no input/ouput actions since they model manipulation of variables through assignments. Please refer to [6] for all the encoding details . The STS ΣD , modeling the data net D, is the synchronized product of all the STSs corresponding to external connection nodes and to data-flow elements of D. The synchronized product Σ1 ||Σ2 models the fact that the systems Σ1 and Σ2 evolve simultaneously on common actions and independently on actions belonging to a single system. We are ready to show how we can integrate the explicit dataflow requirements specification approach within the automated composition framework presented in [11]. Given n component services

50

P&S VTA

Knowledge Level model construction composition 4.391 sec. 0.672 sec. 29.268 sec. 21.761 sec. Table 1.

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 consequently the synthesis task is much harder. For what concerns usability, the judgment is not so straightforward: the two approaches adopt very different perspectives and each can thus be preferable depending on the particular composition scenario. Modeling data-flow composition requirements through a data net requires to explicitly link all the messages received from component services with messages sent to component services and to declare all internal connection nodes (and thus exhaustively define the composite service internal variables). Moreover in this approach component services are black boxes exporting only input and output ports: there is no way to reason about their internal data manipulation behaviors. The knowledge-level approach adopts a more abstract perspective: on the one hand it allows to leave out most implementation details (avoiding to explicitly define internal variables and functions), on the other hand it allows to reason on semantic annotations capturing the component service internal behavior (this becomes essential when dealing with autonomic web services).

6

Data Net model construction composition 2.207 sec. 0.027 sec. 2.584 sec. 0.178 sec.

are derived from business scenarios, rather than high level business goals. In [14] the authors propose a UML-based model-driven method for Web Service composition. They show how composite Web Service models can be transformed into executable models by means of UML model transformations. The weakness of UML-based approaches is that modeling complex composition scenarios is a demanding and difficult task since they require to use several different UML diagrams (e.g. activity, class, collaboration diagrams); moreover, the relationships between these diagrams do not have a clear and formal semantic. For what concerns the formal specification of the requirements that the new composite service should satisfy, most of the existing approaches specify them as reachability conditions (e.g. [8]). A remarkable exception is the work described in [11, 12, 10], on which we based our work, where the composition requirements is formalized using E AGL E [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. Mecella, ‘Automatic composition of E-Services that export their behaviour’, in Proc. ICSOC’03, (2003). [3] U. Dal Lago, M. Pistore, and P. Traverso, ‘Planning with a Language for Extended Goals’, in Proc. AAAI’02, (2002). [4] R. Hull, M. Benedikt, V. Christophides, and J. Su, ‘E-Services: A Look Behind the Curtain’, in Proc. PODS’03, (2003). [5] D. Lau and J. Mylopoulos, ‘Designing Web Services with Tropos’, in Proc. ICWS’04, (2004). [6] A. Marconi, M. Pistore, and P. Traverso, ‘Specifying Data-Flow Requirements for the Automated Composition of Web Services’, in Proc. SEFM’06, (2006). [7] S. McIlraith and S. Son, ‘Adapting Golog for Composition of Semantic Web Services’, in Proc. KR’02, (2002). [8] S. Narayanan and S. McIlraith, ‘Simulation, Verification and Automated 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 Oriented Programming’, in Proc. of the Fifth International Conference on Autonomous Agents, (2004). [10] M. Pistore, A. Marconi, P. Traverso, and P. Bertoli, ‘Automated Composition 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 Web Services by Planning in Asynchronous Domains’, in Proc. ICAPS’05, (2005). [12] M. Pistore, P. Traverso, P. Bertoli, and A.Marconi, ‘Automated Synthesis of Composite BPEL4WS Web Services’, in Proc. ICWS’05, (2005). [13] S. Ponnekanti and A. Fox, ‘SWORD: A Developer Toolkit for Web Service Composition’, in Proc. WWW’02, (2002). [14] D. Skogan, R. Gronmo, and I. Solheim, ‘Web Service Composition in UML’, in Proc. EDOC’04, (2004).

Conclusions and Related Works

In the paper we have compared two different approaches, implicit and explicit, to define data flow requirements for the automated composition of Web services and shown how they can be integrated within an existing automated composition framework. The former is based on the knowledge level automated composition approach presented in [10], while the latter uses the data-flow requirements modeling language proposed in [6]. Though the explicit modeling presents much better performances (due to the very light encoding), both of them have been shown to handle realistic composition problems. The choice of the approach to be used must be made on the basis of the specific composition problem. Several approaches have been proposed to model Web Service compositions and Web Services in general, but none of them addresses the problem of specifying data flow constraints. In the approach proposed in [13] component services are defined in terms of their inputs and outputs; given the inputs and outputs of the service, a rule is then defined which indicates which outputs can be obtained by the service given which inputs. When a developer wishes to create and deploy a new composite service, he specifies the inputs and outputs of the composite service and submits it to the system, which determines if the composite service can be realized using the existing services. This rule based approach can be adopted exclusively for modeling simple composition problems, where component services are atomic and deterministic. The methodology proposed in [5] is founded on Tropos [9], an agent-oriented software development technique that supports early and late requirements analysis, as well as architectural and detailed design. The key idea of this approach is that Web Services are designed by starting from stake-holders goals, that are then analyzed and refined into subgoals and tasks. However, the starting point for Web Service compositions are usually abstract workflows, which

51

Web Service Composition in a Temporal Action Logic 1 Laura Giordano2 and Alberto Martelli3 From several points of view the web service domain is well suited to this kind of formalization. The proposed framework provides a simple formalization of the communicative actions in terms of their effects and preconditions and the specification of an interaction protocol by means of temporal constraints. To accommodate the needs of the application domain, in which information is inherently incomplete, in Section 2 we extend the action theory defined in [9] to deal with incomplete information, by introducing epistemic modalities in the language to distinguish what is known about the social state from what is unknown. We consider the problem of composing web services, by referring to an example consisting of two services for purchasing and for shipping goods. Both services have an interaction protocol with the same structure: the customer sends a request to the service, the service replies with an offer or by saying that the service is not available, and finally , if the customer receives the offer, it may accept or refuse it. In Section 3 we show how to specify such interaction protocols, by adopting a social approach. Communicative actions, such as offer or accept, are modeled in terms of their effects on the social state (action laws). A protocol will be specified by putting constraints on the executability of actions (precondition laws), and by introducing temporal constraints specifying fulfillment of commitments. Several verification problems concerning properties of the web services can be modelled as satisfiability and validity problems in the logic. We make use of an automata based approach to solve these problems and, in particular, we work on the B¨uchi automaton which can be extracted from the logical specification of the protocol. In Section 4 we define the service composition problem as a planning problem, whose solution requires to build a conditional plan, allowing the interaction with the component services. The plan can be obtained from the B¨uchi automaton derived from the logical specification of the protocol. We will also briefly address other related problems such as building a new service that is able to manage the interactions between the customer and the two services, or proving the correctness of a given service implementation with respect to the specification of the interaction protocols.

Abstract. The paper presents an approach to reasoning about web service composition using a temporal action theory. Web services are described by specifying their interaction protocols in an action theory based on a dynamic linear time temporal logic. The proposed framework provides a simple formalization of the communicative actions in terms of their effects and preconditions and the specification of an interaction protocol by means of temporal constraints. We adopt a social approach to agent communication, where the action effects can be described in terms of changes in the social state, and protocols in terms of creation and satisfaction of commitments among agents. We show how the problem of web service composition can be formulated in the action theory as a planning problem, and we show how it can be solved using an automata based approach.

1

Introduction

One of the central issues in the field of multi-agent systems concerns the specification of conversation policies (or interaction protocols), which govern the communication between software agents in an agent communication language (ACL) [4]. To allow for the flexibility needed in agent communication [14, 10] new approaches have been proposed, which overcome the limitations of the traditional transition net approach, in which the specification of interaction protocols is done by making use of finite state machines. A particularly promising approach to agent communication, first proposed by Singh [22], is the social approach [5, 11, 14]. In the social approach, communicative actions affect the “socialstate” of the system, rather than the internal (mental) states of the agents. The social state records social facts, like the permissions and the commitments of the agents. In this paper we adopt a social approach in the specification of the interactions among Web services and, in particular, we address the problem of service composition[23], where the objective is “to describe, simulate, compose, test, and verify compositions of Web services”[15]. In our proposal Web services are described by specifying their interaction protocols in an action theory based on a dynamic linear time temporal logic. Such a logic has been used in [7, 9] to provide the specification of interaction protocols among agents and to allow the verification of protocol properties as well as the verification of the compliance of a set of communicating agents with a protocol.

2

The action theory

In this section we describe the action theory that is used in the specification of the services. We first introduce the temporal logic on which our action theory is based and its epistemic extension.

1

This research has been partially supported by the project MIUR PRIN 2005 “Specification and verification of agent interaction protocols” 2 Dipartimento di Informatica, Universit` a del Piemonte Orientale, Alessandria - email: [email protected] 3 Dipartimento di Informatica, Universit` a di Torino, Torino - email: [email protected]

2.1

Dynamic Linear Time Temporal Logic

In this section we brieflydefine the syntax and semantics of DLTL as introduced in [12]. In such a linear time temporal logic the next state

52

A is a set of agents, to represent the knowledge shared by agents in A. Groups of agents acquire knowledge about social facts when they interact by exchanging communicative actions. The modal operators Ki and KA are both of type KD. They are normal modalities ruled by the axiom schema Kϕ → ¬K¬ϕ (seriality). Following the solution proposed in [1], we restrict epistemic modalities to be used in front of literals, and we neither allow nested applications of epistemic modalities nor we allow epistemic modalities to be applied to boolean combination of literals. Hence, though logic KD45 is usually adopted to represent belief operators, here we do not need to add the positive and negative introspection axioms. The relations between the modalities Ki and KA are ruled by the following interaction axiom schema: KA ϕ → Ki ϕ, where i ∈ A, meaning that what is knowledge of a group of agents is also knowledge of each single agent in the group. As usual, for each modality Ki (respectively, KA ) we introduce the modality Mi (resp. MA ), which is defined as the dual ofKi , i.e. Mi ϕ is ¬Ki ¬ϕ.

modality is indexed by actions. Moreover, (and this is the extension to LTL) the until operator is indexed by programs in Propositional Dynamic Logic (PDL). Let Σ be a finite non-empty alphabet. The members of Σ are actions. Let Σ∗ and Σω be the set of finite and infinite words onΣ, where ω = {0, 1, 2, . . .}. Let Σ∞ =Σ∗ ∪ Σω . We denote by σ, σ 0 the words over Σω and by τ, τ 0 the words over Σ∗ . Moreover, we denote by ≤ the usual prefix ordering overΣ∗ and, for u ∈ Σ∞ , we denote by prf(u) the set of finite prefix es ofu. We define the set of programs (regular expressions)P rg(Σ) generated by Σ as follows: P rg(Σ) ::= a | π1 + π2 | π1 ; π2 | π ∗ where a ∈ Σ and π1 , π2 , π range over P rg(Σ). A set of finite words is associated with each program by the usual mapping [[]] : ∗ P rg(Σ) → 2Σ . Let P = {p1 , p2 , . . .} be a countable set of atomic propositions containing > and ⊥. We define:

2.3 Domain descriptions

DLTL(Σ) ::= p | ¬α | α ∨ β | αU π β

The social state of the protocol, which describes the stage of execution of the protocol from the point of view of the different agents, is described by a set of atomic properties called fluents, whose epistemic value in a state may change with the execution of communicative actions. Let P be a set of atomic propositions, the fluent names . A fluent literal l is a fluentname f or its negation ¬f . We introduce the notion of epistemic fluentliteral to be a modal atom Kl or its negation ¬Kl, where l is a fluentliteral and K is an epistemic operator Ki or KA . We will denote by Lit the set of all epistemic literals. An epistemic state (or, simply, a state) is defined as a complete5 and consistent set of epistemic fluent literals , and it provides, for each agent i (respectively for each group of agents A) a three-valued interpretation in which each literal l is true when Ki l holds, false when Ki ¬l holds, and undefined when both ¬Ki l and ¬Ki ¬l hold. Observe that, given the property of seriality, consistency guarantees that a state cannot contain both Kf and K¬f , for some epistemic modality K and fluent f . In fact, from Kf it follows by seriality that ¬K¬f , which is inconsistent with K¬f . In the following we extend the action theory defined in [9] to accommodate epistemic literals. A domain description D is defined as a tuple(Π, C), where Π is a set of (epistemic) action laws and causal laws, and C is a set of constraints. The action laws in Π have the form:

where p ∈ P and α, β range over DLTL(Σ). A model of DLTL(Σ) is a pair M = (σ, V ) where σ ∈ Σω and V : prf (σ) → 2P is a valuation function. Given a model M = (σ, V ), a finite wordτ ∈ prf (σ) and a formula α, the satisfiability of a formula α at τ in M , written M, τ |= α, is defined as follows (we omit the standard definition for the boolean connectives): • M, τ |= p iff p ∈ V (τ ); • M, τ |= αU π β iff there exists τ 0 ∈ [[π]] such that τ τ 0 ∈ prf (σ) and M, τ τ 0 |= β. Moreover, for every τ 00 such that ε ≤ τ 00 < τ 04 , M, τ τ 00 |= α. A formula α is satisfiable iff there is a model M = (σ, V ) and a finite wordτ ∈ prf (σ) such that M, τ |= α. The formula αU π β is true at τ if “α until β” is true on a finite stretch of behavior which is in the linear time behavior of the program π. The derived modalities hπi and [π] can be defined as follows: hπiα ≡ >U π α and [π]α ≡ ¬hπi¬α. Furthermore, if we let Σ = {a1 , . . . , an }, the U , ° (next), W 3 and 2 operators of LTL can be defined as follows: °α ≡ a∈Σ haiα, ∗ ∗ αU β ≡ αU Σ β, 3α ≡ >U α, 2α ≡ ¬3¬α, where, in U Σ , Σ is taken to be a shorthand for the program a1 + . . . + an . Hence both LTL(Σ) and PDL are fragments of DLTL(Σ). As shown in [12], DLTL(Σ) is strictly more expressive than LTL(Σ). The satisfiability and validity problems for DLTL are PSPACE complete problems [12].

2(Kα → [a]Kl)

(1)

2(Mα → [a]Ml)

(2)

In the following we need to describe the effects of communicative actions on the social state of the agents. In particular, we want to represent the fact that each agent can see only part of the social state as it is only aware of some of the communicative actions in the conversation (namely those it is involved in as a sender or as a receiver). For this reason, we introduce knowledge operators to describe the knowledge of each agent as well as the knowledge shared by groups of agents. More precisely, we introduce a modal operator Ki to represent the knowledge of agent i and the modal operator KA , where

where a ∈ Σ and Kα is a conjunction of epistemic fluents of the form Kl1 ∧ . . . ∧ Kln , and Mα is a conjunction of epistemic fluents of the form Ml1 ∧ . . . ∧ Mln . The meaning of (1) is that executing action a in a state where l1 , . . . , ln are known (to be true) causes l to become known, i.e. it causes the effect Kl to hold. As an example the law 2(Kf ragile → [a]Kbroken) means that, after executing the action of dropping a glass the glass is known to be broken, if the action is executed in a state in which the glass is known to be fragile. (2) is necessary in order to deal with ignorance about preconditions of the action a. It means that the execution of a may affect the beliefs about

4

5

2.2 Epistemic modalities

We define τ ≤ τ 0 iff ∃τ 00 such that τ τ 00 = τ 0 . Moreover, τ < τ 0 iff τ ≤ τ 0 and τ 6= τ 0 .

53

A set S of epistemic fluentliterals is complete if, for all literals l and epistemic operators K, either Kl ∈ S or ¬Kl ∈ S.

2(hai> → ([a]K¬f ↔ V W ( j (Kβj ∧ [a]Kδj )) ∨ (K¬f ∧ i (K¬αi ∨ ¬[a]Mγi )))).

l, when executed in a state in which the preconditions are considered to be possible. When the preconditions of a are unknown, this law allows to conclude that the effects of a are unknown as well. 2(Mf ragile → [a]Mbroken) means that, after executing the action of dropping a glass, the glass may be broken, if the action is executed in a state in which the glass may be fragile (i.e. K¬f ragile does not hold). The causal laws in Π have the form: 2((Kα ∧ °Kβ) → °Kl)

(3)

2((Mα ∧ °Mβ) → °Ml)

(4)

These laws say that a fluent Kf (K¬f ) holds either as (direct or indirect) effect of the execution of some action a, or by persistency, since Kf (K¬f ) held in the state before the occurrence of a and its negation is not a result of a. Observe that the two frame axioms above also determine the values in a state for [a]Mf and for [a]M¬f . As a difference with [9], we do not distinguish between frame and non-frame fluents in a domain description and in the following we assume that all epistemic fluentsare frame, that is, they are fluentsto which the law of inertia applies. The kind of non-determinism that we allow here is on the choice of the actions to be executed, which can be represented by the choice construct of regular programs.

where a ∈ Σ and Kα is a conjunction of epistemic fluents of the form Kl1 ∧ . . . ∧ Kln , Kβ is a conjunction of epistemic fluentsof the form Kln+1 ∧ . . . ∧ Klm , and similarly for Mα and Mβ. The meaning of (3) is that if l1 , . . . , ln are known in a state and ln+1 , . . . , lm are known in the next state, then l is also known in the next state. Such laws are intended to expresses “causal”dependencies among fluents.Causal law (4) is defined similarly. The constraints in C are, in general, arbitrary temporal formulas of DLTL. Constraints put restrictions on the possible correct behaviors of a protocol. The kind of constraints we will use in the specification of a protocol include the observations on the value of epistemic fluent literals in the initial state and the precondition laws. The initial state Init is a (possibly incomplete) set of epistemic literals, which is made complete by adding ¬Kl to Init when Kl ∈ 6 Init. The precondition laws have the form: 2(α → [a]⊥), where a ∈ Σ and α is an arbitrary non-temporal formula containing a boolean combination of epistemic literals. The meaning is that the execution of an action a is not possible if α holds (i.e. there is no resulting state following the execution of a if α holds). Note that, when there is no precondition law for an action, the action is executable in all states. The action theory described above relies on a solution to the frame problem similar to the one described in [9]. A completion construction is defined which, given a domain description, introduces frame axioms for all the frame fluents in the style of the successor state axioms introduced by Reiter [20] in the context of the situation calculus. The completion construction is applied only to the action laws and causal laws in Π and not to the constraints. The value of each fluentpersists from a state to the next one unless its change is caused by the execution of an action as an immediate effect (effect of the action laws) or an indirect effect (effect of the causal laws). We call Comp(Π) the completion of a set of laws Π. Let Π be a set of action laws and causal laws. Both action laws and causal laws can be equivalently written in the following normalized form (where in action laws the second conjunct is omitted):

3

Protocol specification

In the social approach [22, 24] an interaction protocol is specified by describing the effects of communicative actions on the social state, and by specifying the permissions and the commitments that arise as a result of the current conversation state. These effects, including the creation of new commitments, can be expressed by means of action laws. The action theory introduced above will be used for modelling communicative actions and for describing the social behavior of agents in a multi-agent system. In defining protocols, communicative actions will be denoted by action name(s,r), where s is the sender and r is the receiver. In particular, two special actions are introduced for each protocol Pn: begin P n(s, r) and end P n(s, r), which are supposed to start and to finish eachrun of the protocol. For each protocol, we introduce a special fluent P n (where P n is the “protocol name”) which has to be true during the whole execution of the protocol: P n is made true by the action begin P n(s, r) and it is made false by the action end P n(s, r).

3.1 Commitments and permissions Among the most significant proposals to use commitments in the specification of protocols (or more generally, in agent communication) are those by Singh [22], Guerin and Pitt [11], Colombetti [5]. In order to handle commitments and their behavior during runs of a protocol P n, we introduce two special fluents.One represents base-level commitments and has the form C(P n, i, j, α) meaning that agent i is committed to agent j to bring about α, where α is an arbitrary non temporal formula not containing commitment fluents. The second commitment fluentmodels conditional commitments and has the form CC(P n, i, j, β, α) meaning that in protocol P n the agent i is committed to agent j to bring about α, if the condition β is brought about. Commitments are created as effects of the execution of communicative actions in the protocol and they are “discharged” when they have been fulfilled. A commitmentC(P n, i, j, α), created at a given state of a run, is regarded to be fulfilled in the run if there is a later state in the run in which α holds. We introduce the following causal laws for automatically discharging fulfilled commitments6 :

2(hai> → ((Kα ∧ [a]Kβ) → [a]Kl)) 2(hai> → ((Mα ∧ [a]Mβ) → [a]Ml)). The action laws and causal laws for a fluent f in Π can then have the following forms: 2(hai> → (Kαi ∧ [a]Kγi → [a]Kf )) 2(hai> → (Kβj ∧ [a]Kδj → [a]K¬f )) 2(hai> → (Mαi ∧ [a]Mγi → [a]Mf )) 2(hai> → (Mβj ∧ [a]Mδj → [a]M¬f )) We define the completion of Π as the set of formulas Comp(Π) containing, for all actions a and fluents f , the following axioms:

(i) 2(°α → °Ki,j (¬C(P n, i, j, α))) (ii)2((Ki,j (CC(P n, i, j, β, α)) ∧ °β) → °Ki,j (C(P n, i, j, α)))

2(hai> → ([a]Kf ↔ V W ( i (Kαi ∧ [a]Kγi )) ∨ (Kf ∧ j (K¬βj ∨ ¬[a]Mδj ))))

6

54

We omit the three similar rules with K replaced by M

(iii)2((Ki,j (CC(P n, i, j, β, α)) ∧ °β) → °Ki,j (¬CC(P n, i, j, β, α)))

For instance, the first conditional commitment says that the producer is committed to send an offer, or to say that the product is not available, if a request for the product has been made. We can now give the action rules for the action of the protocol. We assume all fluents to be undefined in the initial state (i.e., for each fluent f , for each epistemic modality K, ¬Kf and ¬K¬f hold in the initial state), except for fluent P u which will be known to be false. The execution of begin P u(C, P ) and end P u(C, P ) will have the following effects:

A commitment to bring about α is considered fulfilled and is discharged (i) as soon as α holds. A conditional commitment CC(P n, i, j, β, α) becomes a base-level commitment C(P n, i, j, α) when β has been brought about (ii) and the conditional commitment is discharged (iii). We can express the condition that a commitment C(P n, i, j, α) has to be fulfilled before the “run”of the protocol is finished by the following fulfillment constraint:

2[begin P u(C, P )]KC,P (P u) ∧ KC,P (C(P u, C, P, KC,P (requested))) ∧ w KC,P (CC(P u, P, C, KC,P (requested), KC,P (offered )))∧ w KC,P (CC(P u, C, P, KC,P (offered ), KC ,P (accepted ))) 2[end P u(C, P )]KC,P (¬P u)

2(Ki,j (C(P n, i, j, α)) → P n U α) We will call Comi the set of constraints of this kind for all commitments of agent i. Comi states that agent i will fulfill all the commitments of which it is the debtor. At each stage of the protocol only some of the messages can be sent by the participants, depending on the social state of the conversation. Permissions allow to determine which messages are allowed at a certain stage of the protocol. The permissions to execute communicative actions in each state are determined by social facts. We represent them by precondition laws. Preconditions on the execution of action a can be expressed as: 2(α → [a]⊥) meaning that action a cannot be executed in a state if α holds in that state. We call P ermi (permissions of agent i) the set of all the precondition laws of the protocol pertaining to the actions of which agent i is the sender.

After starting the protocol, the customer is committed to make a request, and the conditional commitments are created. The action laws for the remaining actions are the following: 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[ref use(C, P )]KC,P (¬accepted) We can now give the preconditions for the actions of the protocol. 2(¬KC,P (¬P u) → [begin P u(C, P )]⊥) 2((¬KC,P (P u) ∨ KC,P (requested)) → [request(C, P )]⊥) w 2((¬KC,P (P u) ∨ ¬KC,P (requested) ∨ KC,P (offered )) → [offer (P , C )]⊥) w (offered )) → 2((¬KC,P (P u) ∨ ¬KC,P (requested) ∨ KC,P [not avail(P, C)]⊥) w 2((¬KC,P (P u) ∨ ¬KC,P (offered ) ∨ KC ,P (accepted )) → [accept(C, P )]⊥) w 2((¬KC,P (P u) ∨ ¬KC,P (offered ) ∨ KC ,P (accepted )) → [ref use(C, P )]⊥) 2(¬KC,P (P u) → [end P u(C, P )]⊥)

3.2 An example Let us consider as an example a service for purchasing a good. There are two roles: A customer, denoted by C, and a producer, denoted by P. The communicative action of the protocol are: request(C, P ). meaning that the customer sends a request for a product, offer (P , C ) and not avail(P, C), the producer sends an offer or says that the product is not available, accept(C, P ) and ref use(C, P ), the customer accepts or refuses the offer. Furthermore, as pointed out before, there will be the actions begin P u(C, P ) and end P u(C, P ) to start and finish the protocol. As mentioned before, the social state will contain only epistemic fluents.We denote the social knowledge by KC,P , to mean that the knowledge is shared by C and P . The social state will contain the following fluents,which describe the protocol in an abstract way: requested, the product has been requested, offered , the product is available and an offer has been sent (we assume that ¬offered means that the product is not available), accepted, the offer has been accepted. The fluent P u means that the protocol is being executed. Furthermore, we introduce some base-level commitments (to simw plify the notation, in the following we will use KC,P (f ) as a shorthand of the formula KC,P (f ) ∨ KC,P (¬f )):

For instance, action request(C, P ) cannot be executed if it is not known that the protocol has been started or if it is known that the request has already been achieved (to avoid repeating the action).

3.3 Protocols and their runs A protocol is specified by giving a domain description, defined as follows: Definition 1 A domain description D is a pair (Π, C) where • Π is the set of the action and causal laws containing: – the laws describing the effects of each communicative actions on the social state; – the causal laws defining the commitment rules.

V

C(P u, C, P, KC,P (requested)) w (offered )) C(P u, P, C, KC,P w C(P u, C, P, KC,P (accepted))

• C = Init ∧ i (P ermi ∧ Comi ) is the conjunction of the constraints on the initial state of the protocol and the permissions P ermi and the commitments Comi of all the agents i.

We also need the following conditional commitments:

Given a domain description D, we denote by Comp(D), the completed domain description, the set of formulas:

w (offered )) CC(P u, P, C, KC,P (requested), KC,P w CC(P u, C, P, KC,P (offered ), KC ,P (accepted ))

(Comp(Π) ∧ Init ∧

^ i

55

(P ermi ∧ Comi ))

Logic, based on the use of B¨uchi automata. We recall that a B¨uchi automaton has the same structure as a traditional finite state automaton, with the difference that it accepts infinite words. More precisely a B¨uchi automaton over an alphabet Σ is a tuple B = (Q, →, Qin , F ) where:

Definition 2 Given the specification of a protocol by a domain description D, the runs of the system according the protocol are exactly the models of Comp(D). Note that protocol “runs”are always finite, while the logic DLTL is characterized by infinite models.To take this into account, we assume that each domain description of a protocol will be suitably extended with an action noop which does nothing and which can be executed only after termination of the protocol, so as to allow a computation to go on forever after termination of the protocol. Note that the domain description specifying a protocol contains information related to the semantics of the actions, and information related to the “control”of the protocol, i.e. the allowed sequences of actions. For instance, the precondition rule of action offer (P , C ) specifies both that this action needs a request to be executed, and that it can be executed only once in the protocol. The latter precondition depends on the protocol rather than on the semantics of the action. In the logic DLTL the control of a rigid protocol like this one could be easily represented by means of a regular program. In our example we might define the following regular programπ:

• Q is a finite nonempty set of states; • →⊆ Q × Σ × Q is a transition relation; • Qin ⊆ Q is the set of initial states; • F ⊆ Q is a set of accepting states. Let σ ∈ Σω . Then a run of B over σ is a map ρ : prf (σ) → Q such that: • ρ(ε) ∈ Qin a • ρ(τ ) → ρ(τ a) for each τ a ∈ prf (σ) The run ρ is accepting iff inf(ρ) ∩ F 6= ∅, where inf(ρ) ⊆ Q is given by q ∈ inf (ρ) iff ρ(τ ) = q for infinitely manyτ ∈ prf (σ). As described in [12], the satisfiability problem for DLTL can be solved in deterministic exponential time, as for LTL, by constructing for each formula α ∈ DLT L(Σ) a B¨uchi automaton Bα such that the language of ω-words accepted by Bα is non-empty if and only if α is satisfiable. A more efficient approach for constructing a B¨uchi automaton from a DLTL formula making use of a tableau-based algorithm has been proposed in [6]. Given a formula ϕ, the algorithm builds a graph G(ϕ) whose nodes are labelled by sets of formulas. States and transitions of the B¨uchi automaton correspond to nodes and arcs of the graph. As for LTL, the number of states of the automaton is, in the worst case, exponential in the size if the input formula, but in practice it is much smaller. Since the nodes of the graph G(ϕ) are labeled by sets of formulas, what we actually obtain by the construction is a labeled B¨uchi automaton, which can be defined by adding to the above definition a labeling function L : S → 2Lit , where Lit is the set of all epistemic literals. It is easy to obtain from an accepting run of the automaton a set of models of the given formula. It is sufficient to complete the label of each state in a consistent way. The validity of a formula α can be verified by constructing the B¨uchi automaton B¬α for ¬α: if the language accepted by B¬α is empty, then α is valid, whereas any infinite word accepted by B¬α provides a counterexample to the validity of α. For instance, given a completed domain description

begin P u(C, P ); request(C, P ); ((offer (P , C ); (accept(C , P ) + refuse(C , P ))) + not avail (P , C )); end Pu(C , P ) and add a constraint hπi> requiring that each model must begin with an execution of π. However in this paper we do not use this formulation because it has the drawbacks that it requires the use of the product version of the temporal logic [9] to deal with the composition of protocols. Once the interface of a service has been defined by specifying its protocol, several kinds of verification can be performed on it as, for instance, the verification of services compliance with the protocol at runtime, the verification of properties of the protocol and the verification that a given implemented service, whose behavior is known, is compliant with the protocol. The verification that the interaction protocol has the property ϕ amounts to show that the formula (Comp(Π) ∧ Init ∧

^

(P ermi ∧ Comi )) → ϕ,

(5)

i

is valid, that is that all the admitted runs have the property ϕ. Verifying that the a set services are compliant with a given interaction protocol at runtime, given the history τ = a1 , . . . , an describing the interactions of the services, amounts to check if there is a run of the protocol containing that sequence of communications. This can be done by verifying the satisfiability of the formula (Comp(Π) ∧Init ∧

^

(Comp(Π) ∧ Init ∧

V

i

(P ermi ∧ Comi ))

specifying a protocol, we can construct the corresponding labeled B¨uchi automaton, such that all runs accepted by the automaton represent runs of the protocol. We will show now how we can take advantage of the structure of the problems considered in this paper to optimize the construction of the B¨uchi automaton. We can partition the above domain description into two formulas

(P ermi ∧ Comi ))∧ < a1 ; a2 ; . . . ; an > >

i

where i ranges on all the services involved in the protocol. Finally, the problem of verifying that a service, whose actual behavior is given, is compliant with a given interaction protocol, can be modelled as a validity problem, assuming that the abstract description of the service can be given by means of a regular program. For an example and the detailed description of this verification task we refer to [7].

α=V (Comp(Π) ∧ Init ∧ β = i Comi

V

i

P ermi )

where α contains the description of the initial state, preconditions and effects of the actions, and β contains temporal formulas specifying commitment fulfillment. The B¨uchi automaton for the whole formula can be constructed by building the two B¨uchi automata corresponding to α and β and by making their synchronous product. The B¨uchi automaton for β can

3.4 Reasoning about protocols using automata Verification and satisfiability problems can be solved by extending the standard approach for verification of Linear Time Temporal

56

be constructed with the general algorithm mentioned above. Instead, the B¨uchi automaton corresponding to α can be easily obtained by means of a more efficient technique, exploiting the fact that in our action theory we assume to have complete states and deterministic actions. In fact, we can obtain from the domain description a function next statea (S), for each action a, for transforming a state to the next one, and then build the automaton by repeatedly applying these functions to all states where the preconditions of the action hold, starting from the initial state. The approach we have described here is similar to the model checking techniques which are used to prove properties of programs. For this reason we will sometimes call model automaton the automaton obtained from α. The main difference however is that in the standard model checking approach, the model is given as a transition system and only the properties to be proved are expressed in a temporal logic. Here instead we use a uniform language to express both the action theory and its properties, and the construction outlined above is just an optimization of the general algorithm for obtaining an automaton from a temporal formula. An advantage of this approach is that we can specify a protocol by mixing action rules and preconditions with temporal properties such as the commitment rules.

We assume that, if a protocol contains a point of choice among different communicative actions, the sender of these actions can choose freely which one to execute, and, on the other hand, the receiver cannot make any assumption on which of the actions it will receive. Therefore, from the viewpoint of the receiver, that point of choice is a point of nondeterminism to care about. For instance, the customer cannot know whether the service P u will reply with offer Pu or not avail Pu after receiving the request. Therefore the customer cannot simply reason an a single choice of action, but he will have to consider all possible choices of the two services, thus obtaining alternative runs, corresponding to a conditional plan. On the other hand, the customer has not to care about his own choices. An example of conditional plan is the following7 begin Pu; request Pu; (offer Pu; begin protocol Sh; request Sh; (offer Sh; accept Pu; accept Sh; end Pu; end Sh + not avail Sh; refuse Pu; end Pu; end Sh)) + (not avail Pu; end Pu) This plan is represented as a regular program, where, in particular, “+”is the choice operator. The first step for obtaining aconditional plan consists in building the B¨uchi automaton obtained from the domain description DP S and the constraints Constr. As we want to reason about the executions of the protocol satisfying the constraints, from the composed domain description DP S we can compute the next state function defining the state transitions of the model automaton of the composed protocol. The synchronous product of such an automaton with the B¨uchi automaton BConstr for the constraint V formula Constr (which also includes the fulfilment constraints i Comi ) is then computed. This product can either be done on the fly while building the model automaton or it can be done after the model automata has been completely built. While performing the product operation a special attention has to be devoted to avoid cutting out actions which can be received by the customer (such as offer Sh and not avail Sh) which, though allowed by the protocol, might not satisfy the constraints. In fact, since we are using a linear time temporal logic, the constraints in Constr can only express properties dealing with a single run. For instance, the run begin Pu; request Pu; offer Pu; accept Pu; begin Sh; request Sh; offer Sh; accept Sh; end Pu; end Sh is correct with respect to the above constraints, since both offers are accepted. However, assume that the customer chooses to execute this plan, and, after executing action request Sh, the shipping service replies with not avail Sh. At this point there is no other way of continuing the execution, since the customer has already accepted the offer by the producer, while it should have refused it. If in a state s of the model automaton a set of “receive”actions are possible, all the states s0 which are obtained from s in the product automaton must satisfy the condition that all the “receive” actions possible in s are also possible in s0 . If this happens to be false due to missing transitions in the constraint automaton, the resulting state in the product automaton is kept to be a dangling state (a state with no outgoing edges). The intuition is that such a state represents a failure state as it cannot deal with all the possible “receive” actions occurring in the corresponding state of the protocol. To take this into account, we will mark as AND states those states of the model automaton whose outgoing arcs are labeled with actions whose sender is one of the services, such as offer Pu or

4 Composing protocols Assume now that we have a service Sh for shipping goods, and that the customer wants to reason on the composition of the producer service of the previous section and of this service. For simplicity we assume that the protocol of the shipping service is the same as that of producer service. To distinguish the two protocols we will add the suffix Pu or Sh to their actions and fluents,while the role of the shipper will be denoted by S. The Sh protocol rules the interactions between a customer C and a shipper S. The domain description DP S of the composed service can be obtained by taking the union of the sets of formulas specifying the two protocols: DP S = DP u ∪ DSh . Since we want to reason from the side of the customer, we will replace the epistemic operators KC,P and KC,S with KC , representing the knowledge of the customer. Thus the runs of the composed service P S are given by the interleaving of all runs of the two protocols. The aim of the customer is to extract from the domain description of P S a plan allowing it to interact with the two services. The goal of the plan will be specified by means of a set of constraints Constr which will take into account the properties of the composed service. For instance, the customer cannot request an offer to the shipping service until it has not received an offer from the producer. This can be easily expressed by adding a new precondition to the action request Sh(C, S): 2(¬KC (offered Pu) → [request Sh(C , S )]⊥) Other constraint cannot be easily expressed by means of preconditions, since they involve more “global”properties of a run. For instance we expect that the customer cannot accept only one of the offers of the two services. This property can be expressed by the following formula 3haccept P u(C, P )i ↔ 3haccept Sh(C, S)i stating that the customer must accept both offers or none of them. Then, the specification of the interaction protocol of the composed service is given by DP S ∪Constr, from which the customer will extract the plan. To do this, however, we must first discuss an important aspect of the protocol, i.e. the different kinds of nondeterminism involved.

7

57

We omit sender and receiver of communicative actions.

municative actions of the component protocols. However, in general, the customer should be able to use “private” actions to reason about the information received from the services and to decide what action to execute. Since the information sent by the services will be available only at runtime, such an action should be considered as a nondeterministic action at planning time. We might easily extend our approach to this case by extending the specification of the composed services with “private” actions and fluentsof the customer. The approach described in this section can be applied to the more general problem of building a new service that is able to interact directly with the customer through a suitable protocol [19]. The first step is to put together the three protocols describing the interactions with the two services and with the customer. The next step is to add suitable constraints similar to the ones given above. For instance we may state that the offer of each of the two services can be accepted if and only if the customer accepts them:

not avail Pu8 . A conditional plan can then be obtained by searching the product automaton with a forward-chaining algorithm which considers all AND states as branching points of the plan. The complexity of this algorithm depends on the way it is implemented, in particular on the possibility of keeping in memory all states of the product automaton. If the algorithm does not remember the states it visits, except for those on the search stack, then the complexity will be exponential in the size of the automaton. On the other hand, if the product automaton is given, the search for the conditional plan can be done by making use of faster algorithms, so that the problem of finding a conditional plan can be solved in polynomial time in the size of the graph. In fact a depth-first search algorithm can try to build the conditional plan by visiting the graph without expanding again a node which has already been visited. For the application under consideration, the problem is further simplified by the fact that web services are always assumed to terminate, and thus accepting runs always contain finite sequences of actions different from the noop action, followed by a sequence of noop actions ending in an acceptance cycle. In the case the complete product automaton is given, we might adopt a different approach to the construction of a conditional plan, consisting in “pruning”once for all the automaton by removing all arcs which do not lead to an accepting state, and all AND states for which there is some outgoing arc not leading to an accepting state. This can be achieved by starting from the accepting states, and by propagating backwards the information on the states for which a solution exists. In this way we are guaranteed that, if there is a run σ1 ; offer Sh; σ2 , where σ1 and σ2 are sequences of actions, there must also be a run σ1 ; not avail Sh; σ3 , for some sequence of actions σ3 . Therefore the customer can execute the first partσ1 of the run, being sure that it will be able to continue with run σ3 if the shipping service replies with not avail Sh. In other words, the customer will be able to act by first extracting a linear plan, and begin executing it. If, at some step, one of the services executes an action different from the one contained in the plan, the customer can build a new plan originating from the current state, and restart executing it. In the construction of the conditional plan, we have taken into account only the nondeterministic actions of the two services. However there are some choices regarding the actions of the customer, such as accept Pu or refuse Pu, that cannot be made at planning time. These nondeterministic choices can also be considered in a conditional plan. In our example we might have the following conditional plan

(3haccept P ui ↔ 3haccept Cui) ∧ (3haccept Shi ↔ 3haccept Cui) where the suffix Cu refers to the interaction protocol of the customer. We can then proceed as before by building the B¨uchi automaton from the composed protocol and extracting from it a conditional plan. This plan can be considered as a specification of the (abstract) behavior of the new service. As a final remark, a different problem that can be tackled in this formalism, if the specification of the new service is given, is that of verifying that the new service can indeed be obtained by composing the component services. This requires to verify that, in every run satisfying the action specification as well as the new protocol specification, all the permissions and commitments of the component services are satisfied. This kind of verification requires a validity check. We omit the detailed specification of this task for lack of space.

5 Conclusions and related work In this paper we have presented an approach for the specification and verification of interaction protocols in a temporal logic (DLTL). Our approach provides a unified framework for describing different aspects of multi-agent systems. Programs can be expressed as regular expressions, (communicative) actions can be specified by means of action and precondition laws, social facts can be specified by means of commitments whose dynamics is ruled by causal laws, and temporal properties can be expressed by means of temporal formulas. To deal with incomplete information, we have introduced epistemic modalities in the language, to distinguish what is known about the social state from what is unknown. Various verification problems can be formalized as satisfiability and validity problems in DLTL, and they can be solved by developing automata-based model checking techniques. Our proposal is based on a social approach to agent communication, which allows a high level specification of the protocol and does not require a rigid specification of the correct action sequences. For this reason the approach appears to be well suited for protocol composition, and, in particular, to reason about composition of web services. As a first step in this direction, in [8] we have addressed the problem of combining two protocols to define a new more specialized protocol. Here we have shown that service composition can be modeled by taking the formulas giving the domain descriptions of the services, by adding to them suitable temporal constraints, and translating the set of formulas into a B¨uchi automaton from which a (conditional) plan can be obtained.

begin Pu; request Pu; (offer Pu; begin protocol Sh; request Sh; (offer Sh; (accept Pu; accept Sh; end Pu; end Sh + refuse Pu; refuse Sh; end Pu; end Sh) + not avail Sh; refuse Pu; end Pu; end Sh)) + (not avail Pu; end Pu) Note that, in the case of nondeterministic actions of the customer, we are not imposing all choices to be present in the conditional plan, as we did for the actions of the other participants, because some choices might not be possible due to the constraints. For instance, after accept Pu the customer must necessarily execute accept Sh. Up to now the kind of reasoning performed on composed protocols has taken into account only the “public”actions, i.e. the com8

For simplicity, we assume that there is no state whose outgoing arcs are labeled with actions sent and received by the same agent.

58

The proposal of representing states as sets of epistemic fluentliterals is based on [1], which presents a modal approach for reasoning about dynamic domains in a logic programming setting. A similar “knowledge-based” approach has been used to define the PKS planner, allowing to plan under conditions of incomplete knowledge and sensing [16]. PKS generalizes the STRIPS approach, by representing a state as a set of databases that model the agent’s knowledge, and action effects as updates to these databases. The problem of the automated composition of web services by planning at the “knowledge level” is addressed in [18]. Web services are described in standard process modeling and execution languages, like BPEL 4 WS, and then automatically translated into a planning domain that models the interactions among services at the knowledge level. The planning technique [19] consists in the following steps. First construct a parallel state transition system that combines the given services in a planning domain. The next step consists in formalizing the requirements for the composite service as a goal in a specific language which allows to express extended goals [3]. Finally the planner generates a plan that is translated into a state transition system and into a concrete BPEL 4 WS process. The planning problem is solved by making use of the state of the art planner MBP. The approach to web service composition presented in this paper has analogies with the one presented in [18], in particular with respect to the sequence of steps performed to build the plan. As we have already pointed out, our approach based on DLTL provides a framework, where different aspects such as action theories, protocols and their properties can be expressed in a uniform way as DLTL formulas. A further advantage is that DLTL formulas can be translated into B¨uchi automata, from which it is easy to extract runs and plans. In [2] the problem of automatic service composition is addressed assuming that a set of available services (whose behavior is represented by finite state transition systems) is given together with a possibly incomplete specification of the sequences of actions that the client would like to realize. The problem of checking the existence of a composition is reduced to the problem of checking the satisfiability of a PDL formula. This provides an EXPTIME complexity upper bound. As a difference with [2], in our approach client requirements are specified by providing a set of conditions that the target service must satisfy. The composition problem considered in [2] is a generalization of the verification problem we have addressed at the end of section 4 to the case when the protocol of the target service is underspecified and the component e-services that will provide the services required by the client are not known. The extension of our approach to deal with underspecified specifications of the target service will be subject of further investigation.

REFERENCES [1] M. Baldoni, L. Giordano, A. Martelli, and Viviana Patti. Reasoning about complex actions with incomplete knowledge: a modal approach. In Proc. ICTCS’01- LNCS 2202, pages 405–425, 2001. [2] D. Berardi, G. De Giacomo, M. Lenzerini, M. Mecella and D Calvanese. Syntesis of Underspecified Composite e-Services based on Automated Reasoning. In Proc. ICSOC’04, 2004. [3] U.Dal Lago, M.Pistore, P.Traverso: Planning with a Language for Extended Goals. AAAI 2002, 447-454 [4] F.Dignum and M.Greaves, “Issues in Agent Communication:An Introduction”. In F.Dignum and M.Greaves (Eds.), Issues in Agent Communication, LNAI 1916, pp. 1-16, 1999. [5] N. Fornara and M. Colombetti. Defining Interaction Protocols using a Commitment-based Agent Communication Language. Proc. AAMAS’03, Melbourne, 520–527, 2003.

[6] L. Giordano and A. Martelli. Tableau-based Automata Construction for Dynamic Linear Time Temporal Logic. Annals of Mathematics and Artificial Intelligence, to appear, Springer 2006. [7] L. Giordano, A. Martelli, and C. Schwind. Verifying Communicating Agents by Model Checking in a Temporal Action Logic. Proc. Logics in Artificial Intelligence, 9th European Conference, JELIA 2004, Lisbon, Portugal, Springer LNAI 3229, 57-69, 2004. [8] L. Giordano, A. Martelli, and C. Schwind. Specialization of Interaction Protocols in a Temporal Action Logic. LCMAS05 (3rd Int. Workshop on Logic and Communication in Multi- Agent Systems), Edinburgh, 1st of August 2005. [9] L. Giordano, A. Martelli and C. Schwind. Specifying and Verifying Interaction Protocols in a Temporal Action Logic Journal of Applied Logic (Special issue on Logic Based Agent Verification), Accepted for publication, 2006, Elsevier. [10] M. Greaves, H. Holmback and J. Bradshaw. What Is a Conversation Policy?. Issues in Agent Communication,LNCS 1916 Springer, 118-131, 2000. [11] F. Guerin and J. Pitt. Verification and Compliance Testing.Communications in Multiagent Systems, Springer LNAI 2650, 98– 112, 2003. [12] J.G. Henriksen and P.S. Thiagarajan. Dynamic Linear Time Temporal Logic. in Annals of Pure and Applied logic, vol.96, n.1-3, 187–207, 1999 [13] N.R. Jennings. Commitments and Conventions: the foundation of coordination in multi-agent systems. In The knowledge engineering review, 8(3),233–250, 1993. [14] N. Maudet and B. Chaib-draa. Commitment-based and dialogue-game based protocols: new trends in agent communication languages. In The Knowledge Engineering Review, 17(2):157-179, June 2002. [15] S. Narayanan and S. McIlraith. Simulation, Verification and Automated Composition of Web Services. In Proceedings of the Eleventh International World Wide Web Conference (WWW-11), 77–88, May 2002. [16] R. Petrick and F. Bacchus. A knowledge-based approach to planning with incomplete information and sensing. In Proceedings of the International Conference on Artificial Intelligence Planning (AIPS), 212-222, 2002. [17] M.Pistore and P.Traverso. Planning as Model Checking for Extended Goals in Non-deterministic Domains. Proc. IJCAI’01, Seattle, 479-484, 2001. [18] M. Pistore, A. Marconi, P. Bertoli and P. Traverso. Automated Composition of Web Services by Planning at the Knowledge Level. Proc. International Joint Conference on Artificial Intelligence (IJCAI), 1252–1259, 2005. [19] M. Pistore, P. Traverso and P. Bertoli. Automated Composition of Web Services by Planning in Asynchronous Domains. ICAPS 2005. 2–11, 2005. [20] R. Reiter. The frame problem in the situation calculus: a simple solution (sometimes) and a completeness result for goal regression. In Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, V. Lifschitz, ed., 359–380, Academic Press, 1991. [21] M. P. Singh. Agent communication languages: Rethinking the principles. IEEE Computer, 31(12), 40–47, 1998. [22] M. P. Singh. A social semantics for Agent Communication Languages. In Issues in Agent Communication 2000, Springer LNCS 1916, 31–45, 2000. [23] B. Srivastava and J. Koehler. Web Service Composition - Current Solutions and Open Problems, In ICAPS 2003 Workshop on Planning for Web Services, Pages 28 - 35, Trento, Italy, June 2003. [24] P. Yolum and M.P. Singh. Flexible Protocol Specification and Execution: Applying Event Calculus Planning using Commitments. In AAMAS’02, 527–534, Bologna, Italy, 2002.

59


             ! "$#%%&  %    "')(*+), -/.10204365879. : ;?. @?. =BA CED F GH. :E36IKJ2LM$:E3N520O3P=$IRQ&SUT$5O58IV0 1

W X =U0O:4SY>ZT$[K0O3NSU= t_`~\Y]4]4elyzoˆ^Zs`^&_`‡Y^byzqbacdEkj]E{O‰ d4^b‡Begrnfh^Š^bejdEil‡${Oknyz^bm {Oopd2^b_abd‹eg{Od4_`^boP]4_c€8^Œqlyhabd2yz^b_pdjo_`rO^„s`{OsŽeg^qlil{Oabs`yz^Š^bao`q‚oY‡$_`^tuy{,_`]‘qlvg_`]8eR^bw4opt~{Ow4yhopqgƒKd4^„x4ous`w4^byzqldjf|{}dE_{‹t~igejtuelqls`qlfh^ovg…qg^ŒdE†Nyd{ _ _`t~d4e^„el_Ns`‡/x–^^˜els`abr4vOeg]2›tˆk8abrEo`egyhfhad4^„ql’Kd4fz…p^bfka„“”_`^™š€8{{Oy|^bq _`€8eyhqabel^‡p_Ž]Eayh^„s`ql^˜sA@=BDCFE G @;HA>A:=IJ@D>AK BLB=:DINMD:DO=K >DK :=
0. A CLM contains all valid transitions for a composition goal because 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 appropriate way. The more valid causal links there are, the better it is.

Theorem 1. Let M be a CLM, and sx , sy be two Web services in SW s . 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 )).

Definition 2. The set of p × q CLMs2 is defined as Mp,q (P((SW s ∪ T )×]0, 1])). Columns {1, . . . , q} are labelled by (Input(SW s ) ∪ β) ⊆ T , the inputs parameters of services in SW s and/or the concepts described by the goal set β ⊆ T . Rows {1, . . . , p} are labelled by Input(SW s ). Each entry mi,j of a CLM M is defined as a set of pairs (sy , score) ∈ (SW s ∪ T )×]0, 1] such that ( (sy , SimT (Oy , Cj )), sy ∈SW s , Oy ∈Out(sy ) (sy , score) = (1) (sy , 1), sy ∈T

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 SW s . In case of success, the process is iterated with its input parameters as new goals. Alternatively, the process is stopped and the plan is reduced to the empty plan ∅. All the process is recursive 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 semantically well ordered in a robust and formal model. The solutions are plans wherein Web services are semantically chained by causal links.

with Ci ∈ T ∩ In(sy ) ⊆ Input(SW s ) is the label of the ith row. with Cj ∈ T ∩ (Input(SW s )∪β) is the label of the j th 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 ∈ T of sy and Cj ∈ Input(SW s )∪β in case sy ∈ SW s . In the alternative 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((SW s ∪ T )×]0, 1]).

Algorithm 1: Composition by regression-based approach Ra4 C. Input: A CLM M ([mi,j ]), a plan π, a planning problem Π = hSW s , KB, βi, a temporary set of solved goals G. Result: A set of solution plans π. begin Sc ← ∅; // Temporary set of pairs in (SW s ∪ T )×]0, 1]. if ((∃Ck ∈ KB) & (SimT (Ck , β) 6= 0)) then π ← β; foreach Ii ∈ Input(SW s ) do if ∃(α, v) ∈ mIi ,β then Add((α, v), Sc );

Definition 3. Let M be a CLM and KB be the set of instantiated concepts {C1 , . . . , Ct } ⊆ Input(SW s ) ∩ T . M is initialised according to KB iff mi,k ⊇ (Ck , 1), ∀i ∈ {1, . . . , p}, ∀k ∈ {1, . . . , t}.

if Sc 6= ∅ then foreach (α, v) ∈ Sc with α ∈ SW s do π ←π∪α; foreach In(α) do if β ∈ G then π ← π ∩ ∅; // inconsistent plan else Add(β, G);VΠ ← hSW s , KB, In(α)i; π ← π ∪ ( In(α) Ra4 C(M,π,Π,G);

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 composition. Thus the set of Web services SW s 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 prechaining 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

else π ← π ∩ ∅; // inconsistent plan return π; end

P(S) refers to the set of parts of a set S. #S refers to the Cardinality of S.

67

The Ra4 C algorithm builds a plan with no cycle in the ordering constraints and no causal link conflicts to dispose of inconsistent causal links (consistency [20]). Moreover the Ra4 C algorithm proposes 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 because 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.

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 Katia Sycara, ‘The owl services coalition, owl-s 1.1 beta release’, Technical report, (July 2004). [3] Boualem Benatallah, Mohand-Said Hacid, Alain Leger, Christophe Rey, 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 Marlon Dumas, ‘Declarative composition and peer-to-peer provisioning of dynamic web services’, in ICDE, pp. 297–308, (2002). [5] Tevfik Bultan, Xiang Fu, Richard Hull, and Jianwen Su, ‘Conversation specification: a new approach to design and analysis of e-service composition’, in International conference on WWW, pp. 403–410, (2003). [6] Daniela B Claro, Patrick Albers, and Jin-Kao Hao, ‘Selecting web services 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 contraction for semantic-based discovery of matches and negotiation spaces in an e-marketplace’, in Proceedings of the 6th ICEC, pp. 41–50, (2004). [8] Ion Constantinescu, Boi Faltings, and Walter Binder, ‘Type based service 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, ‘Web service modeling ontology submission, w3c submission’. June 2005. [11] M. Klusch, B. Fries, M. Khalid, and K. Sycara, ‘Owls-mx: Hybrid owls service matchmaking’, in AAAI, (November 2005). [12] Ralf K¨usters, Non-Standard Inferences in Description Logics, volume 2100 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 mines de Saint-etienne (France), Saint-etienne, July 2005. [14] L. Li and I. Horrocks, ‘A software framework for matchmaking based on semantic web technology’, in Proceedings of the Twelfth International 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 automated composition of web services,’, Eleventh International WWW Conference, 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, ‘Delivering semantic web services.’, in Proceedings of the international conference 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-forall” 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 selecting semantic web services with interactive composition techniques’, IEEE Intelligent Systems, 19(4), 42–49, (2004). [22] Biplav Srivastava and Jana Koehler, ‘Web service composition - current solutions 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 semantic 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 AlemanMeza, ‘Automatic composition of semantic web services’, in ICWS, pp. 38–41, (2003).

4 Related work Two different approaches [6, 8] propose matrices to represent the Web services domain. [6] solve an AI planning problem where actions are viewed as tasks. Actions are formally described with their preconditions and effects. Tasks are executed by concrete Web services, 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 reasoning about those matrices. In fact, matrices are simply considered as representation models. Moreover no semantic feature is introduced 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 describing the execution behaviours of Web services. A planner is declared as a state chart in [4], and the resulting composite services are executed by replacing the roles in the chart by selected individual services. [15] propose a composition path, nevertheless they only considered 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 concrete 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 advantage 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 solution 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) specification. 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.

68

Using Quantified Boolean Logics to Verify Web Service Composition Requirements1 Enrico Giunchiglia2 and Massimo Narizzano3 and Marco Pistore4 and Marco Roveri5 and Paolo Traverso6 actors in the business domain with their goals and needs and with their mutual dependencies and expectations. As shown in previous work [7], Tropos business requirements can be exploited to drive the design of business processes and to trace changes in the requirements and in the processes. Tropos has a formal counterpart in the Formal Tropos specification language [3]. Formal Tropos allows for defining constraints and requirements on the behaviors of the different actors participating to a Web service composition. These constraints can be seen as high-level counterparts of the detailed description of the behaviors of services described in languages such as BPEL4WS. More precisely, Formal Tropos allows for the specification of formal constraints expressed in Quantified Linear Time Logics (Quantified LTL, or QLTL). This logics provides standard temporal operators that allow to reason on the behavior and on the evolution of the system. Moreover, it provides existential and universal quantifiers, which permit to reason on the different instances that may exist on a single “class”.The possibility to combine temporal operators and quantifiers is very important in Web service composition scenarios. Consider, for instance, that there may be different “instances”of the same actor (e.g., different customers or different providers), that different “instances”of the same process may be running, and that these instances manage different data values. Expressing conditions in this scenario (e.g., the fact that each customer can have at most one open order with every provider) requires the capability to specify quantifiers on these instances. Given a formal specification of the requirements of a Web service composition scenario in terms of Tropos and of Formal Tropos, different forms of formal verification are possible. In particular, it is possible to validate the requirements of the composition, in order to check that they are consistent and that they satisfy the expectations of the different actors. Moreover, it is possible to verify the requirements against the implementation of the Web service composition, defined for instance by a set of BPEL4WS processes. This however requires the capability to verify QLTL formulas. In the paper, we present two approaches to this verification. The first approach, which is classical, transforms the QLTL formulas into (nonquantified) LTL formulas by expanding the quantifiers, and then exploits SAT-based Bounded Model Checking techniques on the resulting LTL formulas. This approach has the defects that the resulting LTL formulas are usually very large, and that the structure of the original formulas, which is given by the quantifiers, is lost in the expansion and cannot be exploited in the verification. The second approach, which is novel, exploits Bounded Model Checking techniques based on Quantified Boolean Formulas (QBF). In this case, the expansion of the quantifiers is avoided, and the verification is performed using efficient techniques and tools for that can reason directly on QBF specifications.

Abstract. This paper illustrates a framework for the definition of formal requirements on the behavior of Web service compositions. The framework exploits Quantified Linear Time Logics (QLTL) as formal specification language. The paper also discusses two approach for the verification of such formal requirements. The first approach, which is classical, transforms QLTL formulas into (nonquantified) Linear Time Logic formulas by expanding the quantifiers, and then exploits SAT-based Bounded Model Checking techniques on the resulting LTL formulas. The second approach, which is novel, exploits Bounded Model Checking techniques based on Quantified Boolean Formulas (QBF), thus avoiding the explicit expansion of the quantifiers.

1 Introduction Web service technology is rapidly emerging as one of the most practical approaches for the development of distributed business processes that integrate and compose customers’, vendors’, and business partners’ applications. However, composing services is made difficult by the fact that, while aiming at working together, usually companies do not want to uncover the internal structure of their business processes to each other. Moreover, they want to keep the ability to rethink and reorganize their business processes and to modify accordingly the implementation. Business process description languages like BPEL4WS [1] provide means to describe the interface behavior of services without necessarily revealing or constraining the internal behavior of the processes. They can hence be seen as the basic technology for and integration of business processes that guarantees the autonomy of the companies participating to the integration. However, in order to be effectively used for composing business processes, this technological infrastructure needs to be enriched with tools and methodologies that support the development of this composition and that permit to manage the changes and adaptations of business models and of business processes. This requires to take into account the business strategy and goals changes in the software system. To this purpose, business goals and business requirements need to be made explicit in the business process model. A “strategic”description needs to be provided of the different actors in the business domain with their goals and with their mutual dependencies and expectations. Moreover, this strategic description has to be validated and verified against the actual implementation of the Web services, in order to guarantee an alignment between the two models. In this paper we describe a framework for modeling business requirements of Web service compositions. The framework is based on Tropos [4], which provides a “strategic” description of the different 1

2 3 4 5 6

This work is partially funded by the MIUR-FIRB project RBNE0195K5 “Knowledge Level Automated Software Engineering”and by the EC project 507219 “PROSYD”. DIST, University of Genova, Italy, email: [email protected] DIST, University of Genova, Italy, email: [email protected] DIT, University of Trento, Italy, email: [email protected] ITC-IRST, Trento, Italy, email: [email protected] ITC-IRST, Trento, Italy, email: [email protected]

2 Modeling Service Composition Requirements In this section we describe how we model Web service compositions at the requirements level using the Tropos language. Tropos is founded on the premise that during the requirements analysis phase of the software development process it is important to understand

69

and model the strategic aspects underlying the organizational setting within which the software system will eventually function. By understanding these strategic aspects, one can better identify the motivations for the software system and the role that it will play inside the organizational setting. In this paper we consider an extension of Tropos, which is called Tropos4WS, and which is suitable for integration with business process models. We introduce Tropos4WS in the context of a simple case-study concerning a health-care agency that has to provide assistance to the citizens. The following figure is a Tropos diagram that provides a high-level description of the case-study domain:

of a requirements specification are introduced at the strategic level, without requiring an operationalization of the specification. A precise definition of FT and of its semantics can be found in [3]. Here we present only the most relevant aspects of the language. An FT specificatio n describes the relevant objects of a domain and the relationships among them. The description of each object is structured in two layers. The outer layer is similar to a class declaration and defin es the structure of the instances together with their attributes. The inner layer expresses constraints on the lifetime of the objects, using typed Quantified LTL formulas. Several instances of each element may exist during the evolution of the system. To distinguish among the different instances, a list of attributes is associated to each class. Each attribute has a sort which can be either primitive (boolean, integer. . . ) or classes. The inner layer of an FT class declaration consists of constraints that describe the dynamic aspects of entities, actors, goals, and dependencies. In FT we distinguish among Creation, Invariant, and Fulfillment constraints. Creation constraints define conditions that should be satisfied when a new instance of a class is created. In the case of goals and tasks, the creation is interpreted as the moment when the associated actor begins to desire the goal or to perform the task. Invariant constraints define conditions on the life of all class instances. Fulfillment constraints should hold whenever a goal is achieved or a task is completed. Creation and fulfillment constraints are further distinguished as sufficient conditions (trigger), necessary conditions (condition), and necessary and sufficient conditions (definition). In FT, constraints are described with formulas in an LTL logics with typed quantifiers. Besides the standard boolean, relational and temporal operators, the logic provides the quantifiers Forall and Exists, which range over all the instances of a given class. Consider the following fragment of FT specification, corresponding to task DoRequest:

It represents the main actors (circles) and goals (ovals) of the domain: the Citizen that aims at being assisted; the HealthcareAgency which aims at providing a fair assistance to the citizens; the TransportsInc which provides transportation services; the MealsInc which delivers meals at home; and the Bank which handles the government’s finances. The picture also describes the dependencies and expectations that exist among these actors. For instance, the citizen depends on the sanitary agency for being assisted, and this is formulated in the model with dependency ReceiveAssistance from Citizen to HealthcareAgency. Starting from this high-level view, the Tropos methodology proceeds with an incremental refinement process. The next figure, for instance, shows a refinement of the interactions between Citizen and HealthcareAgency:

TASK DoRequest Mode achieve Actor Citizen Super BeingAssisted Attribute constant need: AssistanceNeed result: boolean Invariant 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 describe the expected evolution of the task and its relations with the subtasks. Namely, if the task DoRequest is started, then eventually sub-task InitialRequest is entered (1st invariant). After InitialRequest has ended, subtask ProvideInformation is eventually entered (2nd invariant). And after also this sub-task has ended, WaitAnswer is eventually started (3rd invariant). The fourth invariant constrains the value of attribute result of the task to the value of the same attribute of sub-task WaitAnswer once this sub-task has ended. Finally, the Fulfillment definition tells us that the sub-task WaitAnswer has to complete before we can consider the DoRequest task fulfilled (necessary condition) and that, if WaitAnswer has completed, then DoRequest will eventually be fulfilled (sufficient condition). In FT it is possible to validate a requirements specification by allowing the designer to specify properties that the requirements model is supposed to satisfy. We distinguish between Assertion properties, which describe conditions that should hold for all valid evolutions of the specification, and Possibility properties, which describe conditions that should hold for at least one valid evolution. Some desired properties for the considered case-study are reported in the following:

Goals (ovals) are decomposed into sub-goals, or operationalized into tasks (hexagons), taking into account the dependencies existing among the different actors. For instance, the Citizen refines the goal BeingAssisted into the three sub-task of DoRequest, ReceiveService and Pay. DoRequest is further refined into InitialRequest, ProvideInformation, WaitAnswer. The refinement procedure ends once we have identified all basic tasks that define the business process. To these basic tasks we associate messages (rectangles) that describe the basic interactions among actors. For instance, task InitialRequest requires to send a message Request to the HealthcareAgency. This message is received and processed by the HealthcareAgency task ReceiveRequest. The Tropos graphical models have a formal counterpart described in the Formal Tropos specification language. Formal Tropos (hereafter FT) has been designed to supplement a Tropos model with a precise description of its dynamic aspects. In FT the focus is on the circumstances in which the goals and tasks arise, and on the conditions that lead to their fulfillment. In this way, the dynamic aspects

POSSIBILITY P1 Exists dr: DoRequest (Fulfilled(dr)) ASSERTION A1 Forall c: Citizen ( Forall r: Response (r.receiver = c -> ! r.result) ->

70

variables. In many cases, however, the LTL formula that results from the grounding is very large. Moreover, the “structure”of the original formula, which is given by the quantifiers is lost in the grounded version, and which could be used for more efficient satisfiability check algorithms, is lost in the grounding. The approach just described, which consists in applying a grounding step and then a unrolling step to the QLTL formula, and then to exploit SAT-solvers on the resulting problem, is illustrated in the top/right-side of the following figure:

Forall rs: ReceiveService (rs.actor = c -> ! Fulfilled(rs))) ASSERTION A2 Forall 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)))

Possibility P1 aims at guaranteeing that the set of constraints of the formal business requirements specification allow for the fulfillment of the task of doing a request in some scenario of the model. Assertion A1 requires that it is not possible for the citizen to fulfill its goal of receiving assistance services unless a positive answer to a request from the sanitary agency has been received. Finally, assertion A2 requires that the task of doing a request is eventually fulfilled along every scenario under the condition that: there is a sanitary agency that is bounded to provide assistance to the user (citizen’s dependency ReceiveAssistance); and, the citizen sends the requests to that particular sanitary agency.

QLTL Model Checking Problem

unrolling (length)

3 Verifying Service Composition Requirements In this section we describe our approach to verify an FT specification of a Web service composition scenario. The verification techniques we want to apply require a finite-state model. For this reason, upper bounds need to be specified to the number of instances of the different classes that appear in the formal specification. Given these bounds, a fin ite state automaton is built. Its states describe valid configurations of class instances, according to the class signatures and attributes that appear in the formal specification. Its transitions define valid evolutions of these configurations according to some generic constraints that capture the semantics of FT, e.g., that constant attributes should not change over time, or that, once fulfilled, a goal stays fulfilled forever. The creation, invariant, and fulfillment constraints of the various classes are collected in a set {Ci | i ∈ I} of temporal constraints. In this way, the valid behaviors of a model are those executions of the finite-state automaton that satisfy all temporal constraintsCi . Checking if assertion A is valid corresponds to checking whether the imV plication i∈I Ci ⇒ A holds in the model, i.e., if all valid scenarios also satisfy the assertion A. Checking if possibility P holds amount V to check whether i∈I Ci ∧ P is satisfiable, i.e., if there is some scenario that satisfies the constraints and the property. In both cases, the verification of a property is translated to the verification of a QLTL formula. In [3] we have shown how this verification can be performed using SAT-based model checking techniques. SAT-based model checking algorithms look for a trace of a given length that satisfies —or falsifies— a (non-quantified) LTL property. Since the length of the trace is fix ed, each state in the trace can be modeled through a set of dedicated variables, and the LTL property can be unrolled into a set of constraints on these variables. For instance, in the bounded interpretation the formula requiring that a given condition holds eventually in the future is unrolled into the requirement that the condition holds in some of the (variables defining the) states of the finite trace. SAT-based algorithms are usually very effi cient for traces of reasonable length. The limit of this technique is that, if no trace is found for a given length, then it may still be the case that the property is satisfied by a longer trace. That is, SAT-based model checking verifies the satisfiability of a property only up to a given length, and is hence called Bounded Model Checking (BMC) [2]. If applied to the verification of FT specifications, the BMC-based approach described above has a bottleneck, namely it requires to transform a QLTL formula into a non-quantified LTL formula (notice that we assume bounded ranges for all the classes exploited in the model). A grounding procedure has been defined in [3] which removes all the quantifiers by replacing them with a suitable conjunction or disjunction on all the possible instances of the quantified

grounding(bounds)

LTL Model Checking Problem

unrolling (length)

QBF−based BMC Problem

SAT−based BMC Problem

QBF−solvers

SAT−solvers

The left-side part of the figure illustrates an alternative approach, which is based on QBF-based Bounded Model Checking [5]. Similarly to SAT-based BMC, also in this case we look for a counterexample trace of fix ed length, and hence we perform an unrolling on the temporal formula to be verified. In this case, however, quantifiers are allowed in the specification of the unrolled property, which is hence modeled as a Quantified Boolean Formula (QBF). This way, the grounding step is not necessary anymore, more compact formulas are obtained and, more important, QBF-solvers such as the one described in [6] can be exploited to the verification. The details of QBF-based Bounded Model Checking are omitted for lack of space — the interested reader can refer to [5]. We conclude the section with the following table, that reports the results of verification of the Web service composition scenario described previously using SAT-based and QBF-based model checking. Test SAT QBF

T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 T 9 T 10 48.8 53.8 42.6 62.3 FAIL 62.3 54.4 48.8 FAIL 61.5 12.5 21.7 10.3 12.5 30.9 17.3 14.2 13.4 51.5 12.9

The results clearly show the advantage of the QBF-based approach in terms of time required for the verification.

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, and S. Weerawarana. Business process execution language for web services, version 1.1, 2003. [2] A. Biere, A. Cimatti, E. M. Clarke, and Y. Zhu. Symbolic Model Checking without BDDs. In Proc. TACAS’99, 1999. [3] A. Fuxman, L. Liu, J. Mylopoulos, M. Pistore, M. Roveri, and P. Traverso. Specifying and analyzing early requirements in Tropos. Requirements Engineering Journal, 2004. [4] P. Giorgini, M. Kolp. J. Mylopoulos, and M. Pistore. The Tropos Methodology: an overview. In Methodologies And Software Engineering For Agent Systems. Kluwer Academic Publishing, 2004. [5] E. Giunchiglia, M. Narizzano, M. Pistore, M. Roveri, and P. Traverso. QBF-based Bounded Model Checking. Technical report, 2006. [6] E. Giunchiglia, M. Narizzano, and A. Tacchella. QuBE++: an Efficient QBF Solver. In Proc. FMCAD’04, 2004. [7] R. Kazhamiakin, M. Pistore, and M. Roveri. A Framework for Integrating Business Processes and Business Requirements. In Proc. EDOC’04, 2004.

71