\chapter{Automatic Configuration Service}
\label{chap:autoconfig-service}
\index{automatic configuration!service|(}

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 \twoK operating system \cite{kon00:hpdc}. 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.

\section{A Flexible Framework}
\label{sec:autoconfig-framework}

Different applications domains may have different ways of specifying the
prerequisites\index{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\index{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\index{QoS} descriptions
\cite{QML:coots99,QDL:bbn98} can be plugged into the framework easily.
\index{QoS!specification languages}

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 \ref{fig:prerequisite-framework} shows how the architecture uses the
two basic classes of the Automatic Configuration framework:
\emph{prerequisite parsers} and \emph{prerequisite resolvers}. 
Administrators and developers can plug different concrete implementations of
these classes to implement customized policies. 

\begin{figure}[htbp]
  \begin{center}
    \leavevmode \epsfig{file=figs/prerequisite-framework.eps,width=14cm}
    \caption{Automatic Configuration Architecture}
    \label{fig:prerequisite-framework}
  \end{center}
\end{figure}

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\index{component repository|textbf} (step 1 in Figure
\ref{fig:prerequisite-framework}). 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).

\section{A Concrete Implementation}
\label{sec:autoconfig-concrete}

To evaluate the framework, we created concrete implementations of the
prerequisite parser and resolver. The prerequisite parser, called
\texttt{SPDFParser}, processes SPDF specifications. The first prerequisite
resolver, called \texttt{SimpleResolver}, uses CORBA to fetch components from
the \twoK Component Repository. The second, called \texttt{CachingResolver},
is a subclass of \texttt{SimpleResolver} that caches the components on the
local file system.

\subsection{SPDF}
\label{sec:SPDF}
\index{SPDF|(}

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 \ref{fig:spdf} 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.

\begin{figure}[htbp]
\begin{center}
{\small
\begin{boxedverbatim}
:hardware requirements
machine_type    SPARC
os_name         Solaris
os_version      2.7
min_ram         5MB
optimal_ram     40MB
cpu_speed       >300MHz
cpu_share       10%

:software requirements
FileSystem    CR:/sys/storage/DFS1.0 (optional)
TCPNetworking CR:/sys/networking/BSD-sockets
WindowManager CR:/sys/WinManagers/simpleWin
JVM           CR:/interp/Java/jvm1.2 (optional) 
\end{boxedverbatim}
}
\end{center}
    \caption{A Simple Prerequisite Description}
    \label{fig:spdf}
\end{figure}

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

\centerline{\texttt{FileSystem    CR:/sys/storage/DFS1.0 (optional)}}

\noindent specifies that the component that implements the file system (or the
proxy that interacts with the file system) can be located in the directory
\texttt{/sys/storage/DFS1.0} of the component repository (\texttt{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.

\index{SPDF|)}

\subsection{Simple Resolver and Caching Resolver}

The \texttt{SimpleResolver} fetches the component implementations and
component prerequisite specifications from the \twoK 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\index{component configurator}
of the parent component, i.e., the component that required it. In the web
browser example, the \texttt{SimpleResolver} would add hooks to the web browser
configurator, call them \texttt{FileSystem}, \texttt{TCPNetworking},
\texttt{WindowManager}, and \texttt{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 \texttt{SimpleResolver} to create a
\texttt{CachingResolver} that checks for the existence of the component
in the local disk (cache) before fetching it from the remote repository.

\section{Interactions with Resource Management Services}
\index{resource management|textbf}
\index{QoS}

The QoS-aware Resource Management service can be provided by systems
like SMART \cite{smart97} and the Dynamic Soft Real-Time Scheduler (DSRT)\index{DSRT}
\cite{nahrstedt98:dsrt}. 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 \twoK Resource Management Service
\cite{tomoMS} and QoS Proxy \cite{dongyan00:qos} carried out by other members
of the \twoK team.

\section{Use Cases}

The Automatic Configuration Service has been used successfully in a multimedia
distribution system \cite{kcn:00:communications} described in
Section \ref{sec:reflector}. In addition, it is currently being used in
the development of three other systems in our research group.

\begin{enumerate}
\item \emph{2KFS}, the \twoK Distributed File System\index{twokfs@\emph{2KFS}}
will use the Automatic Configuration Service to load data management
components, called \texttt{Containers} \cite{hess:adapt:00}, to customize the
system at runtime according to user requests.

\item LegORB\index{LegORB}, a component-based ORB,  will use this service to load a minimal
set of ORB components satisfying application requirements \cite{roman:legorb:00}.

\item A QoS-aware video on demand system \cite{dongyan00:qos} uses this
service to load video player components on demand.
\end{enumerate}

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.

\begin{itemize}
\item It eliminates the need to upload components to the entire network each
time a component is updated.

\item It eliminates the need to keep track manually of which machines hold copies of
each component because updates are automatic.

\item It helps machines with limited resources, which no longer need to store
all components locally.
\end{itemize}

\index{automatic configuration!service|)}

%Maybe should include the following somewhere:
%
%Prerequisites for software components can be specified either in
%terms of persistent IORs \cite{Henning98:cacm} or in terms of a pair
%$<$ServiceTypeName, Constraints$>$. In the former case, an implementation
%repository can be used to dynamically create a new CORBA object if one is not
%available. In the latter case, the CORBA Trading Object
%Service \cite{CORBA:services} can be used to locate an instance of the server
%component that meets the requirements specified by the given constraints.

