a self-adaptation model for ubiquitous computing applications

KAIST

Department of Computer Science

A Self-Adaptation Model for Ubiquitous Computing Applications

Kyungmin Lee

KAIST

Dongman Lee

KAIST

Soon J. Hyun

KAIST

CS/TR-2010-328

May 2010

A Self-Adaptation Model for UbiquitousComputing Applications

KYUNGMIN LEE, DONGMAN LEE, and SOON J. HYUN

Korea Advanced Institute of Science and Technology

Numerous efforts have been made to facilitate the building of self-adaptive applications that are

essential to realize the ubiquitous computing vision of enabling users to accomplish their tasks

anytime anywhere with minimal distraction. However, they do not adequately address two com-peting challenges: flexibility and simplicity. More specifically, they either have limitations to

support the engineering of diverse types of self-adaptive behaviors that are necessary for ubiq-

uitous computing applications; or require undue additional efforts from application developersin engineering self-adaptive behaviors. Consequently, for most developers, building self-adaptive

ubiquitous computing applications remains still a difficult and tedious task. In this article, wepropose a self-adaptation model where self-adaptive behaviors are expressed in the form of self-

adaptation policies based on utility functions augmented with thresholds. The proposed model

allows a comprehensive and concise specification of self-adaptation policies involving differenttypes of self-adaptive behaviors, and thus empowers application developers with a simple yet

flexible way of building self-adaptive ubiquitous computing applications. We present a formal

semantics and an XML-based language for the proposed self-adaptation model, and then discussseveral salient features of our model with concrete examples compared to the existing approaches.

Categories and Subject Descriptors: K.6.3 [Management of Computing and InformationSystems]: Software Management—software development; D.2.1 [Software Engineering]: Re-

quirements/Specifications; D.2.7 [Software Engineering]: Distribution, Maintenance, and En-

hancement; D.2.11 [Software Engineering]: Software Architectures—domain-specific architec-tures; patterns; D.1.m [Programming Techniques]: Miscellaneous

General Terms: Design, Languages

Additional Key Words and Phrases: self-adaptive behavior, utility function, self-adaptation policy,

ubiquitous computing

1. INTRODUCTION

Ubiquitous computing envisions that users can accomplish their tasks anytime any-where with minimal distraction by exploiting an ever-rich set of computing devicesand services which are seamlessly integrated into our daily environments [Weiser1991]. With advances in both hardware and software technology, our physical en-vironments such as homes, offices, schools, restaurants, shopping stores, etc., aregradually and incrementally transforming into ubiquitous computing environments.There, a user can easily accomplish her task at hand using an application thatinteracts with services available in her current environment.

Intrinsically, however, ubiquitous computing environments are spontaneous andheterogeneous [Kindberg and Fox 2002; Edwards and Grinter 2001], and thus theavailability of services frequently and unpredictably changes over time and space.This introduces significant challenges in achieving the above-mentioned vision, so-called ubiquity and invisibility of computing. Specifically, services would often notbe available in a particular time and space, possibly because they are not yet

Authors’ address: Department of Computer Science, Korea Advanced Institute of Science andTechnology, Daejeon, Korea; e-mail: [email protected], [email protected], [email protected]

2 · K. Lee et al.

deployed; temporarily shutdown; short of resources; or already in use by others.An application running in such environments cannot be pre-configured to workwith specific services. Rather, it has to make a spontaneous and often short-livedassociation with dynamically discovered services that are capable of supportingsome functions required for its task. Moreover, an application that interacts withsome services available at a particular point in time and space should be ableto continue functioning with different services even if its user has moved from oneenvironment to another; or if available services in an environment has changed. Thisrequirement, so-called dynamic adaptability, is essential for achieving the ubiquityof computing. More importantly, for the invisibility of computing, such dynamicadaptation should not require substantial involvement of users, because manuallyperforming such adaptation may often be infeasible or at least very hard and tediousto most users. Instead, applications should be self-adaptive in that they should beable to autonomously modify their structure and behavior in response to changesin their context.

In this respect, an important question is how to develop and execute self-adaptiveapplications for ubiquitous computing environments. It is challenging because ubiq-uitous computing applications normally involve much more different types of self-adaptive behaviors than traditional enterprise and Internet applications. We believethat a self-adaptation approach should enable application developers to define andrealize diverse types of self-adaptive behaviors that are essential for ubiquitous com-puting applications. We refer to this challenge as flexibility. We further argue thatsimply supporting flexible self-adaptation is not sufficient, but at the same time aself-adaptation approach should not require undue additional efforts from applica-tion developers in the engineering of such diverse types of self-adaptive behaviors.We refer to this challenge as simplicity.

A number of pioneering efforts have been made to facilitate the developmentand execution of self-adaptive applications [Salehie and Tahvildari 2009; Chenget al. 2009; Oreizy et al. 1999; Floch et al. 2006; Li et al. 2005; Dustdar et al.2009; Sousa et al. 2006; Cheng 2008; Garlan et al. 2004; Cervantes and Hall 2004;Di Nitto et al. 2008; Geihs et al. 2009]. To the best of our knowledge, however,they do not adequately address two competing challenges mentioned above. Morespecifically, their main concerns have been on maintaining an application’s Qual-ity of Service (QoS) such as throughput, latency, reliability, etc.; or automaticallyrecovering from failures of an application’s constituent components. On the otherhand, ubiquitous computing applications are increasingly finding various types ofcontextual information including physical or social context as an important stimu-lus for self-adaptation. For example, location or proximity is the most widely usedcontext information that drives the dynamic adaptation of ubiquitous computingapplications. Another important concern for ubiquitous computing applications isa partial failure of services with respect to their functional requirements. In ubiqui-tous computing environments, it is highly probable for an application to encounteran undesirable situation where all the available services can support only a partialsubset of the required functions. Facing such a situation, an application may wantto or need to select and use the best one among many partially-fulfilled services.Due to the lack of support for such diverse types of self-adaptive behaviors, appli-

A Self-Adaptation Model · 3

cation developers would often be required to build extra mechanisms on top of theexisting ones or engineer self-adaptive behaviors in their own ways. Consequently,the task of building of self-adaptive ubiquitous computing applications remains dif-ficult and tedious for most developers. Even experts with substantial experience inengineering some types of self-adaptive applications are likely to find it difficult tobuild other types of self-adaptive applications.

In this article, we propose a self-adaptation model where self-adaptive behav-iors are expressed in the form of self-adaptation policies based on utility functionsaugmented with thresholds. In more detail, our model represents a self-adaptationpolicy in terms of a set of requirements that an application expects from its targetservice. Each of these requirements is described with the following: a dimensionidentifying a specific type of context relevant to this requirement; a utility functionthat assigns a scalar utility value to every possible value in the domain of the di-mension; a threshold representing the minimum utility value that the applicationcan accept or tolerate with respect to this requirement; and a weight reflecting howmuch the application cares about this requirement relative to others. The pro-posed model allows a comprehensive and concise specification of self-adaptationpolicies involving different types of self-adaptive behaviors. Its utility-functionbased representation of self-adaptation polices enables a unified specification andtreatment of different types of requirements on a service, including functional—either coarse-grained or fine-grained—and non-functional—either QoS-related ornon-QoS-related—requirements. By the use of thresholds defined over utility values,it also enables an integrated specification of both detection policies that representwhat changes in an application’s context need to be monitored and when thosechanges need to trigger the application’s modification; and modification policiesthat determine how the application should be modified. Moreover, the proposedmodel has other salient features that help address the two competing challenges ofsimplicity and flexibility. It enables a concise specification of even non-trivial anddynamic context types by adopting the RDF (Resource Description Framework)data model [Manola and Miller 2004] to describe various types of context and asimplified form of the RDF query to identify a specific type of context associatedto a requirement. It also defines a few types of utility functions that are flexibleenough to capture many different patterns of utility value distributions while notimposing an undue burden on eliciting and processing utility values. Finally, it al-lows application developers to specify an aggregate requirement that consists of oneor more other requirements and thus enables a flexible and hierarchical groupingof the related requirements. As such, the proposed self-adaptation model empow-ers application developers with a simple yet flexible way of building self-adaptiveubiquitous computing applications.

The remainder of this article is organized as follows. Section 2 describes thebackground and related work on self-adaptation approaches. Section 3 discusseswhat we have considered in the design of our self-adaptation model. In Section 4, wepresent a formal semantics of self-adaptation policies in the proposed self-adaptationmodel and an XML-based language called SAPL (Self-Adaptation Policy Language)that are used to specify self-adaptation policies based on our model. Section 5discusses the salient features of our model that help address the two competing

4 · K. Lee et al.

challenges of simplicity and flexibility, compared to the existing approaches. Finallywe conclude this article in Section 6.

2. BACKGROUND AND RELATED WORK

Software applications or systems are increasingly becoming more complex andlarger [Feiler et al. 2006]. At the same time, their execution environments aswell as their users’ requirements are becoming subject to frequent and continu-ous change [Di Nitto et al. 2008]. A significant problem arising from these trendsis a dramatic increase in the cost and time involved in maintaining and utilizingsoftware applications. In this respect, self-adaptive software [Laddaga 1997; Oreizyet al. 1999] has emerged as a promising solution to save human efforts by allowingapplications themselves instead of users to automatically adapt to dynamic changesin their environments and requirements.

Over the years, a number of self-adaptation approaches have been proposed tofacilitate the development and execution of self-adaptive applications. A key in-gredient common to most of them is a closed-loop control of the self-adaptationprocesses that is embodied in applications [Salehie and Tahvildari 2009; Dobsonet al. 2006; Kephart and Chess 2003; Oreizy et al. 1999]. Figure 1 illustrates such aloop that we refer in this article to as the “MADE” self-adaptation loop. It consistsof four processes that fall into two distinct phases: one is the phase for detectingchanges and the other for modifying applications. First, the monitoring process ob-serves changes in an application’s context and notifies the analyzing process of suchchanges. The analyzing process then evaluates whether the notified change requiresthe application’s modification and triggers the deciding process if it is the case.The deciding process is responsible for determining how the application should bemodified to cope with the change occurred. Finally, the executing process actuallyperforms the modification of the application according to the decision. These fourprocesses together enable an application’s self-adaptive behavior that modifies itsstructure and/or behavior in response to a specific change in its context.

Existing approaches provide one or more support mechanisms for the above-mentioned self-adaptation processes required to realize self-adaptive behaviors. Ex-amples of such mechanisms include service/resource monitoring and context acqui-sition/reasoning/delivery that help applications detect changes; and service discov-ery/matching, late/dynamic (re-)binding, migration/check-pointing, and dynamicinterface adaptation that help applications modify themselves responding to de-tected changes. These mechanisms are in general application-independent and thusapplication developers need to design and implement self-adaptive behaviors oftheir applications by exploiting appropriate mechanisms. But the level of abstrac-tion provided to application developers in engineering self-adaptive behaviors variesfrom approach to approach.

2.1 Internal vs. External Model

Focusing on the model of how application developers define or specify self-adaptivebehaviors of their applications, we can classify existing self-adaptation approachesroughly into two broad groups. The first group of approaches advocates an internaland programmatic model while the second group seeks an external and declarativemodel. In general, the former approaches exhibit relatively higher flexibility but


Monitoring Analyzing

DecidingExecuting

Detecting Changes

Modifying Applications

Fig. 1. The “MADE” self-adaptation loop with the monitor-analyze-decide-execute processes

lower simplicity than the latter approaches. Our model aims at achieving a higherdegree of flexibility than existing approaches without considerable loss of simplicity.In the rest of this section, we discuss in detail such models with a few representa-tive approaches. For a more detailed and comprehensive survey of self-adaptationapproaches, we refer the reader to [Salehie and Tahvildari 2009].

First, in the internal and programmatic model, self-adaptive behaviors are en-coded as part of the application code through programming language features,libraries, or frameworks. The key rationale behind the approaches advocating thismodel is as follows. There are too many different types of self-adaptive behav-iors that are usually application-specific. Such self-adaptive behaviors is difficultto engineer without precise and flexible control by application developers. Hence,applications developers should be able to determine and implement their own self-adaptive behaviors where necessary by exploiting several mechanisms supported byan underlying middleware infrastructure or framework.

A notable example is one.world [Grimm et al. 2004] that provides an integratedframework for enabling ubiquitous computing applications to adapt to contextualchange by themselves through exposing such change rather than hiding it. It helpsapplications detect changes and modify themselves, respectively, by providing astorage and query engine for tuple-based data and an asynchronous event basedcommunication mechanism; and a discovery, migration, and check-pointing service.Application developers can exploit these mechanisms to implement their own adap-tation strategies for handling changes. Although the APIs for using these mecha-nisms are not significantly harder than conventional distributed programming, itsprogrammatic approach complicates the engineering of self-adaptive behaviors andmakes the reuse of such behaviors difficult.

As such, in general, this group of approaches can give a high degree of flexibilityto application developers because it does not impose any semantic constraints onthem and enables them to design and implement their own complex and preciseself-adaptive behaviors. However, such a high degree of flexibility may unnec-essarily complicate the engineering of self-adaptive behaviors because it requiresapplication developers to be familiar with low-level details of the mechanisms forrealizing self-adaptive behaviors. But more importantly, these approaches make it

6 · K. Lee et al.

difficult to add, remove, and modify self-adaptive behaviors, rendering them in-adequate for highly spontaneous and heterogeneous environments. The internaland programmatic way of engineering self-adaptive behaviors is likely to make theapplication code entangled with code for self-adaptive behaviors. Such spaghetticode is less readable, upgradable, portable, and reusable. Even if we have producedwell-documented and well-designed code, say, by applying design patterns [Gammaet al. 1994], the problem still remains because we cannot avoid recompilation ofcode in order to update self-adaptive behaviors.

Second, the external and declarative model tries to separate and externalize self-adaptive behaviors from the application code. The key idea behind this model isthat by providing application developers with a high-level abstraction and declar-ative way of defining self-adaptive behaviors, the development of self-adaptive ap-plications can be greatly simplified. However, such simplicity usually comes at thecost of reduced flexibility. In general, these approaches have their own and specificmodels and languages that can be used to define and specify self-adaptive behaviors.Normally, however, such models and languages are designed for specific domainsof applications and/or specific types of self-adaptive behaviors. This makes themhardly applicable to a variety of application domains and self-adaptive behaviors.Recently, a few approaches seek to cover a rich set of self-adaptive behaviors orpropose a general framework that can be extended and tailored for specific needsif necessary [Sousa et al. 2006; Garlan et al. 2004]. However, none of the externaland declarative approaches provides a flexible model that supports a full range ofself-adaptive behaviors that are essential for ubiquitous computing applications.

2.2 Explicit vs. Implicit Specification

In the external and declarative model, self-adaptive behaviors are typically rep-resented in the form of the so-called self-adaptation policies. We can classify themethods to specify self-adaptation policies into the explicit and implicit specifica-tion.

First, in the explicit specification method, self-adaptation policies are expressedin the form of event-condition-action or ECA rules. The three components of ECArules can be used for specifying self-adaptation policies as follows. First, the eventpart of a rule is used to describe what changes of an application’s context need tobe monitored and to be analyzed. Second, the condition part is used to representhow those changes are analyzed, i.e., when the application need to be modified.Finally, the action part is used to specify what modifications of the applicationneed to be performed. Either the event or the condition part may be omitted ifit is not necessary or is implicitly known. For example, situation-action rules haveonly two parts, lacking the part corresponding to the event part of ECA rules.From the situation part that corresponds to the condition part of ECA rules, wecan implicitly figure out what changes should be detected. For differences betweenECA rules and situation-action rules, refer to [Paton et al. 1993].

The Rainbow framework supporting architecture-based self-adaptation expressesself-adaptation policies using invariants and adaptation strategies and their explicitassociations [Garlan et al. 2004; Cheng 2008]. An adaptation strategy specifies acoarse of adaptation operations or actions that need to be performed when a specificinvariant is violated. In SAFRAN [David and Ledoux 2006], an aspect-oriented


approach for self-adaptation of Fractal based applications, self-adaptive behaviorsare expressed in terms of adaptation aspects that are in fact a set of ECA rules.Reconfigurable Context Sensitive Middleware (RCSM) [Yau et al. 2002], an object-based development framework for context-aware and ad-hoc applications, proposesCA-IDL (Context-Aware IDL) for describing what method of an object should beinvoked when a certain context condition is met. Roman et al. [2003] present anapplication bridge that can be used to define interaction rules between two ActiveSpace applications [Roman et al. 2002]. When receiving a notification event fromits source application, an application bridge executes pre-specified actions on itstarget application. Such actions are described using the LuaORB script language.

In general, the approaches using the explicit specification method share simi-lar advantages and disadvantages with the internal and programmatic approaches.They seem to give a high flexibility to application developers in designing self-adaptive behaviors because they allows application developers to specify exactlywhat to do in certain situations. However, application developers may find it diffi-cult to explicitly specify a course of actions required for coping with some changesusing low-level scripts. Explicit associations between context changes and modifi-cation actions might often not be feasible or at least not be scalable as increase thenumber of different types of changes and actions. Moreover, flexibility is in factnot a consequence from the simple use of ECA rules. But in practice we need ashared vocabulary of terms and concepts that can be used to define the events, con-ditions, and actions of ECA rules. Such terms and concepts are normally confinedto specific domains of applications or systems.

Unlike the explicit specification method where application developers should ex-plicitly specify the adaptation actions required to handle specific changes, the im-plicit specification method expresses self-adaptation policies in the form of high-levelgoals such as the invariants. Given such high-level goals, the underlying frameworkdetermines what changes to detect, and when and how to modify an application.The implicit specification model is simpler and easier to specify than the explicitone. But such simplicity comes at the cost of reduced flexibility. In other words, itis quite difficult to have goal specifications that are both comprehensible by appli-cation developers and processible by the adaptation framework [Kramer and Magee2007]. Hence, specific models have built for specific application domains, renderingthem not applicable to other domains.

Moreover, the problem of deciding how to modify an application to achieve thespecified goals is challenging. In theory, planning techniques can solve the problembut they are neither generally applicable nor computationally efficient or practical.Thus, in practice the problem is usually reduced to one of selecting among the set ofplans pre-generated offline. However, this is unacceptable for applications runningin ubiquitous computing environments whose spontaneity and heterogeneity makesuch pre-generated set of plans insufficient to handle any possible situations. Forexample, Zhang and Cheng [2006] model a program’s behaviors using a state ma-chine (i.e., states and transitions between states) and use the model to verify andvalidate the program against some constraints such as liveness as well as to generatethe program’s code and test cases. However, application developers are required toexhaustively specify all the possible adaptive and non-adaptive behaviors of their

8 · K. Lee et al.

applications to guarantee the correctness of programs despite adaptation. A scala-bility problem arises when the number of such behaviors becomes very large. Evensuch behaviors cannot be enumerated a priori at design time in highly spontaneousand heterogeneous ubiquitous computing environments.

Morin et al. [2008; 2009] seek to address such scalability problem by integratingAspect Oriented Modeling (AOM) techniques into the model driven approach. In-stead of enumerating all the possible configurations of whole system, they focus onvariation points whose different variants are represented as aspects. The whole con-figurations of a system can be constructed on demand by selecting and weaving aset of aspects. However, their approach relies on humans in selecting a set of aspectsand triggering the weaving of them; or uses adaptation rules in the form of simplecondition-action rules that specify a change in the configuration of aspects in a par-ticular context [Fleurey et al. 2008]. Similarly, Becker et al. [2004] present PCOM,a component system for adaptive, pervasive application, where an application ismodeled as a tree of components that can be independently replaced with others.Each component is associated with a contract that describes, among others, therequirements on other components. A contract is used when a component selectsone of many possible other candidate components fulfilling its requirements. How-ever, PCOM requires application developers to define their own selection strategyfor more fine-grained comparison among candidates with different non-functionalproperties. The Gravity project [Cervantes and Hall 2004] introducing a service-oriented component model, provides support for managing dynamic availability ofservices. Similar to PCOM, it relies on a component description that represents,among others, the dependencies on other services to be able to provide its services.Unlike PCOM, it provides an optional filter expressing constraints over serviceproperties in LDAP query syntax to limit the number of candidate components.But it is still too simple to incorporate complex and dynamic context.

A promising solution to the above limitations of the goal-based implicit specifi-cation method is to use utility functions to define high-level goals. In the context ofcomparing multiple candidates for a service or a component, goals in general pro-vide only a coarse-grained measure of whether a candidate can achieve a goal or not;but utility functions can express a fine-grained degree of how good a candidate iswith respect to a goal. Thus, a utility-function based model can determine the bestout of multiple alternative services while a goal-based model can only randomlychoose one of many services that achieves the specified goal [Walsh et al. 2004].Moreover, a goal-based model cannot handle the case when there is no alternativeservice capable of fully achieving a goal.

The utility-function based specification method has been widely adopted. No-table examples include Aura [Sousa 2005; Sousa et al. 2006] and MADAM [Flochet al. 2006; Geihs et al. 2009]. Aura exploits high-level models of user tasks toautomatically configure a computing environment (a set of services and devices)on behalf of users. A task model defines a user task as a collection of abstractservices such as “play video” and “edit text”, which describe the functionality re-quired for a task independently of specific computing environments and concreteservice providers (e.g., “MSWord”, “Emacs”, or “Vi” for “edit text” service). Themodel uses utility functions to represent user preferences with respect to alternative


combinations of abstract services for a task (configuration preferences); alternativeservice providers for each abstract service (supplier preferences); and acceptableQoS levels and trade-offs between QoS dimensions (QoS preferences). Based onthe task model, a user task is automatically instantiated to maximize the overallutility given available service providers and resource constraints in an environment.MADAM uses architecture models to enable self-adaptation of mobile computingapplications. An architecture model of an application describes a composition ofa set of component types, which different component implementations (or variantcan be plugged into. Each variant is annotated with a set of properties, over whicha utility function is defined. MADAM selects among multiple variants the one withthe highest utility for a specific context whenever context changes.

While these efforts have proven the effectiveness of the utility-function basedmodel with varying success, there still remains some limitations with respect tosupporting the diversity of self-adaptive behaviors. They only support limitedtypes of context information. More specifically, they are little concerned with othertypes of contextual changes beyond QoS or failures. Moreover, they do not pro-vide an appropriate model for representing and measuring fine-grained functionalrequirements.

In summary, to the best of our knowledge, no existing approaches to self-adaptationeffectively supports the engineering of diverse self-adaptive behaviors for ubiquitouscomputing applications. Due to lack of a simple yet flexible self-adaptation modeland mechanisms, application developers are often required to build extra mech-anisms on top of existing approaches or engineer self-adaptive behaviors in theirown ways. Consequently, the engineering of self-adaptive ubiquitous computingapplications remains still a difficult and tedious task.

3. DESIGN CONSIDERATIONS

This section discusses what we have considered in the design of our self-adaptationmodel. The proposed model aims at achieving a higher degree of flexibility thanexisting approaches without considerable loss of simplicity. To this end, a self-adaptation model should allow the unified specification of both detection and mod-ification policies for diverse and variable self-adaptive behaviors. Recall that aubiquitous computing application should have self-adaptive behaviors that are re-sponsible for modifying its structure and behavior in response to changes in itscontext. By definition, this entails two key design issues: one is for detectingchanges in its context and the other for modifying its structure and behavior.

First, a key issue for the change detection phase is the model of context or contextchange that acts as a stimulus for self-adaptation. By context, we refer to anyinformation that characterizes the situation of an application, following the genericdefinition proposed by Dey and Abowd [1999]. It should be able to capture diversetypes of requirements that an application can impose on a service. More specifically,it should support self-adaptive behaviors that are concerned with more general typesof non-functional requirements beyond just QoS-related ones, as well as those thatare supposed to consider fine-grained functional requirements such as partial failureof services rather than coarse-grained ones like total failure. Moreover, it shouldprovide a unified and concise way of defining such diverse types of requirements.

10 · K. Lee et al.

There are various ways of modeling context, including key/value-based, markup-based, object-oriented, and ontology-based model to name a few [Strang and Linnhoff-Popien 2004]. Each has different advantages and disadvantages as discussed in [Bet-tini et al. 2010; Strang and Linnhoff-Popien 2004]. Among them, we adopt theontology-based context model that is widely used in ubiquitous computing systems,e.g., SOCAM [Gu et al. 2005], CoBrA [Chen et al. 2004; 2003], and Gaia [Ran-ganathan et al. 2003]. It supports a uniform, expressive, and interoperable repre-sentation of various and complex context information as well as reasoning aboutcontext [Bettini et al. 2010]. Specifically, any context information can be repre-sented as a triple of subject, predicate, and object. For example, 〈‘alice’, ‘locatedIn’,‘F619’〉 represents that a user ‘alice’ is currently located in a room ‘F619’. Morecomplex context information can be represented by combining a set of triples. Theterms and their semantics that can be used in a triple are defined in a shared on-tology, which is usually written in OWL [Hitzler et al. 2009]. We can benefit fromexisting well-defined ontologies such as CONON [Wang et al. 2004], SOUPA [Chenet al. 2005], GAS [Christopoulou and Kameas 2005] and MUSIC [Reichle et al.2008] that are readily available to us.

Second, the phase for application modification requires the modular structur-ing of applications [McKinley et al. 2004a]. In other words, an application shouldbe constructed with a set of reusable and replaceable building blocks. In thisrespect, Component-Based Software Engineering or CBSE is a well-established dis-cipline that promotes software reuse by assembling a large software system withpre-existing components [Heineman and Councill 2001; Szyperski 2002]. Softwarecomponents can be independently developed by different developers, deployed asbinary units, and composed together by third-parties [Szyperski 2002]. More re-cently, Service Oriented Architecture or SOA [Huhns and Singh 2005; Papazoglouet al. 2007] has been widely adopted as such a paradigm. It advocates service-basedapplications [Di Nitto et al. 2008] that utilize the functions provided by a number ofservices to accomplish their tasks.1 Unlike components that need to be physicallyavailable for being assembled, in general, services are independently executed andmaintained by third parties and thus dynamically composed at runtime [Cervantesand Hall 2004]. For subtle differences between components and services, we referinterested readers to [Elfatatry 2007; Cervantes and Hall 2004].

We adopt the service-based application model because it is more suitable thancomponent-based one, considering highly spontaneous and heterogeneous ubiqui-tous computing environments. In particular, its loosely-coupled interaction modelis a key aspect that facilitates on-the-fly adaptation of applications by dynamicallychanging the services they interact with at runtime. The SOA’s triangular interac-tion model [Vinoski 2002; Huhns and Singh 2005] consists of the publish, find, bind,and invoke processes. A service2 publishes itself by registering its description in a

1Note that this definition is somewhat different from a commonly adopted one where a service-

based application is referred to as the set of services interacting with each other to achieve a goal.Rather, we use the term “client application” or simply “application” for referring to a consumer

or requester of another service. This distinction between an application and a service is just for

clarity in the discussion. A service can be both an application and a service because it can makeuse of other services to provide its functions.2We use the term “service” for referring to both an abstract concept representing a set of func-


service repository (or registry). By querying this repository, a (client) applicationfinds a service that can support functions it requires. After binding to a discov-ered service, the application can request a set of functions provided by the service.The indirection by the publish and find processes, which form together the servicediscovery process, decouples applications and services, hence facilitating dynamicadaptation of applications.

To make a request for a function of a service, an application needs to knowthe service’s programmatic interface that defines a set of operations and their in-put/output messages and/or faults.3 An application can invoke an operation ofa service in a number of ways, including static invocation using a statically com-piled stub for a specific interface as in CORBA, a dynamically generated stub for aspecific interface as in Java RMI, or a statically generated but adaptive stub for in-terfaces with similar signatures as in [Nagano et al. 2004]; and dynamic invocationsuch as DII (Dynamic Invocation Interface) and stubless message-driven invoca-tion [Leitner et al. 2009]. Among them, we assume that an application is writtenusing the stub-based approach that is the most popular and well-supported wayof developing distributed applications. A stub acts as a local proxy for a remoteservice and makes a remote operation invocation as similar and simple as possibleto a local invocation.

Due to the spontaneity and heterogeneity of ubiquitous computing environments,the association or binding between an application and a service cannot be pre-determined, but rather it should be made dynamically at runtime. At design time,an application just specifies a set of requirements it expects from a target ser-vice. At runtime, an application finds a specific service instance that can fulfill itsrequirements from a service registry. It then makes a binding to the discoveredservice by instantiating a stub with the remote reference to the service. Unfortu-nately, however, such a late binding between an application and a service is subjectto constant change. There are at least three causes of such change. First, anapplication’s requirements to its target service can vary. Second, the degree of aservice’s fulfillment of the requirements can also vary. Third, an application canencounter new service that have a better degree of fulfillment to its requirements.All these types of causes may make a currently bound service of an applicationunusable or at least non-optimal in terms of the application’s requirements andthus force an application to replace the current service with a better one availablein the environment.

Based on the discussion above, we can now specifically define an application’sself-adaptive behaviors as those that are responsible for automatically performingdynamic rebinding of its target services in response to changes in the services’fitness to its requirements. By restricting the allowable types of an application’smodification to just rebinding of services, we can substantially simplify the engi-neering of self-adaptive behaviors. Specifically, application developers only need

tions that an application can make a request and an implementation entity or service provider

that performs those functions responding to an application’s requests. For brevity, we do not

differentiate between these meanings if they can be inferred from context.3For these terms, we follow the convention of WSDL (Web Service Definition Language) 2.0 [Chin-

nici et al. 2007].

12 · K. Lee et al.

to specify what requirements an application imposes on its services and how thedegree of a service’s fulfillment of those requirements can be measured. Given sucha specification, an underlying framework can dynamically update the bindings toservices adapting to changes on behalf of applications. Note that this assumptionmay limit the applicability of our self-adaptation model, but we believe it is a rea-sonable assumption for the class of general ubiquitous computing applications. Wediscuss more on this issue later in Section 5.

4. SELF-ADAPTATION MODEL

In this section, we present a comprehensive self-adaptation model that providesa simple yet flexible way of specifying diverse types of self-adaptive behaviors forubiquitous computing applications. We choose to adopt an external and declara-tive model in favor of its simplicity over the flexibility offered by an internal andprogrammatic model. More specifically, in our model, self-adaptive behaviors arespecified in the form of the so-called self-adaptation policies. A self-adaptation pol-icy is concerned with automatic and dynamic rebinding of a target service that anapplication is supposed to interact with. It determines not only when to performthe rebinding of the application’s current service but also how to select the bestamong many alternative services. Thus, the whole self-adaptive behaviors of anapplication are governed by a number of self-adaptation policies for each individualtarget service of the application.

A self-adaptation policy includes a set of requirements that an application expectsfrom its target service. Each of these requirements has a dimension that identifiesa specific type of context it is concerned with. To enable a concise specification ofeven non-trivial and dynamic context types, we propose a simplified form of theRDF query to identify a specific type of context associated to a requirement Arequirement also has a utility function that assigns a scalar utility value to everypossible in the domain of its dimension. We define a few types of utility functionsthat are flexible enough to capture many different patterns of utility value distri-butions while not imposing an undue burden on eliciting and processing utilityvalues. Two more values associated with each requirement are a threshold repre-senting the minimum utility value that the application can accept or tolerate and aweight reflecting how much the application cares about this requirement relative toothers. These values enable application developers to easily control the degree ofstrictness and the relative importance of requirements by adjusting the thresholdsand weights.

In the rest of this section, we first describe the proposed model in a formal anddetailed way and then present an XML-based specification language for our model.

4.1 Formalizing Self-Adaptation Policies

Now let us formally define self-adaptation policies. For simplicity’s sake and withoutloss of generality, let us assume that an application is supposed to interact withonly one target service.

Definition 1. A self-adaptation policy consists of n requirements {r1, r2, . . . , rn}that an application expects from its target service. Each requirement ri (1 ≤ i ≤ n)is defined as a quadruple 〈di, ui, θi, ωi〉 where


(1) di is a dimension that identifies what type of context is associated with thisrequirement;

(2) ui : Dom(di) → (0, 1] is a utility function that assigns a scalar utility valuebetween 0 (exclusive) and 1 (inclusive) to each possible value in the domainDom(di) of the requirement’s dimension;

(3) θi ∈ [0, 1] is a threshold representing the minimum utility value that the appli-cation can accept or tolerate with respect to the requirement; and

(4) ωi ∈ [0, 1] (∑ni=1 ωi = 1) is a weight reflecting how much the application cares

about the requirement relative to others.

We can then formalize the notion of the overall utility of a specific service withrespect to a self-adaptation policy as follows.

Definition 2. Let p be a self-adaptation policy that consists of n requirements{r1, r2, . . . , rn}, and let s be a service that has a set of context values {v1, v2, . . . , vn}where each value vi represents the service’s context corresponding to the dimensionof requirement ri. The overall utility of service s with respect to self-adaptationpolicy p, denoted as U(s; p), is given by

U(s; p) =

[ n∏i=1

H(ui(vi)− θi

)][ n∑i=1

ωi · ui(vi)]

(1)

and where H(x) is the right-continuous Heaviside function, or unit step functionwhose value is 0 if x < 0, and 1 otherwise.

The above definitions entail both detection and modification policies and thusenable the unified and integrated specification of self-adaptation policies. Specifi-cally, we can reify the four adaptation processes of the self-adaptation loop in termsof the above definition. First, the monitoring and analyzing processes for detectingchanges are defined as follows.

Definition 3. Let p be a self-adaptation policy of an application and s a servicethat is currently bound to and used by the application. The monitoring processshould observe changes in the service’s context corresponding to the dimensionsof requirements in p and notify the analyzing process of any changes. Then theanalyzing process should check whether U(s; p) becomes equal to zero wheneversuch a change occurs and triggers the deciding process.

Only the product term of Equation 1 matters to the detection phase. Let usconsider a specific requirement, say, ri of the self-adaptation policy. If the service’scontext value vi corresponding to ri changes due to any reasons, then the utilityvalue ui(vi) might subsequently change. If the changed utility value falls below thecorresponding threshold θi, then H (ui(vi)− θi) becomes equal to zero. This wouldconsequently make the overall utility of the service equal to zero. As such, anyrequirement that cannot be fulfilled by the current service results in the triggeringof the application’s modification. Note that the summation term of Equation 1 isalways larger than 0 because by definition all ui cannot be equal to zero.

Second, we can define the deciding and executing processes for modifying appli-cations as follows.

14 · K. Lee et al.

Definition 4. Let p be a self-adaptation policy of an application and let S be aset of services available for the application’s target service. The deciding processshould select the best alternative service a∗ that has the maximum overall utilitywith respect to p, i.e.,

a∗ = argmina∈S

U(a; p).

Then the executing process should perform the rebinding from the current serviceto the selected alternative a∗.

Central to the modification phase is to compare possibly many similar alternativeservices. The summation term of Equation 1 plays a key role in this phase as itprovides a relative estimate how a specific service is useful or desirable as a targetservice of an application.

4.1.1 Requirement Dimensions. A requirement’s dimension identifies a specifictype of context that is relevant to self-adaptation. As discussed above, we assumethat context information is described as RDF triples. To identify a specific context,we employ a simplified form of the SPARQL query [Prud’hommeaux and Seaborne2008], which consists of a set of triple patterns (〈sub, pred, obj〉). Here, each elementin a triple pattern can be variable (represented as string prefixed with ‘?’) or RDFliteral (represented as URI). We define two special variables: “?self” representingthe application itself and “?target” representing the target service. We allow twoquery forms: ASK that returns true if the query has a solution or SELECT thatreturns the specific value bound to the query variable. This enables a uniformspecification of different context types as well as a concise specification of evennon-trivial and dynamic context types. For example, the following shows an ASKquery for representing whether a target service is co-located with an application’suser.

PREFIX as: <http://as.kaist.ac.kr/>

ASK {?self as:usedBy ?user .

?user as:locatedIn ?loc .

?target as:locatedIn ?loc }

The following example shows a SELECT query for representing the degree of lossof an operation named “op1” of a target service.

PREFIX as: <http://as.kaist.ac.kr/>

SELECT ?loss

WHERE {?target as:hasOperation ?op .

?op as:hasName "op1" .

?op as:hasLoss ?loss }

We formally define the dimension of a requirement as follows.

Definition 5. A dimension of a requirement is defined as a pair d = (q, T ) whereq is a query variable and T is a set of triple patterns {t1, t2, . . . , tm}. Each triplepattern ti (1 ≤ i ≤ m) is defined as a triple 〈sub, pred, obj〉 where each of elementscan be either a query variable or a RDF literal.


Domain

Utility

1

x1

less-is-better

more-is-better

e

(a) Step utility functions

Domain

Utility

1

t1 t2

less-is-better

more-is-better

e

(b) Linear utility functions

Domain

Utility

1

t1 t2

less-is-better

more-is-better

e

(c) Sigmoid utility functions

Domain

Utility

e

1

t4t2t1 t3

(d) Piecewise-linear utility function

Fig. 2. Utility functions for the requirements with a numeric domain

4.1.2 Utility Functions. A utility function plays a central role in our model. Itassigns a scalar utility value to every possible value in the domain of a requirement’sdimension. The assigned utility value provides a formal and relative estimate ofhow useful or desirable each value of the dimension is. As usual, without loss ofgenerality, we encode utility values in the interval (0, 1] of the real numbers. Thehigher the utility value, the more useful or desirable the value of a requirement’sdimension.

A key issue here is how to define utility functions as there can be many differenttypes of utility functions. Our model only allows five types of utility functions,namely step, linear, sigmoid, piecewise-linear, and tabular. The first four of themare used for dimensions with a numeric domain and the last one is for dimensionswith an enumerated domain. We believe that these five types of utility functionsare flexible enough to capture many different patterns of utility value distributionswhile not imposing an undue burden on eliciting and processing utility values.

Let us look at each type of utility functions in turn. The most simplest oneis a step utility function. It is simply defined by only one threshold value thatdivide the domain space of a requirement’s dimension into two intervals, as shownin Figure 2(a). For the less-is-better dimensions such as latency, the utility valueis set to 1 if the context value is less than or equal to the threshold and a smallpositive constant ε, otherwise; and vice versa for the more-is-better dimensions suchas throughput. More formally, it is defined as follows.

16 · K. Lee et al.

Definition 6. A step utility function with one threshold x1, denoted as ustep(x;x1),is given by

ustep(x;x1) =

{α+ (1− α)ε, x ≤ x1αε+ (1− α), x > x1

where α is 1 for less-is-better dimensions and 0 for more-is-better dimensions, andε is an arbitrarily small positive constant.

The next simplest types of utility functions are linear and sigmoid utility func-tions, which are depicted in Figure 2(b) and 2(c). They are defined with twothreshold values. These thresholds divide the domain space into three intervals:(a) good-enough interval where the values are considered to be good enough andthus the utility value is set to 1; (b) unacceptable interval where the values cannotbe acceptable and thus the utility value is set to ε; and (c) tolerable interval wherethe values are tolerable,but only with limited satisfaction and thus the utility valuevaries from ε to 1. Note that the relative positions of these three intervals dependon the characteristics of the requirement’s dimension. In other words, the good-enough interval is in the leftmost position for the less-is-better dimensions but it isin the rightmost position for the more-is-better dimensions. The difference betweenlinear and sigmoid utility functions is in the way of calculating utility values in thetolerable interval.The former provide a linear interpolation but the latter a smoothinterpolation. They can be formally defined as follows.

Definition 7. A linear utility function with two thresholds x1 and x2 (x1 < x2),denoted as ulinear(x;x1, x2), is given by

ulinear(x;x1, x2) =

α+ (1− α)ε, x ≤ x1α+ (−1)α

( x− x1x2 − x1

), x1 < x < x2

αε+ (1− α), x ≥ x2where α is 1 for less-is-better dimensions and 0 for more-is-better dimensions, andε is an arbitrarily small positive constant.

Definition 8. A sigmoid utility function with two thresholds x1 and x2 (x1 < x2),denoted as usigmoid(x;x1, x2), is given by

usigmoid(x;x1, x2) =

α+ (1− α)ε, x ≤ x11 /

(1 + exp

((−1)α

(5(x2 + x1 − 2x)

x2 − x1)))

, x1 < x < x2

αε+ (1− α), x ≥ x2where α is 1 for less-is-better dimensions and 0 for more-is-better dimensions, andε is an arbitrarily small positive constant.

For more complex distribution of utility values for the dimensions with a numericdomain, we can use piecewise-linear utility functions. They are defined with a set ofpossibly many utility entries that explicitly assign utility values to some values of arequirement’s dimension. The utility values for the unspecified dimension values arecalculated through a linear interpolation between two adjacent entries. Figure 2(d)depicts a piecewise-linear utility function with four explicitly defined points. Thefollowing defines piecewise-linear utility functions formally.


Definition 9. A piecewise-linear utility function with a set of k entries {〈xi, yi〉}for i = 1, 2, . . . , k (∀i xi < xi+1 and yi ∈ (0, 1]), denoted as uplinear(x; {〈xi, yi〉}),is given by

uplinear(x; {〈xi, yi〉}) =

y1, x ≤ x1yi +

( yi+1 − yixi+1 − xi

)x, xi < x ≤ xi+1

yk, x > xk

Unlike the above four types of utility functions that are designed for numericdimensions, tabular utility functions are used for dimensions with an enumerateddomain. Tabular and piecewise-linear utility functions have both similarity and dif-ference. They are both defined with a set of possibly many entries, which explicitlydefine utility values for some values in the domain of a requirement’s dimension.But they differ in the way they obtain utility values for those that are not explicitlyspecified. While piecewise-linear utility functions use a linear interpolation, tabu-lar utility functions have a default utility value. This is used as utility value forthe dimension values that are not explicitly specified. A tabular utility function isformally defined below.

Definition 10. A tabular utility function with a set of k entries {〈xi, yi〉} fori = 1, 2, . . . , k (∀i yi ∈ (0, 1]) and a default utility value yd ∈ (0, 1], denoted asutabular(x; {〈xi, yi〉}, yd), is given by

utabular(x; {〈xi, yi〉}, yd) =

{yi, x = xiyd, x 6= xi ∀i

4.1.3 Thresholds and Weights. Specifying thresholds on the utility value spacemakes possible the integrated specification of the detection and modification poli-cies. Moreover, thresholds can be used to differentiate between soft requirementsand hard requirements. By soft requirements, we refer to those requirements thatdo not trigger any adaptation at all even if their utility values are very low. Soft re-quirements can be expressed in our model by just setting the corresponding thresh-old to 0. It makes H always be equal to 1 and thus keeps the overall utility intact.

On the other hand, hard requirements trigger adaptation whenever they cannotbe fulfilled. We express such requirements by setting the threshold to a value greaterthan 0. If we set the threshold to 1, then H evaluates always to 0 except when theutility value is 1, making the requirement very strict. But we can relax the degreeof strictness by lowering the threshold value.

4.1.4 Aggregate Requirements. A requirement imposed on a service can be ofeither simple requirement or aggregate requirement. An aggregate requirementconsists of one or more other requirements, each of which is either a simple oraggregate requirement. This enables application developers to flexibly define theirrequirements and thus self-adaptation policies, as well. While a simple requirementcaptures only a specific context of a service, an aggregate requirement can be usedto define a self-adaptation policy involving several requirements together.

Definition 11. An aggregate requirement is defined as a set of m requirements{r1, r2, . . . , rm} where each ri is a simple or aggregate requirement; and its utility

18 · K. Lee et al.

SAP Container

Requirement Dimension

UtilityFunction

Service Requirement

SAPolicy

Utility EntryTriple Pattern

Fig. 3. The component diagram of SAPL

function is given by

uaggr(x; {ri}) =

[ m∏i=1

H(ui(x)− θi

)][ m∑i=1

ωi · ui(x)

]where H(x) is the right-continuous Heaviside function, or unit step function whosevalue is 0 if x < 0, and 1 otherwise; and ui, θi, and ωi are utility function, threshold,and weight corresponding to each sub requirement ri, respectively.

4.2 Specifying Self-Adaptation Policies

Having described the formal semantics of self-adaptation policies, we now presentSelf-Adaptation Policy Language or SAPL, which is an XML-based language forspecifying self-adaptation policies. SAPL specifies self-adaptation policies usinga number of constructs that facilitate the reuse of policy specifications and pro-mote separation of concerns. We refer to these constructs as SAPL components.Each component has a set of properties that correspond to different aspects ofself-adaptation policies. As the root-level component, SAP Container is a containercomponent for the four types of top-level components, namely, Requirement Dimen-sion, Utility Function, Service Requirement, and SAPolicy. These top-level compo-nents may contain other nested components, e.g., Utility Entry and Triple Pattern.These SAPL components and their properties collectively describe the conceptualmodel of SAPL which is referred to as the SAPL component model and illustratedin Figure 3.

We choose XML [Bray et al. 2008] as the concrete representation format forSAPL components. SAPL Infoset model that defines SAPL in terms of the XMLInformation Set (or simply XML Infoset) [Cowan and Tobin 2004]. For example,a SAPL document consists of a sapl element that includes as its children oneor more utility, dimension, requirement, and policy elements4. There is a

4For brevity, we often use the shortened terms like “element” and “attribute” interchangeably


<sapl targetNamespace="xs:anyURI" >

[ <import /> | <include /> ]*

[ <dimension /> | <utility /> | <requirement /> | <policy /> ]*

</sapl>

Fig. 4. The XML syntax of the sapl element

correspondence between the component model and the Infoset model of SAPL. Inother words, the SAP Container, Requirement Dimension, Utility Function, Service Re-quirement, and SAPolicy components correspond to the sapl, dimension, utility,requirement, and policy elements, respectively.

The types and constraints of these elements are defined in the SAPL schema thatis specified using the XML Schema definition language [Thompson et al. 2004]. Un-fortunately, however, this schema cannot be used to fully validate SAPL documents,because it cannot capture—or does not capture intensionally for simplicity—someof the constraints that a SAPL document must follow. Thus, a valid SAPL docu-ment should not only be valid according to the SAPL schema but also adhere toall the constraints described in this section.

In the following subsections, we describe the major components of SAPL bypresenting their XML syntax with examples. Although the XML schema definitionis more formal and rigorous specification for XML syntax, we use, for brevity, BNF-style conventions that is introduced in the WSDL specification [Chinnici et al. 2007].For convenience, we summarize here the conventions:

—“?”, “*”, and “+” denote optionality (i.e. zero or one occurrences), zero or moreoccurrences, and one or more occurrences, respectively.

—“[” and “]” are used to form groups and “|” is used to represent choices.

—Attributes and elements with simple content are conventionally assigned a valuewhich corresponds to their type.

4.2.1 The SAP Container Component. The SAP Container component is usedto group a set of related top-level SAPL components. It is represented in XMLby the sapl element. Figure 4 shows its XML syntax. The sapl element hasone required attribute: targetNamespace of type xs:anyURI, which defines thenamespace of the child elements defined within this sapl element. It has zero ormore child elements of different types, which should be ordered as follows:

—Zero or more include and import elements in any order; and

—Zero or more dimension, utility, requirement, and policy in any order.

SAPL provides two mechanisms for modularizing the specifications of those com-ponents, similarly to WSDL [Chinnici et al. 2007] and XML Schema [Thompsonet al. 2004]. First, we can use the include element to separate the specificationof SAPL components belonging to the same target namespace into multiple SAPLdocuments. Second, we can use the import element to enable components in a

for the XML Infoset’s lengthy terms like “element information item” and “attribute information

item”.

20 · K. Lee et al.


...

<include location="xs:anyURI" />*

<import namespace="xs:anyURI"

location="xs:anyURI"? />*

...

</sapl>

Fig. 5. The XML syntax of the include and import element


...

<dimension name="xs:NCName"?

base="xs:QName"?

qform="QueryKindType"?

qvar="xs:string"?>

<triple sub="union of xs:anyURI, xs:string"

pred="xs:anyURI"

obj="union of xs:anyURI, xs:string" />*

</dimension>*

...

</sapl>

Fig. 6. The XML syntax of the dimension element

target namespace to refer foreign components that belong to different namespaces.Figure 5 shows the XML syntax of both include and import element.

The SAP Container component in a SAPL document has a set of components thatare included in three different ways. First, they can be directly defined in the origi-nal document. Second, they can be included from a set of SAPL documents that areresolved by the location attribute of the include elements defined in the originaldocument. The components that are either directly defined or included should be-long to the same target namespace. Finally, they can be imported from other SAPContainer components having the same target namespace as the namespace at-tribute of the import elements defined in the original document. Components thatare imported from other SAP Container components have different target namespacefrom that of the importing SAP Container component. SAPL dose not make anydistinction between these components. Note that each named SAPL component ofthe same kind must be uniquely identified by its qualified name. Thus, QNames ofcomponents of a specific kind in the same target namespace must be unique.

4.2.2 The Requirement Dimension Component. The Requirement Dimension com-ponent is used to specify the specific type of context. Its XML representation isthe dimension element whose syntax is depicted in Figure 6. The dimension ele-ment has four optional attributes: qform, qvar, name, and base. First, the qvar

attribute specifies a query variable for this dimension. Second, the value of the



...

<utility name="xs:NCName"?

base="xs:QName"?

type="UtilityTypeType"?

style="UtilityStyleType"?

default="UtilityValueType"?>

<entry x="union of xs:float, xs:string"

y="UtilityValueType"? />*

</utility>*

...

</sapl>

Fig. 7. The XML syntax of the utility element

qform attribute can be one of the following enumeration: ask for the ask queriesthat return a boolean value indicating whether a graph pattern exists or not; andselect for the select queries that return the value of the query variable specifiedusing the qvar attribute. The default value for the qform attribute is ask if qvaris specified; or select otherwise.

The name and base attributes are used for reference. More specifically, dimensionelements can be assigned an optional name attribute of type NCName. This name

attribute allows other elements to just refer to a predefined dimension element byspecifying the QName of the latter as the value for the base attribute the former.

The dimension element has as its children more than one triple elements, whichis an XML representation of the Triple Pattern component. The triple elementhas three required attributes: sub, pred, and obj, each of which represents thesubject, predicate, and object of a RDF triple. Their type is either xs:anyURI orxs:string. A string ending with a question mark (“?”) represents a variable.

4.2.3 The Utility Function Component. The Utility Function component is usedto define a utility function. It has one or more Utility Entry components as itschildren. It is represented in XML by the utility element whose syntax is illus-trated in Figure 7. The utility element has five optional attributes: type, style,default, name, and base. The type and style attributes specify the type of utilityfunctions. First, the value of the type attribute can be one of the following enumer-ation: step for step utility functions, linear for linear utility functions, sigmoidfor sigmoid utility functions, plinear for piecewise-linear utility functions, and fi-nally tabular for tabular utility functions. Second, the style attribute can specifyone of the following enumeration values: less for less-is-better utility functions,more for more-is-better utility functions, and custom for other utility functions.Note that there is a constraint on specifying these two attributes, which is notcaptured in the XML syntax and the SAPL schema. Specifically, the value of thestyle attribute of piecewise-linear and custom utility functions is fixed to custom.On the other hand, the other three kinds of utility functions can have either less

or more as the value of the style attribute.The default attribute is used to define a default utility value that is used as

22 · K. Lee et al.


...

<requirement name="xs:NCName"?

base="xs:QName"?

threshold="ThresholdType"?

weight="WeightType"?>

[ [ <dimension />? <utility />? ] | <requirement />+ ]

</requirement>*

...

</sapl>

Fig. 8. The XML syntax of the requirement element

utility values for those dimension values that are not explicitly specified. Note thatthe default attribute is only applicable to tabular utility functions and can besafely ignored for other types of utility functions.

The name and base attributes are used for either reference or inheritance. Morespecifically, utility elements can be assigned an optional name attribute of typeNCName. First, this name attribute allows one utility element to just refer toanother utility element by specifying the QName of the latter as the value forthe base attribute the former. This enables the definitions of utility functions tobe reusable. Second, one can define a new utility function by inheriting from anexisting one by the same manner. The newly defined utility element overridesthe attribute values such as default. How the inheritance works depends on thekind of utility functions.

Now let’s have a look at the child elements of utility, i.e., the entry element,which is an XML representation of the Utility Entry component. The utility

element can have one or more entry elements as its children. The entry elementis used for two purposes according to the type of utility functions. For step, linear,and sigmoid utility functions, it is used for specifying thresholds while for piecewise-linear and tabular utility functions, it is used for representing explicit utility values.When used as thresholds, its x attribute only matters and its y attribute is justignored. On the other hand, when used as explicit utility values, both attributesmatters. So if the value of x attribute is omitted, then the value of the default

attribute in the utility element is used. Note also that the type of x attributeshould be xs:float for utility functions with a numeric domain but xs:string forthose with an enumerated domain.

The allowable number of child elements also depends on the type of utility func-tions. Step utility functions have only one threshold while linear and sigmoid utilityfunctions have two thresholds. Piecewise-linear and custom utility functions canhave possibly many utility entries. Here, inheritance is useful for those utilityfunctions that require lots of utility entries.

4.2.4 The Service Requirement Component. The Service Requirement compo-nent represents a requirement that an application expects from its target service.It is represented by the requirement element whose XML syntax is depicted in Fig-ure 8. The requirement element has four optional attributes: threshold, weight,



...

<policy name="xs:NCName"

base="xs:QName"?>

<requirement />+

</policy>*

...

</sapl>

Fig. 9. The XML syntax of the policy element

name, and base. The threshold and weight attribute specifies the threshold andweight for this requirement, both of which are a real value between 0 (exclusive)and 1 (inclusive). The name and base attributes are used for reference, similarly asthose of the dimension element.

A requirement element can be either simple or complex. A simple requirementhas as its children the dimension and utility element while an aggregate require-ments has one or more other requirements.

4.2.5 The SAPolicy Component. Finally, the SAPolicy component representinga self-adaptation policy consists of a set of Service Requirements. Figure 9 shows thesyntax of its XML representation, policy element. The policy element a requiredname attribute and an optional extends attribute. It has one or more requirementelements as its children. If its base attribute is specified, then it inherits from thepolicy identified by the specified QName. In other words, the policy will contain aset of requirements specified in the inherited policy as well as those specified in theinheriting policy.

5. DISCUSSION

In this section, we first describe how our proposed model can specify diverse typesof self-adaptation policies. Then we discuss the benefits and limitations of ourmodel compared to the existing approaches.

5.1 SAPL Examples

The examples are taken from the Active Surroundings project where we have de-signed and implemented a middleware infrastructure for multi-user heterogeneousubiquitous computing environments [Lee et al. 2004]. We built a few test-bedubiquitous computing environments including a home and a gym, where severalPhidgets sensors such as pressure-, touch-, light-sensor, etc., were deployed to cap-ture various context changes; and the UbiSense location system and several RFIDreaders and tags were used to track the location of users.

We developed a ubiquitous multimedia player application called UbiMP, whichallows a user to watch and listen live video and audio stream from P2P live stream-ing services such as IPTV (Internet Protocol Television) or personal broadcastingservices. Although running on a wireless-enabled mobile device, e.g., a PDA or asmart phone, UbiMP is designed to exploit not only the screen and earphone of

24 · K. Lee et al.

At Home On the Way to Gym At Gym

Fig. 10. The UbiMP application that uses different services in different environments

its mobile device, but also any suitable display or audio devices5 that are availablein the user’s current location. UbiMP also tries to adjust the lighting level duringplaying a media stream according to its user’s preference by controlling a light bulbnearby the user. For several non-networked appliances such as TV, audio, andlight controller, we developed software proxy services that can control the actualappliances through IR or X10 signals in response to a request from an application.And thus we assume that all the devices are network-enabled and thus can connectto each other through various network technologies such as WiFi, Bluetooth, orZigbee.

UbiMP automatically reconfigures itself to use different services at a particulartime and space, adapting to changes in its context such as its location and itsservices’ quality or availability. The following scenes demonstrate various needs forself-adaptation of UbiMP (See Figure 10).

Scene 1 (At Home). Seated on the couch in the living room, she decides towatch live TV with UbiMP on her mobile device. Among the channels listed up onUbiMP, she selects a channel that shows a big tennis event. Then, UbiMP needsto find a set of services required for playing the selected media stream and control-ling the lighting level. Typically, there are multiple services capable of providingthese functions including displays, audios, and lights available at home as well asthe mobile device itself. Based on several factors like location, display size, audioquality, etc., UbiMP decides to play video on a large PDP display in front of thecouch and audio through a high-end speaker in the living room. It also adjusts thelighting level in the living room to her favorite one, say “dimming level 3” using adimmable light bulb on the ceiling.

Scene 2 (On the Way to Gym). After a while, she realizes that she has togo to a gym to exercise. As she moves away from her home, services that UbiMP

5Note that we assume that these hardware devices expose their capabilities as software services.Also, we do not distinguish explicitly between services and devices and thus use the terms “service”

and “device” interchangeably.


is currently using become unavailable. UbiMP automatically detects such changeand then switches to play video and audio on the mobile device’s small screen andearphone, respectively, so that she can still watch the tennis event while on her wayto a gym. Halfway to the gym, unfortunately, the quality (e.g., latency) of the mediastream that she watches drops significantly due to various reasons in the networkand/or the stream source. Such change triggers the application to re-select and re-connect to another stream source that shows the same tennis event with better or atleast acceptable quality. Moreover, sometimes, a stream source is likely to becomeunavailable when the owner of the stream stops broadcasting. In this case, UbiMPshould also automatically reconnect to another stream source.

Scene 3 (At Gym). Arriving at a gym, she starts to work out on a stair step-ping machine. UbiMP now detects many LCD screens, low-end speakers, and light-ing devices installed above every aerobic exercise equipment in the gym. By compar-ing such alternatives, UbiMP automatically reconfigures itself to use a LCD screenand a speaker above the machine she is on. It also uses a simple light to adjust thelighting level nearby her even though the light does not support dimming control.

We emphasize that the above scenario reveals the diversity of self-adaptive be-haviors that are typical for a large class of ubiquitous computing applications. Letus look into more detail. As mentioned before, traditional enterprise and Internet-based applications are only concerned about system-level context such as availableprocessors, network capacity, QoS and failure. On the other hand, ubiquitous com-puting applications regard physical or social context as well as partial failures asan important stimulus for self-adaptation. As in the scenario above, whenever auser changes its location, an application should find and use an alternative ser-vice. Moreover, a gym has only a simple light service that is a partial alternativefor a dimmable light service at home because it does not provide a dimming con-trol function. Similarly, the high-end speaker in the living room and the low-endspeaker on the stair stepping machine may have different interfaces, akin to theway there are a number of infrared remote control protocols for televisions fromdifferent manufacturers. In summary, ubiquitous computing applications require avariety of self-adaptive behaviors that involve different types of requirements in-cluding functional and non-functional requirements. Non-functional requirementsconcern not only QoS-related context such as latency, throughput, etc., but alsonon-QoS-related context such as location, activity, etc.; and functional requirementscan be either fine-grained such as partial failures or coarse-grained such as totalfailures.

Now let us look at how these different types of requirements can be specified in ourmodel. The following example shows how coarse-grained functional requirementsare specified in SAPL. The requirement has “r light intf” as its name, 1 as itsthreshold, and 1 as its weight. It also has a dimension and utility elementas its children. The dimension element checks whether a target service has the“DimmableLightInterface” interface and returns true if it is, false otherwise. Theutility element has two entries: one assigns 1 to the dimension value of true andthe other assigns 0 to the dimension value of false.

<?xml version="1.0" encoding="utf-8" ?>

26 · K. Lee et al.

<sapl xmlns="http://as.kaist.ac.kr/sapl"

xmlns:as="http://as.kaist.ac.kr"

targetNamespace="http://as.kaist.ac.kr/apps/UbiMP">

....

<requirement name="r_light_intf" threshold="1.0"

weight="1.0">

<dimension qform="ask">

<triple sub="?target" pred="as:hasInterface"

obj="?intf">

<triple sub="?intf" pred="as:hasName"

obj="DimmableLightInterface">

</dimension>

<utility type="tabular">

<entry x="true" y="1.0">

<entry x="false" y="0.0">

</utility>

</requirement>

....

</sapl>

The second requirement is concerned with a fine-grained functional requirement.More specifically, it considers the loss of an operation named “setDimLevel”. Inthis example, the dimension and utility element are defined as a top-level, i.e.,direct children of the root element, so they can be reused in any other elements.Its dimension element specifies the probability of loss that a target service cannotsupport the “setDimLevel” operation. If a target service does not provide thisoperation, then the loss is 1. If a target service fully supports this operation, thenthe loss is 0. For the partially-fulfilled services, the loss is a real value between 0and 1. The utility element specifies a less-is-better, step utility function whosethreshold is 0.5. Thus, the utility is 1 if the loss is less than or equal to 0.5 and 0otherwise.





....

<dimension name="d_loss_setdimlevel" qform="select"

qvar="?loss">

<triple sub="?target" pred="as:hasOperation"

obj="?op">

<triple sub="?op" pred="as:hasId" obj="setDimLevel">

<triple sub="?op" pred="as:hasLoss" obj="?loss">

</dimension>

<utility name="u_loss_setdimlevel" type="step"

style="less">

<entry x="0.5">

</utility>

<requirement name="r_loss_setdimlevel" threshold="0.0"

weight="1.0">


<dimension base="d_loss_setdimlevel" />

<utility base="u_loss_setdimlevel" />

</requirement>

....

</sapl>

Now the following requirement is arguably the most common in ubiquitous com-puting applications. It represents that a service should be co-located with an ap-plication’s user. This requirement is re-used in the several policies of UbiMP withrespect to its display, audio, and light service.





...

<dimension name="d_coloc" qform="ask">

<triple sub="?self" pred="as:usedBy" obj="?user">

<triple sub="?user" pred="as:locatedIn" obj="?loc">

<triple sub="?target" pred="as:locatedIn" obj="?loc">

</dimension>

<utility name="u_coloc" type="tabular">

<entry x="true" y="1.0">

<entry x="false" y="0.0">

</utility>

<requirement name="r_coloc" threshold="1.0" weight="1.0">

<dimension base="d_coloc" />

<utility base="u_coloc" />

</requirement>

....

</sapl>

We can also represent a requirement that a service should be located in a specificlocation, say a room ”F619”, as shown in the following example.

<dimension name="loc" qform="ask">

<triple sub="?target" pred="as:locatedIn" obj="F619">

</dimension>

The following examples show how QoS-related requirements can be specified inSAPL. First, “d latency”, “u latency”, and “r latency” represent the dimension,utility function, and requirement that is concerned with the latency of a mediastreaming service. The utility element represents a sigmoid utility function thathas two threshold entries. The utility value becomes equal to 1, if the latency isshorter than 50ms; 0 if the latency is longer than 200ms; and a real value interpo-lated with a sigmoid function if the latency is between 50ms and 200ms.



28 · K. Lee et al.



...

<dimension name="d_latency" qform="select"

qvar="?latency">

<triple sub="?target" pred="as:hasLatency"

obj="?latency">

</dimension>

<utility name="u_latency" type="sigmoid" style="less">

<entry x="50">

<entry x="200">

</utility>

<requirement name="r_latency" threshold="0.5"

weight="1.0">

<dimension base="d_latency" />

<utility base="u_latency" />

</requirement>

....

</sapl>

Second, “d bitrate”, “u bitrate”, and “r bitrate” are for the requirement aboutthe bitrate of a media streaming service. In this example, the utility elementrepresents a linear utility function. Its utility value becomes equal to 1, if thebitrate is larger than 1000kbps; 0 if the bitrate is less than 300kbps; and a realvalue interpolated with a linear function if the bitrate is between 300kbps and1000kbps.





...

<dimension name="d_bitrate" qform="select"

qvar="?bitrate">

<triple sub="?target" pred="as:hasBitrate"

obj="?bitrate">

</dimension>

<utility name="u_bitrate" type="linear" style="more">

<entry x="300">

<entry x="1000">

</utility>

<requirement name="r_bitrate" threshold="0.7"

weight="1.0">

<dimension base="d_bitrate" />

<utility base="u_bitrate" />

</requirement>

....

</sapl>

The following example demonstrates how to represent an aggregate requirement.The requirement named “r vquality” consists of two simple requirements defined


above: “r latency” and “r bitrate”. If the weighted sum of utility values of thesetwo requirements falls below the threshold of 0.5, then the currently used mediastreaming service needs to be replaced with another.





...

<requirement name="r_vquality" threshold="0.5"

weight="1.0">

<requirement base="r_latency" />

<requirement base="r_bitrate" />

</requirement>

....

</sapl>

Finally, the following example shows a self-adaptation policy that consists of twosimple requirements. One is a functional requirement, “r light intf” and the otheris a non-functional requirement, “r coloc”.





...

<policy name="light">

<requirement base="r_light_intf" weight="0.5" />

<requirement base="r_coloc" weight="0.5" />

</requirement>

...

</sapl>

5.2 Analysis

As demonstrated above with several examples, our self-adaptation model has sev-eral salient features that contribute to the simplicity and flexibility, compared toexisting approaches. Table 5.2 succinctly summarizes the features and benefitsof our model and Table 5.2 compares our model with other three utility-basedspecification approaches: Aura [Sousa et al. 2006], Gaia [Ranganathan 2005], andMADAM [Geihs et al. 2009].

As mentioned before, ubiquitous computing applications require diverse types ofself-adaptive behaviors that are related to different types of requirements includingfunctional and non-functional requirements. Non-functional requirements can beeither QoS-related or non-QoS-related context; and functional requirements can beeither fine-grained or coarse-grained. To address the flexibility and simplicity, aself-adaptation model should support the specification of self-adaptation policiesinvolving these types of requirements. Moreover, it should allow the concise spec-ification of requirement dimensions involving complex and dynamic context types;

30 · K. Lee et al.

Table I. Features and benefits of the proposed modelFeatures Benefits

Utility-based representation Unified specification and treatment of different types ofrequirements

Thresholds on utility values Integrated specification of both detection modificationpolicies

Simplified RDF query Concise specification of even non-trivial and dynamic con-

text types

Five types of utility functions Flexible and compact specification of utility functions

Aggregate requirements Flexible and hierarchical grouping of the related require-

ments

Table II. Comparison with other utility-based specification approachesAura Gaia MADAM Proposed Model

Coarse-grained functional requirements√ √ √ √

Fine-grained functional requirements ×√

×√

QoS-related non-functional requirements√ √ √ √

Non-QoS-related non-functional requirements ×√ √ √

Complex, dynamic context types × × ×√

Compact utility functions√

× ×√

Aggregate requirements × × ×√

allow the compact specification of utility functions; and allow aggregation of relatedrequirements.

First, our model represents self-adaptation polices using utility functions, andthus enables a unified specification and treatment of different types of require-ments on target services. It can specify not only coarse-grained functional require-ments but also fine-grained functional requirements. It can also specify various non-functional requirements including QoS-related ones and non-QoS-related ones. Onthe other hand, existing utility-based approaches are mainly concerned with coarse-grained functional requirements and QoS-related non-functional requirements. InAura, a user task’s functional requirement is expressed using a supplier preference,which explicitly assigns a utility value for each possible alternative supplier. Thisrequires intensive user involvement to distinguish between many similar alterna-tives. Aura also does not provide a way of specifying non-QoS-related requirementsuch as co-location of a service and a user. In Gaia, task parameters are used tospecify the requirements for a user task. The optimal value for each parameteris obtained through semantic discovery process, which can distinguish between se-mantically similar entities. MADAM only allows the replacement of componentimplementations having the same type or interface.

Second, our model uses thresholds that are defined over utility values, and thusenables an integrated specification of both detection policies and modification poli-cies. However, existing approaches uses utility functions for only defining mod-ification policies, i.e., how to select the best alternative service among multiplealternatives. For example, Aura and Gaia rely on explicit triggering from users orapplications; and MADAM assumes a fixed policy that always triggers adaptationwhenever a change occurs.


Third, our model adopts a simplified form of the RDF query to identify a specifictype of context associated to a requirement. It enables a concise specificationof even non-trivial and dynamic context types, e.g., the context information thatrepresent whether a service is physically co-located with a user using an application.Representing such a complex and dynamic requirement using existing approaches isnot trivial because they identify a specific context or property using just the simplename of the context.

Fourth, our model defines a few types of utility functions that are flexible enoughto capture many different patterns of utility value distributions while not imposingan undue burden on eliciting and processing utility values. Aura also define twotypes of utility functions that are included in our model. Gaia and MADAM do notimpose any restriction on the form of utility functions, possibly making it complexto define utility functions.

Fifth, our model allows application developers to specify an aggregate requirementthat consists of one or more other requirements. It enables a flexible and hierarchicalgrouping of the related requirements. On the other hand, Aura only allows alinear combination of utility values over multiple requirements. Gaia chooses themost important requirement among others and compares alternatives using theselected requirement. In MADAM, application developers can define a complexutility function that flexibly combines utility values of different requirements.

The above benefits of our model are mostly come from the assumption that aservice-based application can modify its structure and behavior only through dy-namic rebinding of its constituent services. In other words, modifications of service-based applications are only performed by replacing one or more of its constituentservices with others available in the environment.

This assumption can be justified by showing that other types of modificationsare neither feasible nor useful for service-based applications in ubiquitous com-puting environments. According to McKinley et al. [2004a] and Andersson et al.[2009], we can roughly differentiate between four types of modifications: coarse-grained compositional, fine-grained compositional, coarse-grained parametric, andfine-grained parametric modifications. Dynamic rebinding of services can be con-sidered as coarse-grained compositional modification because it changes the overallstructure of an application by replacing one or more services with another.

Among other three types of modifications, the fine-grained compositional mod-ification, e.g., addition of a new operation to a service, would not be feasible be-cause a service-based application does not own its constituent services and thus itcannot control or modify them in its own right. Second, the fine-grained paramet-ric modification, e.g., change of parameters determining the behavior of services,would be possible, but only provided that services implement and export somemeta-level operations that modify their internal behaviors. Moreover, this typeof modification requires application developers to know too low-level details suchas what meta-level operations are supported by each and every service and howthey should be exploited to modify an application in response to a specific change.Fortunately, fine-grained parametric modification can be implemented using com-positional modification as does MADAM, although the cost of developing and ex-ecuting self-adaptive applications may increase sharply if there are a large number

32 · K. Lee et al.

of parameters to consider. Third, the coarse-grained parametric modification, e.g.,selection of pre-defined or pre-configured structure of an application, would be toolimited to be useful regarding the spontaneity and heterogeneity of ubiquitous com-puting environments. In other words, it is simply impossible or at least tedious toprepare an application’s configurations that best fit to all the possible situations.

The assumption can be further justified by the fact that dynamic rebinding ofservices embodies different cases of coarse-grained compositional modification orjust reconfiguration. Hofmeister [1993] distinguished three cases of an application’sreconfigurations that are the component implementation change, logical structurechange, and geometrical (physical) structure change. Dynamic rebinding of servicesmay result in one or more of these cases, but not the other way around. For example,Li et al. [2005] formulate and solve the problem of determining the optimal (re-)deployment of services into machines. This kind of work that is concerned withspecific cases, i.e., geometrical change here, cannot handle other cases, aside fromthe fact that it is only possible if we can control the deployment of services on ourown rights.

Another implicit assumption in our model on the allowable types of modificationsis that there is no heterogeneity at the lower layers below the application layer. Ingeneral, we can distinguish at least four layers of computing systems: i.e., hardware,operation system, middleware, and application [McKinley et al. 2004a; 2004b]. Itis common practice in distributed systems research to address the issues at eachlayer independently by focusing on one layer and making reasonable assumptionson the other layers, although some seek to address cross layer issues such as conflictsamong adaptations performed at different layers [Di Nitto et al. 2008].

6. CONCLUSIONS

Self-adaptive applications are essential to realize the ubiquitous computing visionof invisibility and ubiquity despite the high spontaneity and heterogeneity of ubiq-uitous computing environments. Thus an important question is how to develop andexecute self-adaptive applications for ubiquitous computing environments. Despiteits importance, however, the engineering of self-adaptive service-based applicationsremains still a difficult and tedious task, inhibiting the wide and rapid proliferationof ubiquitous computing.

This article describes a self-adaptation model that facilitates the building of self-adaptive ubiquitous applications. We have shown how we design a self-adaptationmodel to provide a simple and flexible way of specifying self-adaptive behaviors forubiquitous computing applications. The proposed model represents self-adaptivebehaviors using self-adaptation policies. By representing self-adaptation policesusing utility functions, our model enables a unified specification of various self-adaptive behaviors involving different types of application requirements for services.By allowing application developers to specify thresholds on utility values, our modelenables an integrated specification of both detection and modification policies ofself-adaptive behaviors. We have presented a formal semantics and an XML-basedlanguage for the proposed self-adaptation model. With concrete examples, we haveshown that our model achieves high flexibility without a considerable loss of sim-plicity compared to the existing approaches. We believe that the proposed model


described in this article makes a significant step towards a more challenge prob-lem of unanticipated, proactive, and/or emergent self-adaptation. As future work,We are going to explore opportunities of applying machine learning techniques topersonalize self-adaptation policies.

REFERENCES

Andersson, J., de Lemos, R., Malek, S., and Weyns, D. 2009. Modeling dimensions of Self-

Adaptive software systems. In Software Engineering for Self-Adaptive Systems. Lecture Notes

in Computer Science, vol. 5525. 27–47.

Becker, C., Handte, M., Schiele, G., and Rothermel, K. 2004. PCOM - a component system

for pervasive computing. In Proceedings of the 2nd IEEE Annual Conference on PervasiveComputing and Communications. 67–76.

Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J., Nicklas, D., Ranganathan, A.,

and Riboni, D. 2010. A survey of context modelling and reasoning techniques. Pervasive andMobile Computing 6, 2 (Apr.), 161–180.

Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and Yergeau, F., Eds. 2008. Ex-

tensible Markup Language (XML) 1.0 (5th Edition). World Wide Web Consortium. Availableat http://www.w3.org/TR/REC-xml/.

Cervantes, H. and Hall, R. S. 2004. Autonomous adaptation to dynamic availability usinga service-oriented component model. In Proceedings of the 26th International Conference on

Software Engineering (ICSE 2004). IEEE Computer Society, 614–623.

Chen, H., Finin, T., and Joshi, A. 2003. An ontology for context-aware pervasive computingenvironments. The Knowledge Engineering Review 18, 3, 197–207.

Chen, H., Finin, T., and Joshi, A. 2004. Semantic web in the context broker architecture. In

Proceedings of the 2nd IEEE International Conference on Pervasive Computing and Commu-nications (PerCom 2004). IEEE Computer Society, 277–286.

Chen, H., Finin, T., and Joshi, A. 2005. The SOUPA ontology for pervasive computing. In

Ontologies for Agents: Theory and Experiences. 233–258.

Cheng, B., de Lemos, R., Giese, H., Inverardi, P., Magee, J., Andersson, J., Becker, B.,

Bencomo, N., Brun, Y., Cukic, B., Serugendo, G. D. M., Dustdar, S., Finkelstein, A.,Gacek, C., Geihs, K., Grassi, V., Karsai, G., Kienle, H., Kramer, J., Litoiu, M., Malek,

S., Mirandola, R., Muller, H., Park, S., Shaw, M., Tichy, M., Tivoli, M., Weyns, D.,

and Whittle, J. 2009. Software engineering for self-adaptive systems: A research roadmap.In Software Engineering for Self-Adaptive Systems. Lecture Notes in Computer Science, vol.

5525. Springer, 1–26.

Cheng, S. 2008. Rainbow: cost-effective software architecture-based self-adaptation. Ph.D. thesis,Carnegie Mellon University.

Chinnici, R., Moreau, J., Ryman, A., and Weerawarana, S., Eds. 2007. Web Services Descrip-

tion Language (WSDL) Version 2.0 Part 1: Core Language. World Wide Web Consortium.Available at http://www.w3.org/TR/wsdl20/.

Christopoulou, E. and Kameas, A. 2005. GAS ontology: An ontology for collaboration amongubiquitous computing devices. International Journal of Human-Computer Studies 62, 5, 664–

685.

Cowan, J. and Tobin, R., Eds. 2004. XML Information Set (2nd Edition). World Wide WebConsortium. Available at http://www.w3.org/TR/xml-infoset/.

David, P. and Ledoux, T. 2006. An Aspect-Oriented approach for developing Self-Adaptive frac-

tal components. In Proceedings of the 5th International Symposium on Software Composition(SC 2006). Lecture Notes in Computer Science, vol. 4089. Vienna, Austria, 82–97.

Dey, A. K. and Abowd, G. D. 1999. Towards a better understanding of context and Context-Awareness. Technical Report GIT-GVU-99-22, College of Computing, Georgia Institute of

Technology.

34 · K. Lee et al.

Di Nitto, E., Ghezzi, C., Metzger, A., Papazoglou, M., and Pohl, K. 2008. A journey

to highly dynamic, self-adaptive service-based applications. Automated Software Engineer-ing 15, 3, 313–341.

Dobson, S., Denazis, S., Fernandez, A., Gaiti, D., Gelenbe, E., Massacci, F., Nixon, P.,

Saffre, F., Schmidt, N., and Zambonelli, F. 2006. A survey of autonomic communications.ACM Transactions on Autonomous and Adaptive Systems 1, 2, 223–259.

Dustdar, S., Goeschka, K., Truong, H., and Zdun, U. 2009. Self-Adaptation techniques for

complex service-oriented systems. In Proceedings of the 5th International Conference on NextGeneration Web Services Practices (NWESP ’09). 37–43.

Edwards, W. and Grinter, R. 2001. At home with ubiquitous computing: Seven challenges. In

Proceedings of International Conference on Ubiquitous Computing (Ubicomp 2001). LectureNotes in Computer Science, vol. 2201. 256–272.

Elfatatry, A. 2007. Dealing with change: components versus services. Communications of the

ACM 50, 8, 35–39.

Feiler, P., Gabriel, R., Goodenough, J., Linger, R., Longstaff, T., Kazman, R., Klein, M.,Northrop, L., Schmidt, D., Sullivan, K., and Wallnau, K. 2006. Ultra-Large-Scale Sys-

tems: The Software Challenge of the Future. Software Engineering Institute, Carnegie Mellon

University.

Fleurey, F., Dehlen, V., Bencomo, N., Morin, B., and Jezequel, J. 2008. Modeling and

validating dynamic adaptation. In Proceedings of the 11th ACM/IEEE International Confer-

ence on Model Driven Engineering Languages and Systems (MoDELS 2008). Lecture Notes inComputer Science, vol. 5301. 97–108.

Floch, J., Hallsteinsen, S., Stav, E., Eliassen, F., Lund, K., and Gjorven, E. 2006. Using

architecture models for runtime adaptability. IEEE Software 23, 2, 62–70.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. M. 1994. Design Patterns: Elements of

Reusable Object-Oriented Software. Addison-Wesley Professional.

Garlan, D., Cheng, S., Huang, A., Schmerl, B., and Steenkiste, P. 2004. Rainbow:

Architecture-based self-adaptation with reusable infrastructure. Computer 37, 10, 46–54.

Geihs, K., Barone, P., Eliassen, F., Floch, J., Fricke, R., Gjorven, E., Hallsteinsen, S.,

Horn, G., Khan, M. U., Mamelli, A., Papadopoulos, G. A., Paspallis, N., Reichle, R., and

Stav, E. 2009. A comprehensive solution for application-level adaptation. Software: Practiceand Experience 39, 4, 385–422.

Grimm, R., Davis, J., Lemar, E., Macbeth, A., Swanson, S., Anderson, T., Bershad, B.,

Borriello, G., Gribble, S., and Wetherall, D. 2004. System support for pervasive appli-cations. ACM Transactions on Computer Systems 22, 4, 421–486.

Gu, T., Pung, H. K., and Zhang, D. Q. 2005. A service-oriented middleware for building

context-aware services. Journal of Network and Computer Applications 28, 1, 1–18.

Heineman, G. T. and Councill, W. T. 2001. Component-Based Software Engineering: Putting

the Pieces Together. Addison-Wesley Professional.

Hitzler, P., Krotzsch, M., Parsia, B., Patel-Schneider, P. F., and Rudolph, S. 2009. OWL

Web Ontology Language Primer. World Wide Web Consortium. Available at http://www.w3.

org/TR/owl2-primer/.

Hofmeister, C. R. 1993. Dynamic reconfiguration of distributed applications. Ph.D. thesis,

University of Maryland at College Park.

Huhns, M. N. and Singh, M. P. 2005. Service-oriented computing: key concepts and principles.

IEEE Internet Computing 9, 1, 75–81.

Kephart, J. and Chess, D. 2003. The vision of autonomic computing. IEEE Computer 36, 1,41–50.

Kindberg, T. and Fox, A. 2002. System software for ubiquitous computing. IEEE Pervasive

Computing 1, 1, 70–81.

Kramer, J. and Magee, J. 2007. Self-Managed systems: an architectural challenge. In Proceed-ings of 2007 Future of Software Engineering (FOSE ’07). IEEE Computer Society, 259–268.

Laddaga, R. 1997. Self-adaptive software. DARPA Broad Agency Announcement BAA 98-12.


Lee, D., Han, S., Park, I., Kang, S., Lee, K., Hyun, S. J., Lee, Y.-H., and Lee, G. 2004. A

group-aware middleware for ubiquitous computing environments. In Proceedings of the 14thInternational Conference on Artificial Reality and Telexistence. 291–298.

Leitner, P., Rosenberg, F., and Dustdar, S. 2009. Daios: Efficient dynamic web service

invocation. IEEE Internet Computing 13, 3, 72–80.

Li, Y., Sun, K., Qiu, J., and Chen, Y. 2005. Self-reconfiguration of service-based systems: a

case study for service level agreements and resource optimization. In Proceedings of 3rd IEEEInternational Conference on Web Services (ICWS 2005). Vol. 1. 266–273.

Manola, F. and Miller, E., Eds. 2004. RDF Primer. World Wide Web Consortium. Available

at http://www.w3.org/TR/rdf-primer/.

McKinley, P., Sadjadi, S., Kasten, E., and Cheng, B. 2004a. Composing adaptive software.

IEEE Computer 37, 7, 56–64.

McKinley, P., Sadjadi, S., Kasten, E., and Cheng, B. 2004b. A taxonomy of compositionaladaptation. Technical Report MSU-CSE-04-17, Michigan State University.

Morin, B., Barais, O., Nain, G., and Jezequel, J. 2009. Taming dynamically adaptive sys-

tems using models and aspects. In Proceedings of the 31st IEEE International Conference on

Software Engineering. IEEE Computer Society, 122–132.

Morin, B., Fleurey, F., Bencomo, N., Jezequel, J., Solberg, A., Dehlen, V., and Blair, G.2008. An Aspect-Oriented and Model-Driven approach for managing dynamic variability. In

Proceedings of the 11th ACM/IEEE International Conference on Model Driven Engineering

Languages and Systems (MoDELS 2008). Lecture Notes in Computer Science, vol. 5301. 782–796.

Nagano, S., Hasegawa, T., Ohsuga, A., and Honiden, S. 2004. Dynamic invocation model of

web services using subsumption relations. In Proceedings of the IEEE International Conference

on Web Services (ICWS 2004). 150–156.

Oreizy, P., Gorlick, M., Taylor, R., Heimhigner, D., Johnson, G., Medvidovic, N., Quilici,A., Rosenblum, D., and Wolf, A. 1999. An architecture-based approach to self-adaptive

software. IEEE Intelligent Systems and their Applications 14, 3, 54–62.

Papazoglou, M., Traverso, P., Dustdar, S., and Leymann, F. 2007. Service-Oriented com-

puting: State of the art and research challenges. Computer 40, 11, 38–45.

Paton, N. W., Diaz, O., and Barja, M. L. 1993. Combining active rules and metaclasses forenhanced extensibility in object-oriented systems. Data & Knowledge Engineering 10, 1, 45–63.

Prud’hommeaux, E. and Seaborne, A., Eds. 2008. SPARQL Query Language for RDF. World

Wide Web Consortium. Available at http://www.w3.org/TR/rdf-sparql-query/.

Ranganathan, A. 2005. Task execution framework for autonomic ubiquitous computing. Ph.D.

thesis, University of Illinois at Urbana-Champaign.

Ranganathan, A., McGrath, R. E., Campbell, R. H., and Mickunas, M. D. 2003. Use ofontologies in a pervasive computing environment. The Knowledge Engineering Review 18, 3,

209–220.

Reichle, R., Wagner, M., Khan, M., Geihs, K., Lorenzo, J., Valla, M., Fra, C., Paspallis,

N., and Papadopoulos, G. 2008. A comprehensive context modeling framework for pervasivecomputing systems. In Proceedings of the 8th IFIP WG 6.1 International Conference on

Distributed Applications and Interoperable Systems (DAIS 2008). Lecture Notes in Computer

Science, vol. 5053. 281–295.

Roman, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R., and Nahrstedt, K.2002. A middleware infrastructure for active spaces. IEEE Pervasive Computing 1, 4, 74–83.

Roman, M., Ziebart, B., and Campbell, R. H. 2003. Dynamic application composition: cus-

tomizing the behavior of an active space. In Proceedings of the 1st IEEE International Confer-

ence on Pervasive Computing and Communications (PerCom 2003). IEEE Computer Society,169.

Salehie, M. and Tahvildari, L. 2009. Self-adaptive software: Landscape and research challenges.

ACM Transactions on Autonomous and Adaptive Systems 4, 2, 1–42.

36 · K. Lee et al.

Sousa, J., Poladian, V., Garlan, D., Schmerl, B., and Shaw, M. 2006. Task-based adaptation

for ubiquitous computing. IEEE Transactions on Systems, Man, and Cybernetics, Part C:Applications and Reviews 36, 3, 328–340.

Sousa, J. P. 2005. Scaling task management in space and time: Reducing user overhead in

ubiquitous computing environments. Ph.D. thesis, Carnegie Mellon University.

Strang, T. and Linnhoff-Popien, C. 2004. A context modeling survey. In Proceedings of the 1stInternational Workshop on Advanced Context Modelling, Reasoning and Management. 34–41.

Szyperski, C. 2002. Component Software: Beyond Object-Oriented Programming. Addison-

Wesley Professional.

Thompson, H. S., Beech, D., Maloney, M., and Mendelsohn, N., Eds. 2004. XML SchemaPart 1: Structures 2nd Edition. World Wide Web Consortium. Available at http://www.w3.

org/TR/xmlschema-1/.

Vinoski, S. 2002. Web services interaction models. current practice. IEEE Internet Comput-

ing 6, 3, 89–91.

Walsh, W., Tesauro, G., Kephart, J., and Das, R. 2004. Utility functions in autonomicsystems. In Proceedings of International Conference on Autonomic Computing. 70–77.

Wang, X. H., Zhang, D. Q., Gu, T., and Pung, H. K. 2004. Ontology based context modeling

and reasoning using OWL. In Proceedings of the 2nd IEEE Annual Conference on PervasiveComputing and Communications Workshops. IEEE Computer Society, 18.

Weiser, M. 1991. The computer for the 21st century. Scientific American 265, 3, 94–101.

Yau, S. S., Karim, F., Wang, Y., Wang, B., and Gupta, S. K. S. 2002. Reconfigurable context-

sensitive middleware for pervasive computing. IEEE Pervasive Computing 1, 3, 33–40.

Zhang, J. and Cheng, B. H. C. 2006. Model-based development of dynamically adaptive soft-ware. In Proceedings of the 28th International Conference on Software Engineering. ACM,

Shanghai, China, 371–380.

a self-adaptation model for ubiquitous computing applications

Documents