1 / 28

Precise Service Level Agreements

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

chaka
Download Presentation

Precise Service Level Agreements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Precise Service Level Agreements James Skene, Davide Lamanna, Wolfgang Emmerich University College London

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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.

  7. 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

  8. Model of SLAs • Associated with model of services. • Mimics syntax of SLAng.

  9. App App AS AS Reference Model Application Tier Middle Tier Underlying resources

  10. App AS Embedding SLAs App ASP SLA ASP SLA ASP SLA AS Network SLA Hosting SLA Hosting SLA Network SLA Cont. SLA Storage SLA Storage SLA Network SLA Network SLA Comms SLA

  11. Refined (UML) Reference Model

  12. ASP Client and Provider Behaviour

  13. SLAng Syntax

  14. SLAng Abstract Syntax

  15. Syntax Embedded in Service Model

  16. SLAs Embedded

  17. 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.

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

  19. 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)))

  20. 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))

  21. 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)

  22. 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))

  23. 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

  24. 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.

  25. 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.

  26. 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)

  27. 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.

  28. 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

More Related