TAPAS UCL Wolfgang Emmerich Wolfgang Emmerich 2002 1

TAPAS @ UCL Wolfgang Emmerich © Wolfgang Emmerich, 2002 1

People Cecilia Mascolo (from April 2002) n Wolfgang Emmerich (from April 2002) n Nima Kaveh @ 50% (from April 2002) n Davide Lamanna @ 50% (from Sept 2002) n A. N. Other (Interviews on 12/04/2002) n © Wolfgang Emmerich, 2002 2

Research to TAPAS @ UCL EPSRC Promile (Programmable Networks) n Kodak MANIAC (Qo. S aware Image Processing Services) n BT Studentship on Middleware for Programmable Networks n Studentship Qualitative Analysis of Distributed Object Design n © Wolfgang Emmerich, 2002 3

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

Agenda Service Level Agreements (SLAs) n Service Level Specifications (SLSs) n Horizontal vs. Vertical SLSs n SLS Monitoring n SLS Enforcement n Research Questions n © Wolfgang Emmerich, 2002 5

Service Level Agreements (SLAs) n n n 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 © Wolfgang Emmerich, 2002 6

Example Buyer Vendor 1 Marketplace Vendorn TTP Credit Rating Agency ASP ISP © Wolfgang Emmerich, 2002 SSP Retail Bank 1 Retail Bankn 7

Typical SLA Content n n 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 © Wolfgang Emmerich, 2002 n n n n n 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 8

Design by Contract (Meyer 1988) Component models provide primitives to design service functionality in interfaces (contracts) n How do we specify non-functional aspects (service levels) of contracts between independent parties? n Service Level Specifications (SLS) are SLAs formalized for automated enforcement and monitoring n © Wolfgang Emmerich, 2002 9

Horizontal vs. Vertical SLSs Assume use of components for assembly of distributed application services n We require horizontal SLSs that govern interaction between components n We also need vertical SLSs that govern the support components get from their infrastructure: n • Component Containers • Storage Service Providers • Internet Service Providers © Wolfgang Emmerich, 2002 10

Horizontal SLSs Specified using component meta model n 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 n Vendor 1 Buyer Marketplace Vendorn Credit Rating Agency © Wolfgang Emmerich, 2002 11

Vertical SLSs Specified referring to infrastructure interfaces n E. g. n Marketplace • Replication levels • Network latency • Storage ASP ISP SSP © Wolfgang Emmerich, 2002 12

SLS Monitoring How well do components / infrastructure abide by the service levels determined in an SLS? n Measure metrics defined in the SLS, e. g. times required to execute certain operations n Component infrastructure needs to interpret SLS and generate alerts to administrators if metrics indicate that service levels have been violated n © Wolfgang Emmerich, 2002 13

SLS Enforcement n 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 © Wolfgang Emmerich, 2002 14

Research Questions for TAPAS Language(s) for service level specification n Seamless integration of functional with non-functional design n Parameterisation of service level specifications n Compositionality of service level specifications n Validation of service level specifications n © Wolfgang Emmerich, 2002 15

Summary and Conclusions Service level agreements are human readable definitions of non functional characteristics n Service level specifications are formal specifications that are monitored and enforced by component infrastructure n Service level specifications impose a number of interesting research questions for TAPAS n © Wolfgang Emmerich, 2002 16