Robustness Validation in Service-Oriented Architectures

24
Soft Constraints for Dependable Service Oriented Architectures Stefano Bistarelli 1,2,3 and Francesco Santini 2,3,4 1 Dipartimento di Matematica Informatica, Universit ` a di Perugia, Italy [email protected] 2 Dipartimento di Scienze, Universit ` a “G. d’Annunzio” di Chieti-Pescara, Italy [email protected], [email protected] 3 Istituto di Informatica e Telematica (CNR), Pisa, Italy stefano.bistarelli,[email protected] 4 IMT - Institute for Advanced Studies, Lucca, Italy [email protected] Abstract. We propose the use of Soft Constraints as a natural way to model Service Oriented Architecture. In the framework, constraints are used to model components and connectors and constraint aggregation is used to represent their interactions. Moreover, a specific constraint pro- jection operator is used to highlight the service interface. The quality of a service is measured and considered when performing queries to service providers. In particular, we are here interested to aspect of dependabil- ity, that is to the trustworthiness of a computing system on the service it delivers. In our framework, the dependability score is represented by the softness level of the constraint and the measure of complex (web) services is computed by combining the levels of the components. The framework takes also in account the interaction of software agents representing dis- tributed services, by using a constraint based concurrent language able to also decide the collaboration taking care of the required dependability score. 1 Introduction Constraint programming is a powerful paradigm for solving combinatorial search problems that draws on a wide range of techniques from artificial intel- ligence, computer science, databases, programming languages, and operations research [9, 12, 31]. It is currently applied with success to many domains, such as scheduling, planning, vehicle routing, configuration, networks, and bioin- formatics. The basic idea in constraint programming is that the user states the constraints and a general purpose constraint solver solves them. Constraints are just relations, and a Constraint Satisfaction Problem (CSP) states which rela- tions should hold among the given decision variables (we refer to this classical view as “crisp” constraints). Constraint solvers take a real-world problem, rep- resented in terms of decision variables and constraints, and find an assignment of values to all the variables that satisfies all the constraints.

Transcript of Robustness Validation in Service-Oriented Architectures

Soft Constraints for Dependable Service OrientedArchitectures

Stefano Bistarelli1,2,3 and Francesco Santini2,3,4

1 Dipartimento di Matematica Informatica, Universita di Perugia, [email protected]

2 Dipartimento di Scienze, Universita “G. d’Annunzio” di Chieti-Pescara, [email protected], [email protected]

3 Istituto di Informatica e Telematica (CNR), Pisa, Italystefano.bistarelli,[email protected]

4 IMT - Institute for Advanced Studies, Lucca, [email protected]

Abstract. We propose the use of Soft Constraints as a natural way tomodel Service Oriented Architecture. In the framework, constraints areused to model components and connectors and constraint aggregation isused to represent their interactions. Moreover, a specific constraint pro-jection operator is used to highlight the service interface. The quality of aservice is measured and considered when performing queries to serviceproviders. In particular, we are here interested to aspect of dependabil-ity, that is to the trustworthiness of a computing system on the service itdelivers. In our framework, the dependability score is represented by thesoftness level of the constraint and the measure of complex (web) servicesis computed by combining the levels of the components. The frameworktakes also in account the interaction of software agents representing dis-tributed services, by using a constraint based concurrent language ableto also decide the collaboration taking care of the required dependabilityscore.

1 Introduction

Constraint programming is a powerful paradigm for solving combinatorialsearch problems that draws on a wide range of techniques from artificial intel-ligence, computer science, databases, programming languages, and operationsresearch [9, 12, 31]. It is currently applied with success to many domains, suchas scheduling, planning, vehicle routing, configuration, networks, and bioin-formatics. The basic idea in constraint programming is that the user states theconstraints and a general purpose constraint solver solves them. Constraintsare just relations, and a Constraint Satisfaction Problem (CSP) states which rela-tions should hold among the given decision variables (we refer to this classicalview as “crisp” constraints). Constraint solvers take a real-world problem, rep-resented in terms of decision variables and constraints, and find an assignmentof values to all the variables that satisfies all the constraints.

Rather than trying to satisfy a set of constraints, sometimes people want tooptimize them. This means that there is an objective function that tells us thequality of each solution, and the aim is to find a solution with optimal quality. Forexample, fuzzy constraints [9, 12, 31] allow for the whole range of satisfiabilitylevels between 0 and 1. In weighted constraints, instead, each constraint is givena weight, and the aim is to find a solution for which the sum of the weights ofthe satisfied constraints is maximal.

The idea of the semiring-based formalism [9, 12] was to further extend theclassical constraint notion, and to do it with a formalism that could encompassmost of the existing extensions, as well as other ones not yet defined, with theaim to provide a single environment where properties could be proven once andfor all, and inherited by all the instances. At the technical level, this was doneby adding to the usual notion of a CSP the concept of a structure representingthe levels of satisfiability of the constraints. Such a structure is a set with twooperations (see Sec. 2 for further details): one (written +) is used to generate anordering over the levels, while the other one (×) is used to define how two levelscan be combined and which level is the result of such combination. Because ofthe properties required on such operations, this structure is similar to a semiring(see Sec. 2): from here the terminology of “semiring-based soft constraint” [9, 12](and Sec. 2), that is, constraints with several levels of satisfiability, whose levelsare (totally or partially) ordered according to the semiring structure. In general,problems defined according to the semiring-based frame-work are called SoftConstraint Satisfaction Problems (SCSPs).

A key aspect of any system (in its general definition) is that it can depend-ably fulfil its specified function. The aim of the paper is to extend Quality ofService (QoS) measures of Service Oriented Architectures (SOAs) [29, 28] with as-pects of dependability. Such architecture outlines a way of reorganizing softwareapplications and infrastructure into a set of interacting services and aims at aloose coupling of services with operating systems, programming languages andother technologies. A SOA separates functions into distinct units or services, andthese services communicate with each other by passing data from one serviceto another, or by coordinating an activity between two or more services. Webservices [24, 2] can implement a service-oriented architecture.

SOAs clearly represent a distributed environment and dependability aspectsbecome very important to evaluate, since the final integrated service must fulfillthe requirements of the final user; this composition needs to be monitored [29,28]. In this context, dependability is the ability to deliver a service that canjustifiably be trusted [1, 22] and gathers different non-functional attributes asavailability and reliability (see Sec. 3 for details).

The challenge and opportunity is to create ways to represent, evaluate, andimprove dependability as an architectural attribute, rather than a property thatis buried in the implementation details. The key idea of this paper is to use thea soft constraint framework in order to be able to manage SOAs in a declara-tive fashion by considering together both the requirements/interfaces of eachservice and their dependability estimation. C-semirings can represent several

dependability and, more in general, QoS attributes, while soft constraints rep-resent the specification of each service to integrate: they link these measures tothe resources spent in providing it, for instance, “the reliability is equal to 80%plus 5% for each other processor used to execute the service”. This statementcan be easily represented with a soft constraint where the number of processorscorresponds to the x variable, and the preference (i.e. reliability) level is givenby the 5x + 80 polynomial.

Aside expressivity reasons, other advantages w.r.t. crisp constraints are thatsoft constraints can solve over-constrained problems (i.e. when it is not possibleto solve all of them at the same time) and that, when we have to deal withquality and dependability, many related concepts are “smooth”: quality canbe represented with intervals of “more or less” acceptable values. It has beenproved that constraint in general are a powerful paradigm for solving combina-torial search problems [9, 12, 31]. Moreover, there exists a wide body of existingresearch results on solving (soft) CSP for large systems of constraints in a fullymechanized manner [9, 12].

1.1 Organization of the Work

The paper is organized as follows: Section 2 presents the minimum backgroundnotions needed to understand soft constraints and a nonmonotonic soft con-straint language, while Sec. 3 closes the introductory part by defining SOAsand dependability aspects. In Sec. 4 we show how a soft constraint solver canbe used in a SOA in order to implement the negotiation process of QoS anddependability aspects, which can be expressively modeled with semirings. Sec-tion 5 shows that the use of soft constraints permits us to perform a quantitativeanalysis of system integrity. In Sec. 6 we show that soft constraints can be usedto group service components into trustworthy coalitions. Finally, Sec. 7 presentthe related work, while Sec. 8 draws the final conclusions and discusses thedirections for future work.

2 Background on Soft Constraints

Absorptive Semiring. An absorptive semiring [5] S can be represented as a〈A,+,×, 0, 1〉 tuple such that: i) A is a set and 0, 1 ∈ A; ii) + is commutative,associative and 0 is its unit element; iii) × is associative, distributes over +, 1is its unit element and 0 is its absorbing element. Moreover, + is idempotent, 1is its absorbing element and × is commutative. Let us consider the relation ≤Sover A such that a ≤S b iff a + b = b. Then it is possible to prove that (see [6]): i)≤S is a partial order; ii) + and × are monotonic on ≤S; iii) 0 is its minimum and 1its maximum; iv) 〈A,≤S〉 is a complete lattice and, for all a, b ∈ A, a + b = lub(a, b)(where lub is the least upper bound). Informally, the relation ≤S gives us a wayto compare semiring values and constraints. In fact, when we have a ≤S b (orsimply a ≤ b when the semiring will be clear from the context), we will say thatb is better than a.

In [5] the authors extended the semiring structure by adding the notion ofdivision, i.e. ÷, as a weak inverse operation of ×. An absorptive semiring S isinvertible if, for all the elements a, b ∈ A such that a ≤ b, there exists an elementc ∈ A such that b × c = a [5]. If S is absorptive and invertible, then, S is invertibleby residuation if the set {x ∈ A | b × x = a} admits a maximum for all elementsa, b ∈ A such that a ≤ b [5]. Moreover, if S is absorptive, then it is residuated if theset {x ∈ A | b× x ≤ a} admits a maximum for all elements a, b ∈ A, denoted a÷ b.With an abuse of notation, the maximal element among solutions is denoteda ÷ b. This choice is not ambiguous: if an absorptive semiring is invertible andresiduated, then it is also invertible by residuation, and the two definitions yieldthe same value.

To use these properties, in [5] it is stated that if we have an absorptiveand complete semiring5, then it is residuated. For this reason, since all classi-cal soft constraint instances (i.e. Classical CSPs, Fuzzy CSPs, Probabilistic CSPsand Weighted CSPs) are complete and consequently residuated, the notion ofsemiring division (i.e. ÷) can be applied to all of them.

Soft Constraint System. A soft constraint [6, 12] may be seen as a constraintwhere each instantiation of its variables has an associated preference. GivenS = 〈A,+,×, 0, 1〉 and an ordered set of variables V over a finite domain D, a softconstraint is a function which, given an assignment η : V → D of the variables,returns a value of the semiring. Using this notation C = η → A is the set of allpossible constraints that can be built starting from S, D and V.

Any function in C involves all the variables in V, but we impose that itdepends on the assignment of only a finite subset of them. So, for instance, abinary constraint cx,y over variables x and y, is a function cx,y : (V → D) → A,but it depends only on the assignment of variables {x, y} ⊆ V (the support ofthe constraint, or scope). Note that cη[v := d1] means cη′ where η′ is η modifiedwith the assignment v := d1. Notice also that, with cη, the result we obtain is asemiring value, i.e. cη = a.

Given the set C, the combination function ⊗ : C × C → C is defined as(c1 ⊗ c2)η = c1η × c2η (see also [6, 12, 7]). Having defined the operation ÷ onsemirings, the constraint division function ÷ : C × C → C is instead definedas (c1 ÷ c2)η = c1η ÷ c2η [5]. Informally, performing the ⊗ or the ÷ between twoconstraints means building a new constraint whose support involves all thevariables of the original ones, and which associates with each tuple of domainvalues for such variables a semiring element which is obtained by multiplyingor, respectively, dividing the elements associated by the original constraints tothe appropriate sub-tuples. The partial order ≤S over C can be easily extendedamong constraints by defining c1 v c2 ⇐⇒ c1η ≤ c2η. Consider the set C andthe partial order v. Then an entailment relation `⊆ ℘(C) × C is defined s.t. foreach C ∈ ℘(C) and c ∈ C, we have C ` c ⇐⇒

⊗C v c (see also [12, 7]).

5 If S is an absorptive semiring, then S is complete if it is closed with respect to infinitesums, and the distributivity law holds also for an infinite number of summands.

Given a constraint c ∈ C and a variable v ∈ V, the projection [6, 12, 7] of c overV\{v}, written c ⇓(V\{v}) is the constraint c′ s.t. c′η =

∑d∈D cη[v := d]. Informally,

projecting means eliminating some variables from the support. This is done byassociating with each tuple over the remaining variables a semiring elementwhich is the sum of the elements associated by the original constraint to allthe extensions of this tuple over the eliminated variables. To treat the hidingoperator of the language, a general notion of existential quantifier is introducedby using notions similar to those used in cylindric algebras. For each x ∈ V, thehiding function [12, 7] is defined as (∃xc)η =

∑di∈D cη[x := di].

To model parameter passing, for each x, y ∈ V a diagonal constraint [12, 7] isdefined as dxy ∈ C s.t., dxyη[x := a, y := b] = 1 if a = b and dxyη[x := a, y := b] = 0if a , b. Considering a semiring S = 〈A,+,×, 0, 1〉, a domain of the variablesD, an ordered set of variables V and the corresponding structure C, then SC =〈C,⊗, 0, 1,∃x, dxy〉6 is a cylindric constraint system (“a la Saraswat” [7]).

Soft CSP and an Example. A Soft Constraint Satisfaction Problem (SCSP) [12] definedas P = 〈C, con〉: C is the set of constraints and con ⊆ V is the set of variables ofinterest for the constraint set C, which however may concern also variables notin con. This is called the best level of consistency and it is defined by blevel(P) =Sol(P) ⇓∅, where Sol(P) = (

⊗C) ⇓con; notice that supp(blevel(P)) = ∅. We also say

that: P is α-consistent if blevel(P) = α; P is consistent iff there exists α >S 0 suchthat P is α-consistent; P is inconsistent if it is not consistent.

X Y

c1 c3

c2

<a> 1

<b> 9

<a> 5

<b> 5

<a,a> 5

<a,b> 1

<b,a> 2

<b,b> 2

Fig. 1. A soft CSP based on a Weighted semiring.

Figure 1 shows a weighted CSP as a graph. Variables and constraints arerepresented respectively by nodes and by undirected arcs (unary for c1 and c3,and binary for c2), and semiring values are written to the right of each tuple.The variables of interest (that is the set con) are represented with a double circle(i.e. variable X). Here we assume that the domain of the variables containsonly elements a and b. For example, the solution of the weighted CSP of Fig. 1associates a semiring element to every domain value of variable X. Such anelement is obtained by first combining all the constraints together. For instance,for the tuple 〈a, a〉 (that is, X = Y = a), we have to compute the sum of 1 (which

6 0 and 1 respectively represent the constraints associating 0 and 1 to all assignments ofdomain values; in general, the a function returns the semiring value a.

is the value assigned to X = a in constraint c1), 5 (which is the value assignedto 〈X = a,Y = a〉 in c2) and 5 (which is the value for Y = a in c3). Hence, theresulting value for this tuple is 11. We can do the same work for tuple 〈a, b〉 → 7,〈b, a〉 → 16 and 〈b, b〉 → 16. The obtained tuples are then projected over variablex, obtaining the solution 〈a〉 → 7 and 〈b〉 → 16. The blevel for the example inFig. 1 is 7 (related to the solution X = a, Y = b).

2.1 A Nonmonotonic sccp Language

We summarize the main features of a formal nonmonotonic language based onsoft constraints [11]; the language can be tied to the monitoring of dependabilityaspects, as it will be shown in Sec. 4. Given a soft constraint system as definedin Sec. 2 and any related constraint c, the syntax of agents in nmsccp is givenin Fig. 2. P is the class of programs, F is the class of sequences of proceduredeclarations (or clauses), A is the class of agents, c ranges over constraints, X isa set of variables and Y is a tuple of variables.

P F F.AF F p(Y) :: A | F.FA F success | tell(c)� A | retract(c)� A | updateX(c)� A | E | A‖A | ∃x.A | p(Y)E F ask(c)� A | nask(c)� A | E + E

Fig. 2. Syntax of the nmsccp language.

The� is a generic checked transition used by several actions of the language.Therefore, to simplify the rules in Fig. 4 we define a function check� : σ →{true, f alse} (where σ ∈ C), that, parametrized with one of the four possibleinstances of� (C1-C4 in Fig. 3), returns true if the conditions defined by thespecific instance of� are satisfied, or false otherwise. The conditions betweenparentheses in Fig. 3 claim that the lower threshold of the interval clearly cannotbe “better” than the upper one, otherwise the condition is intrinsically wrong.

In Fig. 3 C1 checks if the α-consistency of the problem is between a1 and a2.In words, C1 states that we need at least a solution as good as a1 entailed bythe current store, but no solution better than a2; therefore, we are sure that somesolutions satisfy our needs, and none of these solutions is “too good”.

To give an operational semantics to our language we need to describe anappropriate transition system 〈Γ,T,→〉, where Γ is a set of possible configu-rations, T ⊆ Γ is the set of terminal configurations and →⊆ Γ × Γ is a binaryrelation between configurations. The set of configurations is Γ = {〈A, σ〉}, whereσ ∈ C while the set of terminal configurations is instead T = {〈success, σ〉}. Thetransition rule for the nmsccp language are defined in Fig. 4.

In the following we provide a description of the transition rules in Fig. 4. Forfurther details, please refer to [11]. In the Tell rule (R1), if the store σ⊗ c satisfiesthe conditions of the specific� transition of Fig. 3, then the agent evolves to the

C1:�=→a2a1

check(σ)� = true if

σ ⇓∅≯S a2

σ ⇓∅≮S a1

(with a1 ≯ a2)

C2:�=→φ2a1

check(σ)� = true if

σ b φ2

σ ⇓∅≮S a1

(with a1 ≯ φ2 ⇓∅)

C3:�=→a2φ1

check(σ)� = true if

σ ⇓∅≯S a2

σ a φ1

(with φ1 ⇓∅≯ a2)

C4:�=→φ2φ1

check(σ)� = true if

σ b φ2

σ a φ1

(with φ1 b φ2)

Otherwise, within the same conditions in parentheses, check(σ)� = f alse

Fig. 3. Definition of the check function for each of the four checked transitions.

R1 check(σ ⊗ c)�〈tell(c)� A, σ〉 −→ 〈A, σ ⊗ c〉 Tell

R2 σ ` c check(σ)�〈ask(c)� A, σ〉 −→ 〈A, σ〉 Ask

R3 〈A, σ〉 −→ 〈A′, σ′〉〈A ‖ B, σ〉 −→ 〈A′ ‖ B, σ′〉〈B ‖ A, σ〉 −→ 〈B ‖ A′, σ′〉

Parall1

R4 〈A, σ〉 −→ 〈success, σ′〉〈A ‖ B, σ〉 −→ 〈B, σ′〉〈B ‖ A, σ〉 −→ 〈B, σ′〉

Parall2

R5〈E j, σ〉 −→ 〈A j, σ

′〉 j ∈ [1,n]〈Σn

i=1Ei, σ〉 −→ 〈A j, σ′〉 Nondet

R6 σ 6` c check(σ)�〈nask(c)� A, σ〉 −→ 〈A, σ〉 Nask

R7 σ v c σ′ = σ÷ c check(σ′)�〈retract(c)� A, σ〉 −→ 〈A, σ′〉 Retract

R8σ′ = (σ ⇓(V\X)) ⊗ c check(σ′)�〈updateX(c)� A, σ〉 −→ 〈A, σ′〉 Update

R9〈A[x/y], σ〉 −→ 〈B, σ′〉〈∃x.A, σ〉 −→ 〈B, σ′〉 with y fresh Hide

R10 〈A, σ〉 −→ 〈B, σ′〉〈p(Y), σ〉 −→ 〈B, σ′〉 p(Y) :: A ∈ F P-call

Fig. 4. The transition system for nmsccp.

new agent A over the store σ⊗ c. Therefore the constraint c is added to the storeσ. The conditions are checked on the (possible) next-step store: i.e. check(σ′)�.To apply the Ask rule (R2), we need to check if the current store σ entails theconstraint c and also if the current store is consistent with respect to the lowerand upper thresholds defined by the specific� transition arrow: i.e. if check(σ)�is true.

Parallelism and nondeterminism: the composition operators + and ‖ re-spectively model nondeterminism and parallelism. A parallel agent (rules R3and R4) will succeed when both agents succeed. This operator is modelled interms of interleaving (as in the classical ccp): each time, the agent A ‖ B canexecute only one between the initial enabled actions of A and B (R3); a parallelagent will succeed if all the composing agents succeed (R4). The nondetermin-istic rule R5 chooses one of the agents whose guard succeeds, and clearly givesrise to global nondeterminism. The Nask rule is needed to infer the absence ofa statement whenever it cannot be derived from the current state: the semantics

in R6 shows that the rule is enabled when the consistency interval satisfies thecurrent store (as for the ask), and c is not entailed by the store: i.e. σ @ c. Retract:with R7 we are able to “remove” the constraint c from the store σ, using the÷ constraint division function defined in Sec. 2. According to R7, we requirethat the constraint c is entailed by the store, i.e. σ v c. The semantics of Updaterule (R8) [15] resembles the assignment operation in imperative programminglanguages: given an updateX(c), for every x ∈ X it removes the influence over xof each constraint in which x is involved, and finally a new constraint c is addedto the store. To remove the information concerning all x ∈ X, we project (seeSec. 2) the current store on V\X, where V is the set of all the variables of theproblem and X is a parameter of the rule (projecting means eliminating somevariables). At last, the levels of consistency are checked on the obtained store,i.e. check(σ′)�. Notice that all the removals and the constraint addition are trans-actional, since are executed in the same rule. Hidden variables: the semantics ofthe existential quantifier in R9 can be described by using the notion of freshnessof the new variable added to the store [11]. Procedure calls: the semantics ofthe procedure call (R10) has already been defined in [7]: the notion of diagonalconstraints (as defined in Sec. 2) is used to model parameter passing.

3 Service Oriented Architectures and Dependability Aspects

Service Oriented Architecture (SOA) can be defined as a group of services, whichcommunicate with each other [29, 28]. The process of communication involveseither simple data passing or it could involve two or more services coordinatingsome activity. Basic services, their descriptions, and basic operations (publica-tion, discovery, selection, and binding) that produce or utilize such descriptionsconstitute the SOA foundation. The main part of SOA is loose coupling of thecomponents for integration. Services are defined by their interface, describingboth functional and non-functional behaviour. Functional includes describingdata formats, pre and post conditions and the operation performed by the ser-vice. Non-functional behaviour includes security and other QoS parameters.The main four features of SOA consist in Coordination, Monitoring, Conformanceand Quality of Service (QoS) composition [29].

Services are self describing, open components that support rapid, low-cost composition of distributed applications. Services are offered by serviceproviders, which are organizations that procure the service implementations,supply their service descriptions, and provide related technical and businesssupport. Since services may be offered by different enterprises and communi-cate over the Internet, they provide a distributed computing infrastructure forboth intra and cross-enterprise [2] application integration and collaboration.Service descriptions are used to advertise the service capabilities, interface, be-haviour, and quality. Publication of such information, about available services,provides the necessary means for discovery, selection, binding, and compositionof services. Service clients (end-user organizations that use some service) and

service aggregators (organizations that consolidate multiple services into a new,single service offering) utilize service descriptions to achieve their objectives.

Dependability as applied to a computer system is defined by the IFIP 10.4Working Group on Dependable Computing and Fault Tolerance as [21]: “[..] thetrustworthiness of a computing system which allows reliance to be justifiably placed onthe service it delivers [..]”. Therefore, this definition stresses the need for justifi-cation of trust. An alternate definition, that provides the criterion for decidingif the service is dependable, is: “the dependability of a system is the ability to avoidservice failures that are more frequent and more severe than is acceptable” [1].

Some different measurements can be applied to a system to determine itsoverall dependability. A generally agreed list of attributes [1] is: i) Availability- the probability that a service is present and ready for use; ii) Reliability - thecapability of maintaining the service and service quality; iii) Safety - the absenceof catastrophic consequences; iv) Confidentiality - information is accessible onlyto those authorized to use it; v) Integrity - the absence of improper systemalterations; and vi) Maintainability - to undergo modifications and repairs. Someof these attributes are quantifiable by direct measurements (i.e. they are ratherobjective scores), but others are more subjective, e.g. safety.

Dependability is clearly strictly related to the concept of security. Whenaddressing security, an additional attribute has great prominence, confidential-ity, i.e., the absence of unauthorized disclosure of information. Security is acomposite of the attributes of confidentiality, integrity and availability. The “de-pendability and security” specification of a system must include the requirementsfor the attributes in terms of the acceptable frequency and severity of servicefailures for specified classes of faults and a given use environment.

4 Embedding Soft Constraints in SOAs

The semiring algebraic structures (see Sec. 2) proves to be an appropriate andvery expressive cost model to represent the dependability metrics shown in thisSection. The cartesian product of multiple c-semirings is still a c-semiring [12]and, therefore, we can model also a multicriteria optimization. In the followinglists we present some possible semiring instantiations and some of the possiblemetrics they can represent:

– Weighted semirings 〈R+,min, +,∞, 0〉 (+ is the arithmetic sum). In general,this semiring can represent additive metrics: it can be used to count eventsor quantities in order to minimize the resulting sum, e.g. for saving moneywhile composing different services with different costs, or to minimize thedowntime of the service components (availability and reliability can bemodeled in this way).

– Fuzzy semirings 〈[0, 1],max,min, 0, 1〉. It can be used to represent fuzzypreferences on components, e.g. low, medium or high reliability when detailedinformation is not available. This semiring can be used to represent concavemetrics, in which the composition result of all the values is obtained by“flattening” to the “worst” or “best” value.

– Probabilistic semirings 〈[0, 1],max, ×, 0, 1〉 (× is the arithmetic multiplica-tion). Multiplicative metrics can be modeled with this semiring. As an exam-ple, the Probabilistic semiring can optimize (i.e. maximize) the probabilityof the successful behavior of services, by choosing the composition thatoptimizes the multiplication of probabilities. For example, the frequency ofsystem faults can studied from a probabilistic point of view; also availabilitycan be represented with a percentage value.

– Set-Based semirings 〈P(A),∪,∩, ∅,A〉. Properties and features of the servicecomponents can be represented with this semiring. For example, in order torepresent related security rights, or time slots in which the services can beused (security issues).

– Classical semirings 〈{0, 1},∨,∧, 0, 1〉. The classical semiring can be adoptedto cast crisp constraints in the semiring-based framework defined in [12, 8].Even this semiring can be used to check if some properties are entailed bya service definition (i.e. true of false values), by composing the properties ofits components together.

One application of the nmsccp language presented in Sec. 2.1 is to modelgeneric entities negotiating a formal agreement, i.e. a Service Level Agreement [2,24] (SLA), where the level of service is formally defined. The main task consistsin accomplishing the requests of all the agents by satisfying their dependabilityrequirements (or QoS in general). Considering the fuzzy negotiation in Fig. 5(Fuzzy semiring: 〈[0, 1],max,min, 0, 1〉) both a provider and a client (offeringand acquiring a web service, for example) can add their request to the store σ(respectively tell(cp) and tell(cc)): the thick line represents the consistency of σafter the composition (i.e. min), and the blevel of this SCSP (see Sec. 2) is the max,where both requests intersects (i.e. in 0.5).

1

5 864 71 9

C Cp c

0.5

x (resource)

preference

xxxxxxxxxxxxxxxxxxxxxxxxxxx

Cc Cpxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Provider's softconstraint

Client's softconstraint

Fig. 5. The graphical interpretation of a fuzzy agreement

In the classical scenario, we propose to add a soft constraint solver in theorchestrator/borker between the clients and the providers (possibly belonging

to different organizations). Notice that the idea of a QoS broker has been alreadyexploited in literature [34, 36]. A broker-based framework is used to facilitate thedynamic integration and adaptation of QoS-aware web services with end-to-end QoS constraints [36]. The key functions of a dynamic broker include servicecollection, selection, composition and adaptation. The broker module is also anorchestrator in the sense that describes the automated arrangement, coordina-tion, and management of complex services, i.e. the classical basic function ofOrchestration [30].

. . . .Provider 1 Provider 1 Provider n

Broke

r

Client

Fig. 6. The broker interfaces with providers and the client, in order to negotiate thedesired QoS of the service integration.

In Fig. 6 we sketch how an architecture with the broker can carry out thenegotiation phase between the client and the providers offering a (composed)service. Our broker must be able to receive the query coming from a client: forexample, SOAP messages can be extended to find web services which satisfyspecific QoS requirements [26]. Providers publish QoS-enabled web services byregistering them at the UDDI registry [26]. The main task of the broker is tointerface itself with clients and providers in order to find a shared agreement.The broker tries to satisfy the requirements of the client by selecting and com-posing the best components among all those possible, i.e. by choosing betweendifferent providers. Below we describe the possible computation steps:

1. The service requestor requests the establishment of the binding by specify-ing the reference to a Web service interface. This request also contains therequired QoS.

2. The QoS broker searches for the service providers in the UDDI.3. The QoS broker performs QoS negotiation as described below.4. The web service QoS broker compares the offered QoS with the required

QoS and uses its internal information to determine an agreed QoS. Thisprocess is called QoS negotiation.

5. If the QoS negotiation has been successful, the service requestor and serviceprovider are informed that a negotiation has been successful and a binding

has been built. From this moment on these objects can interact through thebinding.

We propose to accomplish the negotiation by enhancing the broker witha soft constraint solver engine. Therefore, the documents describing the QoSassociated with a service (usually an XML-based document [26]) need to betranslated into a soft constraint and added to the constraint store with thelanguage proposed in Sec. 2.1. Soft constraints can expressively represent thedependability features of a service, as the examples in Sec. 4.1 and the wholeexample in Sec. 5 show. Since this language is nonmonotonic, we can use it tomodel the relaxation of requirements, the negotiation of the desired parameters(see the examples in Sec. 4.1) and then to find the best agreement, which mustbe then retranslated into an XML-based answer in order to be signed by allthe interested parties. Two nmsccp agents P (provider) and C (client) can beconcurrently executed on the broker and the tell operator can be used to addtheir requirements to the store. The broker can be hosted by a third party toguarantee the transparency of the process and must be able to reach the registriesof the services. Therefore, the soft constraint solver is a transparent componentbecause all the XML-translations are executed inside it, while the stack of theother protocols and technologies is maintained (e.g. SOAP and UDDI).

4.1 Negotiation Examples

We present three short examples to suggest possible negotiation scenarios. Wesuppose there are two distinct companies (e.g. providers P1 and P2) that want tomerge their services in a sort of pipeline, in order to offer to their clients a singlestructured service: e.g. P1 completes the functionalities of P2. This examplemodels the cross-domain management of services proposed in [2]. Notice that,as proposed for the architecture in Fig. 6, all the negotiation operations with thenmsccp language are performed by (and inside) the broker module, on behalf ofthe provider and client modules.

The variable x of the problem represents the global number of failures theycan sustain during the service provision, while the preference models the num-ber of hours (or a money cost in hundreds of euro) needed to manage them andrecover from them. The preference interval on transition arrows models the factthat both P1 and P2 explicitly want to spend some time to manage the failures(the upper bound in Fig. 3), but no so much time (lower bound in Fig. 3). Wewill use the Weighted semiring and the soft constraints given in Fig. 7. Even ifthe examples are based on a single criteria (i.e. the number of hours) for sake ofsimplicity, they can be extended to the multicriteria case, where the preferenceis expressed as a tuple of incomparable criteria.

Example 1 (Tell and negotiation). P1 and P2 both want to present their policy(respectively represented by c4 and c3) to the other party and to find a sharedagreement on the service (i.e. a SLA). Their agent description is: P1 ≡ 〈tell(c4)→0

∞tell(sp2)→0

∞ ask(sp1)→210 success〉||〈tell(c3)→0

∞ tell(sp1)→0∞ ask(sp2)→1

4 success〉 ≡

P2, executed in the store with empty support (i.e. 0). Variables sp1 and sp2 areused only for synchronization and thus will be ignored in the following consid-erations (e.g. replaced by the SYNCHROi agents in Ex. 2). The final store (themerge of the two policies) is σ = (c4 ⊗ c3) ≡ 2x + x + 5, and since σ ⇓∅= 5 isnot included in the last preference interval of P2 (between 1 and 4), P2 does notsucceed and a shared agreement cannot be found. The practical reason is thatthe failure management systems of P1 need at least 5 hours (i.e. c4 = x + 5) evenif no failures happen (i.e. x = 0). Notice that the last interval of P2 requires thatat least 1 hour is spent to check failures.

c1 : ({x} →N)→ R+ s.t. c1(x) = x + 3 c2 : ({y} →N)→ R+ s.t. c2(y) = y + 1

c3 : ({x} →N)→ R+ s.t. c3(x) = 2x c4 : ({x} →N)→ R+ s.t. c4(x) = x + 5

Fig. 7. Four Weighted soft constraints.

Example 2 (Retract). After some time (still considering Ex. 1), suppose that P1wants to relax the store, because its policy is changed: this change can be per-formed from an interactive console or by embedding timing mechanisms inthe language as explained in [4]. The removal is accomplished by retractingc1, which means that P1 has improved its failure management systems. No-tice that c1 has not ever been added to the store before, so this retraction be-haves as a relaxation; partial removal is clearly important in a negotiation pro-cess. P1 ≡ 〈tell(c4) →0

∞ SYNCHROP1 →210 retract(c1) →2

10 success〉||〈tell(c3) →0∞

SYNCHROP2 →14 success〉 ≡ P2 is executed in 0. The final store is σ = c4⊗c3 ÷ c1 ≡

2x + 2, and since σ ⇓∅= 2, both P1 and P2 now succeed (it is included in bothintervals).

Example 3 (Update). The update can be instead used for substantial changes of thepolicy: for example, suppose that P1 ≡ 〈tell(c1) →0

∞ update{x}(c2) →0∞ success, 0〉.

This agent succeeds in the store 0 ⊗ c1 ⇓(V\{x}) ⊗c2, where c1 ⇓(V\{x})= 3 and3 ⊗ c2 ≡ y + 4 (i.e. the polynomial describing the final store). Therefore, thefirst policy based on the number of failures (i.e. c1) is updated such that x is“refreshed” and the new added policy (i.e. c2) depends only on the y numberof system reboots. The consistency level of the store (i.e. the number of hours)now depends only on the y variable of the SCSP. Notice that the 3 component ofthe final store derives from the “old” c1, meaning that some fixed managementdelays are included also in this new policy.

5 Soft Constraints to Enforce System Integrity

In this Section we show that soft constraints can model the implementation ofa service described with a policy document [2, 24]. While composing different

services, it is required to monitor the properties of the obtained global serviceand to consequently check the dependability aspects of the result: the compo-sition is a crucial process since it can impact on several aspects, as integrity,while decomposed modules still prove to be consistent. By using the projectionoperator (i.e. ⇓ in Sec. 2) on this policy, which consists in the composition (i.e.⊗ in Sec. 2) of different soft constraints, we obtain the external interface of theservice that are used to match the requests. This view can be used to check theintegrity of the system, that is if a particular service ensures the consistency ofactions, values, methods, measures and principles; as a remind, integrity is oneof the dependability attributes proposed in Sec. 3. The results presented hereare inspired by the work in [3], but applied to measure integrity in a pipelinedcomposition of photo-editing services.

For the scenario example in Fig. 8, let us suppose to have a digital photo edit-ing service decomposed as a set of sub-services; the compression/decompressionmodule (i.e. COMPF) is located on the client side, while the other filter modulesare located on the side of the editing company and can be reached through thenetwork. The first module, i.e. REDF absorbs green and blue and let only redbecome lighter and the BWF filter turns the colors in grey scale. The client wantsto compress (e.g. in a JPEG format) and send a remarkable number of photos(e.g. the client is a photo shop) to be double filtered and returned by the providercompany; filters must be applied in a pipeline scheme, i.e. BWF obviously goesafter REDF.

The structure of the system represented in Fig. 8 corresponds to a federatedsystem. It is defined as a system composed of components within different ad-ministrative entities cooperating to provide a service [2]; this definition perfectlymatches our idea of SOA.

Federated System

BWFREDFCOMPF

BW StaffRed Staff

Fig. 8. A federated photo editing system.

As a first example we consider the Classical semiring presented in Sec. 3,therefore, in practice we show a crisp constraint case. We suppose to have fourvariables outcomp, incomp, redbyte and bwbyte, which respectively represent

the size in bytes of the photo at the beginning of the process, after applying thered filter, after the black-and-white filter and after compressing the obtainedblack-and-white photo. Since the client has a limited memory space, it wantsthat the memory occupied by the photo does not increase after the filtering andcompressing process:

Memory ≡ incomp ≤ outcomp

The following three constraints represent the policies compiled respectivelyby the staff of the REDF module, the BWF module and COMPF module. Theystate, following their order, that applying the REDF filter reduces the size of theimage, applying the BWF filter reduces the size of the received image and, atlast, compressing the image reduces its size.

REDFilter ≡ redbyte ≤ bwbyte

BWFilter ≡ bwbyte ≤ outcomp

Compression ≡ incomp ≤ redbyte

The integration of the three policies (i.e. soft constraints) describes

Imp1 ≡ RedFilter ⊗ BWFilter ⊗ Compression

Integrity is ensured in this system since Imp1 ensures the high-level require-ment Memory.

Imp1⇓{incomp,outcomp} v Memory

We are unconcerned about the possible values of the ‘internal’ variablesredbyte and bwbyte and thus the constraint relation Imp1⇓{incomp,outcomp} de-scribes the constraints in Imp1 that exist between variables incomp and out-comp}. By definition, the above equation defines that all of the possible solutionsof Imp1⇓{incomp,outcomp} are solutions of Memory, that is, for any assignment η ofvariables then

Imp1⇓{incomp,outcomp} η ≤S Memory η

Definition 1. We say that the requirement S locally refines requirement R throughthe interface described by the set of variables V iff S⇓V v R⇓V.

Continuing the example in Fig. 8, we assume that the application systemwill behave reliably and uphold BWFilter and Compression. Let us supposeinstead that it is not reasonable to assume that REDF will always act reliably,for example because the software of the red filter has a small bug when the sizeof the photo is 666Kbyte. In practice, REDF could take on any behavior:

RedFilter ≡ (redbyte ≤ bwbyte ∨ redbyte > bwbyte) = true

Imp2 ≡ BWFilter ⊗ RedFilter ⊗ Compression

Imp2 is a more realistic representation of the actual filtering process. It moreaccurately reflects the reliability of its infrastructure than the previous designImp1. However, since redbyte is no longer constrained it can take on any value,and therefore, incomp is unconstrained and we have

Imp2⇓{incomp,outcomp} @ Memory

that is, the implementation of the system is not sufficiently robust to be ableto deal with internal failures in a safe way and uphold the memory probityrequirement.

In [16, 17] the author argues that this notion of dependability may be viewedas a class of refinement whereby the nature of the reliability of the system isexplicitly specified.

Definition 2. (Dependability and Constraints [3]) If R gives requirements for anenterprise and S is its proposed implementation, including details about the nature ofthe reliability of its infrastructure, then S is as dependably safe as R at interface that isdescribed by the set of variables E if and only if S⇓E v R⇓E

Quantitative analysis. When a quantitative analysis of the system is required,then it is necessary to represent these properties using soft constraints. This canbe done by simply considering a different semiring (see Sec. 3), while the sameconsiderations provided for the previous example with crisp constraints (byusing the Classical semiring) still hold.

With a quantitative analysis, now consider that we aim not only to havea correct implementation, but, if possible, to have the “best” possible imple-mentation. We keep the photo editing example provided in Fig. 8, but we nowrepresent the fact that constraints describe the reliability percentage, intended asthe probability that a module will perform its intended function. For example,the following (probabilistic) soft constraint c1 : {outcomp,bwbyte} →N→ [0, 1]shows how the compression reliability performed in BWFilter is linked to theinitial and final number of bytes of the treated image:

c1(outcomp, bwbyte) =

1 if outcomp ≤ 1024Kb,0 if outcomp > 4096Kb,

1 − outcomp100 · bwbyte otherwise.

c1 tells us that the compression does not work if the input image is more than4Mb, while is completely reliable if is less than 1Mb. Otherwise, this probabilitydepends on the compression efficiency: more that the image size is reducedduring the compression, more that it is possible to experience some errors, andthe reliability consequently decreases. For example, considering the definitionof c1, if the input image is 4096Kb and compressed is 1024Kb, then the probabilityassociated to this variable instantiation is 0.96.

In the same way, we can define c2 and c3 that respectively shows the reliabilityfor the REDFilter and Compression modules. Their composition Imp3 = c1 ⊗c2 ⊗ c3 represents the global reliability of the system. If MemoryProb is the softconstraint representing the minimum reliability that the system must provide(e.g. MemoryProb is expressed by a client of the photo editing system), then if

MemoryProb v Imp3

we are sure that the reliability requirements are entailed by our system.Clearly, MemoryProb can defined by the client in order to check if the servicesatisfies its integrity requirements. The soft constraint solver proposed in Sec. 4(as a part of the broker) implements all the operators to solve the related SCSP:⊗,÷, ⇓ andv. Moreover, by exploiting the notion of best level of consistency (seethe blevel in Sec. 2), we can find the best (i.e. the most reliable) implementationamong those possible.

At last, notice also that the projection operator (i.e. the ⇓ operator explainedin Sec. 2) can be used to model a sort of function declaration to the “outsideworld”: soft constraints represent the internal implementation of the service,while projecting over some variables leads to the interface of the service, that iswhat is visible to the other software components.

6 Trustworthy Coalitions of Services

Sometimes the orchestrator needs to merge together multiple services to capturewhat the user really wants. Moreover, a desired resource could be consumableand so, the same resource cannot be assigned to more then a user at a giventime. This leads to the problem of creating, from the existent set of resources, apartition of these, in order to adapt the environment to the needs of the user.At each request the orchestrator will create a partition of the resources in orderto fulfill the requirements. The web services that needs to interact to create thedesired composition of services, needs also to share the resources and to trustthemselves. This leads to the problem to not only build a coalition satisfying therequirements, but also to obtain coalitions satisfying several QoS requirements(and among these the dependability ones).

This Section is aimed at using soft constraints to groups together differentservices in order to obtain trustworthy coalitions. We partition the set of entitiesand therefore a single entity can appear in only one coalition at time. Thisscenario can be seen in practice as the problem of finding the best coalition ofservices according to different dependable attributes (see Sec. 3) and in orderto maximize the result of the obtained global service. We can suppose that eachcomponent has an estimation, based on given dependability metrics, of the trustlevel of the other components, and thus they all can be logically organized in anetwork, as shown in Fig. 9; the directed arcs represent the subjectivity of theestimation: in Fig. 9, from x1 to x2 means that x1 judges x2. In the following wesuppose that all these dependable measures are globally view as a single trust

value, since dependability is the ability to deliver a service that can justifiablybe trusted [1] (see Sec. 3).

x1

x2

x3

x4

x5

x6

x7

Fig. 9. A network of service components.

Cooperation involves a degree of risk arising from the uncertainties of in-teracting with autonomous self-interested agents, as distributes service compo-nents (e.g. web services). Trust [23] describes a nodes belief in another nodescapabilities, honesty and reliability based on its own direct experiences. There-fore trust metrics have been already adopted to perceive this risk, by estimatinghow likely other agents are to fulfill their cooperative commitments [20, 14].Since trust is usually associated with a specific scope [23], we suppose that thisscope concerns the task that the coalition must face after its formation; for ex-ample, in electronic marketplaces the agents in the same coalition agree witha specific discount for each transaction executed [14, 27]. Clearly, an entity canalso trust itself in achieving the task, and can form a singleton coalition.

C

C

1

2

x1

x2

x3

x4

x5

x6

x7

r

r

1

2

T (C x ) > T (C )1 14

r (t (x ,x ), t (x ,x ), t(x ,x )) > (t (x ,x ), t (x ,x ), t(x ,x ))1 r24 4 4 4 4 41 2 3 5 6 7

Fig. 10. A graphical intuition of two blocking coalitions.

In the individually oriented approach an agent prefers to be in the samecoalition with the agent with whom it has the best relationship [14]. In thesocially oriented classification the agent instead prefers the coalition in which ithas most summative trust [14]. To do so, in Def. 3 we formalize how to computethe trustworthiness of a whole coalition.

Definition 3. Given a coalition C of agents defined by the set {x1, . . . , xn} and a trustfunction t defined on ordered couples (i.e. t(xi, xy) is the trust score that xi has collectedon x j), the trustworthiness of C (i.e. T(C)) is defined as the composition (i.e. ◦) of the1-to-1 trust relationships, i.e. ∀xi, x j ∈ C. ◦ t(xi, x j) (notice that i can be equal to j,modeling the trust in itself).

The ◦ function models the composition of the 1-to-1 trust relationships. It canbe used to consider also subjective ratings [23] (i.e. personal points of view on thecomposition) or also objective ratings [23], to easily represent and compute trustwith a mathematical operator. For instance, some practical instantiations of the◦ function can be the arithmetic mean or the max operator: ∀xi, x j ∈ C. avg t(xi, x j)or ∀xi, x j ∈ C.max t(xi, x j). In general, the ◦ operator has no relation with theoperators of the semirings (i.e. + and ×), in the sense that it models the socialaggregation of the trust relationships among different entities. By changing thesemiring structure we can represent different trust metrics [10, 35]. Therefore,the optimization of the set of coalitions can follow different principles, as, forexample, minimizing a general cost of the aggregation or maximizing “con-sistency” evaluation of the included entities, i.e. how much their interests arealike.

Moreover, in order to represent more complex interactions among the entitiesand the coalitions, we propose also a mandatory stability condition that is ableto model a more local requirement of an entity, w.r.t. to the global optimizationconsidering all the formed coalitions. This stability can be described by definingblocking coalitions (see Def. 4). Definition 4 highlights just only one of the possiblestability conditions that can be cast in this framework.

Definition 4. Two coalitions Cu and Cv are defined as blocking if, an individualxk ∈ Cv exists such that, ∀xi ∈ Cu, x j ∈ Cv with j , k, ◦xi∈Cu t(xk, xi) > ◦x j∈Cv t(xk, x j)and T(Cu ∪ xk) > T(Cu) at the same time.

A set {C1,C2, . . . ,Cn} of coalitions is stable, i.e. is a valid solution, if no block-ing coalitions exist in the partitioning of the agents. An example of two block-ing coalitions is sketched in Fig. 10: if x4 prefers the coalition C1 (i.e. relation-ship r1 in Fig. 10) to the elements in its coalitions C2 (i.e. r2 in Fig. 10), i.e.◦(t(x4, x1), t(x4, x2), t(x4, x3)) > ◦(t(x4, x5), t(x4, x6), t(x4, x7)), and C1 increases itstrust value by having x4 inside itself, i.e. T(C1 ∪ x4) > T(C1), then C1 and C2 aretwo blocking coalitions and the partitioning {C1,C2} is not stable and thus, it isnot a feasible solution of our problem.

We therefore require the stability condition to be satisfied, but at the sametime we want also to optimize the trustworthiness of the partitioning given byaggregating together all the trustworthiness scores of the obtained coalitions.

6.1 A Formalization of the Problem

In this Section we define the soft constraints needed to represent the coalitionproblem. We adopt the Fuzzy semiring 〈[0, 1],max,min, 0, 1〉 in order to maxi-mize the minimum trustworthiness of all the obtained coalitions. The followingdefinition takes the general ◦ operator as one of its parameters: it can be con-sidered in some sense as a “lower level” operator with respect to the other twosemiring operators (i.e. + and ×).

The variables V of this SCSP (see Sec. 2) problem are represented by themaximum number of possible coalitions: {co1, co2, . . . , con} if we have to partitiona set {x1, x2, . . . , xn} of n elements. The domain D for each of the variables is thepowerset of the element identifiers, i.e. P{1, 2, . . . , n}; for instance, if η(co1) ={1, 3, 5} it means the the coalition co1 groups the elements x1, x2, x5 together(η : V → D is the variable assignment function shown in Sec. 2). Clearly,η(coi) = ∅ if the framework finds less than n coalitions.

1. Trust constraints. As an example from this class of constraint, the soft con-straint ct(coi = {1, 3, 5}) = a quantifies the trustworthiness of the coalitionformed by {x1, x3, x5} into the semiring value represented by a. According toDef. 3, this value is obtained by using the ◦ operator and composing all the1-to-1 trust relationships inside the coalition. In this way we can find thebest set of coalitions according to the semiring operators.

2. Partition constraints. This set of constraints is used to enforce that an elementbelongs only to one single coalition. For this goal we can use a binary crispconstraint between any two coalition, as cp(coi, co j) = 0 if η(coi) ∩ η(co j) , ∅,and cp(coi, co j) = 1 otherwise (with i , j). Moreover, we need to add one crispconstraint more, in order to check that all the elements are assigned to onecoalition at least: cp(co1, co2, . . . , con) = 0 if |η(co1) ∪ η(co2) ∪ · · · ∪ η(con)| , n,and cp(co1, co2, . . . , con) = 1 if |η(co1) ∪ η(co2) ∪ · · · ∪ η(con)| = n.

3. Stability constraints. These crisp constraints model the stability conditionas proposed in Def. 4. We have several ternary constraints for this goal:cs(cov, cou, xk) = 0 if k ∈ η(cov) (i.e. xk belongs to the cov coalition),◦i∈η(cou)t(xk, xi)> ◦ j∈η(cov)t(xk, x j) and ct(η(cou) ∪ k) > ct(cou). Otherwise, cs(cov, cou, xk) = 1.

7 Related Work

Other papers have been proposed in order to study dependability aspectsin SOAs, for example by using the Architecture Analysis and Design Language(AADL). In [32] the authors purpose a modeling framework allowing the gener-ation of dependability-oriented analytical models from AADL models, to facili-tate the evaluation of dependability measures, such as reliability or availability.The AADL dependability model is transformed into a Generalized Stochastic PetriNet (GSPN) by applying model transformation rules. A distinct approach [37]uses a methodology that first involves an extended UML representation for thearchitecture specification of composite web services; this extension is used tosupport the second step of the methodology, which comprises the specification

of properties characterizing the failure. Then, the third step consists in an auto-mated mapping of this extended UML model to Block Diagrams, Fault Trees andMarkov Models. The main difference w.r.t. our solution is that these two worksinitially adopt a descriptive language, that needs to be translated in somethingthat can be executed with a tool in order to find a solution. We do not have thistranslation step: we have only to describe the behavior of the software com-ponents with soft constraints (an “easy” task to do) and then a soft constraintsolver can find the best solution. In words, we only need to use a single andwell tested methodology, instead of extending and tying several frameworkstogether.

The frameworks presented in this paper can join the other formal approachesfor architectural notations: Graph-Based, Logic-Based and Process Algebra ap-proaches [13]. A formal foundation behind is definitely important, since, forexample, UML alone can offer a number of alternatives for representing ar-chitectures: therefore, this lack of precision can lead to a semantic misunder-standing of the described architectural model [19]. Compared to other formalmethods [13], constraints are very expressive and close to the human way ofdescribing properties and relationships; in addition, their solution techniqueshave a long and successful history [31]. The qualitative/quantitative architec-tural evaluation can be accomplished by considering different semirings (seeSec 2): our framework is highly parametric and can consequently deal withdifferent dependability or QoS metrics, as long as they can be represented assemirings.

Other works have studied the problem of issuing requests to a compositionof web services as a crisp constraint-based problem [25], but without optimiz-ing non-functional aspects of services, as we instead do with (semiring-based)soft constraints. For a more precise survey on the architectural description ofdependable software systems, please refer to [18].

8 Conclusions and Future Work

We have proved that soft constraints and their related operators (e.g ⊗, ÷, ⇓ inSec. 2) can model and manage the composition of services in SOAs by takingin account dependability metrics. The key idea is that constraint relationshipsmodel the implementation of a service component (described as a policy), whilethe “softness” (i.e. the preference value associated with the soft constraint)represents one or more dependability measures, as reliability, availability andso on (see Sec. 3). In this way, the composition of services can be monitored andchecked, and the best dependability result can be found on this integration.

We strongly believe that constraints are a natural framework to describeSOAs. It may also be desirable to describe constraints and capabilities (also,“policy”) regarding security, which is another issue studied in dependable sys-tems: a web service specification could require that, for example, “you MUSTuse HTTP Authentication and MAY use GZIP compression”.

Three different but very close contributions are collected in this work. Thefirst contribution in Sec. 5 is that the use of soft constraints permits us to performa quantitative analysis of system integrity. The second contribution, explained inSec. 2.1, proposes the use of formal language based on soft constraints in orderto model the composition of different service components while monitoringdependability aspects at the same time. The third result (see Sec. 6) shows howservice components can be grouped together in order to create trustworthycoalitions of them. Trust is a fundamental concept at the root of dependability.

All the models and techniques presented in this work can be implementedand integrated together in a suite of tools, in order to manage and monitordependability while building SOAs; this goal clearly represents our principalfuture work. To accomplish this task, we could program it from scratch or wecould also extend an existent solver as Gecode [33], which is an open, free,portable, accessible, and efficient environment for developing constraint-basedsystems and applications. The main results will be the development of a SOAquery engine, that will use the constraint satisfaction solver to select whichavailable service will satisfy a given query. It will also look for complex servicesby composing together simpler service interfaces.

References

1. A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomyof dependable and secure computing. IEEE Transactions on Dependable and SecureComputing, 1(1):11–33, 2004.

2. P. Bhoj, S. Singhal, and S. Chutani. SLA management in federated environments.Comput. Networks, 35(1):5–24, 2001.

3. S. Bistarelli and S. N. Foley. A constraint framework for the qualitative analysisof dependability goals: Integrity. In S. Anderson, M. Felici, and B. Littlewood,editors, SAFECOMP, volume 2788 of Lecture Notes in Computer Science, pages 130–143. Springer, 2003.

4. S. Bistarelli, M. Gabbrielli, M. C. Meo, and F. Santini. Timed soft concurrent constraintprograms. In Doug Lea and Gianluigi Zavattaro, editors, COORDINATION, volume5052 of Lecture Notes in Computer Science, pages 50–66. Springer, 2008.

5. S. Bistarelli and F. Gadducci. Enhancing constraints manipulation in semiring-basedformalisms. In European Conference on Artificial Intelligence (ECAI), pages 63–67,August 2006.

6. S. Bistarelli, U. Montanari, and F. Rossi. Semiring-based constraint satisfaction andoptimization. J. ACM, 44(2):201–236, 1997.

7. S. Bistarelli, U. Montanari, and F. Rossi. Soft concurrent constraint programming.ACM Trans. Comput. Logic, 7(3):563–589, 2006.

8. S. Bistarelli, U. Montanari, and F. Rossi. Semiring-based Constraint Solving andOptimization. Journal of the ACM, 44(2):201–236, March 1997.

9. S. Bistarelli and F. Rossi. Semiring-based soft constraints. In P. Degano, R. De Nicola,and J. Meseguer, editors, Concurrency, Graphs and Models, volume 5065 of LectureNotes in Computer Science, pages 155–173. Springer, 2008.

10. S. Bistarelli and F. Santini. Propagating multitrust within trust networks. In SAC ’08:Proceedings of the 2008 ACM symposium on Applied computing, pages 1990–1994, NewYork, NY, USA, 2008. ACM.

11. S. Bistarelli and F. Santini. A nonmonotonic soft concurrent constraint language forsla negotiation. Electr. Notes Theor. Comput. Sci., 236:147–162, 2009.

12. Stefano Bistarelli. Semirings for Soft Constraint Solving and Programming, volume 2962of Lecture Notes in Computer Science. Springer, London, UK, 2004.

13. J.S. Bradbury, J. R. Cordy, J. Dingel, and M. Wermelinger. A survey of self-management in dynamic software architecture specifications. In WOSS ’04: Pro-ceedings of the 1st ACM SIGSOFT workshop on Self-managed systems, pages 28–33, NewYork, NY, USA, 2004. ACM.

14. S. Breban and J. Vassileva. A coalition formation mechanism based on inter-agenttrust relationships. In AAMAS ’02: Proceedings of the first international joint conferenceon Autonomous agents and multiagent systems, pages 306–307, New York, NY, USA,2002. ACM.

15. Frank S. de Boer, Joost N. Kok, Catuscia Palamidessi, and Jan J. M. M. Rutten. Non-monotonic concurrent constraint programming. In ILPS, pages 315–334, 1993.

16. S. N. Foley. Evaluating system integrity. In NSPW ’98: Proceedings of the 1998 workshopon New security paradigms, pages 40–47, New York, NY, USA, 1998. ACM.

17. S.N. Foley. A non-functional approach to system integrity. IEEE Journal on SelectedAreas in Commications, 2003. forthcoming.

18. C. Gacek and R. de Lemos. Architectural description of dependable software systems.In D. Besnard, C. Gacek, and C. Jones, editors, Structure for Dependability: Computer-Based Systems from an Interdisciplinary Perspective, pages 127–142. Springer-Verlag,January 2006.

19. D. Garlan, S.-W. Cheng, and A. J. Kompanek. Reconciling the needs of architecturaldescription with object-modeling notations. Sci. Comput. Program., 44(1):23–49, 2002.

20. N. Griffiths and M. Luck. Coalition formation through motivation and trust. InAAMAS ’03: Proceedings of the second international joint conference on Autonomous agentsand multiagent systems, pages 17–24, New York, NY, USA, 2003. ACM.

21. IFIP. IFIP WG 10.4 on dependable computing and fault tolerance. Technical report,International Federation For Information Processing,, 1998.

22. B.C.W. Lan J.-Y. Chung, S.J.H. Yang. Extending trust computing with service orientedarchitecture. Information Assurance and Computer Security, 6:69–83, 2006.

23. A. Jøsang, R. Ismail, and C. Boyd. A survey of trust and reputation systems foronline service provision. Decis. Support Syst., 43(2):618–644, 2007.

24. A. Keller and H. Ludwig. The WSLA framework: Specifying and monitoring servicelevel agreements for web services. J. Netw. Syst. Manage., 11(1):57–81, 2003.

25. A. Lazovik, M. Aiello, and R. Gennari. Encoding requests to web service composi-tions as constraints. In Conference on Principles and Practice of Constraint Programming(CP’05), pages 782–786, 2005.

26. K. Lee, W. Lee J. Jeon, S.-H. Jeong, and S. W. Park. Qos for web services: Requirementsand possible approaches, 2003. W3C Note, available at http://www.w3c.or.kr/kr-office/TR/2003/ws-qos/.

27. K. Lerman and O.Shehory. Coalition formation for large-scale electronic markets. InICMAS, pages 167–174. IEEE Computer Society, 2000.

28. M. P. Papazoglou. Service -oriented computing: Concepts, characteristics and direc-tions. Web Information Systems Engineering, International Conference on, 0:3, 2003.

29. M. P. Papazoglou and D. Georgakopoulos. Service-oriented computing. Commun.ACM, 46(10), 2003.

30. C. Peltz. Web services orchestration and choreography. Computer, 36(10):46–52, 2003.31. F. Rossi, P. van Beek, and T. Walsh. Handbook of Constraint Programming (Foundations

of Artificial Intelligence). Elsevier Science Inc., New York, NY, USA, 2006.

32. A.-E. Rugina, K. Kanoun, and M. Kaaniche. A system dependability modeling frame-work using aadl and gspns. In Rogerio de Lemos, Cristina Gacek, and Alexander B.Romanovsky, editors, WADS, volume 4615 of Lecture Notes in Computer Science, pages14–38. Springer, 2006.

33. C. Schulte. Programming Constraint Services, volume 2302 of Lecture Notes in ArtificialIntelligence. Springer-Verlag, 2002.

34. M. A. Serhani, R. Dssouli, A. Hafid, and H. Sahraoui. A qos broker based architecturefor efficient web services selection. In ICWS ’05: Proceedings of the IEEE InternationalConference on Web Services, pages 113–120, Washington, DC, USA, 2005. IEEE Com-puter Society.

35. G. Theodorakopoulos and J. S. Baras. Trust evaluation in ad-hoc networks. In WiSe’04: Proceedings of the 3rd ACM workshop on Wireless security, pages 1–10, New York,NY, USA, 2004. ACM.

36. T. Yu and K.-J.Lin. A broker-based framework for qos-aware web service composi-tion. In EEE ’05: Proceedings of the 2005 IEEE International Conference on e-Technology,e-Commerce and e-Service (EEE’05) on e-Technology, e-Commerce and e-Service, pages22–29, Washington, DC, USA, 2005. IEEE Computer Society.

37. A. Zarras, P. Vassiliadis, and V. Issarny. Model-driven dependability analysis ofwebservices. In Robert Meersman and Zahir Tari, editors, CoopIS/DOA/ODBASE (2),volume 3291 of Lecture Notes in Computer Science, pages 1608–1625. Springer, 2004.