Precise Service Level
Agreements
James Skene, Davide Lamanna,
Wolfgang Emmerich
University College London
Overview
• SLAng – A language for service level agreements
developed as part of the TAPAS project
– Based on XML
– Vocabulary from industry consultation
• Deviation from previous work
– Considers service provision or more kinds than usual.
– Semantics defined with reference to model of services
• In contrast to defining ontologies of metrics
• Semantics defined using logical formalism
– Model based semantics…
• …suggest approach to agreeing on SLA terms
• …suggest method for comparing SLAs based on impact of interaction
on clients and servers
• …are potentially integrated with other modelling activities
• …provide a reference for SLA monitoring
Problem
• Produce a language for service level agreements
– Syntax
• Human readable: Part of legal contracts
• Machine readable: Potentially useful input to execution environments.
– Semantics
• Cover a difficult domain because it relates to perceived quality of service.
– Easy to understand the objectives
– Hard to understand the details
– Server and client responsibilities entangled
• Apply to diverse systems
– Potentially very diverse if end-to-end
• Require an understanding of contract between service provider and client.
• Must be integrated with other decision making, such as provisioning
• Used to discriminate services
Previous attempts
• QML – Quality Markup Language (HP labs)
• WSOL – Web-services offering language (academic)
• WSLA – Web-Service Level Agreement language
specification (academic)
• QuA, Uniframe (academic)
• Corba Object Trading Service (OMG)
• Why is there not a standard for SLAs?
– People are not trading services?
– Maybe no consensus
– Maybe because semantics requirements don’t seem to have been
met
Solution - Syntax
• XML
– A machine readable format
– Human presentation via XSLT
– Enumeration of type names
• Seen before in several languages
• Other languages possess advanced features that we
have not implemented:
– Declaration of clauses and references
– Templates
– Other finesses
Semantics
• Previous attempts:
– Metrics;
– Ontologies;
– Natural language descriptions.
• Problem: To apply to a broad range of systems,
has to be fairly generic. However, genericity
admits ambiguity.
• Solution: Abstract model of service systems. Say
exactly what we are talking about.
Model of services and service
behaviour
• Defined using UML class model
– One set of classes describe (in abstract) constant
elements in a class of service scenario:
•
•
•
•
•
Client
Service
Operations on the service
Deployment of the service
Data manipulated by the service
– Another set define the events that can occur, associated
with the static elements
• Operation invoked
• Backup performed
Model of SLAs
• Associated with model of services.
• Mimics syntax of SLAng.
Reference Model
Application Tier
Middle Tier
Underlying
resources
App
App
AS
AS
Embedding SLAs
App
App
ASP
SLA
ASP
SLA
ASP
SLA
AS
AS
Network
Hosting
Hosting
Network
SLA
SLA
SLA
SLA
Cont.
SLA
Network
SLA
Storage
Storage
SLA
SLA
Comms
SLA
Network
SLA
Refined
(UML)
Reference
Model
ASP Client and Provider Behaviour
SLAng Syntax
SLAng Abstract Syntax
Syntax Embedded in Service Model
SLAs Embedded
Semantics of SLAs
• SLAs effectively define a restriction on the possible
behaviours of services, ruling out those that can be
considered lacking in quality.
• OCL constraints refine the set of objects that are implied
by a class diagram.
• Our objects represent service usage scenarios.
• We use OCL constraints to distinguish the set of
behaviours that are acceptable in the context of an SLA.
• The presence of SLA elements implies the presence of
SLA constraints.
SLAs partition service
behaviours
App
Client behaviour
ASP
SLA
AS
Interactions
Server behaviour
Good!
Bad!
Example: Performance and
reliability
• Expressed using a single constraint:
– Proportion of downtime observed to total time that the clause applies must
not be greater than the reciprocal of the reliability.
• Intent:
– Any service usage that takes too long or otherwise fails contributes to the
downtime. See enough of these and you can claim unreliability.
• In OCL:
context ServerPerformanceClause inv:
self.operation->forAll(o |
totalDowntime(o) < (applicationTime * (1 - reliability)))
OCL Definitions
context ServerPerformanceClause
def:
-- Returns the client performance clauses governing the performance of
-- operation o at time t.
let applicableClientClauses(t : double, o : Operation) =
sla.clientResponsibilities.clientPerformanceClause->select(c |
c.schedule->exists(s | s.applies(t)))
-- An expression for the maximum throughput with which the client can use an
-- operation at time t, or -1 if there is no limit
let minThroughput(t : double, o : Operation) =
if applicableClientClauses->isEmpty() then -1
else applicableClientClauses->iterate(
c : ClientPerformanceClause, minTP : double |
minTP.min(c.maxThroughput))
More OCL definitions
-- Amount of downtime observed for a failure at time t. This is 1 / the most
-- restrictive throughput constraint applicable at the time
let downtime(t : double, o : Operation) : double =
if minThroughput(t, o) <= 0 then 0
else 1 / minThroughput(t, o)
-- Total amount of downtime observed for the operation
let totalDowntime(o : Operation) : double =
o.serviceUsage->select(u |
(u.failed or u.duration > maximumLatency) and
schedule->exists(s | s.active(u.date))
)->collect(u | downtime(u.date))->iterate(
p : double, sumP : double | sumP + p)
Still more OCL definitions!
context ScheduledClause def:
-- Next time that the current performance clause applies
let nextApplies(t : double) =
schedule->collect(s.nextActive(t))->iterate(n : double, minN : double |
minN.min(n))
-- One of the next schedules that will apply
let nextSchedule(t : double) =
schedule->one(s | s.nextApplies(t) = self.nextApplies(t))
-- The remaining time for this schedule to apply after time t
-- (recursively adds up period of application of next schedule)
let timeRemaining(t : double) =
if(nextApplies(t) = -1) then 0
else nextSchedule(t).nextDuration(t) +
timeRemaining(nextApplies(t) + nextSchedule(t).nextDuration(t))
-- Total amount of time that this clause will apply
let applicationTime =
timeRemaining(nextApplies(-1))
No more after this – I promise
context Schedule def:
-- Calculates t modulo p using operations supported by OCL v.1
let mod(t : double, p : double) =
(t/p - (t/p).floor()) * p
-- Returns true if the schedule applies at time t
let applies(t : double) : boolean =
t > startDate and
mod(t - startDate, period) < duration
Agreeing on an SLA
• SLAs are now like a legal contract that includes
terms and conditions.
• Terms are defined by the service model.
• Conditions are defined by a combination of the
SLA values, and the resulting semantic
constraints.
• Agree on an SLA:
– Establish terms by stating how service situation
corresponds to model.
– Establish conditions by choosing SLA values that result
in acceptable behaviours according to constraints.
Comparing SLAs
• SLAs can now define what behaviours are acceptable.
• SLA X is compatible with SLA Y if all of the behaviours
acceptable to Y are also acceptable to X.
• Superior to previous efforts that rely on simple, usedefined judgements over metric spaces.
• Practical issues:
– Need some way to decide this, and OCL not really suitable as basis
for reasoning (to expressive)
– Client and server responsibilities are entangle. Need to separate
what is acceptable for the client, from what is acceptable for the
service.
Integrating with system modelling
• Why?: Producing systems is harder if SLAs must be met.
• Service model provides domain model for UML extension
(in model-denotational style of semantic definition).
• A number of methods, including our own work for TAPAS
have produced prescriptions for extracting mathematical
models from UML models.
• We apply the proposed profile for QoS specification, to
establish correspondence between elements in UML
designs and entities in our service model.
• Must then produce analysis models.
• Research problem:
– Formal usages of domain models: How do we ensure that
semantics are respected when using models (for example when
producing analysis models)
Implementing SLAng contract
checkers
• Service model is a data model. It includes:
– All the SLAs that apply, with their terms.
– Descriptions of the service elements present.
– All of the events that must be considered to decide if a contract has
been violated.
• Semantic constraints are checks. If any is violated, the
contract had been violated.
• Implement a contract checker that respects semantics:
– Compile model into data storage objects (database plus Java
objects, perhaps)
– Compile constraints into checking procedures (Java conditional
statements for example)
– This is all possible from UML + OCL.
– If we are confident in our compilation process then we are
confident that implementation respects semantics.
Summary
• SLAng
–
–
–
–
–
Based on XML
Vocabulary from industry consultation
Considers service provision or more kinds than usual.
Semantics defined with reference to model of services
Model based semantics…
• …suggest approach to agreeing on SLA terms
• …suggest method for comparing SLAs based on impact of interaction
on clients and servers
• …are potentially integrated with other modelling activities
• …provide a reference for SLA monitoring
• Future work
– Implement checker
– Build consensus for language features