|
 |
Web Service Level Agreements (WSLA) Project
What is WSLA?
WSLA in a Nutshell
WSLA is a novel framework for specifying and monitoring Service Level Agreements (SLA) for Web
Services. SLA monitoring and enforcement become increasingly important in a Web Service environment
where enterprises rely on services that may be subscribed dynamically and on demand. For economic
and practical reasons, we want an automated provisioning process for both the service itself as well as the
SLA management system. It measures and monitors the QoS parameters, checks the agreed-upon service
levels, and reports violations to the authorized parties involved in the SLA management process.
The Web Service Level Agreement (WSLA) framework, our approach to these issues, is targeted at
defining and monitoring SLAs for Web Services. Although WSLA has been designed for a Web Services
environment, it is applicable as well to any inter-domain management scenario such as business
process and service management or the management of networks, systems and applications in general.
The WSLA framework consists of a flexible and extensible language based on XML Schema and a run-time
architecture comprising several SLA monitoring services, which may be outsourced to third parties
to ensure a maximum of objectivity. WSLA enables service customers and providers to unambiguously
define a wide variety of SLAs, specify the SLA parameters and the way how they are measured, and relate
them to managed resource instrumentations. Upon receipt of an SLA specification, the WSLA monitoring
services are automatically configured to enforce the SLA.
Relationship of WSLA to WSDL
A Web Service Level Agreement definition complements a service definition. While a service description, e.g. in WSDL defines a Web Service interface, the WSLA specification defines the agreed-upon performance characteristics and the way to evaluate and measure them. Thus, WSLA complements service description languages, such as WSDL. A WSLA specification provides input to the measurement and management system in charge of monitoring the compliance of an SLA. See the Figure below.
Both service provider and service customer may run their own measurement infrastructure and/or management systems. Each party may access measured metrics from various sources, e.g. server side metrics from the service provider and client-side Quality-of-Service (QoS) parameters from the customer. In addition, third parties may be involved in the SLA monitoring and enforcement process.
Delegation of SLA-Monitoring Tasks to Third Parties
One or both signatory parties (the customer and service provider that negotiate and sign the SLA) may choose to delegate all or a part of the SLA-monitoring activities to third parties. They come into play when either a function needs to be carried out that neither service provider nor customer wants to do, or if one signatory party does not trust the other to perform a function correctly. These third parties are called supporting parties and are defined in the WSLA along with the signatory parties of the SLA. Supporting parties are sponsored by either signatory party or by both of them. Supporting parties can act in any combination of the following roles:
- A Measurement Service implements a part or all of the measurement functionality required by one or both signatory parties.
- A Condition Evaluation Service implements functionality to compare actual values against the agreed-upon thresholds for all or a part of the obligations defined in an SLA.
-
A Management Service implements functionality to carry out the management actions of a signatory party once an obligation has been violated.
The above Figure outlines an example configuration of these services, which are implemented by the WSLA runtime environment (cf. the Implementation Page).
Structure of a Web Service Level Agreement
The Figure below illustrates the typical elements of an SLA with signatory and supporting parties. There
are many variations of what types of information and which rules are to be included and, hence, enforced
in a specific SLA.
The parties section, consisting of the signatory parties and supporting parties fields
identify all the contractual parties. Signatory party descriptions contain the identification and the technical properties of a party, i.e., their interface definition and their addresses. The definitions of the supporting
parties contain, in addition to the information contained in the signatory party descriptions, an attribute
indicating the sponsor(s) of the party.
The service description section of the SLA specifies the characteristics of the service and its observable
parameters as follows: For every service operation, one or more bindings, i.e., the transport encoding
for the messages to be exchanged, may be specified. In addition, one or more SLA Parameters of the service are specified here. Examples of such SLA parameters are “service availability”, “service throughput”, or “service response time”. SLA
parameters are composed of (composite) Metrics, which, in turn, aggregate one or more other (composite
or resource) metrics, according to a measurement directive or a function. Examples of composite metrics are
“maximum response time of a service”, “average availability of a service”, or “minimum throughput of a
service”. Examples of resource metrics are “system uptime”, “service outage period”,
“number of service invocations”. Measurement Directives specify how an individual metric can be
accessed. Typical examples of measurement directives are the uniform resource identifier of a hosted computer program, a protocol message, or the command for invoking scripts or compiled computer programs.
Functions specify how a composite metric is computed. Examples of functions are formulas of arbitrary length containing average, sum, minimum, maximum, and various other arithmetic operators, or time series constructors. For every function, an evaluation period is specified. It defines the time intervals during which the functions are executed to compute
the metrics. These time intervals are specified by means of “start time”, “duration”, and “frequency”. Examples of the latter are “weekly”, “daily”, “hourly”, or “every minute”.
Obligations, the last section of an SLA, define various guarantees and constraints that may be imposed on
the SLA parameters: First, the validity period is specified; it indicates the time intervals for which a given SLA parameter is valid, i.e., whether it is allowed to apply constraints at all. Examples of validity periods are “business days”, “regular working hours” or “maintenance periods. We deliberately chose
that validity periods are always specified with respect to a single SLA parameter, and thus only indirectly
applicable to the scope of the overall SLA. The predicate specifies the threshold and the comparison operator (greater than, equal, less than, etc.) against which a computed SLA parameter is to be compared. The result of the predicate is either
“true” or “false”. Actions, finally, are triggered whenever a predicate evaluates to “true”, i.e., a violation
of a guarantee has occurred. Actions are e.g., “sending an event to zero or more signatory and supporting
parties”, “opening a trouble ticket or problem report”, “payment of penalty”, or “payment of premium”.
|
|
United States
