Towards a Pattern Language for Self-Adaptation of Cloud- Based Architectures

Aakash Ahmad1, Muhammad Ali Babar

2, 1

1IT University of Copenhagen, Denmark

2University of Adelaide, Australia

1 aahm@itu.dk,

2 ali.babar@adelaide.edu.au

ABSTRACT

Cloud computing enables organisations to deploy their software systems

over a pool of available services – exploiting pay-per-use models –

rather than upfront purchase of an overprovisioned infrastructure. In an

architectural context for cloud systems that demand elasticity in terms

of service availability, reliability, and efficiency, there is a need to

capitalise on the ‘build-once, use-often’ solutions that support reuse-

driven self-adaptations of cloud-based architectures. We support the

composition and application of a pattern language that exploits

adaptation patterns and their relations to support ‘adaptation-off-the-

shelf’ for cloud-based software architectures. We unify the concepts of

software repository mining and software evolution to support the

composition and application of an adaptation pattern language. First, we

exploit the software repository mining concepts by investigating

adaptation logs to empirically discover architecture adaptation patterns

and their relations. Second, we utilise the software evolution techniques

for self-adaptation of cloud architectures guided by a systematic

selection and application of adaptation patterns. In the context of the

IBM’S MAPE-K model for self-adaptation, we propose reusable

policies for self-adaptive cloud architectures. Architectural adaptation

knowledge in the proposed pattern language is expressed as a

formalised collection of interconnected-patterns. Individual patterns in

the language build on each other to provide a generic and reusable

solution to address the recurring adaptation problems. In future, we

focus on an incremental evolution of pattern language by discovering

new patterns from adaptation logs over time.

Categories and Subject Descriptors

D.2.11 [Software Engineering]: Software Evolution

General Terms

Design, Software Architecture, Patterns, Maintenance & Evolution

Keywords

Cloud Computing, Self-adaptive System, Adaptation Pattern Language.

1. INTRODUCTION

The research and practices on cloud computing have recently gained a

significant momentum – proposing theory and innovative solutions to

design, develop and deploy software systems as cloud-based services

[1]. From an economic perspective, cloud computing offers

organizations with a new engagement model to acquire Information and

Communication Technologies (ICT) infrastructures as services for

supporting their business operations. Instead of an upfront purchase of

an infrastructure, the pay-per-use model offered by cloud services is

considered more cost effective and flexible [2]. Despite the offered

benefits, cloud-based software is expected to survive in an Open World

[3, 18] which requires frequent adaptations in its structure and behavior

under continuously varying requirements. Architecture-based self-

adaptation [4, 5] is considered an effective solution in which software

reconfigures its high-level structure and behavior – evolving

components and their connectors – while maintaining system execution.

Research Domain: Cloud-based architectures utilize the software as a

service (SaaS) model to develop systems that are elastic to frequent

variations in their operational environments. In contrast to the more

traditional (object-oriented and component-based) architectures [6],

cloud architectures are characterized by a set of (service) elasticity

requirements. According to Herbst and colleagues [7], elasticity in

cloud systems is defined as “the degree to which a system is able to

adapt to workload changes by provisioning and deprovisioning

resources in an autonomic manner, such that at each point in time the

available resources match the current demand as closely as possible”.

To meet the demands for an autonomic resource provisioning and de-

provisioning, elasticity is characterized by:

(1) Scalability a system’s ability to robustly control the workload fluctuations corresponding to acquiring and releasing resources.

(2) Cost-Time efficiency a system acquiring required resources and releasing unutilised resources in a time and cost efficient manner.

In order to continuously satisfy the elasticity requirements [1, 7], a

cloud architecture must frequently adapt itself. In self-adaptive clouds,

an adaptation policy (e.g., elastic policy [7]) governs the evolution of

architectural structure and behavior (dynamic addition or removal of

services) so a cloud systems could self-adapt. The existing frameworks

and processes [2, 5, 8] enable customisation and implementation of

once-off and adhoc adaptation policies to address the quality

requirements of adaptive architectures [18]. In this paper, we propose an

approach that focus on empirical (i) discovery and (ii) specification of

adaptation patterns to address frequent architectural adaptations.

Research Challenge(s): Lehman’s law of continuing change [9]

demands for long-living and continuously evolving architectures to

prolong the productive life, economic value and operational reliability

of deployed systems. To support continuing change in an automated

way, the IBM autonomic framework [8] – Monitor-Analyse-Plan-

Execute (MAPE) loop – embodies the topology, policy and problem

determination knowledge to derive configuration plans to execute

software adaptations. However, the IBM MAPE loop lacks support for

reusable adaptation policies that can be extended or reused to address

the frequent adaptation problems. We propose to augment the

conventional MAPE loop with reuse knowledge – exploiting

architecture adaptation patterns – for supporting adaptation off-the-shelf

corresponding to the elasticity requirements of cloud architectures. To

support reusable adaptations the primary challenges include (i) a

continuous empirical discovery and (ii) systematic application of architecture adaptation patterns. We identified research challenge as:

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy

otherwise, or republish, to post on servers or to redistribute to lists,

requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org.

WICSA '14, April 07 - 11 2014, Sydney, NSW, Australia.

Copyright 2010 ACM 1-58113-000-0/00/0010 …$15.00.

http://dx.doi.org/10.1145/2578128.2578232

How to continuously discover and utilise adaptation knowledge that

executes reusable adaptation policies to tackle the frequently varying (elasticity) requirements in cloud architectures?

Solution Overview: In the proposed solution, reusable adaptation

knowledge is expressed as a formalized collection of interconnected

adaptation patterns that are empirically discovered. An ‘adaptation

pattern’ is defined as a generic, first class abstraction to support

potentially reusable architectural adaptation plans. We unify the

concepts of software repository mining and software evolution to

support the composition and application of an adaptation pattern

language. First as a design-time activity, we exploit the software

repository mining concepts to investigate the adaptation logs [12] to

empirically discover architecture adaptation patterns and their relations.

An adaptation log represents a collection of adaptive changes that are

captured in the log by analyzing architectural evolution over time. We

further discuss the composition of an adaptation pattern language in

terms of language vocabulary, grammar, and sequencing (also pattern

relations) in Section 4. Second as a runtime activity, we utilize the

software evolution techniques for self-adaptation of cloud architectures

guided by a collection of adaptation patterns. We further discuss the

application of pattern language with a systematic selection and

application of patterns (also pattern-based adaptation policies) in

Section 5. In software engineering research, the concept of pattern

language is borrowed from the theory of natural languages and the

architecting experience of Christopher Alexander [15]. The contribution

of this research lies with:

- Adaptation patterns as an empirically discovered knowledge that can

be reused to enhance efficiency of the architecture adaptation process.

- A continuous acquisition of architecture adaptation knowledge, i.e.,

discovering adaptation patterns and integrating them in a pattern

language to support reuse-driven self-adaptation of cloud architectures.

The rest of this paper is organized as follows. We explain the

architecture adaptation patterns in Section 2. We present the challenges

and proposed solution in Section 3. In Section 4, we discuss the

composition of the pattern language. In Section 5, we discuss language

application to self-adapt cloud architectures. Related research is

presented in Section 6. Conclusions and future research in Section 7.

2. ARCHITECTURE ADAPTATION PATTERNS

In this section, we explain the pattern meta-model (Section 2.1), that

provides a foundation for pattern discovery and pattern application

discussed in subsequent sections. We discuss the role of adaptation logs

as a source of adaptation pattern discovery (Section 2.2). We exemplify

adaptation pattern and also distinguish between a pattern, pattern

instance and pattern variants (Section 2.3).

2.1 A Meta-model of Adaptation Patterns

In Figure 1, the meta-model for pattern-based architecture adaptation

provides the structural composition of a pattern and the relationships

between pattern elements. For example, the relation among the elements

is expressed as: Adaptation Operators ← Adaptation Pattern,

an adaptation pattern is composed of adaptation operators. The pattern

meta-model allows a formal specification of the pattern language

vocabulary and grammar (in Section 3).

1. Specifying Architecture Model (ARCH) during the evolution

process, the first step is to specify the architecture model that is

subject to dynamic adaptation under frequently varying requirements.

The architecture model refers to the architectural elements to which a

pattern can be applied during architectural adaptation. We represent

the architecture model as a topological configurations (CFG) based

on a set of service components (CMP) as the computational entities,

linked through connectors (CON) [3]. Furthermore, service

components are composed of component interfaces (INF), while

connectors are composed of endpoints (EPT) to bind component

interfaces. The architectural description is based on the service

component architecture (SCA) specifications1 that models

architectural components that expose one or more services in a

service-driven architecture (SaaS model). To enable service elasticity

the SaaS must support a continuous composition and decomposition

of components to satisfy operational reliability of architectures.

Figure 1. A Meta-model for Adaptation Pattern Composition

2. Specifying Adaptation Operators (OPR) the adaptation

operators represent the architectural changes that are fundamental to

operationalizing architectural evolution and adaptation. We specify a

set of atomic and composite operations enabling the architectural

adaptation by adding (ADD), removing (REM), and modifying

(MOD) elements in the architecture model. Adaptation operators

enable the execution of an adaptation plan on architecture model [4,

5]. The architectural composition is preserved with:

– Atomic Change Operations: these enable fundamental changes in

terms of adding, removing, or modifying the service component

interfaces (INF) and connector endpoints (EPT). For example,

addition of a new interface I in an existing component C is expressed

as follows ( represents type of element): Add (I INF, C CMP).

– Composite Change Operations: these are sequential collections of

atomic change operations, combined to enable composite

architectural changes. These enable adding, removing, or modifying

architectural configurations (CFG) with service components (CMP)

containing interfaces, connectors (CON) containing endpoints (for

component interface binding). The addition of a new component C

with an interface I in a configuration G is specified as follows, where

represents operational sequence.

Add (C CMP, G CFG) Add (I INF, C CMP)

We propose that the adaptation operators are primitive changes [5, 8]

that are composed to enable pattern-based changes [10, 11] to enhance

reusability of architectural adaptations. Patterns abstract the addition,

removal, and modification of components and connectors to enable the

composition, decomposition, and replacement of architecture elements.

3. Specifying Constraints on Adaptation Operations (CNS) the

constraints refer to a set of pattern-specific conditions in terms of pre-

conditions (PRE - the conditions before application of a pattern) and

post-conditions (POST – the conditions after application of a pattern) to

ensure the consistency of pattern-based adaptations. In addition, the

invariants (INV – the conditions satisfied during application of a

pattern) ensure structural integrity of individual architecture elements

during the execution of adaptation patterns. During addition of a

component C, the preconditions ensure that a component C does not

1 Service Component Architecture (SCA) http://oasis-opencsa.org/sca

exist in a configuration G, and the post-conditions ensure that a

component C with interface I has been added in a configuration G.

4. Specifying the Adaptation Patterns (PAT) an adaptation pattern

defines a first-class abstraction that can be operationalized and

parameterized to support potentially reusable architectural change

execution (adaptation policies) expressed as, PAT<name, intent>:

PRE[OPR(arch ARCH)] → POST[arch′ ARCH]

A pattern has a name and an intent that represents a recurring,

constrained (CNS) composition of change operationalization (OPR) on

architecture elements (aem ARCH) - in Figure 1.

5. A Collection of Architecture Adaptation Patterns (COL) it

provides repository infrastructure that facilitates an automated storage

(in: once-off specification) and retrieval (out: multiple instantiation) of

discovered adaptation patterns. The collection also supports a logical

grouping of related patterns based on types of architectural adaptation

(composition, decomposition, replacement of component etc.).

2.2 Adaptation Log as a Source of Pattern Discovery We focus on a continuous empirical discovery of adaptation patterns by

investigating architecture adaptation logs [12] that provide a history of

adaptive changes. An Architecture Adaptation Log (AAL) refers to a

recorded collection of adaptive change instances (CI) that is expressed

as: AAL =<CI1, CI2,…,CIN>, where CI1 to CIN represent a sequential

collection of adaptive change instances.

Data in Adaptation Logs: currently, the adaptation log contains a

sequential collection of change instances for (i) a dynamic adaptive

instant messenger (IM) and (ii) an auction management system (AMS)

case studies providing a change repository to continuously discover

recurring changes. We propose to formalize change instances in AAL as

an attributed graph (AG) [16] as tuple GAAL = <N, E, A[N, E]>, N : Node

represents an individual change instance; E : Edge maintains change

sequencing among a node collection while A[N, E]: Attributes on nodes

and edges express the intent, scope and impact for change instances

explicitly. This allows us to exploit sub-graph mining – a formalized

knowledge discovery technique to identify the frequent sequences (i.e.,

recurring sub-graphs in GAAL) as potential adaptation patterns.

2.3 Pattern, Pattern Instance and Pattern Variant After presenting the pattern meta-model and pattern discovery source,

we exemplify the adaptation patterns and also provide a distinction

between a pattern, pattern instance and its variant in Figure 2.

Figure 2. Adaptation Pattern, Pattern Instance and Pattern Variant

A. Adaptation Pattern represents a generic and repeatable solution to

recurring architectural adaptation problems. In contrast to primitive

changes on architecture model (cf. Section 2.1 Adaptation Operators),

an adaptation pattern promotes a solutions that can be (a) identified as

recurrent, can be (b) specified once and (c) instantiated multiple times

to support reuse of adaptation plans [5, 8]. Let us consider two

adaptation scenarios in Figure 2 from an adaptive Auction Management

System (AMS) case study. We abstract the details about the Service

Level Agreements (SLAs) and Quality of Service (QoS) [18] aspects

during architectural adaptations in Scenarios I and II. An example with

SLAs and QoS requirements for adaptation is presented in Section 5.

Adaptation Scenario I – In the AMS architectural configuration two

nodes (Provider: P and Bidder: B) are connected in a peer-to-peer

connection for online bidding process. However, as the number of

bidder B increases over time (B1, B2,…,Bn) the AMS architecture must

self-adapt by integrating a bidding server S that mediates the bidding

process between the providers and bidders.

Adaptation Scenario II – Once a bidder has successfully quoted for an

item he/she must pay for that item to complete the transaction. The

current architectural configuration only accepts a bank transfer mode of

payment. In the reconfigured architecture, there is a need to integrate

the Payment Type component so a bidder could select among

DebitPayment or CreditPayment methods.

Adaptation Pattern – Service Mediation

In both the scenarios above, the recurring adaptation problem is the

introduction of a new service that mediates between two or more

directly connected services. We propose the Service Mediation pattern

presented in a pattern template (Table 1) as a repeatable solution to

address the scenarios above. We discovered Service Mediation pattern

with a manual analysis of changes in an adaptation log. In future we aim

to (semi-) automate the pattern discovery process (as in Section 4).

B. Pattern Instance represents a concrete representation of the pattern.

As presented in Figure 2, the instance of Service Mediation pattern

represents the interposition of a mediator service component BidServer: S among the directly connected BidClient: B and BidProvider: P.

C. Pattern Variant represents a possible variation of the

implementation of the adaptation pattern. In Figure 2, the pattern variant

represents the variation of the Service Mediation pattern. It integrates

two mediator components CreditPayment: T and DebitPayment: D.

Pattern Name and Intent Service Mediation ([SM] <S1, SM, S2>)

Intent – To interpose a mediator service component (SM) among two or more directly connected components (S1, S2)

Pattern Constraints, Operators and Impact

Constraints – conditions before, during and after the change.

– Preconditions S1 and S2 must be directly connected.

– Invariants S1 and S2 must be disconnected.

– Post-conditions S1 and S2 must connected with SM.

Change Operators – to apply architecture restructuring.

– Add a Component SM

– Remove a Connector X1 (S1, S2) (more connectors may exist, see variant)

– Add a Connector X2 (S1, SM)

– Add a Connector X3 (SM, S2)

Impact on Architecture Models – the affected architecture model.

Table 1. A Template-based Specification of Service Mediation Pattern

3. CHALLENGES AND PROPOSED SOLUTION

Considering the architectural challenges [4, 5] for self-adaptive

software and elasticity requirements for cloud-based systems [7, 18],

the existing solutions support reusable infrastructure [5], adaptation

strategies [10] and adaptation knowledge [8] for architecture evolution.

Figure 3. Layered Overview of Solution a) Pattern Language Composition and b) Pattern Language Application

In contrast to these existing solution, we propose the adaptation patterns

approach to address the recurring architectural changes [14] under

evolving requirements. We outline the research challenges and provide

solution overview that addresses these challenges by enabling the

composition and application of an adaptation pattern language

illustrated in Figure 3.

Challenge 1 – Discovering Reusable Adaptation Knowledge:

Addressing frequent dynamic adaptations, a critical challenge is to

acquire an explicit adaptation knowledge that enables an anticipative

change management while maintaining a system’s execution (reliability,

correctness, minimal disruptions etc.) [4]. The questions then arises,

what exactly is reusable adaptation knowledge? and how to derive and

express it?

Pattern Language Composition: In the proposed solution illustrated in

Figure ,3 we utilise the software repository mining techniques to

empirically discover an explicit reusable knowledge as the adaptation

pattern language that represents a formalised collection of adaptation

patterns (cf. Section 2). In contrast to the pattern invention in the

SASSY framework [11], we investigate architecture adaptation logs

[12] to empirically discover a classified composition of change patterns

and possible variants (i.e; vocabulary) as in Section 2.2. The pattern

model governs the structural composition and semantic relationships

among pattern elements (i.e., grammar) as in Section 2.1. The last step

involves creating pattern relations to operationalise adaptation

sequencing expressed as a pattern language – fostering pattern

sequences to formalise a generic problem-solution view.

Challenge 2 – Enabling Reuse-Driven Adaptation Plans: In self-

adaptive software, an adaptation plan refers to a systematic mapping

between the problem-solution views and to the derivation of

implementation mechanism(s) to address evolution in an autonomic

way [3, 5, 8]. As opposed to an ad-hoc, one-off step, the challenge is to

apply reusable adaptation plans to address recurring evolution [10]. We

propose to augment the conventional MAPE loop [8] with an explicit

knowledge about architectural adaptation that support adaptation off-

the-shelf corresponding to the elasticity requirements of cloud

architectures [1, 2].

Pattern Language Application: In Figure 3, we utilise the software

evolution techniques as a runtime activity to analyse and execute

recurring adaptation scenarios (cf. section 2.2). In a running

architecture, we continuously analyse the evolving adaptation goals in

terms of changing requirements (adaptation properties) and domain

assumptions for adaptation scenarios. This enables selection of the

appropriate pattern sequences to derive the adaptation plan based on

adaptation scenarios. The pattern language provides a method of

systematic reuse based on pattern collection that comprises the

knowledge-base for future reuse. The proposed pattern language

evolves by incorporating newly discovered patterns from adaptation

logs over time as in Figure 3.

4. PATTERN LANGUAGE COMPOSITION The adaptive changes are captured in an adaptation log [12] (cf.

Section 2.2) by analyzing architectural changes at runtime. In contrast,

the composition of pattern language (cf. Figure 3) is a design-time

activity that aims at an empirical analysis of adaptation logs (cf. Section

2) to discover adaptation patterns and their relations. We model the data

from adaptation logs as a graph and exploit the sub-graph mining

techniques to discover recurring changes as adaptation patterns. In

software engineering research, the concept of pattern language is

borrowed from theory of natural languages and the architecting

experience (buildings) by Christopher Alexander [15]. As illustrated in

Figure 3, the adaptation pattern language (APL) is composed of

language vocabulary, language grammar and language sequencing

expressed as:

[

{ }

{ } ]

The language is composed of (i) discovered patterns and their variants

(1. vocabulary: ) along with a (ii) set of rules to govern the

structure of relations among pattern elements (2. grammar: ) to

create a (iii) sequence-of-patterns (3. sequencing: ) in Figure 3.

4.1 Mining Patterns for Language Vocabulary

The language vocabulary (VAPL) is represented with the discovered

adaptation pattern (PAT) instances and their possible variants (VAR)

expressed as (1), where represents a composition operator. To derive

vocabulary, we rely on a continuous empirical discovery of adaptation

patterns by investigating architecture adaptation logs [12] as a history of

sequential changes. In Section 2, we have explained the concept of

adaptation patterns along with pattern instances and pattern variants that

represent pattern language vocabulary as illustrated in Figure 3. We

modeled the adaptive changes from logs as a graph with graph nodes

representing a change instance and graph edge representing a relation

between two consecutive change instances. Modeling the log data as a

graph allows us to exploit the sub-graph mining techniques to discover

recurring sub-graphs as frequent adaptation patterns.

4.2 Formalising Pattern Language Grammar

The language grammar (GAPL) is represented as structural composition

and semantic relationships among elements in a pattern model (cf.

Section 2). We exploit attributed graphs [16] with typed instances

formalizing the language grammar as in Listing 1. Graph-based

modeling for language grammar is beneficial for visualizing pattern

composition and relations to abstract a complex pattern hierarchy to

facilitate analyzing pattern structure to evaluate possible consequences

and alternatives. In addition, it enables establishing a (graph) network of

patterns to define semantic relationships among patterns that can be

selected and applied in an incremental fashion (Line 02 - 14).

Listing 1. Pattern Language Grammar with Graph Modeling Language

Nodes – Pattern Composition in Listing 1 is expressed as CLS that

represents a classification of patterns (categorizing addition, removal,

modification etc. types of change impact). OPR represents

operationalizing changes. CNS represents a set of constraints as pre-

and post-conditions to be preserved during pattern-based change.

ARCH represents the architecture model to which a pattern is applied.

VAR represents the possible variation of a pattern instance. An

Adaptation Pattern PAT is expressed as a constrained composition of change operators on an architecture model (Line 03 - 07).

Edges – Semantic Relations enable compositional semantics with a

possible relation among a pattern and operators defined as: OPR ← PAT, pattern is a composition of operations (Line 09 - 13).

4.3 Pattern Language Sequences

The sequence-of-patterns represents a collection of interconnected

patterns in the language (3), where is a language sequencing

operation. The pattern selection problem in pattern language is

addressed with a (semi-) formal mapping between the problem-solution

views by employing the Question-Option-Criteria (QOC) methodology

[17]. The mapping of QOC criteria with pattern selection is provided in

Table 2. We further explain the QOC method for pattern selection in

Section 5. QOC Method Pattern Selection Process Description

Question Adaptation Scenario Questions refer to an adaptation scenario

Option Adaptation Pattern(s) Options provide the available patterns, while selection depends

Criteria Pattern Impact Criteria evaluates the impacts and consequences of a pattern on architecture.

Table 2. Overview of the Mapping for QOC and Pattern Selection

5. PATTERN LANGUAGE APPLICATION

After language composition, we now discuss the applicability of the

proposed pattern language as a three step process for self-adaptation of

the running architecture of an auction management system (AMS).

AMS represents a distributed (Client: Bidders, Server: Auction Providers) architecture that provides loosely coupled configurations

among service components (bidders, auction provider) and their

interconnections (bidding requests). The adaptation process comprises

of (i) a continuous analysis of adaptation scenarios in running

architecture, (ii) deriving a pattern-driven reusable adaptation plan

(selecting adaptation patterns) for (iii) dynamic adaptation in the

running architecture [5, 8] as in Figure 3. Self-adaptation is exploited to

enforce service level agreements (SLAs), such as those on performance,

availability and confidentiality of the bidding process while maintaining

the Quality of Service (QoS, i.e. adaptation goals) that change

frequently with system (re-) configurations.

5.1 Adaptation Scenario – Integration of an

Auctioning Protocol in AMS Architecture In the functional context of the AMS case study, a dynamic aspect in

this scenario requires that new Bidders (B) must register with the

AuctionProvider (A) in the running AMS, presented in Figure 4. A

performance SLA has been negotiated in terms of three throughput

service level objectives (SLOs) to guarantee three different levels of

system capacity in AMS. A normal capacity is required for a normal

load; a medium capacity is required when special auctions are placed on

AMS while a high capacity guarantees to deal with the peak load.

In step 1, Figure 4 we continuously analyse the adaptation strategy that

if the number of registered bidders (Bn) increases beyond a certain

threshold (X) such that Bn X the current architecture of AMS cannot guarantee the expected QoS and needs more capacity to deal with the

new bidders. It sends a change request to derive an adaptation plan to

integrate an Auction Protocol (P) to support load balancing among

directly connected Bidders (B1, B2) and Auction Provider (A). The

change request in expressed as an ECA formalism [5]: E (Event):

Bidder registration load; C (Condition): RT (Response Time)>= SLOi; A

(Action): ADD {Bidder, Auction Protocol: P, AuctionProvider} to mediate bidder registration.

Figure 4. Pattern-Driven Reusable Adaptation Plan

5.2 Execution of Reusable Adaptation Plan In contrast to an adhoc addition or removal of individual components

and connectors in AMS, evolution reuse knowledge (expressed as

patterns) allows us to exploit the integration and replacement patterns

successively applied for integration of an auction protocol. Pattern

selection and sequencing from pattern language is guided by QOC

methodology to evaluate consequences, forces and possible pattern

alternatives [10] (cf. Table 2). It allows a declarative composition of

individual changes (Integrate, Replace) that can be operationalized and

parameterized while preserving a set of architectural constraints [CNS],

expressed as follows.

Event: Add<Component : P>

Condition: if RT SLOi

Action(s): Integrate(AuctionProtocol : P, [CNS]) follows

Replace(BidderRequests : b1, [CNS])

- Dependent Patterns – enables change sequencing expressed as PATm → PATn, e.g: PATm{Integrate(P, <B1, A, B2)

→

PATn{Replace(P, b1, b3)} to add an auction protocol (P) with an

appropriate processing capacity.

01: <graphml>

02: <graph id = “PAT_N” edgedefault = “directed”>

03: <node id = “CLS”> …</node>

04: <node id = “PAT”> …</node>

05: <node id = “OPR”> …</node>

06: <node id = “CNS”> …</node>

07: <node id = “ARCH”>… </node>

08: <node id = “VAR”> …</node>

09: <edge id = “Classifies” source=”CLS” target=”PAT”/>

10: <edge id = “ComposedOf” source=”PAT” target=”OPR”/>

11: <edge id = “ConstrainedBy” source=”PAT” target=”CNS”/>

12: <edge id = “Evolves” source=”PAT” target=”ARCH”/>

13: <edge id = “HasVariation” source=”PAT” target=”VAR”/>

14: </graph>

15: </graphml>

- Commutative Patterns – enable changes to be performed in parallel

expressed as: PATm → PATn to the current architecture. Having

prepared a pattern-driven adaptation plan, plan execution in Figure 4

(Step 3) applies reusable operationalization in terms of pattern

sequences to enable architectural adaptation. In the context of MAPE

loop [7], system-level monitoring is outside the scope of this research.

6. RELATED RESEARCH

Our systematic comparison [14] between (i) adaptive evolution and (ii)

runtime change – comparing the Means, Time and Stage of evolution –

reflects on an increasing demand for generic, reusable plans for

adaptive (service) architectures [5, 6, 18]. We review the state-of-

research in terms of the reference models [8] and frameworks [11] that

support architectural adaptations to justify the proposed contributions.

6.1 Needs for Reuse in Architecture-based Self-Adaptation

An interesting observation at the intersection of adaptive evolution and

self-adaptation reflects on future implications [14] to leverage existing

processes [4] and (empirically discovered) knowledge to guide and execute adaptation strategies [5, 11] in an un-anticipated evolution.

The conventional MAPE loop [8] offers an embedded (topology, policy

and problem determination) knowledge to monitor and execute dynamic

adaptive evolution. We specifically argue about the needs to discover

and apply reusable adaptations patterns to create adaptation plans. The

proposed language, as an empirically derived sequence-of-patterns

formalizes the problem-solution view to address frequent adaptation

problems as an incremental refinement process.

6.2 Frameworks for Reuse-Driven Adaptation

The SASSY (Self-Architecting Software Systems) framework [11]

utilises a model-driven approach for run-time self-architecting of

service-driven software using adaptation patterns. In contrast to

patterns invention in SASSY, we focus on a continuous and automated

empirical discovery of patterns with a formalised collection of

interconnected patterns to support an incremental change execution.

Although, the support for reusable infrastructure and adaptation

aspects is provided in [7, 4], these solutions lacks an empirical

acquisition of evolution knowledge in guiding architecture-based self-

adaptations. We believe that, there is a need to extend the concept of

‘Evolution Shelf’ [11] beyond specification-time evolution to rely on

off-the-shelf adaptation expertise to tackle a continuous change [14].

An interesting dimension of research for self-adaptive cloud-service

architectures is the optimisation of cloud-services based on the quality

of service requirements that evolve over time [18]. In contrast to self-

optimising cloud architectures (based on QoS) requirements; our

contribution is about a continuous discovery and utilisation of

adaptation knowledge guided by reusable adaptation patterns.

7. CONCLUSIONS AND FUTURE RESEARCH In this paper, we argue about the needs for ‘built-once, use-often’

adaptation plans to systematically tackle recurring evolution in self-

adaptive (service) architectures. We claim that by investigating the

history of adaptive evolution (exploiting adaptation logs), we can

discover adaptation patterns as a generic, repeatable solution to derive

reusable adaptation plans. We discussed the role of an adaptation

pattern language as an explicit knowledge-base to support reuse-driven self-adaptation of running architectures. The contributions are:

– Enabling ‘post-mortem’ analysis of architecture adaptation histories to

discover operationalisation and patterns that can be shared and reused to

guide architecture change management.

– Language as a formalised system-of-pattern allows problem-solution

mapping to reuse generic, reusable operationalisation. The role of the

pattern language is central in promoting patterns to achieve reuse and consistency in evolution and adaptation of service architectures.

Future Research: A performant solution requires a rigorous validation;

we are specifically interested in evaluating the expressiveness – an

extensive vocabulary of possible patterns and their variants – as a

formalised grammar of pattern language. In addition, the adequacy of

the proposed pattern language determines the effectiveness in terms of

deriving reuse-driven adaptation. A prototype (Pat-Adapt) is envisaged

to automate the (i) pattern discovery and (ii) pattern application

processes. Tool support and data shall form the basis to evaluate the

extent to which the solution enables a reuse-driven dynamic adaptation.

REFERENCES

[1] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A.

Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica and M. Zaharia,

"A view of cloud computing," Communications of the ACM, vol. 53, no.

4, pp. 50-58, 2010.

[2] R. Buyya, C.S. Yeo, S. Venugopal, J. Broberg, and I. Brandic,

“Cloud Computing and Emerging IT Platforms: Vision, Hype, and

Reality for Delivering Computing as the Fifth Utility,” Future

Generation Computer Systems, vol. 25, no. 6, pp. 599-616, 2009.

[3] L. Baresi, E. Di Nitto, C. Ghezzi. Toward Open-World Software:

Issue and Challenges. IEEE Computer Society. 39(10), 36–43, 2006.

[4] J. Kramer and J. Magee. Self-Managed Systems: an Architectural

Challenge. In Future of Software Engineering, IEEE, 2007.

[5] D. Garlan, B. Schmerl, S. Cheng. Software Architecture-based Self-

adaptation. In Autonomic Computing and Networking, 2009.

[6] Nenad Medvidovic and Richard N. Taylor. A Classification and

Comparison Framework for Software Architecture Description

Languages. IEEE Transactions on Software Engineering, vol. 26, no. 1,

pages 70–93, 2000.

[7] N. R. Herbst, S. Kounev and R. Reussner, "Elasticity in Cloud

Computing: What It Is, and What It Is Not," in International

Conference on Autonomic Computing, 2013.

[8] Autonomic Computing. "An architectural blueprint for autonomic

computing." IBM White Paper (2006).

[9] M. M. Lehman. Laws of Software Evolution Revisited. In Software

Process Technology, pages 108–124. Springer, 1996.

[10] E. Truyen, W. Joosen. "Towards an Aspect-oriented Architecture

for Self-adaptive Frameworks." Proceedings of the 2008 AOSD

Workshop on Aspects, Components, and Patterns, 2008.

[11] A. Menasce, H. Gomaa, S. Malek, J. Sousa. SASSY: A Framework

for Self-Architecting Service-Oriented Systems. In IEEE Software,

28(6):78-85, 2011.

[12] A. Ahmad, P. Jamshidi, Claus Pahl. Graph-based Implicit

Knowledge Discovery form Architecture Change Logs. In 7th

International Workshop on Sharing and Reusing Architectural

Knowledge, 2012.

[13] P. Jamshidi, A. Ahmad, C.Pahl. Cloud Migration Research: A

Systematic Review. In IEEE Transactions on Cloud Computing, vol 1,

no. 1, 2013.

[14] P. Jamshidi, M. Ghafari, A. Aakash and C. Pahl. A Framework for

Classifying and Comparing Architecture-centric Software Evolution

Research. In 17th European Conference on Software Maintenance and

Reengineering, IEEE Computer Society, 2013.

[15] C. Alexander. The Origins of Pattern Pheory: The Future of the

Theory, and the Generation of a Living World. In IEEE Software, vol.

16, no. 5, pages 71–82, 1999.

[16] H. Ehrig, U. Prange, G. Taentzer. Fundamental Theory for Typed

Attributed Graph Transformation. In Graph Transformations, 2004.

[17] A. MacLean, R. Young, V. Bellotti, T. Moran: “Questions,

Options, and Criteria: Elements of a Design Rationale for user

interfaces, Human Computer Interaction, vol 6 (3&4), 1991.

[18] V. Nallur and R. Bahsoon. A Decentralized Self-Adaptation

Mechanism for Service-Based Applications in the Cloud. In IEEE

Transactions on Software Engineering, vol 39, no 5, 2013.