Tapas @ ucl
Sponsored Links
This presentation is the property of its rightful owner.
1 / 16

TAPAS @ UCL PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

TAPAS @ UCL. Wolfgang Emmerich. People. Cecilia Mascolo (from April 2002) Wolfgang Emmerich (from April 2002) Nima Kaveh @ 50% (from April 2002) Davide Lamanna @ 50% (from Sept 2002) A. N. Other (Interviews on 12/04/2002). Research to TAPAS @ UCL. EPSRC Promile (Programmable Networks)

Download Presentation


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Wolfgang Emmerich


  • Cecilia Mascolo (from April 2002)

  • Wolfgang Emmerich (from April 2002)

  • Nima Kaveh @ 50% (from April 2002)

  • Davide Lamanna @ 50% (from Sept 2002)

  • A. N. Other (Interviews on 12/04/2002)

Research to TAPAS @ UCL

  • EPSRC Promile (Programmable Networks)

  • Kodak MANIAC (QoS aware Image Processing Services)

  • BT Studentship on Middleware for Programmable Networks

  • Studentship Qualitative Analysis of Distributed Object Design

Service Level Agreements

Wolfgang Emmerich and Davide Lamanna

Dept. of Computer Science

University College London

[email protected]


  • Service Level Agreements (SLAs)

  • Service Level Specifications (SLSs)

  • Horizontal vs. Vertical SLSs

  • SLS Monitoring

  • SLS Enforcement

  • Research Questions

Service Level Agreements (SLAs)

  • SLA are a means for customers to express their service level needs and for ASPs to distinguish their services

  • Typically appendixes to legal contracts

  • ASPs are still struggling to define SLA and manage the service levels

  • Typical SLA of ISPs include availability, latency, and time for error notification

  • Also important are problem resolution speed and resources

  • Refunds are made only upon customer claim in many cases







Credit Rating Agency




Retail Bank1

Retail Bankn

Parties of the agreement

Purpose of the SLA

Duration of agreement

Description of service:

Service overview

Corporate dependence


Critical/peak periods

Service level components





Accuracy and


Targets and metrics for measurement

Scheduled unavailability for maintenance/changes

Support hours

Charging agreements

Monitoring actual service levels against targets


Service level reporting

Penalties for failure

Customer service review meetings/renegotiations


Typical SLA Content

Design by Contract (Meyer 1988)

  • Component models provide primitives to design service functionality in interfaces (contracts)

  • How do we specify non-functional aspects (service levels) of contracts between independent parties?

  • Service Level Specifications (SLS) are SLAs formalized for automated enforcement and monitoring

Horizontal vs. Vertical SLSs

  • Assume use of components for assembly of distributed application services

  • We require horizontal SLSs that govern interaction between components

  • We also need vertical SLSs that govern the support components get from their infrastructure:

    • Component Containers

    • Storage Service Providers

    • Internet Service Providers

Horizontal SLSs

  • Specified using component meta model

  • E.g. A market place component guarantees to a buyer component for a rate below 10 remote method invocations per second a response time of 0.5 milliseconds





Credit Rating Agency

Vertical SLSs

  • Specified referring to infrastructure interfaces

  • E.g.

    • Replication levels

    • Network latency

    • Storage





SLS Monitoring

  • How well do components / infrastructure abide by the service levels determined in an SLS?

  • Measure metrics defined in the SLS, e.g. times required to execute certain operations

  • Component infrastructure needs to interpret SLS and generate alerts to administrators if metrics indicate that service levels have been violated

SLS Enforcement

  • Rather than reactively alert SLS violations use component infrastructure to enforce service levels, e.g.

    • Increase response time of remote requests between components by tightening vertical service level specifications

    • Increase scalability of component execution before it is to violate service level specifications by proactively replicating them

Research Questions for TAPAS

  • Language(s) for service level specification

  • Seamless integration of functional with non-functional design

  • Parameterisation of service level specifications

  • Compositionality of service level specifications

  • Validation of service level specifications

Summary and Conclusions

  • Service level agreements are human readable definitions of non functional characteristics

  • Service level specifications are formal specifications that are monitored and enforced by component infrastructure

  • Service level specifications impose a number of interesting research questions for TAPAS

  • Login