1. S-Cube Learning Package
Designing 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. 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 and the 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 the changes 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 software systems
tackle these changes?
Reason
and
Adapt
make
decision
Monitor
7

8. IBM Model for autonomic computing
8

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. 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. 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. 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. 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. 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 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. 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. 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. 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 of an Adaptable SBA

21. Life-cycle for SBAs

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. 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. 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
§ 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. 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. 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. 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. 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 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. 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. A Context-driven Adaptation Process
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. E-government Scenario

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-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
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 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. Open issues and challenges
§ 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