Automated Analysis of Conflicts in WS-Agreement

IEEE

Proo

f

Automated Analysis of Conflictsin WS-Agreement

Carlos Muller, Manuel Resinas, and Antonio Ruiz-Cortes

Abstract—WS-Agreement is one of the most widely used SLA specifications. An advantage of WS-Agreement over other agreementmetamodels is that it allows one to define conditional and optional term sets inside an agreement document, which arecommonly found features in real-world agreements. Unfortunately, they increase the complexity of the automated detection andexplanation of conflicts between SLA terms, leading to new kinds of conflicts that are not supported by current techniques.Furthermore, creating a general-purpose conflict analyser in WS-Agreement is a hard task since it should understand thesemantics of an unbounded number of languages that can be used in the eight extension points that WS-Agreement includesfor the sake of flexibility. In this article, we address these issues by providing a conflict classification for SLAs that includes newconflicts derived from the use of conditional and optional term sets; and a novel language-agnostic technique based onconstraint satisfaction problems to automatically detect and explain these conflicts. In pursuing these results, we defined someWS-Agreement concepts as well as a fully-fledged WS-Agreement-compliant language. The developed technique and itsreference implementation have been thoroughly validated.

Index Terms—Service level agreement, SLA, WS-agreement, conflict management, consistency

Ç

1 INTRODUCTION AND MOTIVATION

SERVICE Level Agreements (SLA) play an important roleduring the entire life-cycle of a service-based applica-

tion (SBA) because they establish the functional and qualityaspects of SBAs between providers and consumers orservice integrators [2]. Although there is no commonlyaccepted way to describe SLAs, it ranges over a variety ofapproaches that include: the use of natural language inSLAs intended to be used only by humans1; the use offormal languages with the intention of analyzing someproperties of the SLA [3], [4], [5], and the use of XMLdocuments in standardization efforts aimed at making theinteroperability between consumers and providers easier[6], [7], [8]. One of the most widely used SLA standards isWS-Agreement [6], a proposed recommendation of theOpen Grid Forum2 that provides a protocol for establishingagreements between two parties using an extensible XMLlanguage for specifying agreements; and agreement tem-plates to facilitate discovery of compatible agreementparties.

An advantage of WS-Agreement over other agreementmetamodels is that it includes several aspects that arenecessary to model real-world agreements, namely: 1) condi-

tional terms, i.e., terms whose service level objective (SLO),which defines the agreed quality of service, is subject to aqualifying condition (QC); and 2) terms compositors (TC)that enable the inclusion of optional term sets inside anagreement document. For instance, the AmazonS3 SLAguarantees a DataDurability9¼ 99:999999999%, but only ifthe consumer does not request the Reduced RedundancyStorage (RRS) (which is cheaper than default redundancycheck), i.e., ‘‘RRS is false’’ is the QC of the agreement termthat guarantees the DataDurability. In addition, the SLAprovides several client support features such as an onlinereporting support, a turn around time of 15 minutes to solveproblems, a phone support, an extended support and so on.All of them can be modelled as optional terms by means ofTCs to allow clients to choose a customized support plan.Unfortunately, these aspects increase the complexity of theagreements and, hence, the complexity of the tools to managethem. As a result they are not usually supported despite theirimportance to model real-world SLAs. In fact, a comparisonof eight WS-Agreement implementations [9] reveals that onlyone of them (Phosphorus-WSAG4U) supports TCs and onlyanother different one (AssessGrid) supports QCs.

A part of the SLA management whose complexityincreases significantly is the automated detection andexplanation of conflicts that may appear between SLAterms, such as inconsistencies, a type of conflict thatinvolves semantics contradictions between terms. This isa key part of the agreement creation process and it hasreceived significant attention by the research community.In particular, a number of approaches focus on detectinginconsistencies that affect the whole agreement [3], [4].Other proposals go further and also report some explana-tion for such inconsistencies [1]. However, these proposalsare not well suited to deal with SLAs that include QCs aTCs because of two reasons. First, not all proposals are able

. The authors are members of the Applied Software Engineering Group(ISA, www.isa.us.es), ETS. Ingenierıa Informatica, University of Seville,Sevilla 41012, Spain. E-mail: {cmuller, resinas, aruiz}@us.es.

Manuscript received 3 Aug. 2012; revised 1 Feb. 2013; accepted 7 Feb. 2013.Date of publication 18 Feb. 2013.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference the Digital Object Identifier below.Digital Object Identifier no. 10.1109/TSC.2013.9

1. For instance, the SLAs of companies such as Amazon(aws.amazon.com/s3-sla/) or Google(www.google.com/apps/intl/en/terms/sla.html)

2. www.ogf.org

1939-1374 � 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 2014 1

IEEE

Proo

f

to deal with the additional complexity that these aspectsinvolve. For instance, [3], [5] do not consider neither QCsnor TCs. Second, these aspects lead to types of conflictsdifferent than inconsistencies that are not supported bycurrent techniques. These new types of conflicts arisebecause QCs and TCs introduce optional terms and, hence,conflicts may appear in optional parts of the SLA withoutinvalidating the whole document. Thus, a proposal thatonly detect inconsistencies that affect the whole agreementmay incorrectly consider an SLA as conflict-free if itsconflicts only affect optional or conditional terms.

Furthermore, the extension mechanism of WS-Agreementposes an additional problem in the automated detection andexplanation of conflicts in WS-Agreement documents.Contrary to what could be thought, WS-Agreement doesnot provide a fully-fledged language for specifying agree-ment documents. Instead, it defines a general-purposeschema that can and must be complemented with a set oflanguages to specify several parts of the agreement docu-ment such as service description terms or service levelobjectives. Many different languages such as JSDL (JobSubmission Description Language) and the WSLA [8]expression language, have been used for this task sinceWS-Agreement do not impose additional constraints on theirexpressiveness. In this paper, we call sublanguages (SubLs)to those languages that can be used within a WS-Agreementdocument.

Consequently, the first thing one has to do to create aWS-Agreement document is to decide which are the SubLsthat are going to be used in it. We call a WS-AgreementConfiguration (WSAC) to the set of SubLs used within agiven WS-Agreement document. For instance, the WSACused by the WSAG4J framework3 involves using JSDL asthe language for specifying service description terms andJEXL as the language for specifying service level objectives.SWAPS [10] also proposes a WSAC by using WSDL-S/OWL as SubLs for the service functionality, and WSLA [8]expression language as SLOs SubL. A complete example ofWSAC is included in Section 4.1.

These extension points are a great advantage of WS-Agreement since they make it possible to use WS-Agreementin an unbounded number of different ways [11]. However, asusual, this advantage comes with a price for WS-Agreementusers: the difficulty of creating a general-purpose tool sincesuch a tool should deal with the great variety of SubLs thatcan be used in different WS-Agreement documents. Thisproblem gets even harder for conflict analysis since the toolshould understand not only the SubLs syntaxes, but also theirsemantics.

In this paper, we face the aforementioned problems toenable the automated detection and explanation of conflictsin WS-Agreement documents. In particular, this papercontributes to the research on SLAs analysis in general andWS-Agreement in particular in the following ways:

First, we propose a novel classification of conflicts forSLAs as well as a rigorous definition for each of them. Theclassification identifies three kinds of conflicts that can befound in two possible scopes including the only conflict

already identified in the literature (i.e., inconsistencies thataffect the whole agreement) and those we have found whileapplying our proposal to several scenarios (cf. Section 6).Furthermore, the classification is WSAC-agnostic.

Second, we propose a technique based on constraintsatisfaction problems (CSP) [12] that allows the use of anyoff-the-shelf CSP solver to automatically detect and explainthese conflicts in WS-Agreement documents. The onlyrequirement is that the semantics of the SubLs used in theWS-Agreement document can be interpreted as a CSP. Thisrequirement is quite reasonable since, according to [4], itcan be assumed that for automated analysis purposes anySLA can be interpreted as a CSP regardless of the specifica-tion language. In this paper, to illustrate this technique, wedetail how this mapping can be done with WS-Agreementdocuments specified with a WSAC called iAgree [13]. Themain features of the SubLs of iAgree are: 1) they are endowedwith a precise semantics provided by the semantic mappingto CSPs (cf. Section 4.2), 2) they are general-purpose,meaning that they can be used regardless of the domain ofthe agreement, and 3) they are expressive enough to definemany real-world SLAs (cf. Section 6).

The developed technique comes with a publicly-avail-able reference implementation, SLA Explainer from nowon, that support WS-Agreement documents specified withiAgree WSAC. Therefore iAgree is the first general-purposeWSAC proposed with support for conflicts detection andexplanation. Furthermore, an advantage of using iAgree isthat the mechanism to detect and explain conflicts can bedirectly used with any WS-Agreement document whoseWSAC is iAgree or can be mapped into iAgree. In ourvalidation, we have successfully mapped the WSACs usedin WSAG4J framework and SWAPS (cf. Appendices A andE), which suggests that iAgree is generic enough toaccommodate a significant variety of WSACs, although adetailed evaluation in this direction is out of the scope ofthis paper. We are convinced that as well as the inherentvalue of our techniques, the development of adaptable andeasy to use open source tooling support has been a decidingfactor for the adoption of SLA Explainer by users fromdifferent domains and with different WSACs and needs.We are aware that SLA Explainer is merely a first step, but itsimplifies the development of tools that have to manageagreement documents in general and WS-Agreementdocuments in particular because it ensures the assumptionthat said documents are free of conflicts. SLA Explainer hasbeen validated not only by other researchers in thecommunity, but also in a real SOA-Governance system ofour Regional Government, and in an end-user monitoringplatform [14].

The paper is organized as follows. Section 2 provides anoverview of WS-Agreement and introduces our definitionof variants in a WS-Agreement document. Our conflictclassification is described in Section 3. Section 4 discussesthe process to automate the detection and explanation ofconflicts by using CSP. Section 5 describes the majorfeatures and implementation issues of SLA Explainer anda prototypical implementation, while Section 6 reports onits use in a number of different scenarios. Related work isdiscussed in Section 7 and, finally, conclusions and futurework are drawn in Section 8.

3. WS-Agreement framework for Java developed by GRAAPmembers http://packcs-e0.scai.fraunhofer.de/wsag4j/index.html

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 20142

IEEE

Proo

f2 UNDERSTANDING WS-AGREEMENT DOCUMENTS

In this section, we briefly discuss the structure and semanticsof the XML-based schema proposed in WS-Agreementrecommendation [6] for agreement documents as well asthe SubLs that are necessary to get a WSAC. Fig. 2 depicts anexample of WS-Agreement document using a human-friendly syntax instead of XML for the sake of clarity. TheWSAC used in the example is our general-purpose WSAC so-called iAgree [13].

2.1 WS-Agreement Documents: An OverviewThe WS-Agreement recommendation specifies two types ofagreement documents to reach an agreement between theinterested parties: agreement offers and templates.

The most common usage scenario of WS-Agreementstarts with a pre-defined agreement template. A template isa partially completed offer that specifies customizableaspects of the documents, and rules that must be followedin creating an agreement, which are called agreementcreation constraints. Fig. 2 depicts a template created by acompany that provides a language translation service.Once the template is published, any customer demandingthe translation service creates an agreement offer compli-ant with the published template and initiates the process bysending it to the provider. Finally, the provider eitheraccepts or rejects the agreement offer. If accepted, such anoffer becomes the agreement4 that regulates the serviceprovision. As can be seen, the customer initiates theinteraction and therefore it plays the role initiator in theagreement creation process, whereas the provider playsthe role responder.

Although the previous is the usual usage scenario, twoadditional considerations are included in WS-Agreement.First, the publication of a template is optional and thus, any

party may send an agreement offer to other party withoutany template published. However, the acceptance of anagreement offer is more likely if it is defined based on apreviously published template. Second, although theservice provider usually acts as responder, WS-Agreementalso allows consumers to play the role of responders bypublishing templates with the service they intend toconsume and some desired guarantees.

The general structure of WS-Agreement documents isdepicted in Fig. 1 from an abstract point of view. The smallwhite boxes represent the SubLs a user must define todescribe the corresponding element of WS-Agreementdocuments. Thus, a WS-Agreement document is composedof an agreement identifier, an agreement context, and agreementterms. Templates can also include agreement creation con-straints to restrict the space of template-compliant offers thatcan be created from them.

The agreement context contains information aboutwhether the service provider is the agreement initiator orresponder, which is the information that is included in Fig. 2.In addition, it optionally provides information about theagreement parties endpoints, the agreement’s lifetime,references to the template from which the offer is createdif this is the case; and any other relevant information suchas the metrics datatype and domain included Fig. 2.

Fig. 2. WS-Agreement template of the translation service scenario usinga human-friendly syntax.

4. From now on, we will use SLA and agreement as synonyms.

Fig. 1. WS-Agreement documents structure overview.

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 3

IEEE

Proo

f

The terms section of a WS-Agreement document describesboth the characteristics of the services to be provided and theguarantees on such services. In WS-Agreement there are twokinds of terms, namely service terms and guarantee terms.

Service terms describe those service features that arerelevant for an agreement and can be divided into servicedescription terms, service properties, and service references.Service description terms (SDT) define the features of theservice that will be delivered under an agreement. Inaddition, when they appear in templates, as in document ofFig. 2 for TranslationLangs, they are considered asdefault values that can be changed by the other partyaccording to their domains and the constraints included inthe template (see creation constraints at the end of thesection). How these service description terms are orga-nized and expressed must be defined in one or more SubLs.For instance, in our example, we use the iAgree SubLsyntax to describe the translation service by means of a setof attribute-value pairs, namely: the supported translations(TranslationLangs), the input and output files, the sizelimit of the text to translate, whether the consumer wants totranslate images or not, and the service cost. Serviceproperties (SP) define named, service-related sets ofmonitorable variables that can be used for the specificationof guarantee terms and must be therefore considered foragreement monitoring. All variables must be related to aservice description term or a part of it and they may includea metric definition to specify the semantics and type of avariable with one or more SubLs. In our example, thecontext includes such metrics definition for the two definedproperties: 1) TranslationTime represents the time theservice translation takes; and 2) InputErrors representsthe percentage of spelling and grammar errors in theInputFile. Finally, Service references provide endpointreferences for the services under agreement and they alsoneed one or more specific SubLs to be defined.

Guarantee terms (GT) describe the SLOs that an obligatedparty, usually the service provider, must fulfil as part of theagreement (see guaranteed by. . . in figures). The SLO of aguarantee term is an assertion defined over monitorablevariables defined in the service properties section of theagreement document, and over external factors such asdate, time, etc. Each guarantee term can be guarded by anoptional qualifying condition (QC) that expresses a precon-

dition under which the guarantee holds. Thus, using QCs isthe way WS-Agreement allows for defining conditionalterms. Both QCs and SLOs can be expressed using anysuitable assertion language and so, users must specifySubLs for them. The structure of a guarantee term alsoincludes a scope to which the guarantee is applied and a listof business values. However, these two elements are out of thescope of this paper. In our example, the provider assuresdiverse translation times depending on the selection of thetranslation of images. It also includes a guarantee term toassure that the source text to translate sent by the consumerhas less than 1 percent errors of typos.

Finally, creation constraints specify the mandatorypresence of specific elements in the offers created fromthe template, and their acceptable values. To this end, thetemplate may define specific items using XML Schema [15]to delimit the possible value assignments for the servicefeatures defined in the SDTs or, if the creation constraintinvolves several elements, they can be specified using anysuitable constraints language that must be described bymeans of one or more SubLs. Since items can be consideredas a particular case of constraints, we just use the latter inFig. 2. For instance, simple constraints are used to set theallowed translations, or the size of the text to be translated,while more advanced constraints depending on theselected optional features are also included to specifyhow the cost of the service is calculated.

2.2 Variants in a WS-Agreement DocumentThe terms in a WS-Agreement document can be groupedusing and, or and xor-like compositors. In an and-like (All)compositor, every comprised term or compositor is man-datory i.e., all of them must be fulfilled. All terms at the toplevel of the terms section must be inside an and-likecompositor, as depicted in Fig. 2. In an or-like (OneOrMore)compositor, every comprised term or compositor isoptional. i.e., a set of them, at least one, must be fulfilled.Finally, in a xor-like (ExactlyOne) compositor, everycomprised term or compositor is alternative. i.e., only oneof them must be fulfilled.

Furthermore, term compositors can be nested, thusenabling the specification of alternative branches withpotentially complex nesting within the agreement terms.Choices expressed using compositors can be exercised bythe party that makes the next step in the agreement creationprocess, i.e., by the agreement initiator if it is creating anoffer from a template, by the agreement responder if it iscreating an agreement from an offer, or by the serviceprovider if it is delivering the service according to apreviously created agreement. For instance, document ofFig. 3 offers the alternative of either choosing GT1 orchoosing GT2 and one or more terms between GT3 andGT4. SDT1 is not an optional term since it is in the top-leveland-like compositor.

Note that parties can exercise the choice but it is notmandatory to do so. In other words, the term compositorscan remain in an offer and even in a final agreement,exactly as they were defined in the former template.

Given this structure of term compositors in a WS-Agreement document, it is possible to analyse them toidentify all of the sets of terms that can be chosen in the next

Fig. 3. An example of nested term compositors.

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 20144

IEEE

Proo

f

step of the agreement creation process. For instance, fromthe document of Fig. 3, it is possible to choose the sets ofterms depicted in Fig. 4. We call variant to each of those setsof terms that can be chosen in one WS-Agreementdocument. Consequently, term compositors can be seenas a means to define the variability of a WS-Agreementdocument in terms of the variants that can be chosen by theparty that makes the next step in the agreement creationprocess. To obtain these variants it is necessary to follow arecursive procedure that iterates through the nested termcompositors, and processes them according to theirsemantics. More specifically, let variantsðtÞ be a functionthat, given a term, returns the set of variants that it defines,then variantsðtÞ can be defined as follows:

If term t is not a composite term, then variantsðtÞ ¼ ftg.If term t is a composite term, CðT Þ, where T is the set of

composed terms, T ¼ ft1; . . . ; tng, then

variantsðCðT ÞÞ¼

Sp2PðT Þ�˘

variants AllðpÞð Þ ð1Þ

Sni¼1

ji

� �jVni¼1

ji 2 variantsðtiÞ� �

ð2ÞSni¼1

variantsðtiÞ ð3Þ

8>>>>><>>>>>:

9>>>>>=>>>>>;

where PðSÞ is the power set of S and 1), 2) and 3) dependson the type of term compositor Cðt1; . . . ; tnÞ:

1. If term compositor C is OneOrMore, then everycomposed term is optional, but there must be at leastone term selected. Therefore, the variants are allcombinations of the composed terms. For instance,in the previous example, the variants of the one ormore compositor are fGT3; GT4; fGT3; GT4gg. Notethat, in the definition, the use of variantsðAllðpÞÞ isnecessary due to the nesting of term compositors, i.e.,the terms nested in a one or more compositor could beterm compositors themselves.

2. If term compositor C is All, then every composedterm is mandatory. Therefore, the variants shouldalways contain one variant of each of the composedterms. For instance, in the previous example, thevariants of the nested All compositor always containone variant of GT2, which is fGT2g, and one variantof OneOrMoreðGT3; GT4Þ, which are fGT3; GT4;fGT3; GT4gg. Consequently, the variants of thiscompositor are: ffGT2; GT3g; fGT2; GT4g; fGT2;GT3; GT4gg.

3. If term compositor C is ExactlyOne, then every com-posed term is an alternative. Therefore, the variantsof the ExactlyOne compositor are all of the variantsof each composed terms. For instance, in theprevious example, the variants of the ExactlyOnecompositor are the union of the variants of GT1,which is fGT1g, and the variants of AllðOneOrMore

ðGT2; GT3ÞÞ, calculated above. Hence, the variantsof the ExactlyOne compositor are: fGT1; fGT2;GT3g; fGT2; GT4g; fGT2; GT3; GT4gg.

3 CLASSIFICATION OF CONFLICTS

In this paper, we propose a novel classification thatincludes all the conflicts that we have found in our use ofWS-Agreement. Conflicts in WS-Agreement can be classi-fied attending to two different criteria: the type of conflictand its scope.

3.1 Types of ConflictsAll of the literature related to conflicts in SLAs focus oninconsistencies exclusively. However, the use of qualifyingconditions in guarantee terms leads to other types ofconflicts, namely dead terms and conditionally inconsis-tent terms. Moreover, according to the experience of usersvalidating our proposal (see Section 6), these conflicts aremore common than inconsistencies since they are harder todetect because they usually involve relationships amongstseveral properties. Next, we detail these types of conflicts.

3.1.1 InconsistenciesA contradiction between terms, parts of terms, or creationconstraints, and all of these amongst themselves (e.g.,‘‘InputErrors G 1 & InputErrors ¼ 1’’ in the same ex-pression) constitute an inconsistency of the WS-Agreementdocument. This means that it is impossible to find asatisfactory assignment to the variables that appear inthose terms or creation constraints. The consequence is thatthe whole document (or one or more variants) is invali-dated because it will never be fulfilled regardless of theway the service is provided. For instance, document ofFig. 5 includes an inconsistency between the SLO of GT4and the creation constraint C2 because they state contra-dictory expressions. This contradiction may occur in thereal world if the provider tries to obtain a minimum benefitby imposing a minimum file size in the GT4 term, due to thetranslation service cost depends on such size (see the costcreation constraints of Fig. 2). However, the templateowner skips the C2 creation constraint by mistake.

3.1.2 Dead TermThis conflict is caused when the condition of a conditionalterm never holds in a document or one or more variants. Inother words, a dead term is a guarantee term whosequalifying condition has a contradiction with itself or oneor more terms and/or creation constraints of the document

Fig. 4. Enumeration of all of the variants defined by the term compositorsin document of Fig. 3.

Fig. 5. Document with an inconsistency between a GT and a creationconstraint.

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 5

IEEE

Proo

f

making the term dead because its SLO can never be appliedsince its precondition never holds. For instance, documentof Fig. 6, includes a dead term (GT5) because its qualifyingcondition can never be satisfied (by the SLO of the GT3guarantee term). This contradiction may occur in the realworld if the template owner is the provider and he/sheonly considers their guaranteed terms (GT5) while editing,skipping terms guaranteed by the other party (GT3), bymistake.

3.1.3 Conditionally Inconsistent TermThis conflict is caused when a conditional term makes thedocument inconsistent when its condition holds, whichcontradicts usual expectations. In other words, a condition-ally inconsistent term is a guarantee term with the followingcharacteristics: 1) it is not inconsistent, and 2) when itsqualifying condition holds, then its SLO does not holdbecause of a contradiction within itself, with the qualifyingcondition or with other terms or creation constraints of theWS-Agreement document. Consequently, the conditionallyinconsistent term is one that when the qualifying conditionholds, the SLO and, hence, the guarantee term, does nothold. For instance, the GT12 term of Fig. 7 is conditionallyinconsistent because when its qualifying condition enablesthe SLO, such SLO is contradictory with the GT6 SLO. Thiscontradiction may occur in the real world if the templateowner tries to obtain a minimum benefit by imposing aminimum file size (as in the GT6 term), since the translationservice cost depends on such size (see creation constraintsof Fig. 2). However, in a further revision of the template, theprovider decides to reduce the file size of FR_to_EStranslations due to technical problems. The provider skipsthat GT6 term applies to every language and therefore, theconditionally inconsistent GT12 does not allow reachingagreements for any FR_to_ES translations.

3.2 Scope of ConflictsAs stated in Section 2.2, term compositors enable thedefinition of variants in a WS-Agreement document.Therefore, depending on the term or terms that are

involved in a conflict, it may affect all of the variants of aWS-Agreement document or just some of them.

3.2.1 Total ConflictsWhen a conflict affects all of the variants of a document. Forinstance, assuming that there are no term compositors inthe examples of the previous section, the scope of all thoseconflicts is total.

3.2.2 Partial ConflictsWhen a conflict only affects a subset of the variants of adocument. For instance, document of Fig. 8 has a set ofterms composed by the ExactlyOne term compositor. Itdefines two variants, namely: {GT3, GT1, C1} and {GT3,GT2, C1}. The first variant includes a dead term becausethe QC of GT1 never holds since it contradicts the creationconstraint. However, in the second variant there is noconflict because it does not contain guarantee term GT1.Therefore the scope of the conflict is partial since it onlyaffects one variant of the document.

Another example of partial conflicts can be found indocument of Fig. 9. It has a set of optional guarantee terms(GT1, GT2 and GT3) by the OneOrMore term compositor.However, GT2 and GT3 are contradictory. Therefore, everyvariant that contains both GTs is inconsistent. However,since they are optional, there are other variants in which

Fig. 6. Document with a dead GT caused by another GT.

Fig. 7. Document with a conditionally inconsistent GT caused byanother GT.

Fig. 8. WS-Agreement document with a partial dead term originated by acontradiction between the QC of GT1 and the creation constraint.

Fig. 9. WS-Agreement document with a partial inconsistency.

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 20146

IEEE

Proo

f

they do not appear together. Consequently, in thisdocument there is an inconsistency conflict with a partialscope.

4 AUTOMATING THE DETECTION ANDEXPLANATION

In the previous section, we have provided a description ofthe different kinds of conflicts that can be found in a WS-Agreement document. However, its semantics has beendefined in an intuitive way. In this section, we provide aprecise definition of them by means of a semantic mapping.A semantic mapping is a way to provide semantics to amodel, in this case WS-Agreement documents, by mappingthe concepts into a semantic domain, i.e., a target domainwhose semantics has been formally defined [16].

The advantage of defining such semantic mapping isthat it allows one to use the techniques specific to the targetsemantic domain for analysing the source models [17]. Thiscan be done following a process such as that depicted inFig. 10. In that process, a WS-Agreement model is mappedinto a semantic domain, in which an automated techniqueis used to identify and explain the conflicts in a WS-Agreement model, and then, these results are traced backand returned as elements of the WS-Agreement metamodel.

There are several possible semantic domains into whichWS-Agreement documents can be mapped such as de-scription logics [10] or event calculus [18]. In our case, wehave chosen constraint satisfaction problems (CSP) [12] asthe semantic domain for our mapping. A CSP is a three-tuple of the form ðV;D; CÞ where V 6¼ ˘ is a finite set ofvariables, D 6¼ ˘ is a finite set of domains (one for eachvariable) and C is a constraint defined on V . Consider, forinstance, the CSP: ðfa; bg; f½0; 2�; ½0; 2�g; faþ b G 4gÞ. A solu-tion of such CSP is whatever valid assignment of allelements in V that satisfies C. (2,0) is a possible solution ofprevious example since it verifies that 2þ 0 G 4.

CSPs have been chosen because of two major reasons.Firstly, the most significant part of an agreement is a set ofconstraints that are set on some properties or descriptionsof the service and, therefore, CSPs can be used to describethis problem in a very natural way as we have shown inprevious work [4]. Secondly, there is a plethora of CSPsolvers available that supports a wide range of constraintsand can be used to automatically analyse the WS-Agreementdocument in an efficient manner.

4.1 iAgree: An Intermediate WS-AgreementConfiguration

To enable the automated analysis of conflicts, the semanticmapping of a WS-Agreement document into a CSP mustinclude both the mapping of the general-purpose schemaand the mapping of each SubL used in the document sincean important part of the semantics of a WS-Agreementdocument is included in the SubLs chosen for its extensionpoints. However, it is not feasible to provide a mappingfrom all possible SubLs to a CSP. Therefore, a practicalmechanism must be provided to enable SubLs developersto implement these mappings.

The solution we propose is to use an Intermediate WS-AGREEment configuration (iAgree). iAgree is a WSAC thathas been designed with two main features. First, it is ageneral-purpose WSAC, which means that its SubLs can beused in any domain unlike other SubLs such as JSDL thatare domain-specific. Second, the SubLs chosen in iAgreeare generic and expressive enough to make it easier to mapother WSAC into it. Appendices A and E include iAgreedocuments mapped from the WSACs used in WSAG4Jframework and SWAPS [10], respectively. We conjecturethat these mappings are easier to develop than directmappings to CSPs because the concepts used and the resultobtained (another WS-Agreement) are closer semanticallythan CSPs. Furthermore, WS-Agreement documents couldbe written directly in iAgree if it fits the users’ needs.Following this approach, we just need to provide oneunique full semantic mapping from iAgree WS-Agreementdocuments into CSPs. Other WSACs shall benefit of thesemantics and automated conflict analysis of iAgree bydefining a mapping from them to iAgree.

iAgree uses the following SubLs. The service descriptionterm SubL defines services as attribute-value pairs as it isdepicted in Fig. 2 and also provide the domain of theattribute, i.e., a function domainDðattributeÞ. Note that if anXML element can be flattened in terms of attribute-valuepairs and its domain has been defined in a XMLSchema,then it can be easily mapped into this SubL. For instance,the JSDL example included in appendix B is flattened toattribute-value pairs in the APPLICATION_STD_1 SDT inAppendix A.

The metric SubL, which is used to define the metric of aservice property, provides the domain of the serviceproperty, i.e., it describes its data type and its allowedvalues. From an abstract point of view, the SubL provides a

Fig. 10. Automated process to detect and explain conflicts in WS-Agreement documents.

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 7

IEEE

Proo

ffunction domainMðmetricÞ to obtain such domain. Forinstance, Document of Fig. 2 specifies that service propertyInputErrors is measured by Percent. Therefore, as canbe seen in the metric section of Fig. 2, there must be somemetric model, that states Percent must be interpreted asthe domain: ‘‘real value between 0 and 100’’, i.e.,domainMðPercentÞ ¼ fx 2 R : x � 0 ^ x � 100g.

The remaining SubLs are expression languages tospecify SLOs, qualifying conditions, and creation con-straints, respectively. In this case, the SubLs defineassertions using logical, relational, and algebraic operatorsdefined on the domain of the service descriptions, serviceproperties and literals. In practice, the expression languageused shall be restricted by the types of expressions that aparticular CSP solver can use. Section 5.2 provides moredetails about the expression language that we have used inour tool.

4.2 iAgree to CSP MappingA WS-Agreement document D specified with iAgree WSACdescribes a service by means of a set of attribute-value pairsand defines some service guarantees for a set of serviceproperties whose domain has been previously defined. Thesemantics of such WS-Agreement documents can bemodelled in a CSP by means of the semantic mappingmapðDÞ. The basic idea is to map the service descriptionsand service properties into CSP variables, whereas GTs andcreation constraints are mapped into CSP constraints. Bydoing so, the set of CSP solutions represents the range ofvalues that may take the service descriptions and proper-ties in the next step of the agreement creation process, i.e.,when creating an offer from a template, or creating anagreement from an offer. This mapping is summarised inTable 1 and detailed as follows.

Service description terms are mapped into variables,domains and, if they are part of an offer, into constraints.Specifically, for each SDT attribute-value pair, the attributeis added into the set of variables of the CSP; its domain,which is obtained from function domainD defined in theSDT SubL, is added into the set of domains of the CSP, andif the document is an offer, a constraint is added into the setof constraints to assign the specified value to the variable. Ifthe document is a template, SDTs represent default valuesand, hence, they are not mapped into constraints.

Service properties are mapped into CSP variables andtheir respective domain. The domain is obtained from thefunction domainM defined in the metric SubL. Thesevariables are used in the guarantee terms. Note that wejust depict the mapping of one variable in the Table forsimplicity. If a service property defines more variables,then the same mapping should be applied for eachvariable. For instance the InputErrors property ismapped as a variable with the ½0 . . . 100� domain asFig. 11 shows.

Guarantee terms are always mapped as CSP constraints.If there is a qualifying condition, the guarantee term ismapped as an implication between qualifying conditionand the SLO to represent the fact that the SLO can beapplied only if the qualifying condition holds. For instancethe NOT ImageTranslation) TranslationTimeG¼1 con-straint mapped in Fig. 11 from GTranslationTime1 ofFig. 2. Otherwise, only the SLO expression is added into theset of constraints of the CSP. For instance theInputErrorsG¼1 constraint mapped in Fig. 11 fromGTInputErrors of Fig. 2.

Constraints are directly added into the CSP constraints.For instance, InputFileSizeG30) NOT ImageTranslation

in Fig. 11. We do not include a mapping for itemsmentioned in Section 2.1 because we consider them aparticular case of current constraints.

The mapping function mapðDÞ assumes that there are nocomposite terms in the WS-Agreement document and,hence, all terms are composed by an All compositor. Thereare two approaches to take the composite term structure ofWS-Agreement documents into account: The first oneinvolves translating the semantics of term compositorsinto one CSP. In this case, the result is one CSP that useslogical operators OR and NOT to represent the semantics ofthe composite term structure of a WS-Agreement docu-ment. The second approach involves using the concept ofvariant to translate one WS-Agreement document intoseveral CSPs, one for each variant of the document.

TABLE 1Terms Mapping from iAgree to CSP

Fig. 11. CSP generated from mapping Template of Fig. 2.

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 20148

IEEE

Proo

f

From a semantic point of view, both solutions areequivalent. However, from an operational point of view,the first approach makes it much harder to identify partialconflicts and to obtain explanations for the conflicts.Therefore, in this paper we take the second approach anddefine an extended mapping function for composite terms,mapcðDcÞ, as a function that, given a WS-Agreement docu-ment with composite terms Dc, returns a set of CSPs, one foreach variant of Dc: mapcðDcÞ ¼ fmapðxÞ : x 2 variantsðDcÞg,where variantsðDcÞ is the function that returns the set ofvariants defined by a WS-Agreement document Dc that wasdefined in Section 2.

4.3 CSP-Based Analysis of ConflictsThe advantage of the previous semantic mapping is that wecan use the techniques specific to the semantic domain ofCSPs to analyse the conflicts in a WS-Agreement documentas depicted in Fig. 10. In our case, to analyse these conflictswe need two analysis techniques that have been widelyused in CSPs: find solutions and explaining the lack ofsolutions. The former solveðV;D; CÞ involves finding avalid assignment of values to all of the variables of theCSP V so that it satisfies its constraints C. To this end, manyheuristics and techniques have been developed to obtainthese solutions in an efficient manner. The latter techniqueexplainðV;D; CÞ involves providing an explanation whensuch solution is not possible. This explanation is a minimalset of constraints c � C that makes it impossible to find avalid assignment of all elements in V that satisfies c, i.e.,that makes solveðV;D; cÞ ¼ ˘. For instance, for the CSP:ðfa; b; dg; f½0 . . . 2�; ½0 . . . 2�; ½0 . . . 2�g; faþ b G 1; a¼1; d 9 1gÞ,the resulting c would be faþ b G 1; a ¼ 1g because theminimum allowed value for b is 0. On the basis of these twooperations, we can provide a precise semantics to theconflicts described in Section 3 as follows:

4.3.1 Inconsistent TermsA WS-Agreement document has inconsistent terms, i.e., ithas contradictions between its terms or creation con-straints, i f the mapped CSP has no solutions:inconsistentðDÞ , solveðmapðDÞÞ ¼ ˘. For instance, theinconsistent term of template of Fig. 5 would be detected,by means of its CSP mapping as follows:

solve 9�fInputFileSizeg; fintg; fInputFileSize9 ¼ 30;

InputFileSize G 30; InputFileSize G ¼ 50g�¼ ˘:

Furthermore, the inconsistent terms are explained by theresult of tracing back the set of constraints c returned byinconsistentexpðDÞ ¼ explainðmapðDÞÞ ¼ c.

Then, previous example would be explained as follows:

explain�fInputFileSizeg; fintg; fInputFileSize9 ¼ 30;

InputFileSize G 30; InputFileSizeG ¼ 50g�

¼ fInputFileSize 9 ¼ 30; InputFileSize G 30g:

4.3.2 Dead TermsA guarantee term is a dead term if it can never be applied ifall of the mandatory terms of the agreement are fulfilled, i.e.,

if its QC can never be true provided that the other terms of theagreement are fulfilled. Therefore, to detect that a term isdead, we just have to check whether its QC contradicts theremaining terms of the agreement. This can be expressed interms of a CSP as follows: let GTi be a guarantee term whosequalifying condition isQCGTi ,GTi is a dead term if adding itsQC as a new constraint to the document it makes itinconsistent: deadðGTi;DÞ , solveðmapðDÞÞ 6¼ ˘ ^ solveðV;D; ðC nmapðGTiÞ [QCGTiÞÞ ¼ ˘. For instance, the deadterm of template of Fig. 6 would be detected as follows:

solve�fTranslationTime; InputErrorsg;

int½1 . . . 100�; float½0 . . . 100�f g;fInputErrors91) TranslationTime G ¼ 1;

InputErrors G ¼ 1g�6¼ ˘

^ solve�fTranslationTime; InputErrorsg;int½1 . . . 100�; float½0 . . . 100�f g;fInputErrors 9 1; InputErrors G ¼ 1g

�¼ ˘:

A dead term is explained by the result of tracing back theset of constraints c returned by: deadexpðGTi;DÞ ¼explainðV;D; ðC nmapðGTiÞ [QCGTiÞÞ ¼ c.

Then, previous example would be explained as follows:

explain�fTranslationTime; InputErrorsg;fint½1 . . . 100�; float½0 . . . 100�g;fInputErrors 9 1; InputErrors G ¼ 1g

�¼ fInputErrors 9 1; InputErrors G ¼ 1g:

4.3.3 Conditionally Inconsistent TermsA guarantee term is a conditionally inconsistent term if whenits QC is true (i.e., it is enabled), its SLO is always false (i.e., itcannot be fulfilled). Consequently, to detect that a term isconditionally inconsistent, we have to check whether its QCand SLO contradict each other taking into account the otheragreement terms. In terms of a CSP, this can be expressed asfollows: let GTi be a guarantee term whose qualifyingcondition is QCGTi and service level objective is SLOGTi ,GTi is a conditionally inconsistent term if: condInconsistentðGTi;DÞ , solveðmapðDÞÞ 6¼ ˘ ^ solveðV;D; ðC nmapðGTiÞ[QCGTi [ SLOGTiÞÞ ¼ ˘. For instance, the conditionallyinconsistent term of offer of Fig. 7 would be detected asfollows:

solve�fTranslationLangs; InputFileSizeg;setfES to EN-UK; . . . ;Autog; intf g;fTranslationLangs ¼ FR to ES

) InputFileSize G 20; InputFileSize 9 ¼ 30g�6¼ ˘

^ solve�fTranslationLangs; InputFileSizeg;fsetfES to EN-UK; . . . ;Autog; intg;fTranslationLangs¼FR to ES; InputFileSizeG 20;

InputFileSize 9 ¼ 30g�¼ ˘:

A conditionally inconsistent term is explained bytracing back the set of constraints c returned by: condInconsistentexpðGTi;DÞ ¼ explain ðV; D; ðC nmapðGTiÞ[QCGTi [ SLOGTiÞÞ ¼ c.

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 9

IEEE

Proo

f

Then, previous example would be explained as follows:

explain�fTranslationLangs; InputFileSizeg;fsetfES to EN-UK; . . . ;Autog; intg;fTranslationLangs¼FR to ES; InputFileSize

G 20; InputFileSize 9 ¼ 30g�

¼ InputFileSize G 20; InputFileSize G ¼ 30g:

These definitions can be easily extended for a documentwith term compositors by obtaining the variants of thedocument and, then, applying the previous definitions toeach of the variants of the document. If the same conflict isfound in all of the variants, then the scope of the conflict istotal. If the conflict is found in, at least one of the variants,but not all of them, then the scope is partial.

For instance, the partial dead term of template of Fig. 8would be detected by means of the CSP mapping of its twovariants mapðD1Þ and mapðD2Þ:

mapðD1Þ¼ðfTranslationTime;TranslationLangsg;

fint½1 . . . 100�; setfES to EN-UK; . . . ;Autogg;

fTranslationLangs¼ES to DE

) TranslationTime G¼2;

TranslationLangs infES to EN-UK;

ES to FR;EN-UK to ES;

FR to ES,AutoggÞ

mapðD2Þ¼ðfTranslationTime;TranslationLangsg;

fint½1 . . . 100�; setfES to EN-UK; . . . ;Autogg;fTranslationLangs infEN-UK to ES;

EN-US to ES;FR to ES;Autog)TranslationTime G ¼1;TranslationLangs in

fES to EN-UK;ES to FR;

EN-UK to ES;FR to ES,AutoggÞ:

While mapðD2Þ has not conflicts, a partial dead termwould be detected and explained in mapðD1Þ, as follows:

solve mapðD1Þð Þ 6¼ ˘^ solveðfTranslationTime;TranslationLangsg;

fint½1 . . . 100�; setfES to EN-UK; . . . ;Autogg;fTranslationLangs ¼ ES to DE;

TranslationLangs in

fES to EN-UK;ES to FR;EN-UK to ES;

FR to ES,AutoggÞ ¼ ˘explainðfTranslationTime;TranslationLangsg;

fint½1 . . . 100�; setfES to EN-UK;

. . . ;Autogg;

fTranslationLangs ¼ ES to DE

TranslationLangs in

fES to EN-UK;ES to FR;EN-UK to ES;

FR to ES,AutoggÞ¼ fTranslationLangs ¼ ES to DE TranslationLangs in

ES to EN-UK;ES to FR;EN-UK to ES;

FR to ES,Autogg:

5 SLA EXPLAINER

The technique developed in the previous section has areference implementation named SLA Explainer, whichautomatically detects and explains all types of conflicts.Fig. 12 depicts the overall architecture of such implemen-tation. SLA Explainer extends the desktop applicationdeveloped as a proof-of-concept of the technique to detectand explain inconsistent terms in WS-Agreement devel-oped previously [1]. In this extension, external users haveplayed a pivotal role as they have provided high-valueinput we have taken into account to prioritize some non-functional requirements. We hereby comment some of theaspects where the end-users input has been most importantin the design of SLA Explainer.

5.1 FeaturesThe main features provided by the components of SLAExplainer included in Fig. 12 are:

1. ready-to-use by the development of a user-friendlyweb application (see Section 5.4) to test and use theconflict analysis provided by SLA Explainer withfewer effort;

2. functional suitability by supporting the analysis ofexpressive WS-Agreement documents with condi-tional and optional terms by the Variants Man-ager, arithmetic-logic expressions inside SLOs, etc.[13];

3. understandability by supporting a plain-text notationof iAgree [13] that makes reading and writing WS-Agreement documents easier for humans (suchnotation is serialised internally to the XML standardsyntax of WS-Agreement by the XML to iAgreecomponent);

4. interoperability through a triple distribution model(Java library, OSGi5 service, and web service) throughthe SLA explainer Facade component;

5. and CSP solver independence by protecting our designfrom the possible variations derived from using adifferent CSP Solver than Choco constraint solver6,

which is the one SLA Explainer includes by default. For thisreason, we have designed the interface Analyser with whichinteracts both the CSP Mapping component, which performsthe semantic mapping function to map WS-Agreement

5. www.osgi.org6. Laburthe et al. Choco constraint solver. http://www.emn.fr/

z-info/choco-solver/index.html

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 201410

IEEE

Proo

f

documents into the concrete CSP used, and the componentsthat analyse each conflict. In our implementation of SLAExplainer, interface Analyser is implemented by componentChocoAdapter, which interacts with Choco constraint solver.Therefore, the only requirement to add support for a new CSPengine is to provide an implementation to interfaceAnalyser.

5.2 Implementation IssuesSLA Explainer allows the detection and explanation of allkind of conflicts mentioned in this paper for WS-Agreementdocuments specified with iAgree. However, some imple-mentation issues such as the used CSP solver or the wayservice properties metrics are expressed, affect to thesupported type of variables and constraints. For instance,the open source Choco CSP solver only implements completesupport for integer variables. We have made the followingimplementation decisions on the iAgree SubLs.

As mentioned in Section 4.1, SDTs must be modelled asattribute-value pairs, independently of their domain-specific, internal (possibly hierarchical) organization. Weconsider that the advantages of using a generic SubL forSDTs are more relevant than the potential expressiveness ofmore specific SubLs like JSDL or WSDL for example.Applying this generic approach of attribute-value pairs inSDTs, we can automatically process any SLA documentindependently of the specific nature of the services to beagreed upon.

According to WS-Agreement, the (mathematical) do-main of service property variables can be specified bydomain-specific metrics. We have developed a simple yeteffective metrics SubL for the definition of global metricsthat can be used in iAgree or any other WS-Agreementdocument. Examples of the metrics definition are shown inthe context of Fig. 2.

Finally, regarding logic assertions SubLs for guaranteeTerms and creation constraint, we have designed a plain-text predicate-oriented SubL that can be easily fed into anyCSP solver. The abstract syntax of iAgree of the predicate-oriented SubL is shown below, where ID is the identifier ofan integer variable and lit is a literal value.7

P ::¼P opL P jT;predicate;where opL2f^j _ j:j ) j ,gT ::¼E opC E; term;where opC 2 f¼ j 6¼ j9j � jGj �g

E ::¼ E opA Ejvarjlit; expression;where opA is an

algebraic operator defined on the domain of

variables and literals:

5.3 SLA Explainer Front-EndWe have developed a front-end for iAgree that is availableon-line and can be used from any platform including mobiledevices. It uses the WSDL interface http://www.isa.us.es:8081/ADAService?wsdl to consume SLA Explainer as a webservice. The front-end offers the following features (thenumber in brackets refers to the corresponding part ofFig. 13):

1. an user-friendly iAgree notation with syntax high-lighting and a line numbered editor;

2. skeletons for the creation of agreement documents(‘‘New template/offer’’ items of File menu), spe-cially developed for users not familiar with WS-Agreement;

3. several document preloaded to reduce the learningcurve (note that every example of current paper isincluded);

4. analysis operations to launch the conflict checkingand explaining, and to get the number of variants;

5. and the result of the analysis is shown in a message(the message shown corresponds to the inconsisten-cy explanation operation).

Moreover, as Fig. 14 depicts using the document of Fig. 9as example, we have developed a view to launch severalanalysis operations consecutively by using a simple Java-Script notation, and the result is shown in a log window.

5.4 SLA Explainer VerificationA test suite has been developed comprising 780 imple-mentation-independent test cases [19] to verify the func-tionality of SLA Explainer. The test cases have been7. Technical report [13] includes several examples of predicates.

Fig. 13. Edition capabilities of the iAgree front-end to try SLA Explainer(http://labs.isa.us.es/apps/IDEAS).

Fig. 12. SLA Explainer components diagram.

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 11

IEEE

Proo

f

designed in terms of the inputs (i.e., an agreement offer)and expected outputs of the detection or explanation ofconflicts under test. We used three popular black-boxtechniques from the software testing community to designour test cases, namely: equivalence partitioning, pairwisetesting, and error guessing. The test cases helped to find:1) a couple of errors detected while handling documents,for instance documents with variants were not correctlymanaged because a NullPointerException were thrownand it was solved with an adequate exception treatment;and 2) a dozen of errors detected while analysing doc-uments, for instance attribute-value pairs of SDTs in tem-plates were considered as value assignments, instead ofdefault values.

6 VALIDATION

An important validation effort has been carried out in thepursuit of real-world usefulness for SLA Explainer. Asmajor conclusion we can claim that the results are usefulnot only for other colleagues in the community but also tobe used in real end-user platforms and as a tool to helpstudents. In the following, the main hints of this validationeffort are highlighted.

Our first validation scenario was focused on theagreement creation process of WS-Agreement protocol.We revised WSAG4J, a framework developed by membersof the GRAAP working group of the Open Grid Forum toprovide an implementation of the WS-Agreement protocol.We noticed that WSAG4J lacked mechanisms to detect andexplain conflicts in WS-Agreement documents whichmight led to undesired situations: SLAs with inconsisten-cies, dead terms and conditionally inconsistent term, andfailures during the agreement creation process due toinconsistent templates or offers. It was necessary to buildan adapter to SLA Explainer to deal with the documentswritten in the WSAC of WSAG4J. Two alternatives to buildthis adapter were considered: mapping the WSAC ofWSAG4J to iAgree, or mapping the WSAC of WSAG4J toCSP. We chose the former for the sake of simplicity.Examples of this mapping can be found in Appendix A.

As a second validation effort we had the opportunity touse SLA Explainer in the SOA-Governance System used by

our Regional Governmental Organization (see Appendix C).SLA Explainer was integrated into an SLA ManagementInfrastructure to automatically analyse the agreement docu-ments and to enhance editing tools with debugging(detection and explanation) capabilities. During the evalua-tion we were aware of an unidentified kind of conflict thatwe coined as conditionally inconsistent term. We askedourselves about the existence of other unidentified kinds ofconflicts and we decided to conduct an experiment with ourM.Sc students. The students had to choose a real-worldservice such as PayPal, Amazon EC2, Business ProcessManagement Systems, NetOpen EAI, et cetera and create itscorresponding template and a compliant offer. A totalnumber of 46 WS-Agreement documents, 24 templates and22 offers, were created. Amongst them, there were agreementdocuments with up to 14 service properties, 9 guaranteeterms, 5 conditional guarantee terms, 12 variants, 4 itemscreation constraints or 14 general creation constraints. Theconclusion we obtained from this exercise was that real-world SLAs make an intensive use of qualify conditions andvariants in real-world SLAs. Furthermore, we also foundanother unidentified kind of conflict: dead term. All docu-ments created by the students are available in a publicrepository.8

7 RELATED WORK

This section is organized according to the two majorcontributions of this paper, namely: a conflict classificationfor WS-Agreement as well as a rigorous definition for eachconflict, and a novel constraint satisfaction problem (CSP)-based technique to detect and explain every single type ofconflict of that classification.

Although there are conflict taxonomies in other applica-tion domains, we have not found any one neither in SLAdomain in general, nor WS-Agreement in particular. In fact,the only type of conflict we have found regarding SLAs is theinconsistency conflict. Our first steps in defining ourclassification were strongly influenced by [20]. In this work,an error classification of feature models and a CSP-basedtechnique to automatically detect and explain errors in suchmodels was proposed. A feature model allows to representall the products of a Software Product Line in a compact way.Three major type of errors were identified in [20]: deadfeatures, full-mandatory features and void model. A deadfeature is a feature that despite of being defined in a featuremodel, it will never appear in a product in the softwareproduct line. We realized that this concept could betranslated to our context so that we could say that a deadterm is a term that despite of being defined in an agreementdocument, it will never be applied during the agreementlifetime. The adjective ‘‘dead’’ has been also used with a verysimilar meaning to denote activities that cannot be reached inweb services choreographies because their executions wouldlead to violate at least one choreography constraint [21], sowe consider that it is an adjective that perfectly grasps theidea we wished to transmit.

Fig. 14. Scenarios view of the iAgree front-end to try SLA Explainer(http://labs.isa.us.es/apps/IDEAS).

8. Available at http://www.isa.us.es/ada} in the SLARepositorylink.

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 201412

IEEE

Proo

f

We have not found any other correspondence so directin the case of inconsistencies and conditional inconsisten-cies, although we have found some very complete andcomplex taxonomies with very similar, but not the same,type of errors. For instance, in the field of InformationSystem Management, according to the taxonomy proposedin [22], our inconsistencies and dead term conflicts can beconsidered as mutex and our conditionally inconsistentterm conflict can be considered as inconsistence configura-tion. To avoid misunderstandings, we have decided to use‘‘inconsistency’’ because it is commonly used in SLAs [1],and ‘‘conditionally inconsistent term’’ because it transmitsthe meaning of the error type in a more precise way.

As far as we know, our proposal is novel in givingrigorous semantics to WS-Agreements documents andtheir elements using a semantic mapping to CSP. Theproposal of Oldham et al. [10] is the closest to ours becausethey provide semantics to an specific WSAC by means ofontologies to automate the agreement compliance checkingbetween the parties at negotiation phase of the WS-Agreement life-cycle. However, they do not support nestedterm compositors. There are some previous formalisationsof WS-Agreement [23], [24] but all of them are focused onthe protocol-side of WS-Agreement where a formal defini-tion of the offers and templates is not necessary.

The novel CSP-based technique to detect and explain theconflicts of our classification extends our preliminaryproposal to detect and explain only inconsistent terms onWS-Agreement offers [1]. Although WS-Agreement tem-plates, dead or conditionally inconsistent terms, and evenconflict scope were not considered in such previous work,it is the unique proposal we find in the literature thatproposes conflicts explanation in WS-Agreement.

There are also a couple of proposals that are able todetect inconsistencies but neither dead nor conditionallyinconsistent terms conflicts. In the first one [4], we alreadyproposed a constraint-based approach to detect onlyinconsistencies between terms; and in the second one [3],Braga et al. proposes a state-search and model-checkingtechnique that is able to analyse SLA models detectinginconsistent SLOs. In both cases, authors dealt with non-WS-Agreement documents that do not include eitherconditional terms nor term compositors, although condi-tional terms could be expressed as logical entailment.Furthermore, they do not provide any explanation ofconflicts.

Another problem that could be interpreted in terms ofconflicts between several documents is the agreementviolation detection during agreement monitoring. In thiscase, the conflicts are checked between the SLA previouslyagreed by parties and a document that includes the resultof monitoring the agreed service. Some proposals thatallow the detection of agreement violations are: [25], [26],[27], [28], [29]. As for proposals that not only detect, butalso propose to carry out an action when a violation hasbeen detected: [30] proposes to renegotiate the SLA; [31]proposes monetary penalties, impact on potential futureagreements between the parties and the enforced re-running of the agreed service; [32] proposes actions whichtake into account not only penalty clauses, but rewardsclauses also; and finally [18] provides explanation of

violations based on the events of service-based systems.All these proposals can benefit from our SLA Explainer.Actually, proposal [14] extends the monitoring techniqueproposed in [28] with SLA Explainer to explain theviolations, i.e., which metrics and SLOs have been violated.

Finally, there are approaches of the SLA domain ingeneral, and WS-Agreement in particular, that providedetection and explanation for a different kind of conflicts;those not in a unique agreement document but betweenseveral documents. This is the case of [4] where atechnique to determine the compliance between docu-ments described in a non-WS-Agreement notation isintroduced. In [33] this technique is revised to be applicablein WS-Agreement and a new technique to explain the non-compliance conflicts between templates and agreementoffers is introduced.

8 CONCLUSION AND FUTURE WORK

Three main conclusions can be drawn from this paper.First, the use of qualifying conditions and term composi-tors are at the root of two new kinds of conflicts: dead termsand conditionally inconsistent terms. Furthermore, the useof alternative term compositors leads to situations wherethe conflicts affect only partially the agreement document.In turn, to deal with partial conflicts the notion of variantsin a WS-Agreement document have been rigorouslydefined. These findings are valid for any SLA specificationmodel incorporating conditional and alternative terms.

Second, we show how constraint programming can beused to provide a rigorous definition for all kinds ofconflicts in WS-Agreement documents identified to date.More specifically, the definitions rely solely on twoanalysis techniques widely used in constraint program-ming: finding solutions and explaining the lack of solu-tions. Both techniques are generally incorporated by manysolvers which means our solution can be easily shared andreproduced.

Third, we conjecture that both the use of ad-hoc WSACsand the lack of a commonly accepted general-purposeWSAC, are delaying the adoption of WS-Agreement byresearchers and practitioners. In this regard, we areconfident that iAgree will provide a foundation on whichgeneral-purpose tools for WS-Agreement can be built.Furthermore, apart from our technique’s inherent value,having developed open source tooling support which canbe quickly integrated (as it is shown in [13]) and easy-to-use is a determining factor to achieve a useful result andsettles the basis to spread the use of WS-Agreement.

As far as we know, this is the first work that explores thedetection and explaining of conflicts in WS-Agreementsdocuments with conditional and optional terms, and thus alot of work remains to be done. We mention only a twofolddirection: to explore the new conflicts that poses in dealingwith temporal-aware terms [34], [35] and penalties [36].

ACKNOWLEDGMENT

This work is an extended version of [1] and it has beenpartially supported by the European Commission (FEDER),the Spanish and the Andalusian R&D&I programmes (grants

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 13

IEEE

Proo

f

TIN2009V07366 (SETI), TIN2012V32273 (TAPAS),P12VTICV1867 (COPAS), TICV5906 (THEOS), P07-TIC-2533 (ISABEL)). The authors would like to thank F. Casati,A. Metzger, O. Waldrich, W. Ziegler, P. Wieder, A. Duran,O. Martın-Diaz, P. Fernandez, S. Segura, J.M. Alcaraz,M. Montali, M. Aiello, F. Raimondi, P. Dolog, and J. M. Garcıafor their helpful comments and revisions, and the technicalstaff, especially J. Garcia and A. Jurado, for their work anddedication.

REFERENCES

[1] C. Muller, A. Ruiz-Cortes, and M. Resinas, ‘‘An Initial Approachto Explaining SLA Inconsistencies,’’ in Proc. 6th ICSOC, 2008,vol. 5364, pp. 394-406, ser. LNCS.

[2] P. Plebani, A. Metzger, and O. Sammodi, Validated Principles,Techniques and Methodologies for Specifying End-to-End Quality(S-Cube Deliverable CD-JRA-1.3.6), 2012.

[3] C. Braga, F. Chalub, and A. Sztajnberg, ‘‘A Formal Semantics fora Quality of Service Contract Language,’’ Electron. NotesTheoretical Comput. Sci., vol. 203, no. 7, pp. 103-120, Apr. 2009.

[4] A. Ruiz-Cortes, O. Martın-Dıaz, A. Duran, and M. Toro,‘‘Improving Automatic Procurement Web Services Using Con-straint Programming,’’ Int. J. Coop. Inf. Syst., vol. 14, no. 4,pp. 439-467, 2005.

[5] M. Comuzzi and B. Pernici, ‘‘A Framework for Qos-Based WebService Vontracting,’’ ACM Trans. Web, vol. 3, no. 3, pp. 10:1-10:52, 2009.

[6] Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig, T. Nakata,J. Pruyne, J. Rofrano, S. Tuecke, and M. Xu, Web Services AgreementSpecification (WS-Agreement) (v. gfd-r.192), 2011, OGF-Grid ResourceAllocation Agreement Protocol WG.

[7] C. Kotsokalis et al., ‘‘SLA@SOI: SLA Management andFoundations,’’ SLA@SOI consortium, Tech. Rep. DeliverableD.A5.a, 2009. [Online]. Available: http://sla-at-soi.eu/wp-content/uploads/2009/10/D.A5a-M12-SLA-Foundations-and-Management.pdf.

[8] A. Keller and H. Ludwig, ‘‘The WSLA Framework: Specifyingand Monitoring Service Level Agreements for Web Services,’’Network, vol. 11, no. 1, pp. 57-81, 2003.

[9] D. Battre, P. Wieder, and W. Ziegler, WS-Agreement SpecificationVersion 1.0 Experience Document (v. gfd-e.167) 2010, OGF-GridResource Allocation Agreement Protocol WG.

[10] N. Oldham, K. Verma, A. Sheth, and F. Hakimpour, ‘‘SemanticWS-Agreement Partner Selection,’’ in Proc. 15th Int. WWW Conf.,2006, pp. 697-706.

[11] D. Battre, M. Hovestadt, and O. Waldrich, ‘‘Lessons Learnedfrom Implementing WS-Agreement Grids and Service-OrientedArchitectures for Service Level Agreements. New York, NY, USA:Springer-Verlag, 2010.

[12] E. Tsang, Foundations of Constraint Satisfaction, A. Press, 1995.[13] C. Muller, A. Duran, M. Resinas, A. Ruiz-Cortes, and O. Martın-Dıaz,

‘‘Experiences From Building a WS-Agreement Document AnalyzerTool,’’ ISA Research Group, Seville, Spain, Tech. Rep., 2012.

[14] C. Muller, M. Oriol, M. Rodrıguez, X. Franch, J. Marco, M. Resinas,and A. Ruiz-Cortes, ‘‘SALMonADA: A platform for Monitoringand Explaining Violations of WS-Agreement-Compliant Docu-ments,’’ in Proc. 4th Workshop on Principles Eng. Service-OrientedSyst., 2012, pp. 43-49, Zurich.

[15] W3C, Xml Schema Part 0: Primer Second Edition. [Online].Available: http://www.w3.org/TR/xmlschema-0/.

[16] D. Harel and B. Rumpe, ‘‘Meaningful Modeling: What’s theSemantics of ‘Semantics’?’’ IEEE Comput., vol. 37, no. 10,pp. 64-72, Oct. 2004.

[17] J. Rivera, E. Guerra, J. de Lara, and A. Vallecillo, ‘‘AnalyzingRule-Based Behavioral Semantics of Visual Modeling Languageswith Maude Software Language Engineering 2008, vol. 5452/2009,ser. Lecture Notes in Computer Science. New York, NY, USA:Springer-Verlag, 2009, pp. 54-73.

[18] K. Mahbub and G. Spanoudakis, ‘‘Monitoring WS-Agree-ments: An Event Calculus-Based Approach Test and Analysisof Web Services. Berlin, Germany: Springer-Verlag, 2007,pp. 265-306.

[19] C. Muller, S. Segura, and A. Ruiz-Cortes, ‘‘A Test Suite forAgreement Document Analyser,’’ ISA Research Group, Seville,Spain, Tech. Rep., 2012.

[20] P. Trinidad, D. Benavides, A. Duran, A. Ruiz-Cortes, and M. Toro,‘‘Automated Error Snalysis for the Agilization of FeatureModeling,’’ J. Syst. Softw., vol. 81, no. 6, pp. 883-896, 2008.

[21] M. Montali, M. Pesic, W.M.P.V.D. Aalst, F. Chesani, P. Mello,and S. Storari, ‘‘Declarative Specification and Verification ofService Choreographiess,’’ ACM Trans. Web, vol. 4, pp. 3:1-3:62,2010.

[22] J.M.A. Calero, J.M.M. Perez, J.B. Bernabe, F.J.G. Clemente,G.M. Perez, and A.F.G. Skarmeta, ‘‘Detection of SemanticConflicts in Ontology and Rule-Based Information Systems,’’Data K. Eng., vol. 69, no. 11, pp. 1117-1137, 2010.

[23] M. Aiello, G. Frankova, and D. Malfatti, ‘‘What’s in anAgreement? An Analysis and an Extension of WS-Agreement,’’in Proc. ICSOC, 2005, pp. 424-436.

[24] G.D. Modica, O. Tomarchio, and L. Vita, ‘‘Dynamic SLAsManagement in Service Oriented Environments,’’ J. Syst. Softw.,vol. 82, pp. 759-771, 2009.

[25] F. Raimondi, J. Skene, and W. Emmerich, ‘‘Efficient OnlineMonitoring of Web-Service SLAs,’’ in Proc. 16th ACM SIGSOFTInt. Symp. Found. Softw. Eng., Atlanta, GA, USA, Nov. 2009,pp. 170-180.

[26] J. Skene, D. Lamanna, and W. Emmerich, ‘‘Precise Service LevelAgreements,’’ in Proc. 26th Int. Conf. Softw. Eng., May 2004,pp. 179-188.

[27] S. Lamparter, S. Luckner, and S. Mutschler, ‘‘FormalSpecification of Web Service Contracts for Automated Contract-ing and Monitoring,’’ in Proc. 40th Hawaii Int. Conf. Syst. Sci.,2007, pp. 63-72.

[28] M. Oriol, X. Franch, J. Marco, and D. Ameller, ‘‘MonitoringAdaptable SOA-Systems Using Salmon,’’ in Proc. Workshop Serv.Monitoring, Adaptation Beyond (Mona+), 2008, pp. 19-28.

[29] C. Chen, L. Li, and J. Wei, ‘‘AOP Based Trustable SLACompliance Monitoring for Web Services,’’ in Proc. 7th QSIC,Oct. 2007, pp. 225-230.

[30] D. Gmach, S. Krompass, A. Scholz, M. Wimmer, and A. Kemper,‘‘Adaptive Quality of Service Management for EnterpriseServices,’’ ACM Trans. Web, vol. 2, pp. 8:1-8:46, Mar. 2008.

[31] O.F. Rana, M. Warnier, T.B. Quillinan, F. Brazier, and D. Cojocarasu,‘‘Grid Middleware and Services Chapter Title-Managing Viola-tions in Service Level Agreements Managing Violations in ServiceLevel Agreements. New York, NY, USA: Springer-Verlag, 2008,pp. 349-358.

[32] M. Schafer, P. Dolog, and W. Nejdl, ‘‘An Environment forFlexible Advanced Compensations of Web Service Transac-tions,’’ ACM Trans. Web, vol. 2, pp. 14:1-14:36, May 2008.

[33] C. Muller, M. Resinas, and A. Ruiz-Cortes, ‘‘Explaining theNon-Compliance Between Templates and Agreement Offers inWS-Agreement�,’’ in Proc. 7th ICSOC, vol. 5900, 2009, pp. 237-252, LNCS, Stockholm.

[34] O. Martın-Dıaz, A. Ruiz-Cortes, A. Duran, and C. Muller, ‘‘AnApproach to Temporal-Aware Procurement of Web Services,’’ inProc. 3rd ICSOC, 2005, pp. 170-184.

[35] C. Muller, O. Martın-Dıaz, A. Ruiz-Cortes, M. Resinas, andP. Fernandez, ‘‘Improving Temporal-Awareness of WS-Agreement,’’ in Proc. 5th ICSOC, 2007, pp. 193-206.

[36] O.F. Rana, M. Warnier, T.B. Quillinan, and F.M.T. Brazier,‘‘Monitoring and Reputation Mechanisms for Service LevelAgreements,’’ in Proc. GECON, 2008, pp. 125-139.

Carlos Muller received the PhD degree incomputer science from the University of Sevilla,Spain, where he is a Research Assistant andmember of the Applied Software EngineeringGroup (ISA, www.isa.us.es). His current re-search line includes service oriented computing,specifically the automated analysis of servicelevel agreements and the application of suchanalysis at SLA design and monitoring.

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 7, NO. X, XXXXX 201414

IEEE

Proo

f

Manuel Resinas received the PhD degree incomputer science from the University of Sevilla,Spain, where he is a Lecturer. His currentresearch lines include analysis and manage-ment of service level agreements, businessprocess compliance, and process performancemanagement. Previously, he worked on auto-mated negotiation of service level agreements.

Antonio Ruiz-Cortes received the PhD degree(with honors) in computer science from theUniversity of Sevilla, Spain, where he is anaccredited full Professor and Head of theApplied Software Engineering Group (ISA,www.isa.us.es). His current research lines in-clude service oriented computing, softwareproduct lines, and business process manage-ment. Previously, he worked on requirementsengineering and multiparty interaction.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.

MULLER ET AL.: AUTOMATED ANALYSIS OF CONFLICTS IN WS-AGREEMENT 15