Page 1
www.s-cube-network.eu
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)
Page 2
Learning Package Categorization
S-Cube
Engineering Principles, Techniques & Methodologies
Designing and migrating Service-Based Applications
Techniques for design for adaptation
Page 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
Page 4
The machine and the world
Goals
Requirements
Domain
properties
(assumptions)
Specification Goals
Requirements
Page 5
Software lifecycle changes
Clear distinction between development and execution
time
Every change in the world requires the execution be
interrupted and a new software be developed and
deployed
Design
Verification
Deployment Execution
Page 6
What are the changes we need to care of?
World
Goals/ Requirements
Functional
Non-functional
Domain properties (context)
User
Location e.g., moving from
open air to the meeting room
Preferences e.g., today I do not feel I can
take phone calls
Business
New SLA
New regulation
System
Changes in used resources
e.g., the service I’m using is not
working
e.g., I’ve run out of computational
resources SLA has been
broken
Page 7
How can software systems tackle these changes?
Adapt
Monitor
Reason and
make decision
Page 8
IBM Model for autonomic computing
Sensors Effectors
Managed resource
Managed resource touchpoint
Monitor Execute
Analyze Plan
Autonomic Manager
Knowledge
Page 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
Page 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
Page 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
Page 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)…
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 20
Main Ingredients of an Adaptable SBA
Page 21
Life-cycle for SBAs
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 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
Page 32
A Context-driven Adaptation Process
Identify
adaptation
requirements
Identify
adaptation
strategy
Enact
adaptation
Early Requirement
Engineering
Requirement
Engineering
and Design
Construction
Deployment
and provisioning
Operation,
management and
quality assurance
Context Modeling
Identify relevant
context dimensions
Context-driven service identification
and selection
Develop Contextual Monitors and
Adaptation Mechanisms
Design context-driven reasoners
Page 33
E-government Scenario
Page 34
Design Context Dimensions
Decide which context dimensions are relevant for the
application
Early
Requirement
Engineering
Requirement
Engineering
and Design
Design
Context
Dimensions
Application Time Ambient User Service Computing Business
Health-care X X X X X X
Administrative X X X X X X
Census & Reg X X X X X
Information X X X X X X
Auxiliary X X X X
Page 35
Context modeling
Instantiate the domain for context dimensions
SBA context
Ambient
User
Business
Time
Service
Space
Computing
Zip codes
Citizen,
Authority…
Normal,
Emergency
Morning,
afternoon,
evening
Used Services
Pda, PC, Phone
Requirement
Engineering
and Design
Context Modeling
Page 36
Design of context-driven adaptation reasoner
Changes in dimensions can trigger the corresponding
strategies
Requirement
Engineering
and Design
Design of
context-driven
adaptation reasoner
Application Time Ambient User Service Computing Business
Service
substitution
X X X X X X
Re-execution X X X
Re-composition X X X
Fail (Abort) X X X X
Concretization X X X X X X
Re-negotiation X X X
Compensation X X
Evolution X X X X X
Page 37
Requirement Engineering Outcome
Identify
adaptation
requirements
Identify
adaptation
strategy
Early Requirement
Engineering
Requirement
Engineering
and Design
Construction
Monitored
Events
Adaptation
Requirements
Adaptation
strategies
Context Modeling
Design
context-driven
Reasoners
Design
Context Dimensions
Context
Properties
Page 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
Page 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
Page 40
Open issues and challenges
How to test self-adaptable software
Support to unforeseen changes
Preventive adaptation
Dependable self-adaptable software
Page 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.
Page 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).