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

Underlyingresources

4

Embedding SLAs

App

AS

ASPSLA

Hosting

SLANetwork

SLA

Network

SLA

Storage

SLA

Comms

SLA

App

AS

ASPSLA

Hosting

SLANetwork

SLA

Network

SLA

Storage

SLA

ASPSLA

Cont.

SLA

5Good! Bad!

SLAs Constrain Behaviour

App

AS

ASPSLA 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 date Period Duration End date

• Associated with a clause

15

Composite SchedulesM 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 ServerPerformanceClausedef: 

-- 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 comparewith our requirements?

22

Using the Semantics: Two Notions of Composition

Intra-service composition:How do the service components contributeto 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.

QoSprofile QoS model

Somecharacteristics

Somesystem model

SLAngSemantic

model

SLAngcharacteristics

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.