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)

Learning Package Categorization

S-Cube

Engineering Principles, Techniques & Methodologies

Designing and migrating Service-Based Applications

Techniques for design for adaptation

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

The machine and the world

Goals

Requirements

Domain

properties

(assumptions)

Specification Goals

Requirements

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

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

How can software systems tackle these changes?

Adapt

Monitor

Reason and

make decision

IBM Model for autonomic computing

Sensors Effectors

Managed resource

Managed resource touchpoint

Monitor Execute

Analyze Plan

Autonomic Manager

Knowledge

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

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

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

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)…

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

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

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

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

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

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

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

Main Ingredients of an Adaptable SBA

Life-cycle for SBAs

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

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

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

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

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

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

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

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

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

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

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

E-government Scenario

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

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

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

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

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

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

Open issues and challenges

How to test self-adaptable software

Support to unforeseen changes

Preventive adaptation

Dependable self-adaptable software

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.

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).