S-CUBE LP: Techniques for design for adaptation


Published on

Published in: Technology, Education
  • 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: Techniques for design for adaptation

  1. 1. S-Cube Learning PackageDesigning and migrating Service-Based Applications: Techniques for design for adaptation Politecnico di Milano (POLIMI), Fondazione Bruno Kesler (FBK) Elisabetta Di Nitto and Cinzia Cappiello (POLIMI), Antonio Bucchiarone (FBK) www.s-cube-network.eu
  2. 2. Learning Package Categorization S-Cube Engineering Principles, Techniques & Methodologies Designing and migrating Service-Based Applications Techniques for design for adaptation © Di Nitto, Cappiello, Bucchiarone
  3. 3. Learning Package Overview§  Problem Description (changes in the world and self- adaptation)§  Support to self-adaptation during the lifecycle of a SBA§  Context changes and self-adaptation§  Conclusions © Di Nitto, Cappiello, Bucchiarone
  4. 4. The machine and the world Domain properties (assumptions) Goals Specification Requirements
  5. 5. Software lifecycle changes §  Clear distinction between development and execution time Design Verification Execution Deployment §  Every change in the world requires the execution be interrupted and a new software be developed and deployed
  6. 6. What are the changes we need to careof? Functional Goals/ Requirements Non-functional e.g., moving from Location open air to the meeting room User World e.g., today I do Preferences not feel I can take phone calls New SLA Domain Business properties (context) New regulation e.g., the service I’m using is not working Changes in used resources e.g., I’ve run out System of computational resources SLA has been broken 6
  7. 7. How can software systemstackle these changes? Reason and Adapt make decision Monitor 7
  8. 8. IBM Model for autonomic computing 8
  9. 9. Monitoring§  Monitor all possible data§  Activate/deactivate various levels of monitoring depending on the situation§  Perform some filtering to limit the amount of monitoring data offered to the system§  Correlate data 9
  10. 10. Reasoning on monitoring results (1)§  Reasoning can be hardcoded in the execution environment –  E.g.: always replace a failing service with the first one you find in a directory –  Advantage: No need to perform specific programming actions to achieve self-adaptation –  Drawback: Limited to a set of predefined options 10
  11. 11. Reasoning on monitoring results (2)§  Programming mechanisms are made available to define adaptation strategies –  Usually, rule-based languages. Strategies defined in terms of Event- conditions-actions rules –  Advantage: good level of flexibility in defining system-dependent strategies –  Drawback: rule-based programming approach is difficult to use. Validation of result is challenging –  Examples: SCENE (SeCSE), SOA4All 11
  12. 12. Reasoning on monitoring results (3)§  Modeling languages and approaches are offered to define adaptation strategies … –  Use of formal methods –  Possibility to check the effect of adaptation before enacting it§  Examples: ASTRO, Service-tiles (see later)… 12
  13. 13. Actuating adaptation§  Many variations –  Can be specific of a single system instance or it can apply to all running instances –  Can impact only on future instances of system –  Can be permanent or transitory 13
  14. 14. Learning Package Overview§  Problem Description (changes in the world and self- adaptation)§  Support to self-adaptation during the lifecycle of a SBA§  Context changes and self-adaptation§  Conclusions © Di Nitto, Cappiello, Bucchiarone
  15. 15. Problem we tackle here§  Design for Adaptation –  Adaptation Triggers –  Adaptation Strategies –  Mechanisms to enable adaptation that associate strategies with triggers§  Today –  Existing design methodologies do not take into account the problem of SBAs adaptation in a holistic way, but only in a fragmented way§  Our Proposal –  Design phase –  We suggest a number of design principles and guidelines to enable adaptation –  We propose an extension of a basic iterative SBAs life-cycle
  16. 16. Motivating Scenarios§  The life-cycles and frameworks available for SBAs do not support adaptation or tend to focus on specific adaptation strategies§  We consider three scenarios from different domains with different adaptation aspects. –  Automotive –  Wine Production –  Mobile Users§  SBAs have to face very different adaptation needs
  17. 17. Automotive Scenario§  Scenario Description –  Supply-chain business processes in the automobile production domain -  Ordering and importing automobile body parts from supplier -  manufactoring activities -  customization of the products according to customers’ needs –  Long running processes involving a wide range of enterprise services -  Agile Service Network (ASN)§  Scenario Adaptations –  Partner can be chosen at runtime from those belonging to the ASN –  SBA needs to recover from some problem and to accomodate some change in the business context
  18. 18. Wine Production Scenario§  Scenario Description –  SBA realized on a top of a Wireless Sensor and Actuator Nework –  Activities of vineyard cultivation handling, the control of grapes maturation, their harvesting and fermentation§  Scenario Adaptations –  Ability of autonomously detect problems -  Replace devices that may crash, run out of battery or provide incorrect information -  Change the topology of network to optimize the load and the distribution of the sensors
  19. 19. Mobile Users Scenario§  Scenario Description –  A huge number of applications aims to give end user access to various services through mobile devices -  Navigation and route planning, services for accessing social networking and blogging§  Scenario Adaptations –  Continuously changing context -  e.g. Network throughput, user location and time, etc. –  Continuously changing user goals and activities
  20. 20. Main Ingredients of an Adaptable SBA
  21. 21. Life-cycle for SBAs
  22. 22. Adaptation Strategies§  To mantain aligned the application behaviour with the context and system requirements –  Service substitution –  Re-execution –  (Re-)negotiation –  (Re-)composition –  Compensation –  Log/Update adaptation Information –  Fail
  23. 23. Adaptation Triggers§  The adaptation may be motivated by variety of triggers§  Component Services –  Service functionality –  Service quality§  SBAs context –  Business context –  Computational context –  User context
  24. 24. Adaptation Strategies & Triggers§  To re-align the application within the system and/or context requirements§  Each trigger can be associated with a set of adaptation strategies
  25. 25. Design Guidelines§  Design adaptable SBAs implies relate adaptation triggers and adaptation strategies together –  Modeling adaptation triggers –  Realizing adaptation strategies –  Associating adaptation strategies to triggers§  Design approaches –  Built-in adaptation –  Abstraction-based adaptation –  Dynamic adaptation
  26. 26. Discussion – Automotive Scenario§  Properties –  Stable Context and partners –  Long-running SBA instances –  Diversity of Adaptation needs –  Decisions require human involvement§  Adaptation Triggers –  Functional changes –  SLA violations –  Changes in business context§  Design Approach –  Dynamic Adaptation (human-driven) –  Built-in Adaptation (for compensation or process customization)§  Adaptation Strategy –  Service substitution –  SLA re-negotiation –  Re-composition by ad-hoc changes of process control/data –  Trigger evolution
  27. 27. Discussion – Wine Scenario§  Properties –  Fully dynamic and unreliable services –  Fully autonomous SBA§  Adaptation Triggers –  Degrade of service (sensor) QoS§  Design Approach –  Abstraction-based adaptation§  Adaptation Strategy –  Re-composition of services –  Domain-specific actions -  e.g. data transfer frequency changes
  28. 28. Discussion – Mobile User§  Properties –  Strong dependency from context and goals of users§  Adaptation Triggers –  Context changes –  Changes of user activities§  Design Approach –  Abstraction-based adaptation (for context changes) –  Dynamic adaptation§  Adaptation Strategy –  Service substitution (by dynamic discovery) –  Service re-composition
  29. 29. Learning Package Overview§  Problem Description (changes in the world and self- adaptation)§  Support to self-adaptation during the lifecycle of a SBA§  Context changes and self-adaptation§  Conclusions © Di Nitto, Cappiello, Bucchiarone
  30. 30. Problem we tackle here§  Focus on the role of the context in Service Based Applications –  How and when the context should be defined –  How the context should be exploited –  How the context should be evolved –  What is the impact of the context on the various adaptation activities
  31. 31. Context and context model§  Context: any information that can be used to characterize persons, places or objects that are considered relevant to the interaction between a user and the application§  Context model: Captures dimensions that can trigger adaptation –  Six dimensions -  TimeContext -  AmbientContext: e.g., location of users -  UserContext: i.e., user preferences -  ServiceContext: i.e., services used by the application -  BusinessContext: e.g., conditions in which application runs -  ComputationalContext: e.g., device that runs the application –  We have an XML representation of the context
  32. 32. A Context-driven Adaptation Process Monitored Define adaptation and Events monitoring requirements Design Context Context Dimensions Adaptation Early Requirement Properties Design monitoringRequirements Engineering And adaptation Context Adaptation Identify Runtime Requirement strategies Properties adaptation Monitoring Engineering Watchers Context Modeling requirements and Design Operation, Design context-driven Identify management and Reasoners adaptation quality assurance strategy Construction Contextual Monitors Strategy Deployment And Instance Enact and provisioning Adaptation Mechanisms adaptation Deploy Design monitoring Adaptation Contextual Monitors And adaptation Mechanism And Adaptation Mechanisms
  33. 33. E-government Scenario
  34. 34. Design Context Dimensions §  Decide which context dimensions are relevant for the application Application Time Ambient User Service Computing Business Design Health-care X X X X X XContext Dimensions Administrative X X X X X X Census & Reg X X X X X Early Information X X X X X X Requirement Engineering Auxiliary X X X X Requirement Engineering and Design
  35. 35. Context modeling §  Instantiate the domain for context dimensions SBA context Ambient Space Zip codes Citizen, User Authority… Normal, Business EmergencyContext Modeling Morning, afternoon, Time Requirement evening Engineering and Design Service Used Services Pda, PC, Phone Computing
  36. 36. Design of context-driven adaptation reasoner §  Changes in dimensions can trigger the corresponding strategies Application Time Ambient User Service Computing Business Service X X X X X X substitutionDesign of Re-execution X X Xcontext-drivenadaptation reasoner Re-composition X X X Fail (Abort) X X X X Concretization X X X X X X Requirement Engineering Re-negotiation X X X and Design Compensation X X Evolution X X X X X
  37. 37. Requirement Engineering Outcome Monitored Events Design Context Dimensions Adaptation Early RequirementRequirements Engineering Context Modeling Adaptation Identify Requirement strategies Engineering adaptation requirements and Design Design context-driven Reasoners Context Identify Properties adaptation strategy Construction
  38. 38. Learning Package Overview§  Problem Description (changes in the world and self- adaptation)§  Support to self-adaptation during the lifecycle of a SBA§  Context changes and self-adaptation§  Conclusions © Di Nitto, Cappiello, Bucchiarone
  39. 39. Conclusions§  We propose a framework to support the design of SBAs that targets the adaptation requirements raised by context changes§  We propose a novel life-cycle that emphasizes the relevance of the context dimensions in the different facets of adaptation, both during the design phase and at run-time.§  The proposed approach provides guidelines for –  The identification of the relevant context dimensions to monitor –  The definition of the adaptation triggers able to link context changes with suitable adaptation strategies§  The effectiveness of the approach has been evaluated by considering some realistic scenarios
  40. 40. Open issues and challenges§  How to test self-adaptable software§  Support to unforeseen changes§  Preventive adaptation§  Dependable self-adaptable software§  … 40
  41. 41. Further S-Cube Reading§  A. Bucchiarone, C. Cappiello, E. Di Nitto, R. Kazhamiakin, V. Mazza, M. Pistore, “Design for Adaptation of Service-Based Applications: Main Issues and Requirements”. ICSOC/ServiceWave Workshops 2009: 467-476§  A. Bucchiarone, C. Cappiello, E. Di Nitto, R. Kazhamiakin, V. Mazza, "A Context-driven Adaptation Process for Service-based Applications". Proceedings of the PESOS workshop in conjunction with the ICSE conference, 2010§  A. Metzger, E. Schmieders, C. Cappiello, E. Di Nitto, R. Kazhamiakin, B. Pernici, et al. (2010). Towards Proactive Adaptation: A Journey along the S-Cube Service Life-Cycle. In MESOA: 4th International Workshop on Maintenance and Evolution of Service-Oriented Systems.§  A. Bucchiarone, C. Cappiello, E. Di Nitto, S. Gorlatch, D. Meiländer, A. Metzger, “Design for self-adaptation in Service-oriented systems in the Cloud”. In: European Research Activities in Cloud Computing, to appear. © Di Nitto, Cappiello, Bucchiarone
  42. 42. Acknowledgements The research leading to these results has received funding from the European Community’s Seventh Framework Programme [FP7/2007-2013] under grant agreement 215483 (S-Cube). © Di Nitto, Cappiello, Bucchiarone