1. Automating SLA Modelling
Tony Chau
IBM Toronto & University of Toronto
Vinod Muthusamy, Hans-Arno Jacobsen
University of Toronto
Elena Litani, Allen Chan, Phil Coulthard
IBM Toronto
October 27, 2008

2. Outline Service level agreement (SLA) SLA modelling & implementation
Flexible SLA model
Automatic generation of monitoring artifacts

3. service time < 3s, otherwise, charge provider
SLA Example
service time < 3s, otherwise, charge provider N Y
Good?
Check
credit history
Ask
Manager
cost < $0.02
Validate request
Approved?
Deposit
Notify

4. service time < 3s, otherwise, charge provider
SLA Example
service time < 3s, otherwise, charge provider Y
Deposit Y
Approved?
Good?
Validate request
Check
credit history
Ask
Manager
Notify N N
cost < $0.02

5. service time < 3s, otherwise, charge provider
SLA Example
service time < 3s, otherwise, charge provider Y
Deposit Y
Approved?
Good?
Validate request
Check
credit history
Ask
Manager
Notify N N
cost < $0.02

6. Service Level Agreement
Contract between service providers and consumers
Define the level of service agreed by both parties
Optionally define the penalty if the level of service is not satisfied

7. SLA Modelling Today Informally expressed (e.g., in a Word document)
Error-prone interpretation
Time consuming implementation
e.g., to monitor the SLA, create dashboards, perform service selection (fabric support), automate resource provisioning
Tightly coupled with the business process
Formally expressed (e.g., WSLA)
Still tightly coupled with the process
Not designed to be reused
Inflexible to changes in the SLA or process

8. Objective
Simplify modelling and monitoring of SLA for any given business process
Encourage reusability and extensibility of SLA model
Automatic generation of monitoring artifacts

9. Automating SLA Modelling
Flexible SLA model
Based on modular, composable and extensible SLA components
Automatic Generation of Monitoring Artifacts
Based on distributed, event-driven architecture

10. The Flexible SLA Model Component-oriented
Composes of several SLA components
Metrics
Service level objectives (SLOs)
Violation actions
SLA components grouped in libraries
form building blocks of constructing SLAs

11. Reusable SLA Components
A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspect of a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Function
void getDependentEvents() {
return {e1, e2, e3, e4}; }
Event Handler
void onEvent(e) {
static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else
diff = e.time – entry[e.instance] publish (diff, e.instance)
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type
Metric Instances
Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Scope={flight, train}
AdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime

12. Reusable SLA Components
A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspect of a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Function
void getDependentEvents() {
return {e1, e2, e3, e4}; }
Event Handler
void onEvent(e) {
static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else
diff = e.time – entry[e.instance] publish (diff, e.instance)
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type
Metric Instances
Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Scope={flight, train}
AdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime

13. Reusable SLA Components
A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspect of a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Function
void getDependentEvents() {
return {e1, e2, e3, e4}; }
Event Handler
void onEvent(e) {
static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else
diff = e.time – entry[e.instance] publish (diff, e.instance)
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type
Metric Instances
Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Scope={flight, train}
AdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime

14. Reusable SLA Components
A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspect of a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Function
void getDependentEvents() {
return {e1, e2, e3, e4}; }
Event Handler
void onEvent(e) {
static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else
diff = e.time – entry[e.instance] publish (diff, e.instance)
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type
Metric Instances
Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Scope={flight, train}
AdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime

15. Loose Coupling of Flexible Model
SLAs and processes can be modified independently. Their loose coupling reduces the possibility of invalidating the SLA.
SLA Modification
Change SLA to consider cost of all invoked services.
Processes Modification
Change process to only look for a flight if the train takes too long.
Good?
Check
credit history
Ask
Manager
Validate request
Approved?
Deposit
Notify
Name = ServiceCost
Type = TotalServiceCost
Scope = {deposit, notify}
Good?
Check
credit history
Ask
Manager
Validate request
Approved?
Deposit
Notify
Name = ServiceCost
Type = TotalServiceCost
Scope = EntireProcess
No changes to the process are required.
No changes to the SLA are required.

16. Invalid SLA components
Validation
During design time, the SLA can be automatically validated against the process. This provides confidence to modify SLAs or processes independently.
Validation
AdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime
Process
SLA
Pass or Fail
Invalid SLA components
Check if required parameters in all component instance have been specified.
Verify that parameters are valid.
Traverse SLA component graph and compute union of dependent events.
Verify that each event’s activity exists in process.

17. Necessary events turned on
Automatic Generation
Given an SLA, monitoring artifacts can be automatically generated for the process. The runtime artifacts, when executing, monitors the process to detect whether the SLA is violated.
Process
Necessary events turned on
Generation
Engine
Machine logic for monitoring
AdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime
SLA

18. Publish/Subscribe System
Runtime Architecture
Runtime is based on publish/subscribe model. SLA components in the SLA model are generated as agents in the publish/subscribe system. These agents act as both publishers and subscribers.
GenEventAction
AdminAction
Process
PoorExecTimeSLO
SevereExecTimeSLO
AvgExecTime
FinishProcInstance
ProcExecTime
publish avgExecTime event
subscribe execTime event
publish execTime event
subscribe start and end event
StartProcInstance
publish end event
publish start event
Publish/Subscribe System

19. Runtime Execution
Events are consumed by agents. After events are processed, agents emit new events to propagate updates. It causes a chain reaction to re-evaluate the SLA.
GenEventAction
AdminAction
Process
PoorExecTimeSLO
SevereExecTimeSLO
AvgExecTime
FinishProcInstance
ProcExecTime
subscribe execTime event
publish execTime event
subscribe start and end event
StartProcInstance
publish start event

20. Distributed Architecture
Designed for distributed systems
Agents can be arbitrarily deployed across the pub/sub system
Scalable

21. Flexible Architecture
Shared processing and network traffic
Multiple SLAs that make use of the same metric can share the generated agent
Events are sent once even if multiple agents are interested
Dynamic runtime modification of SLAs
Add, modify or remove SLAs during monitoring
No downtime

22. Implementation Flexible SLA model Generation engine
Editor implemented for user to modify SLAs
SLAs created for a given BPEL process
BPEL and WebSphere Integration Developer used as proof of concept
Generation engine
Generate monitoring artifacts to be executed in WebSphere Business Monitor Server
Monitoring artifacts monitors BPEL process, to detect whether the SLA is violated
WebSphere products used as proof of concept

23. Conclusion
Simplify modelling and monitoring of an SLA for any given business process
Maximize reusability and extensibility
Reduce development time
Reduce likelihood of errors
Flexible SLA model
SLA components grouped in libraries
SLAs developed by assembling different SLA components
Extensible, flexible, compensable and configurable
Validation
Automatic generation of monitoring artifacts
Automatic enabling of events in a process
Runtime architecture based on pub/sub system
Decentralized and scalable
Better use of computing/network resources