1 / 16

TAPAS @ UCL

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)

rimona
Download Presentation

TAPAS @ UCL

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TAPAS @ UCL Wolfgang Emmerich

  2. 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)

  3. 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

  4. Service Level Agreements Wolfgang Emmerich and Davide Lamanna Dept. of Computer Science University College London {w.emmerich|d.lammana}@cs.ucl.ac.uk

  5. Agenda • Service Level Agreements (SLAs) • Service Level Specifications (SLSs) • Horizontal vs. Vertical SLSs • SLS Monitoring • SLS Enforcement • Research Questions

  6. 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

  7. Example Vendor1 Buyer Marketplace Vendorn TTP Credit Rating Agency ASP ISP SSP Retail Bank1 Retail Bankn

  8. Parties of the agreement Purpose of the SLA Duration of agreement Description of service: Service overview Corporate dependence Priority Critical/peak periods Service level components Availability Transactions Response Utilization Accuracy and Security Targets and metrics for measurement Scheduled unavailability for maintenance/changes Support hours Charging agreements Monitoring actual service levels against targets Responsibilities Service level reporting Penalties for failure Customer service review meetings/renegotiations Contacts Typical SLA Content

  9. 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

  10. 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

  11. 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 Vendor1 Buyer Marketplace Vendorn Credit Rating Agency

  12. Vertical SLSs • Specified referring to infrastructure interfaces • E.g. • Replication levels • Network latency • Storage Marketplace ASP ISP SSP

  13. 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

  14. 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

  15. 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

  16. 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

More Related