1
Comprehensive Explanation of SLA Violations
at Runtime
C. Müller
(1)
, M. Oriol
(2)
, X. Franch
(2)
, J. Marco
(2)
, M. Resinas
(1)
, A. Ruiz–Cortés
(1)
, M. Rodríguez
(2)
(1)
University of Seville, LSI, Seville (Spain), ISA research group, http://www.isa.us.es/
{cmuller,resinas,aruiz}@us.es
(2)
Universitat Politècnica de Catalunya, Barcelona (Spain), GESSI research group, http://www.essi.upc.edu/~gessi/
{moriol,jmarco}@lsi.upc.edu, {franch,marcr}@essi.upc.edu
Abstract—1
Service Level Agreements (SLAs) establish the Quality of2
Service (QoS) agreed between service-based systems consumers3
and providers. Since the violation of such SLAs may involve4
penalties, quality assurance techniques have been developed to5
supervise the SLAs fulfillment at runtime. However, existing6
proposals present some drawbacks: (1) the SLAs they support7
are not expressive enough to model real-world scenarios, (2) they8
couple the monitoring configuration to a given SLA specification,9
(3) the explanations of the violations are difficult to understand10
and even potentially inaccurate, (4) some proposals either do11
not provide an architecture, or present low cohesion within12
their elements. In this paper, we propose a comprehensive13
solution, from a conceptual reference model to its design and14
implementation, that overcomes these drawbacks. The resulting15
platform, SALMonADA, receives the SLA agreed between the16
parties as input and reports the explanations of SLA violations in17
a timely and highly understandable way. SALMonADA performs18
an automated monitoring configuration and it analyses highly19
expressive SLAs by means of a constraint satisfaction problems20
based technique. We have evaluated the impact of SALMonADA21
over the resulting service consumption time performance. The22
results are satisfactory enough to consider SALMonADA for SLA23
supervision because of its low intrusiveness.24
Keywords-service level agreement; SLA; monitoring; analysis;25
violation detection and explanation; QoS.26
I. INTRODUCTION AND MOTIVATION27
Service Level Agreements (SLAs) establish the Quality of28
Service (QoS) agreed between service-based systems con-29
sumers and providers, as well as penalty/reward clauses to be30
applied when the SLA is violated. Detecting such violations31
may be complicated, consider for instance the following case.32
The Amazon Simple Storage Service (AmazonS3) guaran-33
tees a monthly uptime percentage equal to or greater than34
99.9% in its SLA
1
including a clause to reward their con-35
sumers against a lack of service. However, Amazon requires36
the customer to proof this violation by sending an email within37
ten business days after the end of the billing cycle in which the38
errors occurred. Proving the violation demands the customer to39
compute the monthly uptime percentage by subtracting from40
100% the average of the error rates
2
.41
This Amazon scenario illustrates the need of having tech-42
niques to supervise the fulfillment of SLAs [1]. In response to43
1
http://aws.amazon.com/s3-sla/
2
internal server errors divided by the requests during each five minute period
this need, several quality assurance proposals have been for- 44
mulated. They deal with aspects such as: violation detection, 45
either at runtime [2]–[8] or testing time [9], [10]; violation no- 46
tification either by push (i.e. notifications to subscribed clients 47
as soon as violations are detected at runtime) [4], [5], [11] 48
or pull strategies [2], [8], [12]; and violation explanation [13], 49
[14]. The possible adoption of these proposals in real-world 50
scenarios is greatly influenced by the following factors: 51
1) Which SLAs are supported. Usually, real-world SLAs 52
(e.g. AmazonS3 SLA) describe the parties obligations 53
in natural language and they may comprise complex 54
elements such as: (1) conditional terms subject to a 55
precondition (i.e. if the precondition holds, then the 56
term applies), for instance, AmazonS3 SLA offers a 57
data durability of 99.99% only if the client choose a 58
cheaper reduced redundancy storage; (2) optional or 59
alternative terms (i.e. a set of terms that can be chosen 60
by the customers), for instance, AmazonS3 offers a set 61
of alternative support plan terms. 62
2) How the interaction with the monitor is performed. 63
In order to detect violations we need to monitor the 64
QoS offered by the providers at runtime (i.e. specific 65
values for monitorable service properties such as the 66
service availability or response time). The interaction 67
with the monitoring techniques [15] that gather such 68
QoS monitoring results, requires both: (a) to configure 69
the monitor with the location of the service, and its 70
monitorable service properties; and (b) to decide how 71
the QoS monitoring results are specified. For instance, 72
in the case of AmazonS3, the SLA determines the need 73
for monitoring and obtaining a specific value for the 74
monthly uptime percentage for each billing cycle in 75
order to detect a possible violation. 76
3) How the violations are detected and explained. The 77
SLA violations are detected by checking the agreed 78
QoS against the obtained QoS monitoring result. And, 79
ideally, the explanation of violations needs to be both 80
comprehensive and timely. By comprehensive, we mean 81
to provide a user-friendly and accurate violation report 82
including not only the violated terms, but also the 83
violation causes and even possible effects, in a form 84
that is easy to understand by humans. For instance, in 85
the AmazonS3 scenario, a comprehensive explanation 86
2
would require a report including that the violated term87
is "monthly uptime percentage equal to or greater than88
99.9%" by a monthly uptime percentage of 92% mea-89
sured in a specific monthly billing cycle. By timely,90
we mean to communicate the violation as soon as it91
happens, i.e. when the QoS monitoring result has just92
been retrieved at runtime and it is checked against the93
SLA to detect and explain the violations.94
4) Which architecture is proposed. In order to ease the95
maintainability and adaptability of the system, the ar-96
chitecture should comprise loosely coupled and highly97
cohesive elements separating monitoring from analysis.98
As shown in Sec. II, current proposals do not satisfactorily99
deal with the characteristics above. Some of them may be100
completely coupled to a particular SLA notation that are101
not able to deal with all the aspects required in real-world102
scenarios, others couple the monitoring configuration to a103
given SLA specification, and most (if not all) provide very104
basic information when a violation occurs. Furthermore, not105
all proposals provide architectures with a clear separation of106
concerns between monitoring and analysis.107
The goal of this work is to design and implement108
SALMonADA, a service-based system to monitor and analyse109
SLAs in order to provide timely and comprehensive explana-110
tions of violations. SALMonADA main features are:111
1) specification of a wide range of SLA structures and com-112
plex elements based on the use of WS–Agreement [16].113
2) automated monitoring configuration through the analysis114
of the SLAs but without coupling to a given SLA115
specification.116
3) powerful detection and explanation of the SLAs vio-117
lations by means of a Constraint Satisfaction Problem118
(CSP)-based technique. A comprehensive and timely119
explanation of the SLA violations is notified either by120
push or pull strategies.121
4) low coupling in its service-oriented architecture that122
supports the independent evolution of the core monitor-123
ing and analysis components, or even their independent124
substitution when moving from one problem domain to125
another.126
The impact of SALMonADA over the resulting service127
consumption time performance and its scalability have been128
evaluated over real services. We analysed the results in alter-129
native deployment scenarios and we state that SALMonADA130
has a low intrusiveness compared to the benefits it provides.131
Moreover, we have developed a web client as a front-end to132
try it online.133
The paper is organised as follows. The related work is134
evaluated in Sec. II. The conceptual reference model of135
SALMonADA is detailed in Sec. III, while the details of its136
design and development are included in Sec. IV. Section V137
provides information about the CSP-based technique to anal-138
yse the SLA fulfillment. Section VI provides information about139
how SALMonADA checks the QoS monitoring result against140
the SLA to provide timely and comprehensive explanations.141
In turn, Section VII evaluates the impact of SALMonADA142
over the resulting service consumption time performance and143
Table I
ANALYSIS OF THE RELATED WORK
PROPOSALS
Supported
SLAs
Monitor
config.
Monitoring
results
Explanation of
violations
Architecture
elements
Architecture
structure
WSLA
[2,3]
General
purpose.
Not H-U.
Automatic.
Coupled
to the SLA.
Through
API.
Detection and
partial explanation
Not H-U.
Monitor and
Analyser
separated.
CBS
Comuzzi,
Kotsokalis [4]
Particular.
Automatic.
Decoupled
from the SLA.
Through
API.
Detection.
Monitor and
Analyser
separated.
SOA
Michlmayr
et al. [5]
Particular.
Automatic.
Coupled
to the SLA.
Through
query lang.
Detection.
Monitor and
Analyser
separated.
SOA
Raimondi et
al. [20]
General
purpose.
Not H-U.
Automatic.
Decoupled
from the SLA.
Through
log.
Detection.
Monitor and
Analyser in 1
component.
CBS
Sahai et al.
[17]
Particular.
Automatic.
Coupled
to the SLA.
Through
a formal
model.
Detection and
partial explanation
Not H-U.
Monitor and
Analyser
separated.
CBS
Palacios
et al. [9]
General
purpose.
Not H-U.
Automatic.
Coupled
to the SLA.
[N/A] Detection. [N/A] [N/A]
Di Penta
et al. [10]
Particular.
Automatic.
Coupled
to the SLA.
[N/A] Detection. [N/A] [N/A]
SLA@SOI
[11]
General
purpose.
Not H-U.
Automatic.
Decoupled
from the SLA.
Through
API.
Detection and
partial explanation.
Not H-U.
Monitor and
Analyser
separated.
SOA
TRUSTCOM
[12]
General
purpose.
Not H-U.
Automatic.
Coupled
to the SLA.
Through
API.
Detection and
partial explanation.
Not H-U.
Monitor and
Analyser
separated.
SOA
Mahbub,
Spanoudakis
[13,14]
General
purpose.
Not H-U.
Automatic.
Coupled
to the SLA.
[N/A]
Detection and
explanation.
Not H-U.
Monitor and
Analyser
separated.
CBS
Comuzzi,
Spanoudakis
[19]
General
purpose.
Not H-U.
Automatic.
Decoupled
from the SLA.
Through
API.
Detection.
Monitor and
Analyser
separated.
SOA
our proposal
SALMonADA
General
purpose.
H-U.
Automatic.
Decoupled
from the SLA
Through
a formal
document.
Detection and
explanation.
H-U.
Monitor
and Analyser
separated.
SOA
Functionality
Architecture
H-U: human understandable
scalability. Finally, Sec. VIII concludes the paper with a 144
discussion of our contributions. 145
II. RELATED WORK 146
Several service-based systems quality assurance proposals 147
that aggregate monitoring and analysis facilities can be found 148
in the literature. To conduct the search of the related work, we 149
have revised the most relevant conferences and journals in the 150
area, selecting those papers that were scoped in the field of 151
SLA monitoring and analysis. Furthermore, we have increased 152
the results by adding relevant papers obtained from experts in 153
the field. Table I summarizes the results of this study. 154
We have examined the selected papers under the four factors 155
described in the introduction. The first three factors fall into 156
the functionality of the proposed solution, whereas the fourth 157
factor falls into its architecture. 158
Functionality. Considering the three factors for functionality 159
identified in the introduction, we focus on the following issues: 160
(1) Which SLAs are supported, (2a) How the information 161
to configure the monitor is specified, (2b) How the QoS 162
monitoring result is specified and (3) How the violations are 163
explained. 164
Architecture. The issues arising from this factor are: (4a) 165
Which architectural elements are needed and (4b) How the 166
architectural elements are structured. 167
We analyse these issues below: 168
Which SLAs are supported. The proposals fall into one of the 169
following categories: 170
3
• Ad-hoc SLA notation [4], [5], [10], [17]. The supported171
SLAs include ad-hoc information without considering172
a general-purpose structure or notation. In addition the173
proposals are not able to deal with all the aspects re-174
quired on some real scenarios. For instance, they do175
not support conditional terms subject to preconditions,176
expressive Service Level Objectives (SLOs), and optional177
or alternative terms to specify agreement variants [18]178
• General-purpose SLA notation [2], [3], [9], [11]–[14],179
[19], [20]. The supported SLAs consider a general-180
purpose structure and/or notation. Specifically, in pro-181
posals such as [9], [13], [14], [19] the SLAs sup-182
port the general-purpose structure proposed in the183
WS–Agreement specification [16], a highly flexible184
and widespread SLA notation. An advantage of WS–185
Agreement over other SLA proposals is that it supports186
the aforementioned aspects that are necessary to model187
agreements of real scenarios, namely: (1) optional or188
alternative terms to specify agreement variants, and (2)189
expressive SLOs that can be guarded by a qualifying190
condition (QC) to specify conditional terms. However,191
WS–Agreement just provides a general-purpose schema192
that must be extended up to eight different points with193
an internal sublanguage. More specifically, two of the194
eight points need to be necessarily extended to become195
a fully-fledged language, namely the service description196
terms (SDT) that defines the service functionality, and197
the SLOs. This causes that a system that can deal198
with a particular WS–Agreement notation is not able199
to deal with other WS–Agreement notations. Moreover,200
the sublanguages used in [9], [13], [14], [19] are not201
neither general-purpose to be easily mapped to each other,202
nor human understandable. Other works support SLAs203
specified with WSLA [2], [3] and SLA* [11] that include204
general-purpose structures and notations. However, such205
notations are based on XML schemas even for the SLOs206
assertions (being recursive in the case of SLA*) and thus,207
they are not as human understandable as they should be.208
How the information to configure the monitor is specified. We209
find the following situations:210
• Automatic, coupled to the SLA. Some approaches include211
a mechanism to automatically configure a monitor from212
the SLA [2], [3], [5], [9], [10], [12]–[14], [17]. However,213
in these solutions, the monitor can only be used for214
a concrete SLA specification, and if this specification215
changes, the monitor must be modified as well due to216
its high coupling.217
• Automatic, decoupled from the SLA. There are some218
works [4], [11], [19], [20] which decouple the SLA219
from the monitor by translating automatically the SLA220
to another document which includes the information221
required for monitoring.222
How the QoS monitoring result is specified. Some approaches223
do not describe how the monitoring results are reported [9],224
[10], [13], [14]. From those that describe it, some provide225
a log file [20] or an Application Programming Interface226
(API) [2]–[4], [11], [12], [19] to access the monitoring results.227
Since these logs and APIs are not standarized, they present 228
significant differences to each other. The lack of a standard 229
prevents the possibility to easily change the monitor and also 230
it requires the analyser to be compatible with the monitor’s 231
API or log. A more effective solution is found in [5] where the 232
authors propose a query language to access the measurements 233
of the monitor. However, in this solution, the monitor must 234
deal with that query language. A more advanced solution is 235
also found at [17], where the authors propose a model to store 236
the results, however such model is not explicitly described. 237
How the violations are explained. The proposals fall into one 238
of the following categories: 239
• Just detection. Some works detect SLA violations without 240
explaining the cause [4], [5], [9], [10], [19], [20]. 241
• Partial explanation. Other approaches provide the SLOs 242
that have been violated [2], [3], [11], [12], [17], leading 243
to a partial explanation of the violation as an SLO could 244
be violated for several reasons that are not detailed. 245
• Precise explanation but not human-understandable. 246
In [13], [14] the authors provide an accurate violation 247
explanation that identifies the violated SLOs and the 248
monitoring results which caused the violation. However, 249
they use Event-Calculus to express both the conditions 250
and monitoring results, which as the authors state, is not 251
user-friendly. 252
Which architectural elements are needed. We find the follow- 253
ing situations: 254
• The proposal does not include an architecture [9], [10]. 255
• The proposal includes an architecture where monitoring 256
and analysis are performed in the same component [20]. 257
• The proposal implements the QoS monitoring and SLA 258
analysis in two separated components with different re- 259
sponsibilities, increasing the cohesion and reusability [2]– 260
[5], [11]–[14], [17], [19]. 261
How the architectural elements are structured. We classify the 262
approaches into: 263
• Component-Based Systems (CBS) [2], [3], [13], [14], 264
[17], [20]. The components are specific of the system, 265
and no details regarding deployment or protocols used are 266
described, which makes them difficult to reuse or replace. 267
• Service-Oriented Architecture (SOA) [4], [5], [11], [12], 268
[19]. This architecture adds the capability of deploying 269
the different constituent services in a distributed manner, 270
adapting or replacing them, in a highly cohesive and 271
loosely coupled system. 272
As a summary of this state of the art (see Table I), we 273
can observe that in the functional part, the proposals cover 274
satisfactorily just one or even none of the four identified 275
issues. Improving this situation is the aim of our work. Our 276
solution takes all the features mentioned and either: (1) cover 277
the issues to the same degree of the best proposal of the state 278
of the art or improves the existing proposals by introducing a 279
new strategy, as it will be described in the following sections. 280
This improvement on functionality is accompanied by optimal 281
architectonic decisions (highly decoupled SOA solution). 282
Our solution includes the usage of platforms from our 283
previous works, SALMon [21] and ADA [22]. The main 284
4
SLA Violations Explainer
SLA
MMD
updated
MMD
Analyser
SLF
Client
Configurator
Monitor
Consumer
Provider
Service’s QoS
Figure 1. Conceptual Reference Model for SLA violations explainers
goals and initial features they had before this approach are as285
follows: ADA is a platform whose main goal is to check the286
consistency of an SLA and compatibility between SLA offers287
and SLA demands. In turn, SALMon is a monitoring platform288
whose main goal is to gather the QoS of web services and289
check simple conditions for several activities. None of these290
platforms succesfully cover the aforementioned issues on their291
own. However, under the SALMonADA platform, both plat-292
forms have been extended to fullfill the required functionality.293
ADA has been extended to support detection and explanation294
of violations, and SALMon has been extended to support295
automatic monitoring configuration and to provide monitoring296
results in a formal document. A detailed description of these297
platforms, including their enhancements in this approach are298
described in Sec. IV-C for SALMon and Sec. IV-D for ADA.299
III. THE SALMONADA CONCEPTUAL REFERENCE300
MODEL301
This section presents the conceptual reference model of the302
SALMonADA platform. This model introduces the relevant303
human and software agents that participate in the platform,304
and the data that they need to interchange. Its purpose is305
to provide a high-level view of the platform before going306
into the architectural and technological details. The conceptual307
reference model is shown in Fig. 1, using the SAP-TAM308
notation [23]. It includes the following agents:309
Client: is the user of the platform. The client goal is310
to retrieve the explanations of SLA violations and/or the311
monitoring results. To fulfill such a goal the client has the312
responsibility of providing the SLA to monitor. The role of313
client may be played by the service consumer, the service314
provider or even a third party interested in monitoring the315
assessment of the SLA.316
Configurator: is the agent that configures the monitor317
with the information included in the SLA. Thus, it decouples318
the SLA (a contractual specification understood by SLA-319
dependent agents) from the Monitor, by generating from the320
SLA a Monitoring Management Document (MMD), which321
is a specification of the monitoring directives to configure a322
monitor (see Sect. IV-B for more details about its structure).323
Monitor: is the agent responsible of monitoring the324
interaction between the provider and the consumer according325
to the monitoring directives given in the MMD. The Monitor326
obtains the measured metrics from such an interaction and327
updates the monitoring results in the MMD right after each328
consumer request.329
Analyser: is the agent that checks whether the monitor-330
ing results of a service, available in the updated MMD, is331
«service» SALMonADA
startMonitoring(MMD, nEndpoint):
idSALMonClient
stopMonitoring(idSALMon-
Client): bool
getMMD(idSALMon-
Client): bool
Notify(MMD, id-
SALMonClient)
«controller»
SALMonADA composer
getAgreement(idSLA):
WSAgreement
storeAgreement(WS-
Agreement): idSLA
getSLF(idSLA, MMD): SLF
deleteAgreement
(idSLA):bool
generateMMD(WSAgreement):MMD
retrieveMeasure(MMD)
startMonitoring
(WSAgreement,
nEndpoint): idClient
stopMonitoring(idClient)
:bool
getSLF(idClient)
: SLF
getMMD(idClient)
: MMD
Notify(SLF, idClient)
updateMeasure(measures, MMD)
«service»
MMD Manager
«service»
ADA
[carlos:] Para el pdf del paper
Client
Consumer
Provider
«service»
SALMon
Figure 2. Architectural Model of SALMonADA
compliant or not with the agreed QoS included in the SLA. It 332
ultimately produces the explanations of violations structured 333
in a document designed for this purpose, the Service Level 334
Fulfillment (SLF). 335
As a summary, the conceptual reference model shows a clear 336
separation of concerns on the management of the SLAs, the 337
MMDs and the SLFs, independent of the concrete technologies 338
used, that are described in the next section. 339
IV. THE SALMONADA PLATFORM 340
In this section we present the details of SALMonADA 341
platform which can be viewed as an instantiation of the 342
conceptual reference model presented above. The platform is 343
able to monitor and analyse expressive SLAs specified with 344
WS–Agreement. SALMonADA has a decoupled architecture 345
that integrates into a service-based system two previously 346
existing systems which in turn, have been extended to re- 347
alize this project: the SALMon monitor [21] and the ADA 348
analyser [22]. Such an architecture is shown in Fig. 2. The 349
core component of SALMonADA is its composer that provides 350
the external interface and controls the execution flow of the 351
system keeping SALMon and ADA decoupled from each other. 352
Moreover, SALMonADA also comprises the MMD Manager 353
service, which is used to generate and manipulate the MMDs 354
independently of the underlying structure of such documents. 355
In the following subsections, we provide more details about 356
these SALMonADA components. We focus on the internal 357
architectures and responsibilities. 358
A. The SALMonADA composer 359
The SALMonADA composer is the component that presents 360
the external interface to the client and controls the execution 361
flow of the system. It also orchestrates the composition of 362
ADA and SALMon to: (1) extract the monitoring information 363
to be included in an MMD from an SLA, (2) monitor SLAs, 364
and (3) analyse SLAs. The composer follows the low coupling 365
design principle, so that it is possible to replace the monitor, 366
the analyser, or the MMD manager without affecting the other 367
elements of the platform. This implies that also the formats of 368
SLAs and MMDs can be changed with minimal impact. 369
Thus, the SALMonADA composer controls the information 370
flow needed for the different constituent services such as: (1) 371
which client is interested in knowing which SLA violations; 372
(2) the MMDs obtained from the SLAs through the MMD 373
5
SALMonADA composer
Client
Manager
storeClient(idSLA, idMonitoringSession,
nEndpoint): idClient
deleteClient(idClient): bool
getClient(idClient): Client
Client
repository
Client Data
startMonitoring(WSAgreement,
nEndpoint): idClient
stopMonitoring(idClient): bool
getSLF(idClient): SLF
getMMD(idClient): MMD
Notify(SLF, idClient)
«service»
MMD Manager
generateMMD
(WSAgreement):MMD
«service»
SALMon
«service»
ADA
«service»
Controller
«service»
Publisher
Figure 3. Architectural Model of the SALMonADA composer
Manager; (3) the MMD with the monitoring results obtained374
by the monitor service; and (4) the pair SLA-MMD with the375
monitoring results that is required by the analyser service.376
Moreover, the composer provides the interface to supply to377
the clients both, the SLF information, and the MMD with the378
monitoring results to be aware of the QoS evolution at runtime.379
The architectural model of the SALMonADA composer is380
depicted in Fig. 3
3
and comprises the following elements:381
Controller: it provides the external interface to the client382
and controls the execution flow of the system by communicat-383
ing with the SALMon and ADA services. It is also responsible384
to interact with the other components of the composer.385
Client Manager: is responsible for storing and retrieving386
the different clients of SALMonADA from the client reposi-387
tory. Each client has associated one or more WS–Agreement388
documents to monitor.389
Publisher: This component implements the Reference390
Data Observer SOA pattern [24]. In SALMonADA it notifies391
the SLF to any subscribed service when a violation occurs.392
B. The MMD Manager service393
The MMD Manager is one of the components that delimits394
the kind of SLA supported by SALMonADA because it395
generates the MMD from a given SLA. SALMonADA aims396
to support a general-purpose SLA specification in order to397
report the SLF of as many SLAs as possible. Although any398
other MMD Manager service can be developed supporting any399
SLA specification, we choose to support the WS–Agreement400
specification due to its flexibility. As stated in Sec. II, the401
WS–Agreement schema must be extended at least with two402
sublanguages. In our proposal we use general-purpose sublan-403
guages [18] to make it easier to map from other sublanguages404
and SLA notations to our supported SLA. Specifically, we405
support specifications of: (1) the service by means of a simple406
attribute-value pairs within SDTs, and (2) the SLOs by means407
of an assertion language that is described in Sec. IV-D. Exam-408
ples of both sublanguages are included in the SLA of Fig. 4409
that comprises several SLOs relating three service properties410
of the ADA analysis service: the average service availability411
3
Note that rounded squares denote stored data and repositories in SAP-TAM
1 Agreement − SALMonADA−c o m p l a i n t ADA SLA
2 Co nt ex t :
3 I n i t i a t o r : I ne e dS L AA n aly sis C or p .
4 Responder : ADA T ool o f ISA Group , a s S e r vic e P r o vi d e r ,
5 E xp ir ation Ti me : 2014−01−01T00 : 0 0 : 0 0
6 A l l
7 ADA−SDT : S e r v i c e D e s c r i p t i o n f o r ADAService
8 / / Web s e r v i c e i n f o r m a t i o n
9 D e s c r i p t i o n = ADA i s an a n a l y s i s t o o l f o r WS−Ag . do cs ,
10 Domain = A n a l y s i s t o o l ,
11 wsdlURL = h t t p : / /www. i s a . u s . e s : 8 0 8 1 / ADAService ? w sd l
12 e n d p o i n t = h t t p : / / www. i s a . u s . e s : 8 0 8 1 / ADAService ? w sd l
13 o p e r a t i o n s : c h e ck D oc u m en t Co n s is t en c y , g e t M e t r i c F i l e ,
14 e x pla inN o nC o mp l ia n ce , xmlToWSAg4People , wsag4PeopleToXML
15 . . . more o p e r a t i o n s a r e i n c l u d e d i n t h e r e a l SLA . . .
16
17 SP1 : S e r v i c e Pr ope rt y f o r ADAService
18 Av er ageResp on se Ti me − measured by m e t r i c : F l o a t ,
19 / / a v e r a g e r e s p o n s e t i m e o f a g i v e n o p e r a t i o n
20 G ene r al R es p on s eTi m e − measured by m e t r i c : Fl o a t ,
21 / / a v e r a g e r e s p o n s e t i m e o f a l l o p e r a t i o n s
22 A v e r a g e A v a i l a b i l i t y − measured by m e t r i c : P e r c e n t
23 / / I t i s t h e a v e r a g e s e r v i c e a v a i l a b i l i t y
24
25 G T g e n e r a l A v a i l a b i l i t y : G uaranteed by Pro vid er
26 SLO: A v e r a g e A v a i l a b i l i t y >= 95
27
28 GT ge ne r al Re s po ns eTi me : Guaranteed by P r ov i de r
29 SLO: G e ne r alR e sp o ns e Ti m e <= 1 . 5
30
31 GTe xplai nN on Com pl ia nceRe sp Time : Guaranteed by P ro v id e r
32 Scope : e xp l ain Non Com p li a nc e ,
33 QC: Gen e ra l Re s po n seT i me >= 0 . 5 ,
34 SLO: A ve ra ge Re sp on se Ti me < 2
35
36 G T g ene r a l R e s p o n s e Tim e R e l a t i o n s : Guaranteed by P rov i de r
37 Scope : c hec k Do c ume n tC o n si s te n c y , xmlToWSAg4People ,
38 wsag4PeopleToXML , g e t M e t r i c F i l e ,
39 QC: Gen e ra l Re s po n seT i me >= 0 . 5 ,
40 SLO: A ve ra ge Re sp on se Ti me <= G e ne r al R es p ons e Ti m e
41 . . . more g u a r a n t e e t e r m s a r e i n c l u d e d i n t h e r e a l SLA . . .
Figure 4. Main terms of the ADA SLA
(AverageAvailability); the average response time of 412
all service operations (GeneralResponseTime); and the 413
average between several response time measures of a given 414
service operation (AverageResponseTime). In this sense, 415
note that the two last SLOs of the SLA guarantee a certain 416
response time depending on the operations that are in the scope 417
of the guarantee term. In addition, such terms are conditional 418
terms because they are guarded by a qualifying condition 419
(QC). That is, the SLOs are only evaluated if the QCs holds. In 420
this case, the QCs holds when the GeneralResponseTime 421
is more than 0.5 seconds. 422
The MMD Manager receives the WS–Agreement document 423
and generates the corresponding MMD. Fig. 5 provides an 424
excerpt of the MMD obtained from the WS–Agreement doc- 425
ument of Fig. 4 and it depicts our selected MMD structure as 426
well as which SLA information is included in each and every 427
of its XML elements. Thus, the MMD structure is divided into 428
four elements: (1) the web service information element which 429
includes the information needed to invoke the service, that 430
is extracted from the service description terms of the SLA; 431
(2) the monitor configuration element which comprises the 432
monitoring time interval, which starts monitoring from the 433
generation of the MMD until the SLA expiration time; (3) the 434
service metrics which are the service properties used within 435
the SLOs whose scope is the whole service (i.e. to all service 436
operation in the SLA); and (4) the operation metrics which 437
