next up previous
Next: Goal Statement Up: Problem Description Previous: The SIDAM Project

Main Objective and Related Work

Our work aims at addressing the problem of how to change computing systems at runtime in order to adapt to variations in the execution environment, such as resource availability and user mobility. Our main interest is on adapting distributed information systems composed of several components spread over a network where data are also decentralized and users are mobile. The problem of how to provide dynamic adaptation of software has been addressed recently by several research groups. Sudame and Badrinath [12] describe a mechanism based on ICMP messages [3] to propagate information about network environment parameters such as the cost of communication, latency, and bandwidth. Mobility specific parameters, such as signal strength, location, energy consumption and availability can also be addressed by the described mechanism. Once variations on network parameters has been detected, actions that adjust parameters of the transport layer protocol (TCP or UDP) can be automatically triggered. There are a fixed predefined set of actions that can be taken. Sudame and Badrinath [12] do not address the problems of dynamic reconfiguration of system components as well as the monitoring of inter-component interactions. It also focuses on adapting transport layer protocol parameters and not on generic system adaptations. Finally, the monitoring and adaptation are mainly local to a host and the work does not address the adaptation of a system composed of several components distributed over a network. Fox et al. [5] address the problem of network bandwidth and client variability with respect to both hardware and software properties. Adaptation is done via data-type-specific lossy compression. Compression is performed by distillers, which preserve most of the semantic content of the data object. A proxy is placed between the client and the server. Its role is to retrieve content from Internet servers on the client's behalf, determine the high-level types of the various components (e.g., images, text runs), and determine which distillation engine must be employed to adapt the data to the current bandwidth availability and client type. Fox et al. focus their work on applications composed of a client and a server, where a proxy is placed between them. In our work, the application is composed of several components spread in a network. The proxy adaptation is based on data-type-specific transformations; other adaptation mechanisms, such as component reconfiguration and relocation are not considered. We believe that information server migration, replication and reconfiguration is essential to support user mobility and resource availability fluctuations. Odyssey [9] also addresses the problem of providing information access to mobile computers. Its approach is different from Fox's proxies but it uses the same principle of adjusting the data according to the environment status. It is implemented as a set of extensions to the NetBSD operating system. In Odyssey's view, the operating system is responsible for monitoring resource availability, notifying applications of relevant changes to those resources, and enforcing resource allocation decisions. Each application is responsible for deciding how to exploit available resources by selecting the fidelity level of the transmitted data. As with Fox et al., an Odyssey application is divided on a client and server components. The adaptation is based on choosing between different versions of the data (fidelity levels) in order to match the resource availability. It lacks other adaptation mechanisms such as component reconfiguration and relocation. Chang and Karamcheti [2] describe an adaptation framework that eliminates the need for adaptation decisions to be explicitly programmed into the application. The framework is based on two components: a tunability interface and a virtual execution environment. The tunability interface provides language support to express availability of multiple execution paths for the application, and the means by which application progress can be monitored and influenced (by switching to a different path). A driver script repeatedly executes the application in virtual environments, obtaining application behavior profiles. The execution system incorporates these profiles into adaptation decisions at run time to choose the appropriate execution path that the application must take in order to satisfy user-defined preferences, such as transmission time. All the different execution paths (algorithms) are coded into a single, monolithic execution process together with the monitoring and steering agents. This approach is not well suited to our needs since we must consider resource availability and user request load in multiple nodes in order to determine the best adaptation action to be triggered. Application reconfiguration is supported (by choosing between different execution paths) but migration and replication of components are not considered.
next up previous
Next: Goal Statement Up: Problem Description Previous: The SIDAM Project
Francisco Jose da Silva e Silva 2001-09-24