On Automated Generation of Web Service Level
Agreements
Cinzia Cappiello, Marco Comuzzi, and Pierluigi Plebani
Dipartimento di Elettronica e Informazione – Politecnico di Milano
Piazza Leonardo da Vinci 32, 20133 Milano (Italy)
{cappiello,comuzzi,plebani}@elet.polimi.it
Abstract. Before a service invocation takes place, an agreement
between the service provider and the service user might be required.
Such an agreement is the result of a negotiation process between the two
parties and defines how the service invocation has to occur. Consider-
ing the Service Oriented Computing paradigm, the relationship among
providers and users is extremely loose. Traditional agreements are likely
to concern long term relationships and to be manually performed. In this
paper, we propose a model to generate service level agreement on-the-fly.
Just before the invocation commences, the quality of the service is nego-
tiated in order to generate a service level agreement tied to that specific
invocation. Such an approach relies on a quality model that supports
both users requirements and providers capabilities definition.
1 Introduction
Organizations are increasingly exporting their services as Web services [1]. Such
a proliferation increases the likelihood that users may find several services sat-
isfying their functional requirements [2,3,4]. When users can choose among a
set of functionally equivalent services, non-functional requirements become the
driver for Web service selection. As a consequence, we need to define and manage
Service Level Agreements (SLAs) between service providers and users [5].
In Service Oriented Computing paradigm, an SLA is defined as a binding con-
tract which formally specifies user expectations about the solution and tolerances.
SLA is a collection of service level requirements that have been negotiated and mu-
tually agreed upon by the information providers and the information consumers.
Usually, providers define some service levels as a fixed combination of their spe-
cific capabilities on a set of quality dimensions, and users must choose one these
levels. Reasonable service levels that meet user requirements can be achieved by
increasing the flexibility of the SLA definition. We argue that this could be ob-
tained by allowing parties, i.e., users and providers, to re-examine and to nego-
tiate defined levels. It is worth noting that identifying attainable service levels is
a time consuming activity for the providers. Adding negotiation features creates
further overhead during SLA definition activity. For these reasons, our approach
does not identify service levels in advance. Providers only clarify their capabilities
J. Krogstie, A.L. Opdahl, and G. Sindre (Eds.): CAiSE 2007, LNCS 4495, pp. 264–278, 2007.
c
Springer-Verlag Berlin Heidelberg 2007
On Automated Generation of Web Service Level Agreements 265
and service levels will be identified on-the-fly considering the users expectations.
Service levels negotiation is also performed on-the-fly to reduce its overhead.
The discussion of mechanisms for on-the-fly generation of the SLA will be
tied to a running example. We focus on a TrafficMonitoring service example.
The TrafficMonitoring Web service provides up-to-date information about local
traffic to business and retail customers across the US. The quality of such a
service is defined by two classes of quality dimensions: technical and domain
dependent.
Technical quality dimensions refer to technical aspects of service provisioning.
Quality dimensions belonging to this class can be associated with any Web ser-
vice, and do not explicitly depend on a characterization of the domain in which
a Web service operates. For the sake of simplicity, we consider three quality di-
mensions, that is, availability, data encryption,andresponse time.Readersmay
refer to [6,7] for an extensive review of Web service technical quality. Availabil-
ity refers to the expected percentage of time the system is up and accessible.
Data encryption refers to the algorithms adopted for protecting data from ma-
licious accesses. Eventually, response time refers to the expected delay between
the moment in which a request is sent and the moment in which results are
received [6].
Domain dependent quality dimensions strongly rely on the type of Web ser-
vice that is under consideration. For the TrafficMonitoring example, we consider
the covered area, routes set,anddetail level dimensions. The covered area di-
mension characterizes the extensiveness of the area over which the service is able
to provide traffic information. A service, for instance, may provide information
only on national highways, while other ones may also consider interstate or local
routes and downtown traffic conditions. Similarly, the detail level of traffic infor-
mation provided by a service may also vary. A service may provide information
on accidents and traffic jams, while other ones may also provide information
about closed routes, detours, and predictions about future conditions of local
traffic.
The paper is organized as follows. Section 2 presents a model to describe
Web service quality, provider capabilities, and user requirements. Section 3 de-
scribes the negotiation model by which SLAs can be obtained on-the-fly. Section
4 discusses related work, while conclusions are finally drawn in Section 5.
2 Quality Model
A negotiation process occurs whenever bothauserandaproviderareableto
define the documents specifying the requirements and the capabilities, namely.
In a Web service environment, where users and providers might not know each
others in advance, these documents must rely on the same language. In [8], a
model able to express the quality of a Web service is discussed. The same model,
discusses in the following, will be adopted in this work as well.
266 C. Cappiello, M. Comuzzi, and P. Plebani
e
availability
K=5
pc
1
=[0,0.3)
…
pc
5
=[0.7,1]
0.5
1
1
0.3
qd
1
.V
0.2
0.4
0.6
0.8
0.6
0.7
(a) Availability
e
data_encryption
pc
1
={AES -128} K =3
pc
2
={AES -192}
pc
3
={AES -256}
qd
2
.V
1
AES128
AES192 AES256
(b) Data Encryption
NE NW
SW
e
covered_area
qd
3
.V
NOT-NEGOTIABLE
SE
1
(c) Covered area
Fig. 1. Evaluation functions and primitive service classes for availability, data encryp-
tion,andcovered area
The quality of a Web service is defined by a set of quality dimensions
1
each
of them associated to a given quality aspect. More formally, we define a quality
dimension qd
i
as:
qd
i
= name,V,ef(V ),PC i =1,...,I. (1)
The name uniquely identifies the quality dimension. The element V corre-
sponds to either categorical or interval admissible values. In the former case, the
admissible values will be included in a specific vector V = {v
h
} (h =1,...,H),
while, in the latter case V will be defined by its extremes, i.e., V =[v
min
,v
max
].
The function ef : V → [0..1] represents the quality evaluation function, i.e.,
how the quality increases or decreases with respect to the admissible values: 0
means lowest quality, 1 highest quality. The trend of ef is usually defined by an
utility function, e.g., linear, logarithmic, exponential, sigmoidal. The admissible
value set V is organized in disjoint primitive service classes PC = {pc
k
} (k =
1,...,K) and are obtained as follows:
– In case of categorical values, the primitive service classes coincide with the
values that the dimension may assume: i.e, qd
i
.P C ≡ qd
i
.V , H = K.
– In case of interval values, primitive service classes are obtained by split-
ting V =[v
min
,v
max
]intoK intervals, so PC = {pc
k
=[pc
k
min
; pc
k
max
]}
where pc
k
max
= pc
(k+1)
min
,pc
1
min
= v
min
,pc
K
max
= v
max
. pc
k
ranges are
obtained as follows: let divide qd
i
.ef(V )inK ranges {[e
k
min
; e
k
max
]},then
p
k
min
= qd
i
.ef
−1
(e
k
min
)andpd
k
max
= qd
i
.ef
−1
(e
k
max
).
Figure 1(a) and 1(b) show, respectively, this methodology applied to the avail-
ability and data encryption dimensions in the running example. The definition
of primitive service classes is exploited by the negotiation algorithms described
in Section 3. We assume that additional elements, such as measurement units
or metrics, are also defined. We do not explicitly include them in qd
i
since they
are not relevant for our approach.
1
In the literature, quality dimensions are also named quality attributes or quality
parameters.
On Automated Generation of Web Service Level Agreements 267
Given a Web service, its quality is defined by the set QD = {qd
i
}.As
mentioned break above, negotiation takes place only if both requirements and
capabilities are expressed on the same quality dimensions set. For this reason we
assume that a third party, called community, is in charge of identifying the set of
relevant quality dimensions. In this way, the quality dimensions included in QD
will be used (i) by the provider to express the offered quality, i.e., capabilities C
and (ii) by the user to define the required quality, i.e., user requirements UR.
As defined in [9], a community is a group of people which aims at proposing
a specification for a group of objects with some relevant common characteris-
tics. More generally, given an application domain, we suppose that a community
exists and produces the set of relevant quality dimensions. Sometimes, the com-
munity can be easily identified since it is explicitly constituted (e.g., tourism
community, financial community). Most of the times the community associated
with an application domain does not explicitly exist. For example, if we want
to buy a laptop then everyone can list the set of relevant quality dimensions
which the evaluation of the laptop quality relies on, e.g., CPU, memory, HD
capacity, screen resolution, and so on. Roughly speaking, the agreement on QD
between providers and users definitely exists but it is implicit. In some way,
introducing the actor community means to make explicit this implicit common
understatement.
Table 1 shows the quality dimensions included in QD for the TrafficMonitoring
example. Once the community decides to include a qd
i
in QD, the community
also defines the range of admissible values, the related evaluation function qd
i
.ef,
and the primitive service classes qd
i
.P C. In Table 1, all the qd
i
∈ QD are
described. In some case (e.g., covered area), the community cannot state which
are the best and worst values, since they depend on the user preferences. So, the
evaluation function always returns 1. This kind of dimensions, as explained in
Section 3, are non-negotiable.
It is worth noting that the range of admissible values has been identified
regardless of a specific Web service implementation. So, we assume that all the
existing Web services, given a quality dimension, can only offer a subset of the
Table 1. Quality parameters for Traffic Monitoring example
name V ef P
availability [0,1] sigmoidal {[0, 0.3); [0.3, 0.5);
(see Figure 1(a)) ...;[0.7, 1]}
data encryption [AES-128;AES-192;. . . ] linear [AES-128;AES-192;. . . ]
response time [0,10] inverse linear {[0.2, 1],...,[9, 10]}
covered area [SouthEast;SouthWest; 1 ∀v
h
∈ V [SouthEast;. . . ]
NorthEast;NorthWest] (see Figure 1(c))
routes set [Highways;interstate; 1 ∀v
h
∈ V [Highways;interstate;
local;. . . ] local;. . . ]
detail level [jams; detours; 1 ∀v
h
∈ V [jams; detours;
toll;. . . ] toll;. . . ]
268 C. Cappiello, M. Comuzzi, and P. Plebani
admissible values defined by the community. In addition, users will customize
the quality dimensions accordingly to their preferences.
Starting from the QD defined by the community, Sections 2.1 and 2.2 describe,
respectively, how the capabilities and the requirements can be defined.
2.1 Capabilities
Capabilities reflect the quality offered by a Web service provider. Focusing on
the service description, the provider before publishing its Web service will define
a document expressing the functional aspects. About this, WSDL represents the
de-facto standard that identifies the set of available operations and exchanged
messages. Along with the functional aspects, the service provider also needs to
attach a document in which the offered quality is described. At this stage, the
literature does not include a language for quality description with the same
consensus as WSDL does for the functional aspects. Anyway, we think that the
capabilities as introduced in the following can be simply expressed according to
languages such as WSOL [10] or WS-Policy [11].
We define a capability c(qd
i
) as a restriction on the range of admissible values
of the quality dimension qd
i
. More precisely:
c(qd
i
)=qd
i
.name,offering, qdprice(offering), (2)
where offering ⊆ qd
i
.V represents the restriction on the range of admissible
values. In this way, the provider defines, given a quality dimension, which are
the actual values the provider is able to support. In addition, the provider also
defines qdprice function which maps the dependency between the offered values
and the price per user associated with such a provisioning.
According to this model, the provider during the publication process of a
Web service, will attach a document C collecting all the supported capabilities.
In particular:
C = {c(qd
i
)}∀qd
i
∈ QD. (3)
In other words, a capability document must include all the quality dimensions
previously identified by the community. Table 2 lists the capabilities of a hypo-
thetical TrafficMonitoring service provider. For instance, the offered availability
is included in the range [0.5, 1.0] and the price for such a provisioning is given by
a fixed amount (e.g., 30$) and a variable one that varies according to the actual
value of the availability (e.g., availability*5$). Similarly, different prices will be
associated to different covered area. Since US NorthEast is more populated than
US NorthWest then the price varies accordingly (e.g., 5$ rather than 3$).
2.2 Requirement Model
Similarly to the capabilities, the user requirements are expressed on the basis
of the quality dimensions identified by the community. In particular, for each
qd
i
∈ QD users operate a restriction on the admissible range of values. With this
