SLAng Semantics, and Service
Composition
James Skene, Davide Lamanna,
Wolfgang Emmerich
1
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)
2
Reference Model
Application Tier
Middle Tier
App
App
AS
AS
Underlying
resources
3
Embedding SLAs
App
App
ASP
SLA
ASP
SLA
ASP
SLA
AS
AS
Network
Hosting
Hosting
Network
SLA
SLA
SLA
SLA
Cont.
SLA
Network
SLA
Storage
Storage
SLA
SLA
Comms
SLA
Network
SLA
4
SLAs Constrain Behaviour
App
Client behaviour
ASP
SLA
AS
Interactions
Server behaviour
Good!
Bad!
5
Refined
(UML)
Reference
Model
6
ASP Client and Provider Behaviour
7
SLAng Syntax
8
SLAng Abstract Syntax
9
Syntax Embedded in Service Model
10
SLAs Embedded
11
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?
12
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.
13
Schedules
• Associated with a clause
Applies
Does not apply
Start date
Period
Duration
End date
14
Composite Schedules
M T W T F
M T W T F
Mondays
Tuesdays
Wednesdays
Thursdays
Fridays
Combined
15
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)))
16
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))
17
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)
18
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))
19
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
20
Using the Semantics: Two
Notions of Composition
Inter-service composition:
How does an offered level of QoS compare
with our requirements?
21
Using the Semantics: Two
Notions of Composition
Intra-service composition:
How do the service components contribute
to the QoS of the composed service?
22
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.
23
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
24
acceptable to the client.
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.
25
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
Some
characteristics
SLAng
characteristics
Some
system model
QoS model
SLAng
Semantic
model
26
The SLAng Catalogue
27
Example
28
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?
29
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. 30
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.
31