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

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

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

4 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

5 Good!Bad! SLAs Constrain Behaviour App AS ASP SLA Interactions Server behaviour Client 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 Applies Does not apply Start datePeriodDurationEnd date Associated with a clause

15 Composite Schedules 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 Using the Semantics: Two Notions of Composition Inter-service composition: How does an offered level of QoS compare with our requirements?

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

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 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. QoSprofileQoS model Some characteristics Some system model SLAng Semantic model SLAng characteristics

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.