Download as PDF, PPTX
![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](https://image.slidesharecdn.com/techniquesfordesignforadaptation-111206101043-phpapp02/75/S-CUBE-LP-Techniques-for-design-for-adaptation-42-2048.jpg)
More Related Content
Similar to S-CUBE LP: Techniques for design for adaptation
S-CUBE LP: Techniques for design for adaptation
- 1. S-Cube Learning Package Designingand 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. 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. 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. The machine andthe world Domain properties (assumptions) Goals Specification Requirements
- 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. What are thechanges we need to care of? 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. How can softwaresystems tackle these changes? Reason and Adapt make decision Monitor 7
- 8. IBM Model forautonomic computing 8
- 9. Monitoring § Monitor allpossible 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. Reasoning on monitoringresults (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. Reasoning on monitoringresults (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. Reasoning on monitoringresults (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. Actuating adaptation § Manyvariations – 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. 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. Problem we tacklehere § 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. Motivating Scenarios § Thelife-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. Automotive Scenario § ScenarioDescription – 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. 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. 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. Main Ingredients ofan Adaptable SBA
- 21.
- 22. Adaptation Strategies § Tomantain 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. Adaptation Triggers § Theadaptation may be motivated by variety of triggers § Component Services – Service functionality – Service quality § SBAs context – Business context – Computational context – User context
- 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. Design Guidelines § Designadaptable 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. Discussion – AutomotiveScenario § 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. Discussion – WineScenario § 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. Discussion – MobileUser § 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. 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. Problem we tacklehere § 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. Context and contextmodel § 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. A Context-driven AdaptationProcess Monitored Define adaptation and Events monitoring requirements Design Context Context Dimensions Adaptation Early Requirement Properties Design monitoring Requirements 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.
- 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 X Context 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. Context modeling § Instantiate the domain for context dimensions SBA context Ambient Space Zip codes Citizen, User Authority… Normal, Business Emergency Context Modeling Morning, afternoon, Time Requirement evening Engineering and Design Service Used Services Pda, PC, Phone Computing
- 36. Design of context-drivenadaptation reasoner § Changes in dimensions can trigger the corresponding strategies Application Time Ambient User Service Computing Business Service X X X X X X substitution Design of Re-execution X X X context-driven adaptation 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. Requirement Engineering Outcome Monitored Events Design Context Dimensions Adaptation Early Requirement Requirements Engineering Context Modeling Adaptation Identify Requirement strategies Engineering adaptation requirements and Design Design context-driven Reasoners Context Identify Properties adaptation strategy Construction
- 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. Conclusions § We proposea 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. Open issues andchallenges § How to test self-adaptable software § Support to unforeseen changes § Preventive adaptation § Dependable self-adaptable software § … 40
- 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. 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