S-CUBE LP: Proactive SLA Negotiation


Published on

Published in: Business, Travel
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

S-CUBE LP: Proactive SLA Negotiation

  1. 1. Khaled Mahbub and George Spanoudakis City University London www.s-cube-network.eu © City University London
  2. 2. SLA and SLA NegotiationService Level Agreement (SLA)  A Service Level Agreement (SLA) is an explicit formal contract between the provider and the clients of a service determining guarantees on service quality properties and penalties in case of defaultsSLA Negotiation  SLA negotiation is the process where service providers and clients reach an agreement on desired levels of service that satisfy each partner involved in the negotiation process.  SLA negotiation typically involves the resolution of differences between the initial positions of the two parties regarding the desired levels of service provision  Two types of negotiation •  Reactive: after decisions on binding with a service have been made and/or once SLA violations has occurred •  Proactive: prior to service binding and/or SLA violation www.s-cube-network.eu © City University London
  3. 3. Proactive SLA Negotiation – TriggeringScenarios (SLA Violation Scenarios)   Following forecasts for a higher level of client demand that can put agreed SLA terms at risk.   Following forecasts that the constituent services of a system will fail or violate their own SLAs (this applies to both software and infrastructure services).   If it becomes known that competitors provide or are going to provide better service offerings www.s-cube-network.eu © City University London
  4. 4. Handling of SLA Violations  Traditional Approaches –  application of penalties depending on the importance of the service level objectives [1,2] –  runtime negotiation (re-negotiation) of SLA [3,4,5,6,7]: -  To accept a service from the existing provider with reduced service levels -  To terminate the existing SLA and negotiate new SLA with a new provider  At runtime, these approaches have limitations as they –  May affect the quality of the delivered service, or –  fail to guarantee uninterrupted service  Proactive SLA negotiation with alternative service providers is a means for addressing such limitations  Proactive SLA negotiation needs to be driven and integrated with service discovery www.s-cube-network.eu © City University London
  5. 5. Two Phase Proactive SLA Negotiation  Identification of potential service providers (aka SLA negotiators): service discovery, search in published SLA templates (i.e., service levels advertised by providers)  Pre-agreement: Process of agreeing SLA terms without putting the SLA into force; it may establish a time frame within which the pre-agreement can be automatically brought into force without further negotiation  Final agreement: Confirmation that an SLA comes into force  The two phases are required for proactive SLA negotiation but may also be useful in reactive negotiation. www.s-cube-network.eu © City University London
  6. 6. Architecture for Proactive (& Reactive) SLANegotiation   The service discovery query may be specified in order to identify candidate replacement services that a composite service (S) uses currently.   The runtime service discovery tool identifies potential alternative services.   The negotiation broker manages the negotiation process on behalf of a service consumer/provider. –  Jess rule engine is used as the negotiation engine –  Negotiation rules are expressed in XML and translated into Jess rules by negotiation rule translator. www.s-cube-network.eu © City University London
  7. 7. Negotiation Rule (1) www.s-cube-network.eu © City University London
  8. 8. Negotiation Rule (2) <tnsr:NegotiationRule name="rule1"> <tnsr:If> <tnsr:LogicalExpression> <slac:Condition relation="LESS-THAN"> <slac:Arg1><slac:QualityAttribute name="RESPONSE_TIME"party="CONSUMER"/></slac:Arg1> <slac:Arg2><slac:Constant type="NUMERICAL" unit=”ms”>10</slac:Constant></slac:Arg2> </slac:Condition> <slac:LogicalOperator>AND</slac:LogicalOperator> <slac:Condition relation="EQUAL-TO"> <slac:Arg1><slac:QualityAttribute name="PRICE"party="CONSUMER"unit=”GBP”/></slac:Arg1> <slac:Arg2><slac:Constant type="NUMERICAL">0.5</slac:Constant></slac:Arg2> </slac:Condition> </tnsr:LogicalExpression> </tnsr:If> <tnsr:Then> <tnsr:Action> <tnsr:Accept> <tnsr:QualityAttribute name="PRICE“ party="CONSUMER" /> <tnsr:QualityAttribute name="RESPONSE_TIME" party="CONSUMER"/> </tnsr:Accept> </tnsr:Action> </tnsr:Then> </tnsr:NegotiationRule>   if the consumer of a service has made an offer (or counter-offer) where the response time of the service must be less than 10 milliseconds (ms) and the price to be paid per service use is 0.5 pounds, the offered values will be accepted. www.s-cube-network.eu © City University London
  9. 9. Negotiation Rule (3)  A rule in Jess has the form (defrule rule-name(logical-operator (cond-1 …cond-n)) ⇒action)  XML negotiation rules are transformed into Jess rule by applying a set of translation patterns: Negotiation Rule Element Jess Representation<slac:Arg><slac:QualityAttribute A-P name="A” party="P"/></slac:Arg><slac:Arg><slac:Constanttype="NUMERICAL">C C </slac:Constant></slac:Arg><slac:Condition relation="REL"> {Jess-Rep(Arg1) REL Jess- <slac:Arg1>...</slac:Arg1> Rep(Arg2)} <slac:Arg2>...</slac:Arg2></slac:Condition><tnsr:Action><tnsr:Set> (modify 0 (Jess-Rep(Arg1) <tnsr:LogicalExpression> (fact-slot-value 0 Jess- <slac:Condition relation="EQUAL-TO"> Rep(Arg2)))) <slac:Arg1>...</slac:Arg1> <slac:Arg2>...</slac:Arg2> </slac:Condition></tnsr:LogicalExpression> </tnsr:Set></tnsr:Action> www.s-cube-network.eu © City University London
  10. 10. SLA Negotiation Process (1)   potential candidate services (RS) are identified.   Services in RS are ranked based on their distances to the query.   RS is updated regularly.   An SLA is negotiated and a pre- agreed SLA is established for each service in RS. www.s-cube-network.eu © City University London
  11. 11. SLA Negotiation Process (2)   Time validity period is set for each pre-agreed SLA.   pre-agreed SLA is proactively re- negotiated if the service is unused and the validity period is about to expire.   A service in SBA is replaced by the best available service in RS if it is needed.   If a service in RS is selected for dynamic binding, its pre-agreed SLA is automatically enforced. www.s-cube-network.eu © City University London
  12. 12. Proactive SLA Negotiation – Evaluation (1)  Case study and evaluation set up: –  A service based client application, called Route Planner, implemented by a BPEL service orchestration process. –  Route Planner uses several services, including Global Positioning Service (GPS) and electronic map service (eMapS). –  A service discovery query is specified in order to identify candidate replacement services for GPS of Route Planner. The discovery query expresses the structural discovery criteria as WSDL of GPS service. –  An SLA template with four QoS terms (price, availability, response time and mean number of service request per hour) for negotiation is used. www.s-cube-network.eu © City University London
  13. 13. Proactive SLA Negotiation – Evaluation (2)  Setup –  A set of 15 service consumer negotiation rules (CNR set) is sued. –  20 different sets of provider negotiation rules sets (PNR set) are used, where each set contains between 5 and 20 rules. During experiment, negotiation broker randomly selects one PNR to simulate the different behaviour that different service provider might have. –  Three different service sets (registries), containing 100, 300 and 500 services, are used. Service sets are populated by geographic location related services taken from SEEKDA. –  All experiments were carried out using a Pentium 2.33GHz with 3.23GB RAM machine. www.s-cube-network.eu © City University London
  14. 14. Proactive SLA Negotiation – Evaluation (3)  Measurements of the time needed to a)  Build the initial candidate service set (RS) by runtime service discovery (SD) b)  Maintain the RS at runtime due to arrival of new service or change in the description of an existing service in the registry c)  Select a new service for replacing a service in the service based system Times required for (a), (b) and (c) were measured for executions of service discovery process •  Without SLA negotiation (SD Only) •  With proactive SLA Negotiation (SD with Proactive SLA) •  With reactive SLA negotiation (SD with Reactive SLA) www.s-cube-network.eu © City University London
  15. 15. Proactive SLA Negotiation – Evaluation (4)   Results (time measurements) SD Only SD with Proactive SLA SD with Reactive SLA 100 300 500 100 300 500 100 300 500ReplacementService Set (RS) 160.62 408.05 686.697 157.399 435.985 715.685 159.804 408.03 688.23Building(Time in Sec.)ReplacementService Set (RS)Maintenance. 690.5 698.3 673.5 837.2 881.2 892 637.4 668.5 677.6avg(trsm-*)(Time in milli-sec)Selection ofReplacementService from RS. 22 28 21.8 53.2 45.8 50.2 453 459.4 443.8avg(trep-*)(Time in milli-sec) www.s-cube-network.eu © City University London
  16. 16. Proactive SLA Negotiation – Evaluation (5)  Results (time measurements) –  service discovery with proactive SLA negotiation is slightly larger than the time required to identify a replacement without any SLA negotiation. –  time required to select and bind a replacement service at runtime in the case of SD with reactive SLA negotiation is significantly larger than the service selection and binding time in the case of SD with proactive SLA negotiation www.s-cube-network.eu © City University London
  17. 17. Proactive SLA Negotiation – Evaluation (6)  Results (effectiveness) Service Agpro = avg(trep-sd-rea-sla) - RGpro=avg(trep-sd-rea-sla) / BEpro= (∑trsm-sd-pro-sla – ∑trsm- Registry avg(trep-sd-pro-sla) avg(trep-sd-pro-sla) sd-rea-sla)/(∑trep-sd-pro-sla – ∑trep-sd- rea-sla) 100 187 8.51 0.999 300 230.4 10.03 1.028 500 192.8 8.84 1.089 www.s-cube-network.eu © City University London
  18. 18. Proactive SLA Negotiation – Evaluation (7)  Results (effectiveness) –  possibility of inefficient resource utilization. –  the efficiency of resource utilization with proactive SLA discovery/ negotiation over a period of time T can be defined as, •  SRRR: the service replacement request rate; •  SRUS: service registry update rate; •  tmatch : average time required to match a query with a service •  tSLA-Neg : average time required to negotiate an SLA with a service •  tinit-RS : the time needed to build the initial copy of RS –  to have efficient resource utilization, there must be that SRRR ≥ SRUR + Rinit/T i.e. SRRR ≥ SRUR www.s-cube-network.eu © City University London
  19. 19. Conclusion & Future Works  Although preliminary, our experiments have shown that proactive SLA negotiation leads to significant reduction of the time required to perform service replacement at runtime.  This approach has opened new possible lines for future investigation, –  Support for proactive negotiation for hierarchical SLA. –  Heuristics for tuning the triggering of proactive SLA negotiation process so as to reduce the number of cases where pre-agreed SLAs never get used –  Support for dynamic adaptation of negotiation rules. www.s-cube-network.eu © City University London
  20. 20. S-Cube Publications  Check the following S-Cube papers for a detail description of Proactive SLA Negotiation framework.   Khaled Mahbub and George Spanoudakis, "A Framework for Proactive SLA Negotiation", 5th International Conference on Software and Data Technologies (ICSOFT 2010), 22 - 24 July, Athens, Greece.   Khaled Mahbub and George Spanoudakis, "Proactive SLA Negotiation for Service Based Systems", Proceedings of the 2010 IEEE World Congress on Services (SERVICES 2010), 5-10 July 2010, Miami, Florida, USA.   Khaled Mahbub and George Spanoudakis "Proactive SLA Negotiation for Service Based Systems: Initial Implementation and Evaluation Experience", 8th IEEE International Conference on Services Computing, July 4 - 9, 2011, Washington DC, USA. www.s-cube-network.eu © City University London
  21. 21. References1.  Service Level Agreements”, the Proceedings of the Usage of Service Level Agreements in Grids Workshop, 20072.  Q. He, J. Yan, R. Kowalczyk, H. Jin, Y. Yang, "Lifetime Service Level Agreement Management with Autonomous Agents for Services Provision". Information Sciences, Elsevier, 20093.  “SLAM – Service Level Agreement Management”, Whitepaper, Whitestein Technology, August 2005.4.  Dominic Greenwood, Giosue Vitaglione, Lukas Keller and Monique Calisti, “Service Level Agreement Management with Adaptive Coordination”, International Conference on Networking and Services (ICNS’06), July 19-21, 2006, Silicon valley, USA.5.  Di Modica G.,Tomarhio O. and Lorenzo V., "A framework for the management of dynamic SLAs in composite service scenarios", Service-Oriented Computing - ICSOC 2007 Workshops: ICSOC 2007, International Workshops, Vienna, Austria, September 17, 20076.  Michael Parkin, Peer Hasselmeyer, Bastian Koller, Philipp Wieder: An SLA Re-negotiation Protocol. In proceedings of the 2nd Workshop on Non Functional Properties and Service Level Agreements in Service Oriented Computing at ECOWS 2008. Dublin, Ireland. 12 November 2008.7.  Rizos Sakellariou and Viktor Yarmolenko, "On the Flexibility of WS-Agreement for Job Submission", Proceedings of the 3rd International Workshop on Middleware for Grid Computing MGC 05, vol. 117, 1-6 (Nov. 2005) www.s-cube-network.eu © City University London