Enabling Collaborative Adaptation across Legacy ... - CiteSeerX

277

Middleware 2004 Companion

Enabling Collaborative Adaptation across Legacy Components Z. Yang, Z. Zhou, B. H.C. Cheng, and P. K. McKinley Software Engineering and Network Systems Laboratory Department of Computer Science and Engineering Michigan State University East Lansing, Michigan 48824 {yangzhe1,zhouzhin,chengb,mckinley}@cse.msu.edu

ABSTRACT Software frequently needs to adapt its behavior at run time to respond to changes in its execution environment. Different software components may use different approaches to adaptation. Composing a single adaptive system from existing adaptive components requires an “adaptation infrastructure” to integrate and arbitrate adaptive behaviors. This paper proposes a model for such an infrastructure and describes the design and operation of M 2 , a prototype implementation. M 2 uses a technique called transparent shaping to modify existing components so that they can report events of interest to the M 2 core and implement appropriate responses. The architecture and communication infrastructure of M 2 are described, followed by a case study in which M 2 is used to construct an adaptive multimedia conferencing application from otherwise incompatible components.

1.

INTRODUCTION

In recent years, dynamically adaptive software has been investigated for different parts of the computing environment. Adaptation is needed to respond to changing conditions and user needs. Some changes might be anticipated, such as those associated with battery lifetime, CPU load, or available network bandwidth. Other changes, such as new security threats, might be unknown at development time. Several techniques have been proposed to support dynamic adaptation. For example, compositional adaptation enables software to change its structure and behavior dynamically in response to external conditions [1, 2]. As the need for adaptive software increases, so does the need for integration methods that support the coordination and collaboration of adaptive components developed with different adaptive technologies. This paper introduces M 2 (middleware for middleware), a framework intended to provide an open interface that supports the integration of different adaptation techniques, while leveraging existing middleware services.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 3rd Workshop on Adaptive and Reflective Middleware Toronto, Canada Copyright 2004 ACM 1-58113-949-7 ...$5.00.

Significant effort has been spent in developing adaptive capabilities for individual parts of a computing system. For example, many approaches introduce adaptive behavior in middleware [3–10, 12], exploiting information hiding to enhance portability while taking into account application-specific requirements and constraints. Supporting adaptation in individual parts of the system can address many aspects of dynamic execution environments. However, some situations require coordinated responses from multiple system elements, where elements may comprise one or more components.1 Even a relatively simple multimedia conferencing application for mobile users might need to balance quality of service against other concerns, such as energy consumption, security, and fault tolerance. This need for balancing competing concerns has fueled increasing interest in more holistic approaches to adaptation, where an adaptive system comprises multiple adaptive elements, possibly spanning multiple system layers, that collaborate to achieve overall system goals. Example cross-layer (and collaborative) adaptation frameworks include Odyssey [13], GRACE [14], DEOS [15], and Chisel [16]. In these systems, collaboration is realized either by constructing components specifically for integration in the common framework [13–15], or by transparently augmenting components with interfaces to the framework [16]. Increasingly, however, distributed computing applications are constructed from relatively independent (legacy) components. For example, our example conferencing system might comprise components for streaming audio and video, for displaying images and graphics, and for interaction via a shared whiteboard. This trend poses two important challenges to the design of adaptive systems. First, the individual components might not support adaptive behavior at all, or might not support the type of adaptation needed in the target environment. Second, even if they are individually adaptive, the components might have been developed by different organizations, using different languages and/or different middleware platforms, and using different (and likely incompatible) adaptation techniques. We contend that supporting collaborative adaptation among existing adaptive components should be based on a model that (1) requires little or no modification of existing components; (2) can be easily extended to accommodate new platforms and services; and (3) leverages existing middleware services whenever possible. 1

Here, we use the term component loosely, referring to standalone applications as well as software modules developed and deployed by by third parties.

Adaptive and Reflective Middleware

To explore the issues involved in realizing such a model, we have developed a prototype framework, M 2 , that provides platform- and language-independent middleware support for collaborative adaptation in distributed systems. M 2 (middleware for middleware) provides an open interface that supports the integration of different adaptation techniques, while leveraging existing middleware services. The M 2 framework makes three main contributions to the challenge of achieving collaborative adaptation in heterogeneous distributed systems. First, M 2 introduces a messagebased collaboration protocol that defines how components interact to implement collaborative adaptation. Second, M 2 uses transparent shaping [17], originally designed to add new adaptive behavior to non-adaptive applications, to support the collaboration protocol. Third, M 2 defines an open interface to the protocol that enables new components to plug themselves into an adaptive system and collaborate with elements already in the system. Once plugged into the M 2 framework, an element can obtain or provide context information to and from other elements, as well as support reconfigurations. M 2 has been implemented as a prototype environment and used to support the development of a number of adaptive systems comprising disparate adaptive and non-adaptive components. In this paper, we illustrate the use of M 2 in the context of a multimedia conferencing system, whose adaptive elements were developed using a variety of adaptation techniques. The remainder of this paper is organized as follows. Section 2 provides background information on adaptive middleware and collaborative adaptation. Section 3 gives an overview of the M 2 framework. Section 4 uses a distributed adaptive multimedia conferencing system to demonstrate the operation, and benefits, of M 2 . Finally, Section 5 summarizes this paper and discusses future research directions.

2.

RELATED WORK

Interest in adaptive computing systems has grown dramatically in the past few years [2], driven primarily by two ongoing revolutions: ubiquitous computing, which removes traditional boundaries for how, when, and where humans and computers interact, and autonomic computing, which refers to the ability of systems to manage and protect their own resources with only high-level human guidance. Adaptive software behavior, and specifically dynamic recomposition of the code itself, has been studied extensively with respect to different system layers [2]. Supporting adaptation usually involves intercepting and redirecting interactions among software entities: encapsulating these actions within a particular system layer provides transparency to higher and lower layers. Several projects address adaptation at the operating system level [18, 19]. Many others place adaptive behavior in middleware which, in addition to its traditional role in hiding resource distribution and platform heterogeneity, can be used to address concerns such as quality-of-service, energy management, fault tolerance, and security policy. Examples include Iguana/J [3], TAO [4], DynamicTAO [5], Open ORB [6], QuO [7], ORBacus [8], Squirrel [9], IRL [10], AspectIX [11], and ACT [12]. Finally, several projects focus on dynamic recomposition within the application itself, either directly by using a language that supports recomposition (e.g., CLOS or Python) or indirectly by modifying code as it is loaded by a virtual machine (as in

278

Kava), or dynamically weaving new behavior into running programs (e.g., Iguana/J, TRAP/J, DADO, ABASCO, and Reflex. Recently, several frameworks have been proposed to address the need for a coordinated, system-wide approach to software adaptation. Odyssey [13] is a relatively early crosslayer framework, supporting interaction between the operating system and applications to meet user-specified goals for battery duration. The Odyssey framework uses a viceroy to monitor system resources, and uses wardens to reconfigure application power consumption. Inter-element communications are handled by an intercepter embedded in the operating system. DEOS [15] uses an extended Linux, with open interfaces for adaptation, to build a cross-layer adaptation framework that supports QoS in distributed applications. GRACE [14] uses a global coordinator to support adaptive behavior involving the hardware, network, operating system and application layers. The Chisel project [16] provides an open framework for dynamic adaptation that leverages the advantages of existing commonly-used middleware while supporting collaboration among elements in a distributed system. To support dynamic adaptation, Chisel uses IguanaJ metatypes [3] to associate non-functional behavior to base-level objects and classes. To support collaboration among adaptive applications and service objects, Chisel uses a policy-based approach to control the dynamic adaptation behavior, which incorporates user- and application-specific semantic knowledge and intelligence. Like Chisel, M 2 supports collaborative adaptation by weaving new behavior into different components of an application. However, M 2 is intended to complement projects like Chisel by enabling different techniques to be used for weaving M 2 -compatible behavior into existing components. Moreover, M 2 is designed to enable existing adaptation protocols and decision-making components to be integrated into a common framework.

3. THE M 2 FRAMEWORK

M 2 is part of the RAPIDware project [20], which addresses the design of adaptive middleware services to support critical infrastructure protection in dynamic, heterogeneous environments. The M 2 framework leverages tools and techniques developed for the RAPIDware project, as well as several developed by other groups and organizations, to support collaborative adaptation in distributed applications.

3.1 Overview Figure 1 shows the architecture of M 2 and its relationship to other parts of the system; the shaded areas indicate the key elements of M 2 responsible for collaboration and adaptation. Message gateways communicate with the message router in the M 2 core and deliver messages among the corresponding components. As such, message gateways play an essential role in enabling the collaboration among the adaptive elements. The M 2 core serves as a chassis for adaptation and interacts with three types of adaptive entities: adapt-ready components, platform brokers, and adaptation services. Next, we describe each of these elements in turn. The M 2 core provides four main functions: (1) The topology manager maintains a representation of elements in the current system and a description of of the reconfiguration interface for each element. The topology manager is also responsible for notifying elements interested in system topol-

279

Middleware 2004 Companion

M2-Ready Component Sensing

Reconfiguration

Legacy System

3.2 Bridging Existing Components with M 2

MessageGateway

M2 Core

Adaptation Services Message Gateway

Message Gateway

Context Manager

Adaptation Service

Reconfiguration Manager

Topology Manager

Message Router

Platform Broker MessageGateway Sensing

the system, decide future actions, and issue reconfiguration requests.

Reconfiguration

Platform:

middleware, operating system, and hardware

Figure 1: The M 2 architecture.

ogy whenever the topology changes. (2) The message router handles message exchanges both between local adaptive elements and with message routers on remote adaptive systems. The message gateway in the core is responsible for forwarding messages to and from core components. (3) The context manager is an event-based system that observes events of interest (either those fired explicitly by adaptive elements or changes in state) and distributes this information to elements that have registered interest. Other elements can obtain this information either by requesting it explicitly or by registering to be notified when certain events occur. (4) The reconfiguration manager handles all requests for software reconfiguration and forwards them to corresponding elements. M 2 -ready components are typically stand-alone components that together form a more complex application. In addition to providing one or more types of adaptation, they have been “bridged” to interact with the M 2 core. Bridging can be done manually by modifying the code, or transparently by using one of a number of tools for adding new behavior to programs. The added code is used for M 2 interface registration and message processing. Platform brokers are used to probe and reconfigure systemlevel components, including the operating system and various middleware platforms. For example, a power sensor is a platform broker used to collect energy-related context information and communicate that information to other elements. Adaptation services address management aspects of dynamic adaptation. Tasks include decision making, resource optimization, and correctness checking. These services can be plugged into the M 2 framework. For example, by adhering to M 2 interface specifications, a rule-based decision maker component can be integrated into M 2 and use its primitives to obtain context information from elements of

For M 2 to support collaboration among components that use different adaptation mechanisms, we need to augment existing components so that their adaptation mechanisms (both for gathering information and invoking responses) are accessible to the M 2 core and other elements. Specifically, we need to add a communication interface (for example, a message gateway) to the legacy elements. To do so, one could modify the application manually, but a better approach is to weave in the new behavior transparently with respect to the existing application code. We refer to this process as bridging. The mechanism(s) used on a particular component depend on the characteristics of the component, in particular, the programming language and any middleware platforms used. In earlier work on RAPIDware, our group has developed several techniques that can be used to implement bridging. Several of these techniques are referred to collectively as transparent shaping [17]. Although originally intended to enable new adaptive behavior to be added to existing applications, transparent shaping also provides a means to enable existing adaptive components to interact with the M 2 core. Effectively, the new adaptive behavior is the M 2 protocol. Transparent shaping tools developed by our group include AOPA [21], which uses aspect-oriented programming to weave hooks for adaptive behavior into existing Java programs; TRAP/J [22], a generator framework that subsumes AOPA by enabling automatic generation of the necessary aspects; TRAP/C++, a C++ version of TRAP that uses OpenC++ instead of AOP to define adaptation hooks; and ACT [12], a framework that uses CORBA portable interceptors to support transparent adaptability and interoperabiltiy of CORBA applications. Finally, we note that several other tools, designed to add new behavior to existing applications, could be used to implement M 2 bridging. Examples include IguanaJ [3] and QuO [7].

3.3 Collaboration Protocol The M 2 collaboration protocol defines the messages communicated among, and the corresponding actions taken by, M 2 elements. Three main categories of messages are defined. Topology messages. The first category includes messages that enable the system to maintain a representation of its topology. The interfaces define the types of context information that can be retrieved from the element and the types of reconfiguration commands supported by the element. Elements send connect and disconnect messages to the core when entering and leaving the system, respectively. Other elements can register interest in topology changes, and are informed when services become available or unavailable. For example, a video component in a conferencing multimedia system uses a connect message to inform the core and other elements that a video component has joined the adaptive system. Context messages. The second category of messages include those that enable context acquisition and propagation. In order to achieve dynamic adaptation, adaptive elements need to obtain system-wide run-time context information.

Adaptive and Reflective Middleware

Context acquisition and dispatching messages, respectively, are used to request and distribute values of context variables among adaptive elements. Again, elements can register their interest in a context change with the respective element. For example, a decision maker uses a get message to obtain remaining battery life from a power sensor. Reconfiguration messages. The third category includes messages used to reconfigure elements and thereby adapt the system. An element reconfiguration message is used by a source element to request the target element to perform a reconfiguration action with the given name and argument parameters. The M 2 collaboration protocol requires that an adaptive element perform the specified adaptive action upon receipt of a reconfiguration message. For example, a decision maker uses a reconf message to request the video component in a multimedia conferencing system to lower the data transfer rate to save power. Together, these messages and associated actions form the M 2 collaboration protocol. The current protocol is sufficient to support collaborative adaptation among existing adaptive components. Ongoing and future work includes investigation of decision makers, safe adaptation feature interaction, and contract-driven adaptation.

4.

DEMONSTRATION

To evaluate its effectiveness, we have used the M 2 framework to construct an adaptive mobile multimedia conferencing system, comprising five components: a video streamer, an audio streamer, a text-based conferencing tool, a decision maker, and an energy sensor application. All were existing applications either developed by our group or others. Figure 2 shows two users of the conferencing application. The demonstration environment contains a server and a client. The server runs on a wired Windows desktop, while the client sub-system runs atop a wireless Linux laptop (Panasonic Toughbook). The server and the client are connected over a combination of wired Ethernet and a multi-cell 802.11 wireless network that covers most of the Michigan State University Engineering Building. Figure 3 depicts the software configuration. Both the client and the server contain the following adaptive elements, in addition to the M 2 framework itself: Vplayer, an interactive video streaming component; ASA, an interactive audio streaming component; Conf, a text-based communication tool. We bridged the components as needed and used M 2 to realize collaborative adaptation. Next, each of the components is briefly described. Video Component. Vplayer, a Java application, was developed with Sun’s JMStudio to send video stream over wireless network. It was made adaptable and M 2 -ready using AOPA. For lower power and bandwidth consumption purposes, we could adapt the system to use bette [7], a CORBA application that gives an image-based slideshow. (BBN used QuO to make bette adaptable by changing picture frame rates.) In order to transparently shape bette to support additional adaptations, as well as make it M 2 -ready, we developed several rules for use with ACT [12] and used the AOPA approach to weave in code that supports the M 2 communication and collaboration protocol. Audio Component. ASA is a Java application that was made adaptable using TRAP/J [22]. After startup,

280

TRAP/J is used to replace Java Sockets with MetaSockets [23], whose behavior can be adapted at run time. Given a list of of class names, TRAP/J weaves hooks into applications and allows run-time replacement of method implementations. ASA supports the following adaptive action: inserting and removing MetaSocket filters for forward error correction (FEC), thereby affecting the quality of received audio [24]. Using FEC consumes additional energy and network bandwidth. This tradeoff between QoS and energy consumption is captured and codified in the decision making process by balancing user preference and available adaptive actions. ASA was made M 2 -ready using AOPA. Text-based conferencing. Conf is based on UDP and is also constructed atop MetaSockets. However, Conf was made adaptive using AOPA. We also used AOPA to make Conf M 2 -ready. Conf supports the following adaptive action: inserting/removing FEC filters, thereby affecting the delay and packet loss rate of the text, energy consumption, and bandwidth consumption. In addition to the above components, the server side provides a console display for monitoring the entire adaptive system, and the client side includes an energy sensor for monitoring remaining battery lifetime and a decision maker. The energy sensor is a platform broker written for M 2 . The sensor uses the Linux /proc file system to obtain the current energy level and current energy consumption rate. In our experiments, the adaptation developer provides the desired lifetime of the system as input to the decision maker. The energy sensor periodically compares the expected remaining lifetime with the run-time goal. If the current consumption rate is too high to meet the goal, then the energy sensor generates a lowpoweralert event, which triggers the decision maker to activate rules associated with power saving. The decision maker [21] is rule-based, where each rule contains three parts: a goal, a condition, and a set of actions. When the condition in a rule is satisfied, the first action that has not been applied is taken to achieve the specific goal. The decision maker also supports reordering of actions so that various adaptive actions can be taken in a different order to reflect user priorities. Figure 4 shows traces of two experiments in which we established a battery lifetime goal of 250 minutes for the laptop. In the first experiment, with adaptive behavior disabled, the battery drains in a little over 100 minutes. In the second experiment, after 60 minutes have elapsed with all three components (Vplayer, ASA, Conf) running, the energy sensor detects insufficient remaining energy to maintain the current operation for another 190 minutes, so it generates a lowpwralert message and sends it to M 2 . The M 2 core checks the list of adaptive elements interested in this event and notifies them individually. In this experiment, the list includes only the decision maker service. The decision maker checks its rule base, finds the goal related to lowpwralert is savepwr, checks the list of adaptive actions for achieving this goal, and triggers the first eligible action. This action switches the system from using the Vplayer video streaming to using bette to send still images. Although this adaptive action greatly reduces the power consumption rate, the energy sensor again detects insufficient energy and generates another lowpwralert event. This time, the decision maker chooses the next adaptive action, which is to remove the FEC functionality from ASA. Although the audio quality is

281

Middleware 2004 Companion

Figure 2: Users of adaptive multimedia conferencing system.

Video Receiver

Audio Reciever

Power Sensor

CORBA/ACT

AOP/TRAPJ

hardwired

TextMsg Receiver

M2 Core

AOP/AspectJ

Decision−Maker Service rule−based tech

Wireless Network

Video Sender

Audio Sender

CORBA/ACT

AOP/TRAPJ

M2 Core

AOP/AspectJ

Console Service

Console Service

Multimedia Client (Laptop, Linux)

TextMsg Sender

Multimedia Server (Desktop, Windows)

Figure 3: Software configuration

Power Status

Battery Lifetime (minutes)

350

low power alert

300

remove FEC filter

250 200 150 100

low power alert

50

switch to slide show

0 0

20

40

60

80

100 120 140 160 180 200 220 240

Elapsed Time (minutes) Non-Adaptive

Threshold

Adaptive

Figure 4: Experimental trace of adaptive behavior.

reduced, this adaptation enables the system to achieve the 250-minute goal.

5.

CONCLUSIONS AND FUTURE WORK

Collaborative adaptation among separately-designed adaptive components is an increasingly important problem. The M 2 framework proposed in this paper provides middleware support for communication and collaboration among multiple elements in an adaptive system. This paper described the M 2 collaborative protocol and the use of transparent

shaping to enable disparate adaptive components to be integrated into a single application. We used M 2 to support collaborative adaptation in a conferencing application comprising several existing applications. Our ongoing and future work will investigate the integration of adaptive elements developed from other adaptation techniques, such as Iguana/J, QuO, and others. Other work is focusing on decision makers, safe adaptation, feature interaction, and contract-driven adaptation. Further Information: Related papers and technical reports of the Software Engineering and Network Systems Laboratory can be found at the SENS website: http://www.cse.msu.edu/sens. Additional details on the RAPIDware project, including downloads, can be found at: http://www.cse.msu.edu/rapidware. Acknowledgements: We greatly appreciate the efforts of S. M. Sadjadi, who was instrumental in helping us to incorporate adaptive elements developed using TRAP/J, QuO, and ACT. This work was supported in part by the U.S. Department of the Navy, Office of Naval Research under Grant No. N00014-01-1-0744, and in part by National Science Foundation grants CCR-9901017, CCR-9912407, EIA0000433, EIA-0130724, and ITR-0313142.

6. REFERENCES [1] M. Aksit and Z. Choukair, “Dynamic, adaptive and reconfigurable systems overview and prospective vision,” in Proceedings of the 23rd International Conference on Distributed Computing Systems Workshops (ICDCSW’03), (Providence, Rhode Island), May 2003.

Adaptive and Reflective Middleware

[2] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and B. H. C. Cheng, “Composing adaptive software,” IEEE Computer, vol. 37, no. 7, pp. 56–64, 2004. [3] B. Redmond and V. Cahill, “Supporting unanticipated dynamic adaptation of application behaviour,” in Proceedings of the 16th European Conference on Object-Oriented Programming, (Malaga, Spain), Springer-Verlag, June 2002. volume 2374 of Lecture Notes in Computer Science. [4] D. C. Schmidt, D. L. Levine, and S. Mungee, “The design of the TAO real-time object request broker,” Computer Communications, vol. 21, no. 4, 1997. [5] F. Kon, M. Rom´ an, P. Liu, J. Mao, T. Yamane, L. C. Magalh˜ aes, and R. H. Campbell, “Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB,” in Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’2000), no. 1795 in LNCS, (New York), pp. 121–143, Springer-Verlag, April 2000. [6] G. Blair, G. Coulson, L. Blair, H. Duran-Limon, P. Grace, R. Moreira, and N. Parlavantzas, “Reflection, self-awareness and self-healing in OpenORB,” in ACM SIGSOFT Workshop on Self-Healing Systems (WOSS’02), (Charleston, SC), November 2002. [7] R. Vanegas, J. A. Zinky, J. P. Loyall, D. A. Karr, R. E. Schantz, and D. E. Bakken, “QuO’s runtime support for quality of service in distributed objects,” in Proceedings of the IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’98), (The Lake District, England), September 1998. [8] IONA Technologies Inc., ORBacus for C++ and Java version 4.1.0, 2001. [9] T. Kramp and R. Koster, “A service-centered approach to QoS-supporting middleware (Work-in-Progress Paper),” in IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’98), (The Lake District, England), September 1998. [10] R. Baldoni, C. Marchetti, and A. Termini, “Active software replication through a three-tier approach,” in Proceedings of the 22th IEEE International Symposium on Reliable Distributed Systems (SRDS02), (Osaka, Japan), pp. 109–118, October 2002. [11] F. Hauck, U. Becker, M. Geier, E. Meier, U. Rastofer, and M. Steckermeier, “AspectIX: A middleware for aspect-oriented programming,” Tech. Rep. TR-I4-98-06, Computer Science Department,Friedrich-Alexander-University, Erlangen-N¨ urnberg, Germany, September 1998. [12] S. M. Sadjadi and P. K. McKinley, “ACT: An adaptive CORBA template to support unanticipated adaptation,” in Proceedings of the 24th IEEE International Conference on Distributed Computing Systems (ICDCS’04), (Tokyo, Japan), March 2004. [13] J. Flinn and M. Satyanarayanan, “Energy-aware adaptation for mobile applications,” in Symposium on Operating Systems Principles, pp. 48–63, 1999.

282

[14] S. V. Adve, A. F. Harris, C. J. Hughes, D. L. Jones, R. H. Kravets, K. Nahrstedt, D. G. Sachs, R. Sasanka, J. Srinivasan, and W. Yuan, “The Illinois GRACE Project: Global Resource Adaptation through Cooperation,” in Workshop on Self-Healing, Adaptive, and self-MANaged Systems (SHAMAN) (held in conjunction with the 16th Annual ACM International Conference on Supercomputing), June 2002. [15] C. Poellabauer, H. Abbasi, and K. Schwan, “Cooperative run-time management of adaptive applications and distributed resources,” in Proceedings of the tenth ACM international conference on Multimedia, pp. 402–411, ACM Press, 2002. [16] J. Keeney and V. Cahill, “Chisel: A policy-driven, context-aware, dynamic adaptation framework,” in Proceedings of the Fourth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 2003), pp. 3–14, 2003. [17] S. M. Sadjadi, Transparent Shaping to Support Adaptation in Pervasive and Autonomic Computing. PhD thesis, Department of Computer Science and Engineering, Michigan State University, 2004. [18] F. Kon, R. H. Campbell, M. D. Mickunas, K. Nahrstedt, and F. J. Ballesteros, “2K: A distributed operating system for dynamic heterogeneous environments,” in Ninth International Symposium on High Performance Distributed Computing (HPDC), pp. 201–210, 2000. [19] J. Appavoo, K. Hui, C. A. N. Soules, R. W. Wisniewski, D. M. D. Silva, O. Krieger, D. J. E. M. A. Auslander, B. Gamsa, G. R. Ganger, P. McKenney, M. Ostrowski, B. Rosenburg, M. Stumm, and J. Xenidis, “Enabling autonomic behavior in systems software with hot-swapping,” IBM Systems Journal, vol. 42, no. 1, 2003. [20] “The RAPIDware project.” http://www.cse.msu.edu/ mckinley/rapidware. [21] Z. Yang, B. H. Cheng, R. E. K. Stirewalt, J. Sowell, S. M. Sadjadi, and P. K. McKinley, “An aspect-oriented approach to dynamic adaptation,” in Proceedings of the ACM SIGSOFT Workshop On Self-healing Software (WOSS’02), November 2002. [22] S. M. Sadjadi, P. K. McKinley, R. E. K. Stirewalt, and B. H. Cheng, “Generation of self-optimizing wireless network applications,” in Proceedings of the International Conference on Autonomic Computing (ICAC-04), (New York, NY), pp. 310–311, May 2004. [23] S. M. Sadjadi, P. K. McKinley, and E. P. Kasten, “Architecture and operation of an adaptable communication substrate,” in Proceedings of the Ninth IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS’03), (San Juan, Puerto Rico), pp. 46–55, May 2003. [24] Z. Zhou, P. K. McKinley, and S. M. Sadjadi, “On quality-of-service and energy consumption tradeoffs in fec-enabled audio streaming,” in Proceedings of the 12th IEEE International Workshop on Quality of Service (IWQoS 2004), (Montreal, Canada), June 2004.