scispace - formally typeset
Search or ask a question
Proceedings Article•DOI•

Building self-adapting services using service-specific knowledge

An-Cheng Huang1, Peter Steenkiste2•
Carnegie Mellon University1, University of Florida2
24 Jul 2005-pp 34-43
TL;DR: This paper proposes a self-adaptation architecture that allows service developers to specify their service-specific adaptation knowledge as "externalized" adaptation strategies used by a general, shared adaptation framework to perform run-time adaptation operations that automatically incorporate service- specific knowledge.
Abstract: With the advances in middleware and Web services technologies, network sendees are evolving from simple client-sender applications to self-configuring services that can compose primitive components distributed in the Internet into a value-added service configuration that provides rich functionalities to users. A resulting research problem is how to continuously adapt such composite service configurations at run time in order to cope with the increasingly dynamic and heterogeneous network environments and computing platforms. In this paper, we propose a self-adaptation architecture that allows service developers to specify their service-specific adaptation knowledge as "externalized" adaptation strategies. These adaptation strategies are used by a general, shared adaptation framework to perform run-time adaptation operations that automatically incorporate service-specific knowledge. In addition to the strategies, we also identify another aspect of adaptation knowledge that is not addressed by previous solutions: adaptation coordination. Our framework provides integrated support for the specification and execution of both aspects of developers' adaptation knowledge.

Summary (4 min read)

Jump to: [1. Introduction] – [2. Problem statement] – [3. Overview of adaptation architecture] – [4. Adaptation strategies] – [4.1. Strategy format] – [4.2. Strategy specification] – [4.3. Example] – [5. Adaptation coordination] – [5.1. Conflict detection] – [5.2. Conflict resolution] – [5.3. Identifying incompatibility] – [6. Implementation and evaluation] – [7. Related work] and [8. Conclusions]

1. Introduction

  • Network applications such as Web browsing, video conferencing, instant messaging, file sharing, and online gaming are becoming a necessity for more and more people.
  • From a user’s perspective, these network applications are used to accesservicesoffered by service developersover the Internet.
  • Multiple strategies may be invoked at the same time, and they may want to make conflicting changes to the configuration.
  • Such adaptation coordination issues are a challenging problem that is not addressed by previous solutions.
  • The authors present a self-adaptation architecture that allows service developers to easily add run-time adaptation capability to their services.

2. Problem statement

  • One possibility is that the developer constructs the configuration manually.
  • Given the initial service configuration, the authors have identified two aspects of a developer’s service-specific knowledge that can be used to guide the adaptation of the configuration at run time: adaptation strategies and coordination policies.
  • Two use MBone conferencing applications vic/SDR (VIC), two use NetMeeting (NM), and one uses a receiveonly handheld device (HH).
  • To handle run-time problems such as high load and congestion at the VGW, the developer may have the following two strategies: S1: (VGW overloaded)→ (replace VGW with a highcapacity VGW) S2: (VGW congestion)→ (replace VGW with a highbandwidth VGW).
  • The authors limit their scope tol cal adaptation, i.e., they focus on how to support adaptation strategies involving only “local” actions and how to coordinate such strategies.

3. Overview of adaptation architecture

  • In their architecture , a developer uses their knowledge representation to express its service-specific adaptation knowledge, includingadaptation strategiesand coordination policies.
  • This knowledge, along with the initial configuration of the service, are given to the selfadaptation framework, which consists of andaptation manager(AM), an adaptation coordinator(AC), and the supporting infrastructure.
  • The authors assume the necessary infrastructures exist, and they focus on how the developers’ knowledge can be represented and on how the AM and the AC can make use of the adaptation and coordination knowledge to adapt the target service configuration.
  • At run time, the AM handles a developer’s adaptation strategies by monitoring the configuration to detect run-time problems.
  • If a proposal does not conflict with other proposals, the AC accepts the proposal and asks the AM to change the configuration accordingly.

4. Adaptation strategies

  • Previous studies have proposed many run-time adaptation solutions based on “internalized” adaptation strategies (i.e., the adaptation logic and mechanisms are hard-wired into the system itself), for example, [16, 19, 9, 3].
  • To support externalized strategies, one important design decision is how to specify such strategies.
  • The utility approach allows a service developer to specify a utility function indicating the “desirable” configurations, and the adaptation mechanisms automatically modify the service configuration towards higher utility.
  • Their scope of adaptation is much broader and includes component-level adaptations such as replacing/adding/removing components.
  • Therefore, the utility approach is not feasible.

4.1. Strategy format

  • The authors support for adaptation strategies is built on the externalized approach presented in Rainbow [11].
  • An adaptation strategy consists of the following three parts.
  • The properties can be performance metrics, e.g., bandwidth and latency, or component properties.
  • When a strategy is invoked, it may need to, for example, query more specific configuration properties to determine the actual triggering problem.
  • In the video conferencing example, a strategy triggered by “low HH video quality” needs to determine whether the actual problem is HHP failure, low quality codec used by the HHP, or congestion at the HHP.

4.2. Strategy specification

  • The authors self-adaptation framework is based on the selfconfiguration framework the authors built previously [13].
  • A developer can use the objective function API to construct a function of the relevant properties of components and connections in the configuration, also known as Constraint.
  • A constraint can then be constructed using RelationOp and BooleanOp with the function.
  • Since their framework is implemented in Java and exports Java interfaces and classes for specifying strategies, a strategy designed by a developer is basically a small Java class, also known as Problem determination.
  • Similar to their previous self-configuration framework, when a tactic requires a new component, it specifies an objective function as the component selection criterion usingsetTacticObjective .

4.3. Example

  • The authors use the video conferencing service as an example to illustrate how a developer’s adaptation strategies can be specified using the above APIs.
  • Suppose the developer implements the tactics shown in Table 2.
  • As seen in Table 3, the constraints for these strategies are as follows: C1: (config.numUnconnectedUsers == 0) C2: (NM.videoQuality >= Tn) C3: (VIC.videoQuality >= Tv) Strategies for the video conferencing service.
  • The strategies are given to the AM, which monitors the configuration and invokes a strategy when its constraint is violated.

5. Adaptation coordination

  • The authors goal with respect to adaptation coordination is to only require a service developer to specify the servicespecific coordination knowledge without worrying about the underlying mechanisms.
  • The authors identified three important coordination issues: detecting conflicts between proposals, resolving conflicts between proposals, and identifying incompatible strategies (i.e., strategies that work at cross purposes).
  • Next, the authors discuss how they address these three issues.

5.1. Conflict detection

  • The authors categorize conflicts into two types:action-leveland problem-level.
  • The AC can automatically detect such conflicts by looking at the actions in different proposals.
  • Strategy S1 connects a new VIC user to the closest ESMP in the configuration, and S2 replaces a failed ESMP with a new one.
  • A developer must specify explicitly whether the triggering of two problems simultaneously constitutes a “problem-level conflict”.
  • The authors framework provides the following function for specifying such a conflict between tactics T1 and T2. addProblemConflict(T1, T2);.

5.2. Conflict resolution

  • Figure 3 illustrates two different approaches for resolving conflicts between proposals.
  • The authors now briefly describe the two different approaches.
  • This approach accepts or rejects proposals as they are received.
  • The FCFS approach supports more limited conflict resolution while the epoch/priority approach is more flexible.

5.3. Identifying incompatibility

  • To prevent adaptation strategies from working at cross purpose, the authors need to identify “incompatible” strategies.
  • If the authors want to automatically determine whether such cycles exist, The AC need to determine the exact effects of strategies (e.g., how much load is reduced by adding a server) and whether one strategy’s effects will trigger another.
  • Instead of solving the general problem, the authors observe that it is usually sufficient to identify strategies that have opposite goals (and thus may cause undesirable cycles) and warn the developer.
  • To automatically identify incompatible tactics, the authors let de- velopers “annotate” the tactics with causes and effects.
  • Therefore, their framework exports the following functions for cause and effect specification: addTacticCauses(List increasedMetrics, List decreasedMetrics) addTacticEffects(List increasedMetrics, List decreasedMetrics).

6. Implementation and evaluation

  • The authors have implemented a prototype of the self-adaptation framework based on their earlier self-configuration framework.
  • The authors implemented an event-driven simulator that takes such a trace and simulates the gaming service described above.
  • AddProblemConflict(join, split); addProblemConflict(join, merge); addProblemConflict(leave, split); addProblemConflict(leave, merge); addProblemConflict(cross, split); addProblemConflict(cross, merge);.
  • The percentage of delayed adaptations is much higher for split/merge operations than that for join/leave/cross operations.
  • This example demonstrates that their approach of separating the knowledge from the mechanisms allows a service developer to easily implement service-specific coordination policies without worrying about the underlying coordination mechanisms.

8. Conclusions

  • The authors presented a reusable self-adaptation framework that provides common adaptation functionality and yet can take advantage of developers’ service-specific adaptation knowledge.
  • The authors framework allows a developer to specify not only adaptation strategies but also coordination policies.
  • The authors identified and addressed three adaptation coordination issues: conflict detection, conflict resolution, and identifying incompatible strategies.
  • The authors implemented a prototype of the framework and evaluated their solution using a simulated gaming service.
  • Results show that coordination works as expected and that their approach also allows developers to easily design and change coordination policies.

Did you find this useful? Give us your feedback

Figures (8)

Content maybe subject to copyright    Report

Building Self-adapting Services Using Service-specific Knowledge
An-Cheng Huang
†
and Peter Steenkiste
†‡
Computer Science Department
†
Electrical and Computer Engineering Department
‡
Carnegie Mellon University
{pach,prs}@cs.cmu.edu
Abstract
With the advances in middleware and Web services tech-
nologies, network services are evolving from simple client-
server applications to self-configuring services that can
compose primitive components distributed in the Internet
into a value-added service configuration that provides rich
functionalities to users. A resulting research problem is
how to continuously adapt such composite service config-
urations at run time in order to cope with the increas-
ingly dynamic and heterogeneous network environments
and computing platforms. In this paper, we propose a self-
adaptation architecture that allows service developers to
specify their service-specific adaptation knowledge as “ex-
ternalized” adaptation strategies. These adaptation strate-
gies are used by a general, shared adaptation framework
to perform run-time adaptation operations that automati-
cally incorporate service-specific knowledge. In addition
to the strategies, we also identify another aspect of adap-
tation knowledge that is not addressed by previous solu-
tions: adaptation coordination. Our framework provides
integrated support for the specification and execution of
both aspects of developers’ adaptation knowledge.
1. Introduction
Network applications such as Web browsing, video con-
ferencing, instant messaging, file sharing, and online gam-
ing are becoming a necessity for more and more peo-
ple. From a user’s perspective, these network applica-
tions are used to access services offered by service de-
velopers over the Internet. Advances in middleware and
Web services technologies have enabled service develop-
ers to build value-added services using distributed software
components to satisfy particular user requirements. In or-
der to maintain the service performance and quality, such
This research was funded in part by NSF under award number CCR-
0205266.
distributed composite services must be able to dynamically
adapt their configurations to the frequent run-time changes
in network characteristics (e.g., latency and bandwidth), re-
source availability (e.g., CPU and memory), and other en-
vironment factors.
In many cases, how to perform run-time adaptation is
highly service-specific, i.e., simply using some generic
adaptation heuristics is not sufficient, and service-specific
knowledge is required to appropriately adapt the service
configuration at run time. Many previous research ef-
forts to support run-time adaptation adopt an “internal-
ized” approach that requires developers to integrate their
service-specific adaptation strategies into the target system,
e.g., [16, 19, 9, 3]. While this approach is flexible, it forces
a developer to hard-wire the knowledge into the system, in-
creasing design complexity and development cost.
In addition to the adaptation strategies, adaptation coor-
dination is another important aspect of distributed compos-
ite services that requires service-specific knowledge. Mul-
tiple strategies may be invoked at the same time, and they
may want to make conflicting changes to the configuration.
Furthermore, the developer may design strategies that “at
cross purposes”, e.g., one strategy adds a server to improve
performance while another strategy removes a server to re-
duce cost. Such adaptation coordination issues are a chal-
lenging problem that is not addressed by previous solutions.
In this paper, we present a self-adaptation architecture
that allows service developers to easily add run-time adap-
tation capability to their services. We use an “externalized”
approach adopted in several previous studies (e.g., [11, 26]):
we define a representation for developers to express their
service-specific adaptation knowledge in the form of exter-
nalized strategies and coordination policies, and we build
a general framework that can interpret such knowledge to
automatically adapt the target system at run time. Since
the general, shared framework provides common adaptation
functionalities, our approach reduces the development cost
as the developers do not need to worry about lower-level
mechanisms.
In the rest of the paper we define the run-time adaptation
Figure 1. A video conferencing service.
problem, present the self-adaptation architecture, discuss
the support for service-specific adaptation strategies and co-
ordination policies, describe our prototype implementation,
and use simulation to demonstrate the advantages of our ap-
proach.
2. Problem statement
We focus on the problem of adding run-time adaptation
capabilities to a composite service. Therefore, we assume
that the initial configuration of a service is already con-
structed. One possibility is that the developer constructs
the configuration manually. Alternatively, the developer
can build a “self-configuring service” using an existing self-
configuration framework, e.g., [13, 12, 22, 1], that automat-
ically composes the service configuration.
Given the initial service configuration, we have identi-
fied two aspects of a developer’s service-specific knowl-
edge that can be used to guide the adaptation of the con-
figuration at run time: adaptation strategies and coordi-
nation policies. Let us first use an example to illustrate
these. In Figure 1, five users want to hold a video confer-
ence. Two use MBone conferencing applications vic/SDR
(VIC), two use NetMeeting (NM), and one uses a receive-
only handheld device (HH). Suppose the initial configura-
tion for the users consists of a video conferencing gateway
(VGW) that translates different conferencing protocols, a
handheld proxy (HHP) joining the session on behalf of HH,
and three End System Multicast (ESM) proxies that provide
wide-area multicast functionality for the users.
At run time, the service configuration needs to be
adapted to accommodate environmental changes. For ex-
ample, to handle run-time problems such as high load and
congestion at the VGW, the developer may have the follow-
ing two strategies:
• S1: (VGW overloaded) → (replace VGW with a high-
capacity VGW)
• S2: (VGW congestion) → (replace VGW with a high-
bandwidth VGW)
These strategies are service-specific because another devel-
oper may have different strategies, e.g., VGW overload and
congestion could be handled by reducing the codec quality
and bit rate.
Another important aspect of the adaptation knowledge
is how the strategies should be “coordinated”. For exam-
ple, suppose at run time, S1 and S2 above are invoked at
the same time. If the two strategies want to replace the
VGW with different candidates, obviously only one of them
should be allowed to execute.
Our goal is to build an adaptation framework that allows
a developer to add self-adaptation capabilities to a service
and adapts the system based on the developer’s knowledge.
In this paper, we limit our scope to local adaptation, i.e.,
we focus on how to support adaptation strategies involving
only “local” actions and how to coordinate such strategies.
Specifically, a local adaptation only changes a single com-
ponent (e.g., changing the parameters of a component, re-
placing a component, etc.) and has limited “indirect” effects
(e.g., it only affects the component it changes).
3. Overview of adaptation architecture
In our architecture (Figure 2), a developer uses our
knowledge representation to express its service-specific
adaptation knowledge, including adaptation strategies and
coordination policies. This knowledge, along with the
initial configuration of the service, are given to the self-
adaptation framework, which consists of an adaptation
manager (AM), an adaptation coordinator (AC), and the
supporting infrastructure.
The supporting infrastructure provides the common
functionality required for run-time adaptation, e.g., a net-
work measurement infrastructure for measuring critical net-
work performance metrics, a service discovery infrastruc-
ture for finding new components, a component manage-
ment/deployment infrastructure for controlling/deploying
the components, etc. In this paper, we assume the necessary
infrastructures exist, and we focus on how the developers’
knowledge can be represented and on how the AM and the
AC can make use of the adaptation and coordination knowl-
edge to adapt the target service configuration.
At run time, the AM handles a developer’s adaptation
strategies by monitoring the configuration to detect run-time
problems. When a problem occurs, e.g., a component be-
comes overloaded, and one of the developer’s strategies is
designed to handle the problem, the AM invokes the strat-
egy to adapt the configuration, e.g., replace the overloaded
component. When a strategy is executed, it generates a pro-
posal specifying how it wants to change the configuration,
and the proposal is sent to the AC. If a proposal does not
conflict with other proposals, the AC accepts the proposal
and asks the AM to change the configuration accordingly.
Figure 2. Architecture for run-time local adaptation support.
Otherwise, the AC rejects the proposal.
Next, we discuss our design of the knowledge represen-
tation for specifying the adaptation strategies and coordina-
tion policies, and we describe how such knowledge is used
to perform run-time adaptation.
4. Adaptation strategies
Previous studies have proposed many run-time adapta-
tion solutions based on “internalized” adaptation strategies
(i.e., the adaptation logic and mechanisms are hard-wired
into the system itself), for example, [16, 19, 9, 3]. While
this approach gives the service developer complete control
over how adaptations are performed, it typically results in
high development costs.
The “externalized” approach adopted by some previous
projects, e.g., [11, 26], addresses this problem by separat-
ing the strategies and mechanisms from the actual system.
This enables the development of a general adaptation frame-
work that can be reused by different systems, and the devel-
oper of a system can add run-time adaptation capabilities by
designing externalized strategies without modifying system
components. Therefore, the development cost is potentially
much lower than with the internalized approach.
To support externalized strategies, one important de-
sign decision is how to specify such strategies. As cat-
egorized in [26], an adaptation strategy can be specified
as a high-level “utility” function or an explicit “event-
action” rule. The utility approach allows a service devel-
oper to specify a utility function indicating the “desirable”
configurations, and the adaptation mechanisms automati-
cally modify the service configuration towards higher util-
ity. This approach is for example used in run-time adap-
tation solutions that focus on dynamic resource allocation,
e.g., [17, 21, 26]. However, our scope of adaptation is
much broader and includes component-level adaptations
such as replacing/adding/removing components. Therefore,
the utility approach is not feasible.
The event-action approach lets a developer specify rules
dictating what “actions” should be taken when a particular
“event” occurs. For example, when the event “component X
becomes overloaded” occurs, the appropriate action is “re-
place X with a higher capacity one”. This approach is used
in previous studies where the target system involves differ-
ent, heterogeneous components, e.g., [11, 8]. Therefore, we
adopt the externalized, event-action approach for strategy
specification.
4.1. Strategy format
Our support for adaptation strategies is built on the exter-
nalized approach presented in Rainbow [11]. An adaptation
strategy consists of the following three parts.
• Constraint: A strategy is invoked when its constraint is
“violated”. A constraint is a condition on certain prop-
erties of the configuration, e.g., “load(X) < C” where
X is a component in the configuration. The properties
can be performance metrics, e.g., bandwidth and la-
tency, or component properties. At run time, the AM
monitors the constraints of the strategies and invokes a
strategy when its condition becomes false.
• Problem determination: A constraint violation may be
caused by multiple triggering problems. When a strat-
egy is invoked, it may need to, for example, query
more specific configuration properties to determine the
actual triggering problem. For example, in the video
conferencing example, a strategy triggered by “low
HH video quality” needs to determine whether the ac-
tual problem is HHP failure, low quality codec used by
the HHP, or congestion at the HHP.
• Tactic: A tactic consists of a set of actions that are
used to address a particular triggering problem. Ac-
tions range from changing a run-time parameter of a
component to changing the configuration by insert-
ing/removing components. In the example above,
“HHP failure” can be addressed by a tactic that re-
places the failed HHP with a new one, “low qual-
ity codec” can be addressed by “increasing the codec
quality”, and so on.
4.2. Strategy specification
We now discuss how each part of a strategy is speci-
fied. Our self-adaptation framework is based on the self-
configuration framework we built previously [13]. Specif-
ically, we leverage the existing abstract configuration API
and objective function API. The abstract configuration API
includes data structures representing components and com-
ponent types in a service configuration and functions for
adding/removing/connecting components in the configura-
tion. We assume the initial configuration is given to our self-
adaptation framework as a data structure that is constructed
using this API. Therefore, an adaptation strategy designed
by a developer can “reference” components or component
types in the configuration. The objective function API in-
cludes data structures representing performance metrics and
other properties of components/connections in the configu-
ration and operators in an objective function for component
selection.
In addition to the above existing functionality, new data
structures and functions are needed for specifying all parts
of a strategy. Table 1 summarizes the additions. We now
describe how a developer can use these APIs to specify each
part of an adaptation strategy.
• Constraint: A developer can use the objective func-
tion API to construct a function of the relevant prop-
erties of components and connections in the config-
uration. A constraint can then be constructed using
RelationOp and BooleanOp with the function.
When a constraint is violated, the “violator” in the con-
figuration is passed to the corresponding strategy (sim-
ilar to Rainbow [11]), which can then operate on the
appropriate component.
• Problem determination: Since our framework is im-
plemented in Java and exports Java interfaces and
classes for specifying strategies, a strategy designed
Data structure
RelationOp: Represent relation operators such as
“==”, “>=”, etc.
BooleanOp: Represent boolean operators such as
“AND”, “OR”, etc.
Condition: Represent a combination of “Term
RelationOp Term”.
Constraint: Represent a combination of
“Condition BooleanOp Condition”.
Tactic: Represent the base class for a tactic; develop-
ers implement tactics by creating specializations.
Strategy: Represent the base class for a strategy;
developers implement strategies by creating specializa-
tions.
Function
replaceComponent(c): Represent an adaptation
action that replaces an existing component c in the cur-
rent configuration.
changeParameter(pn,pv): Represent an adapta-
tion action that changes the value of the parameter pn of
a component to pv.
connect(c1,c2): Represent an adaptation action
that connects components c1 and c2.
setTacticObjective(obj): Set the component
selection objective for a tactic to obj, which will be used
for, e.g., the replaceComponent actions.
setConstraint(C): Associate the constraint C with
an adaptation strategy.
invokeTactic(T): Invoke the tactic T.
Table 1. API for specifying adaptation strate-
gies.
by a developer is basically a small Java class. This
approach gives the developer significant flexibility in
implementing the problem determination logic.
• Tactic: Since we focus on “local adaptation”, our
API allows a tactic to specify actions such as
replaceComponent, changeParameter, and
connect. Similar to our previous self-configuration
framework, when a tactic requires a new component, it
specifies an objective function as the component selec-
tion criterion using setTacticObjective. The
support infrastructure will then use this objective func-
tion to select the best server to execute the component,
given current runtime conditions.
• Strategy: Finally, we need a data structure to represent
a strategy. The constraint of a strategy can be assigned
using setConstraint, and a strategy can invoke a
tacticNewNM: This tactic connects a new NM user to
the VGW.
tacticNewVIC: Connect a new VIC user to the clos-
est ESMP.
tacticNewHH: Connect a new HH user to the HHP.
tacticVGWFail: Replace a failed VGW with a high-
capacity one.
tacticVGWOverload: Replace an overloaded VGW
with a high-capacity one.
tacticVGWCongest: Replace a congested VGW
with a high-bandwidth one.
tacticVGWLowQual: Increase the VGW’s codec
quality.
tacticESMPFail: Replace a failed ESMP with a
high-bandwidth one.
tacticESMPCongest: Replace a congested ESMP
with a high-bandwidth one.
Table 2. Tactics for the video conferencing
service.
particular tactic using invokeTactic.
We believe our self-adaptation framework can also be
applied to other component-based services frameworks
such as Ninja [12], SWORD [22], and ACE [1]. The major
requirement is that such a framework (1) provides a repre-
sentation of the service configuration allowing our frame-
work to reference the components in the configuration and
(2) provides an interface allowing our framework to make
changes to the configuration according to the developers’
knowledge.
4.3. Example
We use the video conferencing service as an example
to illustrate how a developer’s adaptation strategies can be
specified using the above APIs. Suppose the developer im-
plements the tactics shown in Table 2. Based on these tac-
tics, the developer then designs the strategies shown in Ta-
ble 3 (for simplicity, the actual code is not shown). As seen
in Table 3, the constraints for these strategies are as follows:
• C1: (config.numUnconnectedUsers == 0)
• C2: (NM.videoQuality >= Tn)
• C3: (VIC.videoQuality >= Tv)
Therefore, the adaptation strategies are instantiated and as-
sociated with their constraints using the following state-
ments:
stratNewUser: This strategy is triggered when a new
user joins the session. It determines the triggering prob-
lem and invokes the appropriate tactic as follows.
New NM user → tacticNewNM
New VIC user → tacticNewVIC
New HH user → tacticNewHH
stratNMQual: Triggered when the video quality of
NM is below a threshold T
n
.
VGW failed → tacticVGWFail
VGW overloaded → tacticVGWOverload
VGW congested → tacticVGWCongest
VGW poor codec → tacticVGWLowQual
stratVICQual: Triggered when the video quality of
VIC is below a threshold T
v
.
ESMP failed → tacticESMPFail
ESMP congested → tacticESMPCongest
Table 3. Strategies for the video conferencing
service.
stratNewUser S1 = new stratNewUser();
S1.setConstraint(C1);
stratNMQual S2 = new stratNMQual();
S2.setConstraint(C2);
stratVICQual S3 = new stratVICQual();
S3.setConstraint(C3);
The strategies are given to the AM, which monitors the con-
figuration and invokes a strategy when its constraint is vio-
lated.
5. Adaptation coordination
Our goal with respect to adaptation coordination is to
only require a service developer to specify the service-
specific coordination knowledge without worrying about
the underlying mechanisms. We identified three important
coordination issues: detecting conflicts between proposals,
resolving conflicts between proposals, and identifying in-
compatible strategies (i.e., strategies that work at cross pur-
poses). Next, we discuss how we address these three issues.
5.1. Conflict detection
We categorize conflicts into two types: action-level and
problem-level. An action-level conflict occurs when two
proposals want to make “conflicting changes” to the con-
figuration. For example, if one proposal wants to replace
server A with B, and another proposal wants to replace A
with C, then obviously only one can be accepted. In other
words, the two proposals attempt to change the same “tar-
get” in different ways. The AC can automatically detect
Citations
More filters
Proceedings Article•DOI•
Using queries for distributed monitoring and forensics

[...]

Atul Singh1, Petros Maniatis2, Timothy Roscoe2, Peter Druschel1•
Rice University1, Intel2
18 Apr 2006
TL;DR: This paper presents an application logging, monitoring, and debugging facility that is built on top of the P2 system, comprising an introspection model, an execution tracing component, and a distributed query processor, to demonstrate a range of on-line distributed diagnosis tools.
Abstract: Distributed systems are hard to build, profile, debug, and test. Monitoring a distributed system - to detect and analyze bugs, test for regressions, identify fault-tolerance problems or security compromises - can be difficult and error-prone. In this paper we argue that declarative development of distributed systems is well suited to tackle these tasks. We present an application logging, monitoring, and debugging facility that we have built on top of the P2 system, comprising an introspection model, an execution tracing component, and a distributed query processor. We use this facility to demonstrate a range of on-line distributed diagnosis tools that range from simple, local state assertions to sophisticated global property detectors on consistent snapshots. These tools are small, simple, and can be deployed piecemeal on-line at any point during a system's life cycle. Our evaluation suggests that the overhead of our approach to improving and monitoring running distributed systems continuously is well in tune with its benefits.

75 citations

Cites methods from "Building self-adapting services usi..."

  • ...[13] propose an architecture for adapting applications to changing runtime environments using the event-action based rules provided by the application designers....

    [...]

Proceedings Article•DOI•
A Utility-Based Adaptivity Model for Mobile Applications

[...]

Mourad Alia, Viktor S. Wold Eide, Nearchos Paspallis1, Frank Eliassen2, Svein Hallsteinsen3, George A. Papadopoulos1 •
University of Cyprus1, University of Oslo2, SINTEF3
21 May 2007
TL;DR: A formal model of the approach to support adaptivity is presented and this model is used to show the expressiveness of utility-based adaptation policies and a case study based on a real adaptive application built using the model and middleware is included.
Abstract: Mobile environments are characterized by resource fluctuations and limitations, and variations in user preferences. Therefore mobile applications need to be adaptive to retain usability, usefulness and reliability. In our approach to support adaptivity, we combine context awareness, reflection and component composition planning. The planning is done by generic middleware and supports dynamic discovery, utility-based and context-aware evaluation, and selection of the best implementation alternative of a given mobile application. In this paper we present a formal model of our approach and use this model to show the expressiveness of utility-based adaptation policies. To demonstrate the feasibility and expressiveness of our approach we include a case study based on a real adaptive application built using our model and middleware.

42 citations

Cites background from "Building self-adapting services usi..."

  • ...To overcome the complexity of building such adaptation loops, component-based approaches combined with reflection mechanisms have been widely adopted in many systems [2, 6, 11, 12, 14]....

    [...]

Role Oriented Adaptive Design

[...]

Alan Colman
01 Jan 2006
TL;DR: A meta-model and framework called Role Oriented Adaptive Design (ROAD) is introduced that is consistent with the concept of maintaining organisational integrity through ontogenic adaptation and the applicability of the ROAD framework to the domain of Service-Oriented Computing is demonstrated.
Abstract: Software systems are becoming inexorably more open, distributed, pervasive, mobile and connected. This thesis addresses the problem of how to build adaptive software systems. These systems need to reliably achieve system-level goals in volatile environments, where the system itself may be built from components of uncertain behaviour, and where the requirements for the software system may be changing. This thesis adopts the systemtheoretic concept of ontogenic adaptation from biology, and applies it to software architecture. Ontogenic adaptation is the ability of an individual system to maintain its organisational integrity by reconfiguring and regulating itself. A number of approaches to adaptive software architecture have been recently proposed that, to varying degrees, enable limited adaptive behaviour and reconfiguration, but none possess all the properties needed for ontogenic adaptation. We introduce a meta-model and framework called Role Oriented Adaptive Design (ROAD) that is consistent with the concept of maintaining organisational integrity through ontogenic adaptation. The ROAD meta-model defines software applications as networks of functional roles which are executed by players (objects, components, services, agents, people, or rolecomposites). These flexible organisational structures are adaptive because the relationships (contracts) between roles, and the bindings between roles and players, can be regulated and reconfigured at run-time. Such flexible organisational role-structures are encapsulated into composites each with its own organiser. Because self-managed composites are themselves role-players, these composites can be distributed and recursively composed. The organisers of the composites form a management system over which requirements and performance data pass. Rather than being monolithic constructions, ROAD software applications are dynamic, self-managed compositions of loosely-coupled, and potentially, distributed entities. The concepts in the ROAD meta-model have been implemented in a programming framework which can be extended by the application programmer to create adaptive applications. Central to this framework are dynamic contracts. These contracts define the role structure, control interactions between the role instances, and measure the performance of those interactions. Adaptivity is achieved by monitoring and manipulating these contracts, along with the role-player bindings. Contracts have been implemented using the mechanism of “association aspects”. The applicability of the ROAD framework to the domain of Service-Oriented Computing is demonstrated. The framework is further evaluated in terms of its ability to express the concept of ontogenic adaptation and also in terms of the overhead its runtime infrastructure imposes on interactions.

35 citations

Book Chapter•DOI•
A component-based planning framework for adaptive systems

[...]

Mourad Alia, Geir Horn1, Frank Eliassen, Mohammad Ullah Khan2, Rolf Fricke, Roland Reichle2 •
SINTEF1, University of Kassel2
29 Oct 2006
TL;DR: A planning framework that subsumes and automates the adaptation decision-making in reflective component-based adaptive systems and shows that the selection problem can be modelled as a multi constraint shortest path that can be found in polynomial time.
Abstract: Recently, many researchers have focused on designing generic and reusable middlewares to overcome the complexity in building adaptive systems There is a general agreement that the openness provided by component-based approaches coupled with reflection mechanisms is the minimum prerequisites for supporting dynamic reconfigurations However, this is not sufficient to implement the heart of the adaptation loop namely the decision making on the required reconfiguration that adapts the system in a given context In this regard, this paper proposes a planning framework that subsumes and automates the adaptation decision-making in reflective component-based adaptive systems The salient feature of this framework is to model the variability of the adaptive system as a set of variation points at which alternative component compositions and implementations can be selected to form an application configuration The selection of a feasible configuration in a given context is based on the concept of component wise utility functions that estimates the user benefit of including a specific implementation alternative at a variation point in the composition We show that the selection problem can be modelled as a multi constraint shortest path that can be found in polynomial time Our approach is validated through a real world example implementing adaptive scenarios in the domain of mobile computing.

24 citations

Book Chapter•DOI•
Achieving Self-configuration Capability in Autonomic Systems Using Case-Based Reasoning with a New Similarity Measure

[...]

Malik Jahan Khan1, Mian M. Awais1, Shafay Shamail1•
Lahore University of Management Sciences1
21 Aug 2007
TL;DR: A new similarity measure to find nearest neighbors is introduced and the case preparation, case retrieval and case reuse and refinement methods to enable self-configuration in autonomic systems are suggested.
Abstract: A lot of activities inside human body are carried out intelligently without the explicit intervention of human itself, e.g. various actions of nervous systems, blood circulation system etc. Inspired from these natural systems, autonomic computing is an emerging concept which promises to enable such kind of self-management capabilities inside software systems. Case-based reasoning (CBR) is a methodology to solve current problems using the solutions of past problems of the similar nature. In this paper, we propose to use CBR to achieve self-configuration in autonomic systems. We introduce a new similarity measure to find nearest neighbors. We have also suggested the case preparation, case retrieval and case reuse and refinement methods to enable self-configuration in autonomic systems. To support our proposed methodology, we illustrate a case-study of Autonomic Forest Fire Application.

20 citations

References
More filters
Proceedings Article•DOI•
Rainbow: architecture-based self-adaptation with reusable infrastructure

[...]

Shang-Wen Cheng1, An-Cheng Huang1, David Garlan1, Bradley Schmerl1, Peter Steenkiste1 •
Carnegie Mellon University1
17 May 2004
TL;DR: The Rainbow framework uses software architectural models to dynamically monitor and adapt a running system and shows that the separation of a generic adaptation infrastructure from system-specific adaptation knowledge makes this reuse possible.
Abstract: Software-based systems today are increasingly expected to dynamically self-adapt to accommodate resource variability, changing user needs, and system faults. Recent work uses closed-loop control based on external models to monitor and adapt system behavior at run time. Taking this externalized approach, the Rainbow framework we have developed uses software architectural models to dynamically monitor and adapt a running system. A key goal and primary challenge of this framework is to support the reuse of adaptation strategies and infrastructure across different systems. We show that the separation of a generic adaptation infrastructure from system-specific adaptation knowledge makes this reuse possible.

1,052 citations

"Building self-adapting services usi..." refers background or methods in this paper

  • ...When a constraint is violated, the “violator” in the configuration is passed to the corresponding strategy (similar to Rainbow [11]), which can then operate on the appropriate component....

    [...]

  • ...Our support for adaptation strategies is built on the externalized approach presented in Rainbow [11]....

    [...]

  • ..., [11, 26]): we define a representation for developers to express their service-specific adaptation knowledge in the form of externalized strategies and coordination policies, and we build a general framework that can interpret such knowledge to automatically adapt the target system at run time....

    [...]

  • ...Since we target both component-level and parameter-level adaptations in distributed composite services, previous component-level adaptation solutions such as [23, 10, 25, 20, 11] are more relevant to our work....

    [...]

  • ..., [11, 26], addresses this problem by separating the strategies and mechanisms from the actual system....

    [...]

Journal Article•DOI•
Rainbow: architecture-based self-adaptation with reusable infrastructure

[...]

David Garlan1, Shang-Wen Cheng1, An-Cheng Huang1, Bradley Schmerl1, Peter Steenkiste1 •
Carnegie Mellon University1
01 Oct 2004-IEEE Computer
TL;DR: The rainbow framework provides reusable infrastructure together with mechanisms for specializing that infrastructure to the needs of specific systems, and lets the developer of self-adaptation capabilities choose what aspects of the system to model and monitor, what conditions should trigger adaptation, and how to adapt the system.
Abstract: While attractive in principle, architecture-based self-adaptation raises a number of research and engineering challenges. First, the ability to handle a wide variety of systems must be addressed. Second, the need to reduce costs in adding external control to a system must be addressed. Our rainbow framework attempts to address both problems. By adopting an architecture-based approach, it provides reusable infrastructure together with mechanisms for specializing that infrastructure to the needs of specific systems. The specialization mechanisms let the developer of self-adaptation capabilities choose what aspects of the system to model and monitor, what conditions should trigger adaptation, and how to adapt the system.

840 citations

Proceedings Article•DOI•
Agile application-aware adaptation for mobility

[...]

Brian D. Noble1, Mahadev Satyanarayanan1, Dushyanth Narayanan1, James Eric Tilton1, Jason Flinn1, Kevin R. Walker1 •
Carnegie Mellon University1
01 Oct 1997
TL;DR: The design of Odyssey is described, a prototype implementing application-aware adaptation, and how it supports concurrent execution of diverse mobile applications, and agility is identified as a key attribute of adaptive systems.
Abstract: In this paper we show that application-aware adaptation, a collaborative partnership between the operating system and applications, offers the most general and effective approach to mobile information access. We describe the design of Odyssey, a prototype implementing this approach, and show how it supports concurrent execution of diverse mobile applications. We identify agility as a key attribute of adaptive systems, and describe how to quantify and measure it. We present the results of our evaluation of Odyssey, indicating performance improvements up to a factor of 5 on a benchmark of three applications concurrently using remote services over a network with highly variable bandwidth.

827 citations

"Building self-adapting services usi..." refers background in this paper

  • ..., the adaptation logic and mechanisms are hard-wired into the system itself), for example, [16, 19, 9, 3]....

    [...]

  • ...However, the flexibility of the epoch/priority approach is gained by sacrificing “agility” [19]: all proposals within an epoch have to wait until the end of the epoch....

    [...]

Proceedings Article•DOI•
Architecture-based runtime software evolution

[...]

Peyman Oreizy1, Nenad Medvidovic1, Richard N. Taylor1•
University of California, Irvine1
01 Apr 1998
TL;DR: An architecture-based approach to runtime software evolution is presented and the role of software connectors in supporting runtime change is highlighted and an initial implementation of a tool suite for supporting the runtime modification of software architectures is presented.
Abstract: Continuous availability is a critical requirement for an important class of software systems. For these systems, runtime system evolution can mitigate the costs and risks associated with shutting down and restarting the system for an update. We present an architecture-based approach to runtime software evolution and highlight the role of software connectors in supporting runtime change. An initial implementation of a tool suite for supporting the runtime modification of software architectures, called ArchStudio, is presented.

704 citations

"Building self-adapting services usi..." refers background in this paper

  • ...Since we target both component-level and parameter-level adaptations in distributed composite services, previous component-level adaptation solutions such as [23, 10, 25, 20, 11] are more relevant to our work....

    [...]

Proceedings Article•DOI•
Utility functions in autonomic systems

[...]

William E. Walsh1, Gerald Tesauro1, Jeffrey O. Kephart1, Rajarshi Das1•
IBM1
17 May 2004
TL;DR: A distributed architecture, implemented in a realistic prototype data center, that demonstrates how utility functions can enable a collection of autonomic elements to continually optimize the use of computational resources in a dynamic, heterogeneous environment is presented.
Abstract: Utility functions provide a natural and advantageous framework for achieving self-optimization in distributed autonomic computing systems. We present a distributed architecture, implemented in a realistic prototype data center, that demonstrates how utility functions can enable a collection of autonomic elements to continually optimize the use of computational resources in a dynamic, heterogeneous environment. Broadly, the architecture is a two-level structure of independent autonomic elements that supports flexibility, modularity, and self-management. Individual autonomic elements manage application resource usage to optimize local service-level utility functions, and a global arbiter allocates resources among application environments based on resource-level utility functions obtained from the managers of the applications. We present empirical data that demonstrate the effectiveness of our utility function scheme in handling realistic, fluctuating Web-based transactional workloads running on a Linux cluster.

402 citations

Related Papers (5)
Rainbow: architecture-based self-adaptation with reusable infrastructure

[...]

17 May 2004
Shang-Wen Cheng, An-Cheng Huang, David Garlan, Bradley Schmerl, Peter Steenkiste 
Utility functions in autonomic systems

[...]

17 May 2004
William E. Walsh, Gerald Tesauro, Jeffrey O. Kephart, Rajarshi Das 
The vision of autonomic computing

[...]

01 Jan 2003-IEEE Computer
Jeffrey O. Kephart, David M. Chess
A control theory based framework for dynamic adaptable systems

[...]

14 Mar 2004
João W. Cangussu, Kendra M. L. Cooper, Changcheng Li
Agile application-aware adaptation for mobility

[...]

01 Oct 1997
Brian D. Noble, Mahadev Satyanarayanan, Dushyanth Narayanan, James Eric Tilton, Jason Flinn, Kevin R. Walker 
Frequently Asked Questions (11)
Q1. What is the main aspect of distributed composite services?

In addition to the adaptation strategies, adaptation coordination is another important aspect of distributed composite services that requires service-specific knowledge. 

The authors identified and addressed three adaptation coordination issues: conflict detection, conflict resolution, and identifying incompatible strategies. 

In this paper, the authors limit their scope to local adaptation, i.e., the authors focus on how to support adaptation strategies involving only “local” actions and how to coordinate such strategies. 

To allow a developer to specify problem-level conflicts, the authors observe that since each problem is addressed by a tactic, a problem-level conflict can be specified as a conflict between two tactics. 

In the rest of the paper the authors define the run-time adaptationproblem, present the self-adaptation architecture, discuss the support for service-specific adaptation strategies and coordination policies, describe their prototype implementation, and use simulation to demonstrate the advantages of their approach. 

This enables the development of a general adaptation framework that can be reused by different systems, and the developer of a system can add run-time adaptation capabilities by designing externalized strategies without modifying system components. 

The major requirement is that such a framework (1) provides a representation of the service configuration allowing their framework to reference the components in the configuration and (2) provides an interface allowing their framework to make changes to the configuration according to the developers’ knowledge. 

For this reason, the epoch/priority approach is used for applications where simplifying assumptions about the timing of events can be made, e.g., coordinating rules in active databases [15, 5]. 

Since the general, shared framework provides common adaptation functionalities, their approach reduces the development cost as the developers do not need to worry about lower-level mechanisms. 

As categorized in [26], an adaptation strategy can be specified as a high-level “utility” function or an explicit “eventaction” rule. 

The constraint of a strategy can be assigned using setConstraint, and a strategy can invoke aparticular tactic using invokeTactic.