Automatic Configuration
The Automatic Configuration
Service’s objective is to ease system and application configuration by
managing two kinds of inter-component dependencies: prerequisites,
which specify the requirements for
loading an inert component into the runtime system; and dynamic
dependencies, which refer to the dependencies among loaded components in a
running system. As long as the system has access to the requirements for
installing and running a software component, the installation and configuration
of new components can be automated. As a byproduct of this knowledge, component
performance can be improved by analyzing the dynamic state of system resources,
by analyzing the characteristics of each component, and by configuring them in
the most efficient way.
The prerequisites for a particular
inert component specify any special requirement for properly loading,
configuring, and executing that component. Prerequisites specify 1) the type and
share of hardware resources that a component needs and 2) the software services
(i.e., other components) it requires. The
first kind of prerequisites lets the QoS-aware Resource Management Service
determine where, how, and when to execute each component. It uses this data to
enable proper admission control, resource negotiation, reservation, and
scheduling. The second kind of
prerequisites determines which auxiliary components must be loaded and which
other software services must be located. Prerequisite specifications can be
created manually by application developers but we will also investigate
mechanisms for automating its creation using, for example, software tools for
QoS profiling such as QualProbes.
As the Automatic Configuration Service
parses the software prerequisite specifications, it verifies whether it is
necessary to create new instances of the required components in the system
runtime. If necessary, it contacts the a repository of components, fetches the
component binary code compiled for that specific platform, and dynamically loads
it. This approach is reminiscent of the Jini pull-based mechanism for code
distribution. Using the Automatic
Configuration Service, a client running in a certain network node pulls
the code and configuration information from a Component
Repository available in the Active Space. Our approach takes the Jini
mechanism to a new level, enabling the construction of sophisticated
component-based systems in a language-independent way.
To support that, we will develop a flexible Component Repository that
will be able to (1) classify components according to their categories, (2) store
multiple implementations of the same component for different kinds of software
and hardware platforms, and (3) support security by providing mechanisms for
access control and for digitally signing components.
In large-scale systems, this
pull-based approach may not be enough. To support efficient and scalable code
distribution, we also need a mechanism to allow system administrators to push
code and configuration information into the network. Our architecture will achieve that by using mobile agents for
distributing software components and reconfiguration scripts across Active
Spaces in a scalable way.
]
