Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 © Wolfgang Emmerich, 2002 UCL Wolfgang Emmerich.

Similar presentations


Presentation on theme: "1 © Wolfgang Emmerich, 2002 UCL Wolfgang Emmerich."— Presentation transcript:

1 1 © Wolfgang Emmerich, 2002 UCL Wolfgang Emmerich

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

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

4 4 © Wolfgang Emmerich, 2002 Service Level Agreements Wolfgang Emmerich and Davide Lamanna Dept. of Computer Science University College London Wolfgang Emmerich and Davide Lamanna Dept. of Computer Science University College London

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

6 6 © Wolfgang Emmerich, 2002 Service Level Agreements (SLAs) n SLA are a means for customers to express their service level needs and for ASPs to distinguish their services n Typically appendixes to legal contracts n ASPs are still struggling to define SLA and manage the service levels n Typical SLA of ISPs include availability, latency, and time for error notification n Also important are problem resolution speed and resources n Refunds are made only upon customer claim in many cases n SLA are a means for customers to express their service level needs and for ASPs to distinguish their services n Typically appendixes to legal contracts n ASPs are still struggling to define SLA and manage the service levels n Typical SLA of ISPs include availability, latency, and time for error notification n Also important are problem resolution speed and resources n Refunds are made only upon customer claim in many cases

7 7 © Wolfgang Emmerich, 2002 Example Marketplace Vendor 1 Vendor n Buyer Credit Rating Agency Retail Bank 1 Retail Bank n ASP ISPSSP TTP

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

9 9 © Wolfgang Emmerich, 2002 Design by Contract (Meyer 1988) n 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 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

10 10 © Wolfgang Emmerich, 2002 Horizontal vs. Vertical SLSs n 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: Component Containers Storage Service Providers Internet Service Providers n 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: Component Containers Storage Service Providers Internet Service Providers

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

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

13 13 © Wolfgang Emmerich, 2002 SLS Monitoring n 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 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

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

15 15 © Wolfgang Emmerich, 2002 Research Questions for TAPAS n 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 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

16 16 © Wolfgang Emmerich, 2002 Summary and Conclusions n 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 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


Download ppt "1 © Wolfgang Emmerich, 2002 UCL Wolfgang Emmerich."

Similar presentations


Ads by Google