SLAng Semantics, and Service Composition

1. SLAng Semantics, and Service Composition James Skene, Davide Lamanna, Wolfgang Emmerich

2. Approach to defining the Semantics of SLAng • Model the environment of SLAs, i.e. Internet services • Model the SLA language itself • Embed the language model in the Internet service model • Show how SLAs constrain the services (assuming they are respected)

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

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

5. App AS Good! Bad! SLAs Constrain Behaviour Client behaviour ASP SLA Interactions Server behaviour

6. Refined (UML) Reference Model

7. ASP Client and Provider Behaviour

8. SLAng Syntax

9. SLAng Abstract Syntax

10. Syntax Embedded in Service Model

11. SLAs Embedded

12. Features of ASP contract • Backup clauses: • How frequent • What type of backup • Should the backup be encrypted? • What datatypes • How can the client access the backups • Monitoring clauses: • What monitoring solution? • How frequent • On demand?

13. Features of ASP contract (2) • Server Performance • Maximum latency for service operations • Reliability (proportion of time that service should be available) • Maximum time to repair • Client Performance • Maximum throughput • These clauses are scheduled to allow different performance at different times. • Also the specification of maintenance periods.

14. Schedules • Associated with a clause Applies Does not apply Start date Period Duration End date

15. Composite Schedules M T W T F M T W T F Mondays Tuesdays Wednesdays Thursdays Fridays Combined

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

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

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

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

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

21. Inter-service composition: How does an offered level of QoS compare with our requirements? Using the Semantics: Two Notions of Composition

22. Intra-service composition: How do the service components contribute to the QoS of the composed service? Using the Semantics: Two Notions of Composition

23. SLA Compatibility • Compare offered SLA with requirements expressed in as SLA. • SLAs impose constraints on the services that they are associated with. • SLA B is compatible with SLA A if they constrain the same services and B allows no behaviours/configurations that would violate A.

24. Implications of our Definition of Compatibility • Must compare complete SLAs because of interactions between terms • Example: Reliability constraints depends on three specifications: • maximumLatency • reliability • maximumThroughput – A client constraint • In this example only SLAs with the same or stronger throughput constraint have the chance to be compatible. • Stronger throughput constraint may not be acceptable to the client.

25. Intra-service Composition • We need to know what the service is doing. This requires a view of the design of the system • In general, we need to perform analysis. • Our approach to this is to analyse UML designs as discussed in previous presentations. • To integrate SLAs we need notation for SLAs in designs.

26. Some characteristics SLAng characteristics SLAng Semantic model Some system model The QoS Profile • ‘UML Profile for Modelling Quality of Service and Fault Tolerance Characteristics and Mechanisms’, or the QoS profile. • The QoS profile allows Modelling of QoS Properties. • Profiles are defined with reference to semantic models. QoSprofile QoS model

27. The SLAng Catalogue

28. Example

29. Implementing SLAng Systems • Take a Model Driven Architecture approach • SLAng semantics provide a reference for the behaviour of SLA aware systems. • Use semantics led transformations to refine designs. • Why not model the TAPAS architecture too?

30. Conclusions • We have formally defined the SLAng semantics for ASP SLAs. • We embedded a model of the language into a model of services. • We used constraints to show the effect that SLAs have. • The semantic provides a basis for comparing SLAs – compatibility. • The semantic forms the basis for a UML extension allowing analysis and implementation activities.

31. Future Work • Starting to be overwhelmed by UML extensions. • Lots of confusing models. Are they models, meta-models, domain models, semantic models, domain specific languages, UML extensions? • Need a unified approach to handling diverse model information, probably based on meta-modelling and consistency rules.