[ Software Research Group ]

[Home] [Projects] [Members] [Publications] [Links] [Documents] [Demos] [Videos]


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.