Next: Goal Statement
Up: Problem Description
Previous: The SIDAM Project
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: Goal Statement
Up: Problem Description
Previous: The SIDAM Project
Francisco Jose da Silva e Silva
2001-09-24