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 dont 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 App AS App AS Application Tier Middle Tier Underlying resources

Embedding SLAs App AS ASP SLA Hosting SLA Network SLA Network SLA Storage SLA Comms SLA App AS ASP SLA Hosting SLA Network SLA Network SLA Storage SLA ASP SLA Cont. 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.

Good!Bad! SLAs partition service behaviours App AS ASP SLA Interactions Server behaviour Client behaviour

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, use- defined 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