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

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

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

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

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

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

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

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

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

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

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 TypeMetric InstancesComponent Compositions Name = ProcessTime Type = ExecTime Scope=EntireProcess Name = BookingTime Type = ExecTime Scope={flight, train} AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime

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 TypeMetric InstancesComponent Compositions Name = ProcessTime Type = ExecTime Scope=EntireProcess Name = BookingTime Type = ExecTime Scope={flight, train} AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime

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 TypeMetric InstancesComponent Compositions Name = ProcessTime Type = ExecTime Scope=EntireProcess Name = BookingTime Type = ExecTime Scope={flight, train} AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime

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 TypeMetric InstancesComponent Compositions Name = ProcessTime Type = ExecTime Scope=EntireProcess Name = BookingTime Type = ExecTime Scope={flight, train} AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime

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. Name = ServiceCost Type = TotalServiceCost Scope = {deposit, notify} Name = ServiceCost Type = TotalServiceCost Scope = EntireProcess No changes to the process are required. No changes to the SLA are required. Good? Check credit history Ask Manager Validate request Approved ? Deposit Notify Good? Check credit history Ask Manager Validate request Approved ? Deposit Notify

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.

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. Generation Engine AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime Process SLA Necessary events turned on Machine logic for monitoring

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. Process AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime Publish/Subscribe System publish start event publish end event publish execTime event subscribe start and end event publish avgExecTim e event subscribe execTime event

Process 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. AdminAction SevereExecTimeSLO PoorExecTimeSLO GenEventAction AvgExecTime FinishProcInstance StartProcInstance ProcExecTime publish start event publish execTime event subscribe start and end event subscribe execTime event

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

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

Implementation Flexible SLA model –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

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