0018-9162/04/$20.00 © 2004 IEEE56 Computer

C O V E R F E A T U R E

P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y

Middleware

Compositional adaptation

Separation ofconcerns

Computationalreflection

Component-baseddesign

Figure 1. Main technologies supporting compositional adaptation: separation ofconcerns, computational reflection, and component-based design.

Composing Adaptive Software

I nterest in adaptive computing systems hasincreased dramatically in the past few years,and a variety of techniques now allow softwareto adapt dynamically to its environment. Tworevolutions in the computing field are driving

this development. First is the emergence of ubiqui-tous computing,1 which focuses on dissolving tra-ditional boundaries for how, when, and wherehumans and computers interact. For example,mobile computing devices must adapt to variableconditions on wireless networks and conserve lim-ited battery life. Second is the growing demand forautonomic computing,2 which focuses on devel-oping systems that can manage and protect them-selves with only high-level human guidance. Thiscapability is especially important to systems such asfinancial networks and power grids that must sur-vive hardware component failures and securityattacks.

There are two general approaches to implement-ing software adaptation. Parameter adaptationmodifies program variables that determine behav-ior. The Internet’s Transmission Control Protocolis an often-cited example: TCP adjusts its behaviorby changing values that control window manage-ment and retransmissions in response to apparentnetwork congestion. But parameter adaptation hasan inherent weakness. It does not allow new algo-rithms and components to be added to an applica-tion after the original design and construction. Itcan tune parameters or direct an application to usea different existing strategy, but it cannot adopt newstrategies.

By contrast, compositional adaptation exchangesalgorithmic or structural system components withothers that improve a program’s fit to its currentenvironment. With compositional adaptation, anapplication can adopt new algorithms for address-ing concerns that were unforeseen during develop-ment. This flexibility supports more than simpletuning of program variables or strategy selection.It enables dynamic recomposition of the softwareduring execution—for example, to switch programcomponents in and out of a memory-limited deviceor to add new behavior to deployed systems.

Dynamic recomposition of software dates backto the earliest days of computing, when self-modi-fying code supported runtime program optimiza-tion and explicit management of physical memory.However, such programs were difficult to write anddebug. Several new software tools and technologiesnow help address these problems. Given the increas-ing pace of research in compositional adaptation,we offer a review of the supporting technologies,proposed solutions, and areas that require furtherstudy.

Compositional adaptation enables software to modify its structure andbehavior dynamically in response to changes in its execution environment.A review of current technology compares how, when, and whererecomposition occurs.

Philip K.McKinleySeyedMasoud SadjadiEric P. KastenBetty H.C.ChengMichigan State University

ENABLING TECHNOLOGIESAt the core of all approaches to compositional

adaptation is a level of indirection for interceptingand redirecting interactions among program enti-ties. Figure 1 shows three technologies—separa-tion of concerns, computational reflection, andcomponent-based design—that we consider as keyto reconfigurable software design. Programmerscan use these technologies to construct self-adap-tive systems in a systematic and principled—asopposed to ad hoc—manner.3

In addition, the widespread use of middlewarein distributed computing has been a catalyst forcompositional adaptation research. Middlewareprovides a natural place to locate many types of adaptive behavior, as the “Middleware andAdaptation” sidebar describes.

Separation of concernsSeparation of concerns4 enables the separate

development of an application’s functional behav-ior—that is, its business logic—and the code for

July 2004 57

Much recent research in adaptive software focuses on mid-dleware—the layers of services separating applications fromoperating systems and network protocols.

Douglas Schmidt decomposes middleware into four layers,1

shown in Figure A:

• Host-infrastructure middleware resides atop the operat-ing system and provides a high-level API that hides theheterogeneity of hardware devices, operating systems,and—to some extent—network protocols.

• Distribution middleware provides a high-level program-ming abstraction, such as remote objects, enabling devel-opers to write distributed applications in a way similar tostand-alone programs. Corba, DCOM, and Java RMI allfit in this layer.

• Common middleware services include fault tolerance,security, persistence, and transactions involving entitiessuch as remote objects.

• Domain-specific middleware services are tailored to matcha particular class of applications.

Most adaptive middleware is based on an object-orientedprogramming paradigm and derived from popular middlewareplatforms such as Corba, Java RMI, and DCOM/.NET.

Many adaptive middleware approaches work by intercept-ing and modifying messages. Figure B shows the flow of arequest-reply sequence in a simplified Corba client-server appli-cation. This application comprises two autonomous programshosted on two computers connected by a network.

Assume that the client has a valid Corba reference to the ser-vant object. The client request to the servant goes first to thestub, which represents the Corba object on the client side. Thestub marshals the request and sends it to the client objectrequest broker. The client ORB sends the request to the serverORB, where a skeleton unmarshals the request and delivers itto the servant. The servant replies to the request, by way of theserver ORB and skeleton. The client ORB will receive the replyand dispatch it to the client.

In recent years, numerous studies have addressed the issue ofhow middleware can adapt to dynamic, heterogeneous envi-ronments to better serve applications.2,3 Middleware tradition-ally hides resource distribution and platform heterogeneity fromthe application business logic. Thus it is a logical place to putadaptive behavior that is related to crosscutting concerns such asQoS, energy management, fault tolerance, and security policy.

References1. D.C. Schmidt, “Middleware for Real-Time and Embedded Sys-

tems,” Comm. ACM, June 2002, pp. 43-48.2. Comm. ACM, special issue on adaptive middleware, June 2002,

pp. 30-64.3. IEEE Distributed Systems Online, special issue on reflective mid-

dleware, June 2001; http://dsonline.computer.org/0105/features/gei0105.htm.

Middleware and Adaptation

Domain-specific middleware services

Common middleware services

Distribution middleware

Applications

Host-infrastructure middleware

Operating systems and protocols

Hardware devices

Figure A. Four-layer decomposition of middleware to bridge thegap between an application program and the underlying operatingsystems, network protocols, and hardware devices.

Client application Server application

Skeleton

Request flow Reply flow

Applications

Distribution

Domain servicesCommon services

Host infrastructureSystem platform

Network

Servant

Server ORB

Stub

Client

Client ORB

Figure B. Corba call sequence for a simplified client-server application.

58 Computer

crosscutting concerns, such as quality of service(QoS), energy consumption, fault tolerance, andsecurity. An application cannot implement a cross-cutting concern at a single program location;instead, it must add the code at many places.Separating crosscutting concerns from functionalbehavior simplifies development and maintenance,while promoting software reuse.

Separation of concerns has become an importantprinciple in software engineering.5 Presently, themost widely used approach appears to be aspect-oriented programming.6 AOP provides abstractiontechniques and language constructs to managecrosscutting concerns. The code implementingthese concerns, called aspects, is developed sepa-rately from other parts of the system. In AOP,pointcuts are sets of locations in the code where thedeveloper can weave in aspects. Pointcuts are typ-ically identified during development. Later, forexample during compilation, the developer uses aspecialized compiler, called an aspect weaver, tocombine different aspects with an application’sbusiness logic to create a program with new behav-ior. An example is the AspectJ compiler. AOP pro-ponents argue that disentangling crosscuttingconcerns leads to simpler software development,maintenance, and evolution.

AOP is important to dynamic recompositionbecause most adaptations are relative to somecrosscutting concern, such as QoS. AOP enablesthese concerns to be isolated from the rest of theprogram. However, in traditional AOP the com-piled program is still tangled. To support dynamicrecomposition, the programmer needs a way tomaintain this separation at runtime.

Computational reflectionComputational reflection refers to a program’s

ability to reason about, and possibly alter, its ownbehavior.7 Reflection enables a system to revealselected details of its implementation without com-promising portability.

Reflection comprises two activities: introspectionto let an application observe its own behavior, andintercession to let a system or application act on

these observations and modify its own behavior. Ina self-auditing distributed application, for exam-ple, software “sensors” could use introspection toobserve and report usage patterns for various com-ponents. Intercession would allow the system toinsert new types of sensors, as well as componentsthat implement corrective action, at runtime.

As Figure 2 shows, a reflective system (repre-sented as base-level objects) and its self-represen-tation (represented as metalevel objects) arecausally connected, meaning that modifications toeither one will be reflected in the other.

A metaobject protocol (MOP) is an interface thatenables “systematic” introspection and interces-sion of the base-level objects. MOPs support eitherstructural or behavioral reflection.3 Structuralreflection addresses issues related to class hier-archy, object interconnection, and data types. Asan example, a metalevel object can examine a base-level object to determine what methods areavailable for invocation. Conversely, behavioralreflection focuses on the application’s computa-tional semantics. For instance, a distributed appli-cation can use behavioral reflection to select andload a communication protocol well suited to cur-rent network conditions.

A developer can use reflective services that areeither native to a programming language—such asCommon Lisp Object System (CLOS), Python, orvarious Java derivatives—or provided by a mid-dleware platform. When combined with AOP,reflection enables a MOP to weave code for cross-cutting concerns into an application at runtime.However, dynamically loading and unloadingadaptive code requires the target software modulesto exhibit a “plug-and-play” capability.

Component-based designThe third major technology supporting compo-

sitional adaptation is component-based design.Software components are software units that thirdparties can independently develop, deploy, andcompose.9 Popular component-based platformsinclude COM/DCOM, .NET, Enterprise JavaBeans, and the Corba Component Model.

Component-based design supports two types ofcomposition. In static composition, a developer cancombine several components at compile time toproduce an application. In dynamic composition,the developer can add, remove, or reconfigure com-ponents within an application at runtime. To pro-vide dynamic recomposition, a component-basedframework must support late binding, whichenables coupling of compatible components at run-

Base levelApplication

MOPs

Objects

Metalevel

Structural Behavioral

IntrospectionIntercession Intercession

Introspection

Figure 2. Metalevel understanding collected into metaobject protocols.

time through well-defined interfaces used as con-tracts. In addition, to provide consistency withother applications, a component-based frameworkmust support coexistence of multiple versions ofcomponents.

By enabling the assembly of off-the-shelf com-ponents from different vendors, component-baseddesign promotes software reuse. Moreover, mech-anisms for maintaining a program’s componentstructure after the initial deployment, when com-bined with late binding, facilitate compositionaladaptation.

Middleware and other factorsIn addition to the three main technologies sup-

porting dynamic recomposition, many other fac-tors have contributed to the growth in this area.Perhaps the most important is middleware’s

increasing role in distributed computing. Middle-ware provides a layer that developers can exploitto implement adaptive behavior. Indeed, manyapproaches to compositional adaptation are real-ized in various middleware layers.

Other technologies important to adaptive soft-ware design include software design patterns,mobile agents, generative programming, adaptiveprogramming, and intentional programming.5

COMPOSITIONAL ADAPTATION TAXONOMYResearchers and developers have proposed a

wide variety of methods for supporting composi-tional adaptation. Table 1 lists several research pro-jects, commercial software packages, and standardspecifications that support some form of composi-tional adaptation. The list is by no means exhaus-tive. Rather, it includes projects that exemplify the

July 2004 59

Table 1. Example research projects, commercial packages, and standard specifications that provide compositional adaptation.

Project Institution/Organization

Language-based projectsAspectJ Xerox Palo Alto Research Center Composition filters Universiteit Twente, The Netherlands Program Control Language (PCL) University of Illinois Open Java IBM Research R-Java University Federal de São Carlos, Brazil Kava University of Newcastle, UK Adaptive Java Michigan State UniversityTransparent Reflective Aspect Programming in Java (TRAP/J) Michigan State UniversityMiddleware-based projectsDomain-specific services layer:Boeing Bold Stroke (BBS) Boeing Common services layer:CorbaServices Object Management Group Quality objects (QuO) BBN Technologies Adaptive Corba Template (ACT) Michigan State University Interoperable Replication Logic (IRL) University of Rome, Italy Distribution layer:.NET remoting Microsoft Open ORB and Open COM Lancaster University, UK The ACE ORB (TAO) and Component Integrated ACE ORB (CIAO) Distributed Object Computing Group DynamicTAO and Universally Interoperable Core (UIC) University of Illinois Orbix, Orbix/E, and ORBacus Iona Technologies Squirrel University of Kaiserslautern, GermanyAspectIX Friedrich-Alexander University, Germany Host infrastructure layer:Java virtual machine (JVM) Sun Microsystems Common Language Runtime (CLR) Microsoft Iguana/J Trinity College, Dublin Prose Swiss Federal Institute of Technology Adaptive Communication Environment (ACE) Distributed Object Computing Group Ensemble Cornell University Cross-layer projectsDistributed Extensible Open Systems (DEOS) Georgia Institute of Technology Grace University of Illinois

60 Computer

distinctions in a taxonomy we have developedbased on how, when, and where software compo-sition takes place. We have applied the taxonomyto many additional projects.10

How to composeThe first dimension of our taxonomy addresses

the specific software mechanisms that enable com-positional adaptation. Table 2 lists several key tech-niques with brief descriptions and examples.Mehmet Aksit and Zièd Choukair8 provide anexcellent discussion of such methods.

All of the techniques in Table 2 create a level ofindirection in the interactions between programentities. Some techniques use specific softwaredesign patterns to realize this indirection, whereasothers use AOP, reflection, or both. The two mid-dleware techniques both modify interactionbetween the application and middleware services,but they differ in the following way: Middlewareinterception is not visible to the application,whereas integrated middleware provides adaptiveservices invoked explicitly by the application.

We use the term composer to refer to the entitythat uses these techniques to adapt an application.The composer might be a human—a software devel-oper or an administrator interacting with a runningprogram through a graphical user interface—or apiece of software—an aspect weaver, a component

loader, a runtime system, or a metaobject. Indeed,autonomic computing promises that, increasingly,composers will be software components.

When and where the composer modifies the pro-gram determines the transparency of the recom-position. Transparency refers to whether anapplication or system is aware of the “infrastruc-ture” needed for recomposition. For example, amiddleware approach to adaptation is transparentwith respect to the application source code if theapplication does not need to be modified to takeadvantage of the adaptive features. Differentdegrees of transparency (with respect to applica-tion source, virtual machine, middleware source,and so on) determine both the proposed solution’sportability across platforms and how easily it canadd new adaptive behavior to existing programs.10

When to composeSecond, we differentiate approaches according

to when the adaptive behavior is composed withthe business logic. Generally speaking, later com-position time supports more powerful adaptationmethods, but it also complicates the problem ofensuring consistency in the adapted program. Forexample, when composition occurs at develop-ment, compile, or load time, dynamism is limitedbut it is easier to ensure that the adaptation willnot produce anomalous behavior. On the other

Table 2. Software recomposition techniques.

Technique Description Examples

Function pointers Application execution path is dynamically Vtables in COM, delegates and events in redirected through modification of function .NET, callback functions in Corbapointers.

Wrappers Objects are subclassed or encapsulated by other ACE, R-Java, PCL, QuO, TRAP/J objects (wrappers), enabling the wrapper to control method execution.

Proxies Surrogates (proxies) are used in place of objects, ACT, AspectIXenabling the surrogate to redirect method calls to different object implementations.

Strategy pattern Each algorithm implementation is encapsulated, DynamicTAO and UICenabling transparent replacement of one implementation with another.

Virtual component pattern Component placeholders (virtual components) are ACE and TAO inserted into the object graph and replaced as needed during program execution.

Metaobject protocol Mechanisms supporting intercession and Open Java, Kava, TRAP/J, Open ORB, introspection enable modification of program Open COM, Iguana/J behavior.

Aspect weaving Code fragments (aspects) that implement a AspectJ, Composition Filters, TRAP/J, crosscutting concern are woven into an application AspectIX, Iguana/J, Prose dynamically.

Middleware interception Method calls and responses passing through a ACT, IRL, Prose middleware layer are intercepted and redirected.

Integrated middleware An application makes explicit calls to adaptive Adaptive Java, Orbix, Orbix/E, ORBacus, services provided by a middleware layer. BBS, CIAO, Iguana/J, Ensemble

July 2004 61

hand, while runtime composition is very powerful,it is difficult to use traditional testing and formalverification techniques to check safety and othercorrectness properties. Figure 3 illustrates the useof composition time as the classification metric foradaptive applications. The vertical axis lists appli-cation types that implement either static or dynamiccomposition. Static composition methods takeplace at development, compile, or load time,whereas dynamic composition refers to methodsthat a composer can apply at runtime.

Static composition. If an adaptive program is com-posed at development time, then any adaptivebehavior is hardwired into the program and can-not be changed without recoding.

Alternatively, a developer or user can implementa limited form of adaptation at compile time or linktime by configuring the application for a particu-lar environment. For example, aspect-oriented programming languages such as AspectJ enableweaving of aspects into programs during compila-tion. Aspects might implement an environment-specific security or fault-tolerance policy. Such cus-tomizable applications require only recompilationor relinking to fit to a new environment.

Configurable applications delay the final deci-sion on the algorithmic units to use in the currentenvironment until a running application loads the corresponding component. For example, theJava virtual machine (JVM) loads classes when a Java application first uses them. Although we con-sider load-time composition a type of static com-position, it offers more dynamism than other staticmethods. When the application requests the load-ing of a new component, decision logic might selectfrom a list of components with different capabili-ties or implementations, choosing the one that mostclosely matches the current needs. For example, ifa user starts an application on a handheld com-puter, the runtime system might load a minimal dis-play component to guarantee proper presentation.

Other load-time approaches work by dynami-cally modifying the class itself as it is loaded. For

example, to provide runtime monitoring anddebugging capabilities, Kava enables the JVM tomodify the bytecode as it loads a class.

Dynamic composition. The most flexible approachesto compositional adaptation implement it at run-time. A composer can replace or extend algorith-mic and structural units during execution withouthalting and restarting the program. We differenti-ate two types of approaches according to whetheror not the composer can modify the application’sbusiness logic.

Tunable software prohibits modification of codefor the business logic. Instead, it supports fine-tun-ing of crosscutting concerns in response to chang-ing environmental conditions, such as dynamicconditions encountered in mobile computing envi-ronments. An example is the fragment object modelused in AspectIX, which enables runtime tuning ofa Corba application’s distribution behavior.

In contrast, mutable software allows the com-poser to change even the program’s imperative func-tion, enabling dynamic recomposition of a runningprogram into one that is functionally different. Forexample, in the OpenORB middleware platform,all objects in the middleware and application codehave reflective interfaces, so at runtime the reflec-tive application can change virtually any object inany way, including modifying its interface and inter-nal implementation. While very powerful, in mostcases the developer must constrain this flexibility toensure the system’s integrity across adaptations.

Where to composeThe final dimension in which we compare

approaches to compositional adaptation centers onwhere in the system the composer inserts the adap-tive code. The possibilities include one of the mid-dleware layers (see Figure A in the “Middlewareand Adaptation” sidebar) or the application codeitself. In this survey, we do not discuss changes tothe operating system; however, we note that oper-ating system extensibility is an active research area.Moreover, adaptations in cross-layer frameworks

Dynamiccomposition

StaticcompositionAp

plic

atio

n ty

pe

Increasing dynamism

Compile/linktime

Loadtime

RuntimeDevelopmenttime

Hardwired

Customizable

Configurable

Tunable

Mutable

Figure 3. Classification for software composition usingthe time of composition orrecomposition as a classificationmetric.

62 Computer

such as DEOS and Grace involve the coop-eration of the operating system, middleware,and application.

Middleware layers. Projects involving com-positional adaptation at the host-infrastruc-ture middleware layer generally fall in oneof two groups. One approach is to constructa layer of adaptable communication services.ACE is an early example that used servicewrappers and C++ dynamic binding to sup-port adaptable interprocess communicationand event handling services. Ensemble pro-vides a layered architecture that enables a

distributed application to select a particular com-munication protocol.

The second approach is to provide a virtualmachine with facilities to intercept and redirectinteractions in the functional code. For example,JVM and common language runtime (CLR) facil-itate dynamic recomposition through reflectionfacilities provided by the Java language and .NETplatform, respectively. R-Java supports metaob-jects by adding a new instruction to the Java inter-preter, while Prose and Iguana/J use aspect weavingto add behavioral reflection to the standard JVM.In general, approaches in this category are veryflexible with respect to dynamic reconfiguration inthat they allow new code to be introduced at run-time. However, they use customized virtualmachines to provide transparency to the applica-tion, which may reduce portability.

Introducing adaptive behavior in higher mid-dleware layers—distribution, common services,and domain-specific services—enables portabilityacross virtual machines. These approaches typi-cally involve middleware components that inter-cept messages associated with remote methodinvocations and redirect or modify them in a man-ner that accounts for current conditions. For someframeworks, the application developer constructsexplicit calls to adaptive middleware services.Examples include Orbix, Orbix/E, ORBacus,CIAO, and Boeing Bold Stroke. QuO uses wrap-pers around Corba stubs and skeletons to gain con-trol of the call sequence, whereas IRL and ACTuse Corba portable interceptors to do so. Portableinterceptors serve as “generic” hooks that a com-poser can use at runtime to load other types ofinterceptors. Since a user can load a portable inter-ceptor using a command-line parameter, thisapproach enables the composer to integrate adap-tive components into the program without modi-fying either the application or the middlewarecode.

Application code. Although middleware approachessupport transparent adaptation, they apply only toprograms that are written against a specific mid-dleware platform. A more general approach is fordevelopers to implement compositional adaptationin the application program itself.

Two main techniques are available. The first is toprogram all or part of the application code using alanguage that directly supports dynamic recompo-sition. Some languages, such as CLOS or Python,provide support inherently, while others have beenextended to support adaptation. For example, OpenJava, R-Java, Handi-Wrap, PCL, and Adaptive Javaall extend Java to include new keywords and con-structs that enhance the adaptive code’s expres-siveness. However, this approach requires thedeveloper to use these features explicitly in con-structing the program.

The second technique is to weave the adaptivecode into the functional code. AspectJ andComposition Filters weave adaptive behavior intoexisting applications at compile time. In contrast,tools such as TRAP/J use a two-step approach toenable dynamic recomposition. In the first step, anaspect weaver inserts generic interception hooks,in this case implemented as aspects, into the appli-cation code at compile time. In the second step, acomposer dynamically weaves new adaptive com-ponents into the application at runtime, and ametaobject protocol uses reflection to forwardintercepted operations to the adaptive components.This approach offers a way to add adaptive behav-ior to existing applications transparently withrespect to the original code. Such a capability isimportant as users expect legacy applications toexecute effectively across an increasingly diversecomputing infrastructure.

KEY CHALLENGESDespite many advances in mechanisms to sup-

port compositional adaptation, the full potentialof dynamically recomposable software systemsdepends on fundamental advances on four otherfronts.

AssuranceRecomposable software design requires a pro-

gramming paradigm that supports automatedchecking of both functional and nonfunctional sys-tem properties.11

To help ensure the adapted system’s correctness,developers must first certify all components for cor-rectness with respect to their specifications. Theycan obtain this certification either by selecting com-

Introducing adaptive behavior

in higher middleware

layers enablesportability acrossvirtual machines.

ponents that have already been verified and vali-dated offline using traditional techniques, such astesting, inspection, and model checking, or by gen-erating code automatically from specifications. Thecertification can include nonfunctional require-ments, such as security and performance, as wellas functional requirements.

Second, techniques are needed to ensure that thesystem still executes in an acceptable, or safe, man-ner during the adaptation process. Our group andothers are using dependency analysis to address thisproblem. In addition, developers can use high-levelcontracts12 and invariants to monitor system cor-rectness before, during, and after adaptation.

Security Whereas assurance deals primarily with system

integrity, security addresses protection from mali-cious entities—preventing would-be attackers fromexploiting the adaptation mechanisms. In additionto verifying component sources, an adaptive softwaresystem must protect its core from attackers. Variouswell-studied security mechanisms are available, suchas strong encryption to ensure the confidentiality andauthenticity of messages related to adaptation.

However, the system must also hide adaptationmanagement from would-be intruders and preventthem from impeding or corrupting the adaptationprocess. A comprehensive approach to this prob-lem must ensure the integrity of the data used indecision-making and conceal the adaptive actions,perhaps by obscuring them within other systemactivities.

InteroperabilityDistributed systems that can adapt to their envi-

ronment must both adapt individual componentsand coordinate adaptation across system layers andplatforms. Software components are likely to comefrom different vendors, so the developer may needto integrate different adaptive mechanisms to meetan application’s requirements. The problem is com-plicated by the diversity of adaptive software ap-proaches at different system layers. Even solutionswithin the same layer are often not compatible.

Developers need tools and methods to integratethe operation of adaptive components across thelayers of a single system, among multiple comput-ing systems, and between different adaptive frame-works.

Decision makingAdaptive systems respond to a dynamic physical

world. They must act autonomously, modifying

software composition to better fit the currentenvironment while preventing damage or lossof service. Decision-making software usesinput from software and hardware sensorsto decide how, when, and where to adapt thesystem. Interactive systems may even requirethe decision maker to learn about and adaptto user behavior.

Some researchers have constructed soft-ware decision makers using rule-basedapproaches or control theory. Others havedesigned decision makers whose actions areinspired by biological processes, such as the humannervous system and emergent behavior in insectspecies that form colonies.

These approaches to decision making in adaptivesoftware have been effective in certain domains, butenvironmental dynamics and software complexityhave limited their general application. More exten-sive research in decision making for adaptive soft-ware is needed. Future systems must accommodatehigh-dimensional sensory data, continue to learnfrom new experience, and take advantage of newadaptations as they become available.

M any of the mechanisms for compositionaladaptation are available now, and we expecttheir use to increase as programmers become

more familiar with adaptive software technologiesand society comes to expect computer systems tomanage themselves. There is a potential downside,however, in the lack of supporting development envi-ronments. Compositional adaptation is powerful,but without appropriate tools to automatically gen-erate and verify code, its use can negatively impact—rather than improve—system integrity and security.

The computer science community must builddevelopment technologies and tools, well groundedin rigorous software engineering, to support com-positional adaptation. This foundation will raisethe next generation of computing to new levels offlexibility, autonomy, and maintainability withoutsacrificing assurance and security. �

AcknowledgmentsWe express our gratitude to the many individu-

als who have contributed to this emerging area ofstudy. Discussions with researchers associated withmany of the projects listed in Table 1 have greatlyimproved our understanding of this area. We alsothank the faculty and students in the SoftwareEngineering and Network Systems Laboratory at

July 2004 63

The system must also hide

adaptation management

from would-beintruders.

64 Computer

Michigan State University for their contributionsto RAPIDware, Meridian, and related projects.

This work was supported in part by NationalScience Foundation grants CCR-9901017, CCR-9912407, EIA-0000433, EIA-0130724, and ITR-0313142, and by the US Department of the Navy,Office of Naval Research, under grant no. N00014-01-1-0744.

Further informationOur group is participating in compositional

adaptation research through two projects:RAPIDware (www.cse.msu.edu/rapidware) ad-dresses adaptive software for protecting criticalinfrastructures, and Meridian (www.cse.msu.edu/meridian) addresses automated software engi-neering for mobile computing. Among other arti-facts, these projects produced ACT, Adaptive Java,and TRAP/J. The technical report on our taxon-omy is a “living document” available through theRAPIDware URL.

References1. M. Weiser, “Hot Topics: Ubiquitous Computing,”

Computer, Oct. 1993, pp. 71-72.2. J.O. Kephart and D.M. Chess, “The Vision of Auto-

nomic Computing,” Computer, Jan. 2003, pp. 41-50.3. G.S. Blair et al., “An Architecture for Next-Genera-

tion Middleware,” Proc. IFIP Int’l Conf. DistributedSystems Platforms and Open Distributed Processing(Middleware 98), Springer, 1998, pp. 191-206.

4. D.L. Parnas, “On the Criteria to Be Used in Decom-posing Systems into Modules,” Comm. ACM, Dec.1972, pp. 1053-1058.

5. K. Czarnecki and U. Eisenecker, Generative Pro-gramming, Addison-Wesley, 2000.

6. G. Kiczales et al., “Aspect-Oriented Programming,”Proc. European Conf. Object-Oriented Program-ming (ECOOP), LNCS 1241, Springer-Verlag, 1997,pp. 220-242.

7. P. Maes, “Concepts and Experiments in Computa-tional Reflection,” Proc. ACM Conf. Object-OrientedProgramming Systems, Languages, and Applications(OOPSLA), ACM Press, 1987, pp. 147-155.

8. M. Aksit and Z. Choukair, “Dynamic, Adaptive, andReconfigurable Systems Overview and ProspectiveVision,” Proc. 23rd Int’l Conf. Distributed Com-puting Systems Workshops (ICDCSW03), IEEE CSPress, May 2003, pp. 84-89.

9. C. Szyperski, Component Software: Beyond Object-Oriented Programming, 2nd ed., Addison-Wesley,2002.

10. P.K. McKinley et al., “A Taxonomy of CompositionalAdaptation,” tech. report MSU-CSE-04-17, Dept.Computer Science and Engineering, Michigan StateUniv., 2004.

11. N. Venkatasubramanian, “Safe ‘Composability’ ofMiddleware Services,” Comm. ACM, June 2002, pp.49-52.

12. A. Beugnard et al., “Making Components ContractAware,” Computer, July 1999, pp. 38-45.

Philip K. McKinley is a professor in the Depart-ment of Computer Science and Engineering atMichigan State University. His research interestsinclude adaptive middleware, mobile computing,pervasive computing, distributed systems, andgroup communication. McKinley received a PhDin computer science from the University of Illinoisat Urbana-Champaign. He is a member of theIEEE Computer Society and the ACM. Contacthim at mckinley@cse.msu.edu.

Sayed Masoud Sadjadi is a PhD candidate in theDepartment of Computer Science and Engineeringat Michigan State University. His research interestsinclude adaptive software, middleware, pervasivecomputing, autonomic computing, and sensor net-works. Sadjadi received an MS in software engi-neering from Azad University at Tehran. He is astudent member of the IEEE Computer Society andthe ACM. Contact him at sadjadis@cse.msu.edu.

Eric P. Kasten is a PhD candidate in the Depart-ment of Computer Science and Engineering and asoftware developer in the National Superconduct-ing Cyclotron Laboratory, both at Michigan StateUniversity. His research interests include autonomiccomputing and learning algorithms for adaptablesoftware. Kasten received an MS in computer sci-ence from Michigan State University. He is a mem-ber of the IEEE Computer Society and the ACM.Contact him at kasten@cse.msu.edu.

Betty H.C. Cheng is a professor in the Departmentof Computer Science and Engineering at MichiganState University. Her research interests include for-mal methods for software engineering, component-based software development, object-orientedanalysis and design, embedded systems develop-ment, and visualization. Cheng received a PhD incomputer science from the University of Illinois atUrbana-Champaign. She is a senior member of theIEEE Computer Society and a member of theACM. Contact her at chengb@cse.msu.edu.