As described in the previous chapter, automatic configuration enables the construction of network-centric systems following a WYNIWYG model. To experiment with these ideas, we developed an Automatic Configuration Service for the 2K operating system [KCM+00]. In this chapter, we present the framework in which the service is based and describe a concrete implementation of the service. We conclude the chapter by discussing interactions with other services and use cases.
Different applications domains may have different ways of specifying the prerequisites of their application components. Therefore, rather than limiting the specification of prerequisites to a particular language, we created a framework in which different kinds of prerequisite descriptions can be utilized. To validate the framework, we designed SPDF, a very simple, text-based format that allowed us to perform initial experiments. In the future, other more elaborated prerequisite formats including sophisticated QoS descriptions [FK99b,LBS+98] can be plugged into the framework easily.
In addition, depending upon the dynamic availability of resources and connectivity constraints, different algorithms for prerequisite resolution may be desired. For example, if a diskless PDA is connected to a network through a 2Mbps wireless connection, it will be beneficial to download all the required components from a central repository each time they are needed. On the other hand, if a laptop computer with a large disk connects to the network via modem, it will probably be better to cache the components in the local disk and re-use them whenever is possible.
Figure 4.1 shows how the architecture uses the two basic classes of the Automatic Configuration framework: prerequisite parsers and prerequisite resolvers. Administrators and developers can plug different concrete implementations of these classes to implement customized policies.
The architecture for automatic configuration works as follows. First, the client sends a request for loading an application by passing, as parameters, the name of the application's ``master'' component and a reference to a component repository (step 1 in Figure 4.1). The request is received by the prerequisite resolver, which fetches the component code and prerequisite specification from the given repository, or from a local cache, depending on the policy being used (step 2.1).
Next, the prerequisite resolver calls the prerequisite parser to process the prerequisite specification (step 2.2). As it scans the specification, the parser issues recursive calls to the prerequisite resolver to load the components on which the component being processed depends (step 2.3). This may trigger several iterations over steps 2.1, 2.2, and 2.3.
After all the dependencies of a given component are resolved, the parser issues a call to the Resource Manager to negotiate the allocation of the required resources (step 3). After all the application components are loaded, the service returns a reference to the new application to the client (step 4).
To evaluate the framework, we created concrete implementations of the prerequisite parser and resolver. The prerequisite parser, called SPDFParser, processes SPDF specifications. The first prerequisite resolver, called SimpleResolver, uses CORBA to fetch components from the 2K Component Repository. The second, called CachingResolver, is a subclass of SimpleResolver that caches the components on the local file system.
We designed the Simple Prerequisite Description Format (SPDF) to serve as a proof-of-concept for our framework. An SPDF specification is divided in two parts, the first is called hardware requirements and the second, software requirements. Figure 4.2 shows an example of an SPDF specification for a hypothetical web browser. The first part specifies that this application was compiled for a Sparc machine running Solaris 2.7, that it requires at least 5MB of RAM memory but that it functions optimally with 40 MB of memory, and that it requires 10% of a CPU with speed higher than 300MHz.
The second part, software requirements, specifies that the web browser requires four components (or services): a file system (to use as a local cache for web pages), a TCP networking service (to fetch the web pages), a window manager (to display the pages), and a Java virtual machine (to interpret Java Applets).
The line
specifies that the component that implements the file system (or the proxy that interacts with the file system) can be located in the directory /sys/storage/DFS1.0 of the component repository (CR). It also states that the file system is an ``optional'' component, which means that the web browser can still function without a cache. Thus, if the Automatic Configuration Service is not able to load the file system component, it simply issues a warning message and continues its execution.
The SimpleResolver fetches the component implementations and component prerequisite specifications from the 2K Component Repository. It stores the component code in the local file system and dynamically links the components to the system runtime. As new components are loaded, they are attached to hooks in the component configurator of the parent component, i.e., the component that required it. In the web browser example, the SimpleResolver would add hooks to the web browser configurator, call them FileSystem, TCPNetworking, WindowManager, and JVM, and attach the respective component configurators to each of these hooks.
Resolvers can be extended using inheritance. For example, with very little work, we extended the SimpleResolver to create a CachingResolver that checks for the existence of the component in the local disk (cache) before fetching it from the remote repository.
The QoS-aware Resource Management service can be provided by systems like SMART [NL97] and the Dynamic Soft Real-Time Scheduler (DSRT) [NhCN98]. In the latter case, DSRT can use the QoS requirements in the prerequisite specifications to perform QoS-aware admission control, negotiation, reservation, and scheduling.
Although our architecture permits the integration of the Automatic Configuration Service with any Resource Management scheme, a concrete implementation of this integration is beyond the scope of this thesis. This has been addressed by the research on the 2K Resource Management Service [Yam00] and QoS Proxy [XWN00] carried out by other members of the 2K team.
The Automatic Configuration Service has been used successfully in a multimedia distribution system [KCN00] described in Section 7.2. In addition, it is currently being used in the development of three other systems in our research group.
In all these applications, the Automatic Configuration Service simplifies management greatly. Whenever new components are requested, the service downloads the most up-to-date version of each component from the component repository and installs them locally. This provides several advantages including the following.
