\chapter{Related Work}
\label{chap:related}

No other system architecture offers a more complete and integrated solution
for automatic configuration\index{automatic configuration} in heterogeneous,
distributed systems than the one proposed in this thesis. To the best of our
knowledge, our work is the first to identify the lack of an explicit
representation of inter-component dependence as one of the most fundamental
problems in existing computer systems.

Our architecture leverages modern technologies such
as CORBA, component-based programming, and mobile agents with the results of
the research in operating systems and dynamic configuration of the previous
decade.

In this section, we describe previous work in related areas, explain how they
influenced our research, and discuss the differences with our approach.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Programming Models}

Our work was strongly influenced by the advances in programming languages and
methodologies for software development of the last two decades. These advances
include not only the concepts of reflection and aspect-oriented programming,
described next, but also, object-orientation and design patterns
\cite{ralph:patterns}.

\subsection{Reflective Programming}
\index{reflection|(textbf}

The idea of having a \class{ComponentConfigurator} object associated with
each component is similar to the concept of \emph{meta-objects} present in 
reflective languages such as CLOS \cite{kiczales91:clos}, OpenC++
\cite{openC++}, Iguana \cite{dsg-97}, and Guaran\'a \cite{guarana99} and
reflective systems such as Apertos \cite{apertos95}. Meta-objects are used to
modify the object model and customize all aspects of object behavior, at
compile time, link time, or run time.  In contrast, the intent of the
component configurator\index{component configurator} is not to modify the
object model, but to maintain extra information about inter-component
dependence. This extra information helps the system to provide automatic
configuration\index{automatic configuration} and fault-tolerance and offers
components the possibility of reasoning about their own dependencies.

Reflective languages and environments could be used to implement the component
configurator model. The management of dependencies could be carried out by
meta-objects associated with the relevant components.  The reflective mechanisms
could then be used to instrument component creation and destruction to take
care of the dependencies properly. The architecture described here does not
rely on a particular reflective language or environment. We use only standard
languages and architectures such as C++, Java, and CORBA.

In spite of the differences between our model and previous implementations of
reflective systems, we believe that component configurators are a valuable
tool for implementing high-performance reflective systems. Component
configurators help realizing the following basic concepts of reflective
systems.
\begin{itemize}
\item \emph{Introspection of system structure} is achieved by
examining inter-component dependence relationships through the component configurator interface.
\item \emph{Reconfiguration of system structure} is achieved by manipulating the dependencies 
reified by the component configurator and by adding and removing components. 
\item \emph{The construction of systems that can reason about themselves} is achieved by
customizing the implementation of the component configurators, adding specialized code to 
implement specific policies.
\end{itemize}

Unlike most existing reflective systems, in our model, the component
configurator is not present in the normal invocation path to the component or
to the objects inside it. The configurator is not activated each time the
component is invoked.  Normally, the component configurator code is only
executed when some meta-level operation, such as reconfiguration, is required.

\index{reflection|)}

\subsection{Aspect-Oriented Programming}
\index{AOP}
\index{Aspect Oriented Programming|see{AOP}}

Aspect-Oriented Programming (AOP) \cite{aspects97} is a novel programming
paradigm in which different aspects of a program are coded in separate
subprograms. A tool called \emph{aspect weaver} is used to combine multiple
aspects into a single executable program image. As noted in \cite{lunao98},
AOP can be seen as a reflection model in which each object has multiple
meta-objects (its aspects).

AOP could also be used to implement the model described in this thesis.
Dependence management could be coded in a separate aspect that would be
inserted in the executable program by the aspect weaver. Another option would
be to use AOP to implement complex component configurators. Programmers would
write the code to deal with the different aspects of dependence management
(such as fault-tolerance, dynamic reconfiguration, and adaptability) using AOP
aspects. The weaver would then be used to generate the component configurator.

AOP is still a very recent, emerging technology. The modeling of dependencies
using aspects is an open problem. It is not clear yet how to support dynamic
(re)configuration of aspects. In existing AOP platforms, executables are
created off-line by the aspect weaver that mixes the code of all the aspects,
making dynamic replacement of a single aspect extremely difficult. A solution
to this problem may reside in some of the recent research in this area
\cite{aksit:rm2000}.

\section{Component Architectures}

Three major component architectures are likely to be present in the software
development arena in the next few years: Enterprise JavaBeans \cite{JavaBeans97},
ActiveX Controls \cite{ActiveX:candib,ActiveX:denning}, and the CORBA
Component Model (CCM) \cite{CORBA:components}. They all intend to provide an
infrastructure to support the construction of complex applications from
off-the-shelf components.

\subsection{Enterprise Java Beans and Jini}
\index{Jini|(}

Sun Microsystem's Enterprise Java Beans\index{Java Beans} specify a standard
for packaging components, called JAR, and for inspecting the interfaces
exported by each component (Introspection). Java beans must be completely
composed of Java byte code, which limits the applicability of the model.

Jini is a set of mechanisms for managing dynamic environments based on Java.
It provides protocols to allow services to \emph{join} a network and
\emph{discover} what services are available in this network. It also defines 
standard service interfaces for leasing, transactions, and events
\cite{JINI:whitePaper98}.  

When a Jini server registers itself with the Jini lookup service, it stores a
piece of Java byte code, called proxy, in its entry in the lookup
service. When a Jini-enabled client uses the lookup service to locate the
server, it receives, as a reply, a \class{ServiceItem}, which is composed by a
service ID, the code for the proxy, and a set of service attributes. The proxy
is then linked into the client address-space and is responsible for
communication with the server. In this way, the communication between the
client and the server can be customized, and optimized protocols can be
adopted.

This Jini mechanism for proxy distribution can be achieved in a CORBA
environment by using the Automatic Configuration Service\index{automatic
configuration} (see Chapter \ref{chap:autoconfig-service}) in conjunction with
a reflective ORB such as \dTAO (see section \ref{sec:dtao}). The Automatic
Configuration Service would fetch the proxy code and dynamically link it,
while \dTAO would use the TAO pluggable protocols framework
\cite{middleware2000} to plug the proxy code into the TAO framework.

Jini is typically limited to small-scale networks and it does not address the
management of component-based applications and inter-component dependence. Due
to the large memory requirements imposed by Java/Jini, this is not yet a
viable alternative for most PDAs and embedded devices.

\index{Jini|)}

\subsection{CORBA Component Model (CCM)}
\index{CCM|(}

The CORBA Component Model (CCM) adopted by OMG on November, 1999, specifies a
standard framework for building, packaging, and deploying CORBA components 
\cite{CORBA:components}.
Unlike our model, which focuses on
prerequisites and dynamic dependencies, the CORBA Component Model concentrates
on defining an XML vocabulary and an extension to the OMG IDL to support the
specification of component packaging, customization, and configuration.
We believe that our model and CCM complement each other and could be
integrated. CCM provides a static description of component needs and
interactions while our model manages the runtime dynamics.

Although CCM was already approved by OMG, publicly available ORBs do not support it
yet. Once this happens, we intend to work towards the integration of the two
models.

\index{CCM|)}

\subsection{ActiveX Controls, COM, and DCOM}
\index{COM}
\index{DCOM}

Microsoft's ActiveX Controls architecture \cite{ActiveX:candib,ActiveX:denning} 
also provides mechanisms for packaging, dynamic instantiation, and inspection
of the interfaces exported by COM components. Distributed components can
communicate via DCOM, which defines a protocol based on the Distributed
Computing Environment (DCE) RPC specification \cite{DCE94}. The architecture
is tailored to Microsoft operating systems and very little was done to support
interoperability with other platforms. As shown in \cite{dcomXcorba98},
implementing DCOM clients and servers is clearly more complicated than writing
CORBA clients and servers. The architecture provides no support for dependence
management.

%activex defines a low-level memory layout for components, right? Since this layout
%was defined to match that of C++, it may be not so natural to map it to other languages.
%CORBA is more language-independent. I'm not sure about this. Renato could help.

\subsection{OpenDoc and OpenStep}
\index{OpenDoc}

OpenDoc \cite{orfali96}, promoted in the past by Apple and CI Labs, defines a
compound document infrastructure based on IBM's SOM and CORBA.  Its design
influenced modern component architectures but it was abandoned in favor of
Java Beans.  Apple is now supporting CORBA, Java Beans, and ActiveX in their
OpenStep environment \cite{OpenStep}. OpenStep is an object-oriented software
development environment that runs on top of Mach, Windows NT, Solaris, and
HP-UX and provides an interface independent of the underlying operating
system.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Prerequisites}
\index{prerequisites|(}

A few systems dealt with concepts similar to the prerequisites
presented in section \ref{sec:prerequisites}, thus addressing parts of the
problem of dependence management.

\subsection{Job Control Languages}
\index{JCL}

The concept of prerequisites has its origins in the Job Control Languages of
the mid-1960s. The OS/360 operating system, deployed in a wide range of
IBM computers, used JCL \cite{jcl:71} to control the multiple jobs in its
innovative ``multiprogramming'' environment. The \texttt{JOB} statement, in
JCL, may have a series of keyword parameters of the form $<$\texttt{NAME=value}$>$
to specify certain characteristics of the job. The statement 
\begin{verbatim}
//Little2KJob     JOB     TIME=(3,45) REGION=20K PRTY=5
\end{verbatim}
specifies that the job \texttt{Little2KJob} takes approximately 3 minutes and
45 seconds to run, requires approximately 20 Kbytes of memory and must be
executed with priority 5. Thus, the parameters of the \texttt{JOB} statement
can be seen as a primitive version of the ``hardware prerequisites'' portion
of a SPDF\index{SPDF} specification (see section \ref{sec:SPDF}). 


\subsection{SOS}
\index{SOS}

The use of the term ``prerequisites'' to refer to the dependencies of
operating system objects originated in the SOS operating system
\cite{SOS,shapiro94} developed at INRIA, France. In the SOS model, objects
contain a list of prerequisites that must be satisfied before they are
activated. Even though the idea was promising, it was not fully explored in
that project. Prerequisites were only used to express that an object depends
on the code implementing it and not much experimentation was carried out
\cite{shapiro89:persistence,shapiro-personal}. Besides, SOS does not include 
a model for dynamic management of inter-component dependence.

\subsection{Dynamically Loadable Libraries}
\index{DLLs}

Modern operating systems, like Solaris, use an explicit
representation of the dependencies among shared libraries to implement dynamic
linking \cite{dynamicLinking97}. A shared library contains a list of the
pathnames of other libraries upon which it depends. The system tries to locate
all the required libraries before executing any application code.

Our approach can be seen as an extension to that, since it uses a
representation of dependencies to support dynamic loading. The difference is
that our approach is able to represent dependencies among generic components
(not only shared libraries) in heterogeneous, distributed environments and it
uses this representation to support different kinds of (re)configurations (not
only dynamic linking).


\subsection{Globus and RSL}
\index{Globus|(}

The Globus project \cite{globus98} provides a ``computational grid''
\cite{grid-book:99} integrating heterogeneous distributed resources in a
single wide-area system. It supports scalable resource management based on a
hierarchy of resource managers similar to those of \twoK \cite{tomoMS}. But, unlike
\twoK, Globus is tailored to computationally-intensive applications such as
large-scale simulations and teleimmersive applications.

Globus defines an extensible Resource Specification Language (RSL)\index{RSL}
that is similar to our SPDF. RSL \cite{globus-RSL} allows Globus users to
specify the executables they want to run as well as their resource
requirements and environment characteristics.

RSL could be integrated in our system by plugging an \class{RSLParser} into
our Automatic Configuration framework. A fundamental difference between Globus
and our work is that we focus on \emph{component-based} applications that are
dynamically configured by assembling components fetched from a network
repository. In Globus, on the other hand, the user specifies the application
to be executed by giving the name of a single executable on the target host
file system or by giving a URL from which the executable can be fetched.

Although the Globus design includes a service for managing application code
(the Globus Executable Management service or GEM), the current implementation
does not include it as a separate service. The name of this service, however, implies that
Globus views an application as a single executable, rather than a collection of
components that can be dynamically instantiated.  Since Globus is one of the
most important works in this area, we hope that their system evolves to
incorporate support for dynamic component-based applications.

\index{Globus|)}

\index{prerequisites|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{WYNIWYG in Operating Systems}
\index{WYNIWYG}

The idea of building a small system core that could be extended in different
ways depending on user and application requirements was explored extensively
by previous work on customizable operating systems, microkernels, and
exokernels. As discussed below, this research created the basic mechanisms
that enable extensions to operating systems, but it did not reach far enough
to provide a real ``what you need is what you get'' model as the one described
in section \ref{sec:autoconfig}.

\subsection{Customizable Operating Systems}
\index{Choices}

Systems like Choices \cite{campbell:cacm} let
 administrators build a new instance of the kernel by specifying
 at compile or link time which mechanisms to
 use in the various subsystems.
System developers implement a fixed set of modules from which
the administrator can choose to construct a certain instance of the kernel. Different
modules contain different implementations for virtual memory, file system,
 networking, and so on.
In addition, users can choose to implement a new mechanism
  by writing a new system module. 
Unfortunately, implementing a new system module requires
 intimate knowledge of system internals and conventions.
As a result, extending the system is not as easy as expected.

Choices contributed very significantly to the field of operating system design
 and construction as it showed how principles of object-orientation and design
 patterns can help to build efficient systems more easily. But it did not
 address the problems of dynamic configuration or how to express the
 requirements for constructing the system. The choice of which modules would
 compose each instance of the kernel were left to a human administrator that
 edited Makefiles manually.

\subsection{Microkernels}
\index{microkernels}

Mach \cite{MachDesign}, SPIN \cite{bershad:spin},
\uChoices \cite{uc-java96}, and L4 \cite{l4}, are operating systems with a
small core, called microkernel, that runs in privileged mode. A collection of user-level
processes, running on top of this small core, support services that are traditionally
provided by the kernel in monolithic systems.
Thus, administrators can configure the system by selecting different sets of
user-level services to be executed in each machine. So, even if all the
machines in a network run the same microkernel, their services can be adjusted
to the requirements of their users.

Some microkernels also provide mechanisms for modifying their
configuration dynamically by adding new modules at runtime.
\uChoices can, for example, dynamically load a new
 module written in Java into its kernel.
The code is then run by a JAVA
 interpreter that resides in the kernel.
SPIN can load modules written in the
 type safe language Modula-3 and then compiled by a trusted compiler.
Synthetix \cite{synthetix96} dynamically generates new
 code that is specialized to provide improved performance for a 
 particular situation.

\subsection{Exokernels}
\index{exokernels}

The concept of exokernels, first introduced by Engler, Kaashoek and O'Toole
\cite{exokernel95,exokernel97} and further extended by Ballesteros
\cite{ballesteros99:OOinOff,voff++99,off++97}, suggests that high-performance, 
configurable operating systems can be built by implementing a minimal kernel
exporting only low-level hardware abstractions. In these systems, traditional
operating system abstractions, such as processes and files, are implemented by
user-level libraries. Each application can be linked to different libraries at
runtime and, therefore, use customized system abstractions.  Exokernels have
one major objective: to export the hardware resources safely.

\subsection{Comparison with our Approach}

As described above, customizable operating systems, microkernels, and
exokernels supported system configuration using low-level
techniques for linking new modules into the operating system in
kernel and user space, either statically or dynamically. 
However, all of them lack a high-level model for operating system
configuration and reconfiguration.
Although they permit the establishment of different, customized system
configurations, they do not have any model for expressing the requirements of
user and applications with respect to system modules. All the work is left to
the system administrator, who must know about all users, all applications, and
have total control over the configuration.

The model presented in this thesis is an integrated solution to the problem
of configuring operating systems. Each system module, application, and user defines
its requirements explicitly. The system processes all this information and
configures the user environment automatically to provide exactly what is
needed, no less, no more.

Previous work in operating systems have not addressed
a number of problems related to fault-tolerance and dynamic reconfiguration.
Using prerequisites and the \class{ComponentConfigurator} framework, this thesis shows
how a system can answer the following questions.
\begin{itemize}
\item What system modules are needed to support the user's environment?
\item What system modules are needed to run a particular application?
% with this quality of service.
\item When a system module is replaced, which other modules are affected? 
\item How must those other modules react?
\item If a system component fails, how can the system detect it and recover
gracefully?
\end{itemize}

By answering these questions, this thesis presents a framework that
helps future research efforts to address the following questions.

\begin{itemize}
\item What are the consequences of reconfiguring the system? 
\item What is the cost of reconfiguring the system?
\item When (re)configuring the system, which components must be loaded to meet 
the required quality of service in light of dynamic system conditions?
\item When is it time to reconfigure the system?
\end{itemize}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



\section{Software Architecture}
\label{sec:soft-arch}
\index{software architecture}

As the complexity of software increases, the design of the overall system
architecture (also known as \emph{programming in the large}) becomes even more important
than the choices of the individual algorithms and data structures that are used
in each component (\emph{programming in the small}). Software architecture is an
emerging discipline in software engineering that aims to teach developers to
program in the large effectively.

Many of our ideas regarding how to deal with dynamic configuration extend
previous work in the field of software architecture. We now discuss some of
the most important work in this area and, in Section \ref{sec:comparison},
explain how our approach differs from them.

\subsection{Software Buses}
\label{sec:software-buses}
\index{software buses|(}

James Purtilo's group developed the Polylith\index{Polylith} system
\cite{polylith94} in which components interact with each other through
\emph{software buses}. The major idea behind Polylith is that it would allow
programmers to implement functional aspects of components separately from
their interfacing aspects. Components interface with the bus only, while
Polylith provides different implementations of the bus using different
communication protocols.

Polylith can be seen as one of the precursors of OMG's CORBA, helping
programmers to interconnect software components written in different languages
and executing them in heterogeneous environments. CORBA, in turn, can be seen
as a particular implementation of the software bus concept.

Surgeon\index{Surgeon} \cite{surgeon93} is a tool for building dynamically reconfigurable
applications based on Polylith. Based on \emph{module specifications} and
\emph{application specifications}, Polygen \cite{polygen91} integrates
application modules and builds executable files. Surgeon pre-processes
modules that are subject to dynamic reconfiguration instructing Polygen about
how the modules must be packaged. At execution time, Surgeon agents, called
\emph{catalysts}, manage the reconfiguration process. The catalysts automate
the process of updating the bindings between a module being replaced and the
modules with which it communicates.

Surgeon works with a limited set of applications in which the modules do not
need to participate in the reconfiguration process. As identified in their
research, this implies that the modules that are safely reconfigurable using a
catalyst must satisfy the following conditions.
\begin{enumerate}
\item The module's state can be safely discharged during reconfiguration.
\item Modules must be able to start without receiving state from old modules.
\item There must be no synchronization between the reconfigurable module and
its neighbors. For example, modules that use synchronous calls with return
values do not satisfy this condition. Thus, modules must use asynchronous
messages for communication only.
\end{enumerate}

In her PhD thesis \cite{hofmeister94}, Christine Hofmeister extends this work
presenting a framework for dynamic reconfiguration of distributed programs
with module participation \cite{hofmeister93}. Although this framework does
not support the degree of automation that Surgeon does, it does not require
that the component state be discharged. Instead, they apply a technique
suggested by Herlihy and Liskov, for transmission of abstract data types
\cite{herlihy82}. Each module is responsible for exporting its internal state, 
by implementing an \texttt{encode} operation, and for importing state through a
\texttt{decode} operation. In addition, programmers must carefully design
application modules so that they can reach a stable state for reconfiguration.
When a user requests a module reconfiguration, the module continues its
execution until a stable state is achieved.  The entire application need not
be suspended for reconfiguration; only the affected modules are.

Aster\index{Aster} \cite{aster96} is an implementation of a software bus on top of
CORBA. Instead of allowing components to implement and use arbitrary interfaces
defined with IDL, Aster components interface with a bus written in CORBA. This
bus supports only one interface which contains operations like
\texttt{sendBus(out msg m)} and \texttt{receiveBus(in msg m)}.
In section \ref{sec:related:dynconf}, we describe ongoing work on supporting
dynamic configuration in the Aster environment.

\index{software buses|)}

\subsection{Architectural-Awareness}
\label{sec:architectural-awareness}
\index{architectural-awareness}

Sefika addressed the issue of architectural-awareness in the Choices operating system,
emphasizing quantitative aspects of the interaction between objects in the
Choices kernel \cite{sefika:osview,visualization:oopsla}.
The goal was to monitor compliance of the system with its design 
models \cite{sefika:compliance}.

The motivation of our research, however, is to extend that concept to
a broader group of software systems including, not only operating system
kernels, but also system libraries, distributed services, and user-level
applications. Also, rather than concentrating on the quantitative aspects of
the interactions, our work focuses on representing dependencies among software
components to support automatic configuration, reliability, and QoS.

\subsection{Architectural Description Languages}
\label{sec:adl}
\index{ADL|(}

Architectural Description Languages (ADLs) provide a way for practitioners to
define the architecture of their systems using a formal notation. Thus, they
can present their architectures to other people, reason about them, and even
submit the descriptions to automated tools to analyze their
consistency\index{consistency} or generate code automatically.

ADLs evolved as an extension of Module Interconnection Languages (MILs) first
defined in 1975 by DeRemer and Kron \cite{deremer:programming-in-the-small}.
MIL \index{MIL} compilers were able to build static systems by combining
different modules while ensuring system integrity by performing type-checking
at compile-time.  Early MILs posed a series of restrictions to software
developers, requiring that all the modules be written in the same language, be
available during system construction, and that each module describe the other
modules with which it interacts \cite{Unicon96}.

The research carried out by Kramer and Magee at the Imperial College in London
provided some of the most significant results in the area of ADLs and dynamic
configuration. After earlier work on the Conic\index{Conic}
\cite{magee89:conic} and Rex\index{Rex} \cite{kramer92:rex} projects, their
most recent research is based on the Darwin ADL.

Darwin\index{Darwin} has been used in environments like Regis\index{Regis}
\cite{darwin:regis94} and CORBA \cite{darwin:corba97} to specify the overall
architecture of component-based applications. A Darwin specification defines
all the components of an application and the communication interactions
between them. At application start time, the middleware loads all the
application components and establishes the links between them.

UniCon\index{UniCon} \cite{shaw96,Unicon96} introduced the concept of
\emph{Architectural Connectors}\index{connectors}, first class objects that
mediate the interactions between the components of a system. Components are
identified by their \emph{interfaces} and connectors are identified by
\emph{protocols}. Applications are built as composite components specified in
the UniCon ADL. A composite component specification contains three parts: (1)
a list of components to be instantiated, (2) a description of the connections
between the components inside the composite, and (3) a binding of the external
interface of the composite with the internal configuration. Given this
description, UniCon is able to build executable files and scripts that are
used to instantiate the whole application.

UniCon connectors implement various communication mechanisms such as UNIX
pipes, file I/O, and local and remote procedure calls. Developers may
associate an \emph{expert} to each connector. The expert is a piece of
executable code that is capable of building the executable code for the
connections and checking if a particular use of a connector is consistent. The
experts are called by the UniCon compiler as the application is built.


Olan\index{Olan} \cite{olan96,olan98} is an execution environment and an architectural
description language focusing primarily on distributed applications. The ADL,
called Olan Configuration Language (OCL), is an extension of Darwin that
includes two new abstractions: the \emph{connectors}, as in UniCon, and
\emph{collections}, that represent a dynamic set of objects that can be
controlled as a group by the configuration language.

In Olan, applications are organized as a hierarchy of components, where each
component may have a set of sub-components. A sub-component can be
instantiated dynamically in three ways: (1) at the same time as the enclosing
component, (2) when the first communication request reaches the sub-component,
or (3) when an explicit instantiation request arrives. These explicit
instantiation requests are used to build dynamic groups of components that are
stored in \emph{collections}. Thus, in contrast to traditional ADLs, where the
architecture of the system is statically determined by the ADL description,
OCL provides a little more dynamism by allowing \emph{collections} of
components whose contents are determined according to decisions made at
runtime.

The Olan developers implemented a prototype in the Python programming language
and made experiments with simple applications, like a configurable electronic
mail tool. They targeted Olan towards rapid prototyping and, as a consequence,
system performance was low. Other major drawbacks were the lack of a graphical
interface and the lack of support for dynamic reconfiguration and dynamic
replacement of components. Even with the limitations of its prototype
implementation, Olan may be, today, the most complete language for
representing software architectures.


\subsection{Comparison with our Approach}
\label{sec:comparison}

Systems based on architectural connectors like UniCon \cite{Unicon96} and
ArchStudio \cite{oreizy98} and systems based on software buses like Polylith
\cite{polylith94} separate issues concerning component functional behavior
from component interaction. Our model goes one step further by separating
inter-component communication from inter-component dependence\index{dependence
management}.  Connectors and software buses require that applications be
programmed to a particular communication paradigm.  Unlike previous work in
this area, our model does not dictate a particular communication paradigm like
connectors or buses. It can be used in conjunction with connectors, buses,
local method invocation, CORBA, Java RMI, and other methods. As shown in our
discussion about \dTAO (see section \ref{sec:dtao}), the model was applied to
a legacy system without requiring any modification to its functional
implementation or to its inter-component communication mechanisms.

Communication and dependence are often intimately related. But, in many cases,
the distinction between inter-component dependence and inter-component
communication is beneficial. For example, the quality of service provided by a
multimedia application is greatly influenced by the mechanisms utilized by
underlying services such as virtual memory, scheduling, and memory allocation
(e.g., through the \texttt{new} operator). The interaction between the
application and these services is often implicit, i.e., no direct
communication (e.g. library or system calls) takes place. Yet, if the system
infrastructure allows developers to establish and manipulate dependence
relationships between the application and these services, the application can
be notified of substantial changes in the state and configuration of the
services that may affect its performance.


\vspace{5mm}

Research in software architecture and dynamic configuration generally assumes
that the operating system is an omnipresent, monolithic black box that can be
left out of the discussion; it concentrates on the architecture of individual
applications.  Previous work in this field does not represent dependencies of
application components towards system components, other applications, or
services available in the distributed environment. Our approach differs from
them in the sense that, for each component, we specify its dependencies on all
the different kinds of environment components and we maintain and use these
dynamic dependencies at runtime.

Approaches based on software architecture typically rely on global,
centralized knowledge of application architecture. In contrast, our method
is more decentralized and focuses on more direct component dependencies.
We believe that, rather than conflicting with the software architecture
approach, our vision complements them by reasoning about \emph{all} the
dependencies that may affect reliability, performance, and quality of service.

The final solution to the problem of supporting reliable automatic
(re)configuration may reside on the combination of our model with recent work in 
ADLs and dynamic (re)configuration. This is certainly an important open
research problem to be investigated in the future (see chapter \ref{chap:future-work}).

\index{ADL|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\section{Dynamic Configuration}
\label{sec:related:dynconf}
\index{dynamic (re)configuration|(}

Following the early work on dynamic configuration performed by Bloom and Day
\cite{argus93} and Hofmeister \cite{hofmeister93}, a significant international
community organized around the International Conference on Configurable
Distributed Systems \cite{iccds98} has been working on the difficult problem
of dynamic configuration.

Oreizy, Taylor, and Rosenblum \cite{oreizy98:connectors,oreizy98} have
identified the need for an explicit representation of the system architecture
in order to support consistent, dynamic reconfiguration. In their model,
components interact with each other through \emph{Connectors}, which are used
both for communication and for representing the dependencies among groups of
components. However, because connectors are also used for group communication
(for broadcasting asynchronous messages), the model does not make it clear
whether two components linked by a connector really depend on each other. It
is a good idea to restrict the freedom of the application developer but, in
this case, they also restricted the expressiveness of the model.

Val\'erie Issarny at IRISA, France developed a Dynamic Reconfiguration Service
for CORBA \cite{bidan98}. In this work, a centralized Dynamic Reconfiguration
Manager (DRM) maintains a representation of the distributed system
architecture, receives requests for reconfiguration, and invokes the proper
distributed components to carry out the reconfiguration. Maintaining
application consistency\index{consistency} is the responsibility of the
application. The infrastructure guarantees that the semantics of the RPC is
kept consistent even if components are replaced on-the-fly.  Ongoing work
includes the integration of this Dynamic Reconfiguration Service in the
Aster\index{Aster} programming environment (see \ref{sec:software-buses}).


Shrivastava and Wheater \cite{reconfiguration:workflow} are currently working
on a workflow-based model\index{workflow} for distributed applications. In
their model, a scripting language \cite{reconfiguration:workflow:language} is
used to provide high-level descriptions of \emph{workflow schemas}. Schemas
represent the structure of \emph{tasks} in a distributed application with
respect to task composition and inter-task \emph{dependencies}.

The meaning of the term ``dependency'' in their work is directly related to
the workflow model and differs slightly from the one we adopt. A dependency
can be either
\begin{itemize}
\item a notification dependency (meaning that a task can only
start its execution after its dependency has completed its execution) or a
\item dataflow dependency (meaning that a task needs to receive input data
from another task before starting its execution).
\end{itemize}

A \emph{workflow execution service} coordinates the execution of the workflow
and helps to guarantee that reconfigurations will be performed in a
consistent way.  Each task is managed by a \emph{task controller} that handles
workflow dependencies and helps support reconfiguration.

A task is modeled as having a set of \emph{input sets} (analogous to our
\emph{hooks}) and a set of  \emph{output sets} (analogous to the
\emph{clients} in the component configurator model). Their \emph{workflow schemas} resemble our
\emph{prerequisites} slightly. Their \emph{task controller} resembles our
component configurator.\index{component configurator}

The main difference between their model and ours is that their model mixes the
representation of data flow, coordination, and inter-component
dependence. Their model is suited to expressing temporal workflow dependencies
among components in a certain application.  It does not address the
interactions between application components and system services.

However, it is important to note that, in Shrivastava and Wheater's model,
users are able to specify what the requirements for application tasks must be,
so that reconfigurations can be performed in a consistent way. This problem is
out of the scope of our work and it could be a PhD thesis in itself. Our
framework, however, gives developers the chance to write code to take care of
consistency\index{consistency} inside the component configurators.

\index{dynamic (re)configuration|)}

\section{Application Scenarios}
\label{sec:related-application-scenarios}

Using the architecture for dependence management and automatic configuration
presented in this thesis, we were able to implement two novel applications,
the multimedia distribution system and \dTAO.  These applications provided
original contributions to the research in their respective Computer Science
fields. We now discuss previous work in these fields and emphasize our
contributions.

\subsection{Multimedia Distribution System}
\index{Reflector|(}

Our research on the multimedia distribution system benefits from and builds on
previous work on IP-Multicast \cite{deering:host-extensions} and the Internet
MBone \cite{mbone92,mbone-book96}.  The MBone is a virtual network that is
layered on top of the Internet to support routing of IP-Multicast packets.  It
is composed of islands that can directly support IP-Multicast (e.g., multicast
LANs connected by multicast-capable routers), linked by virtual point-to-point
links called \emph{tunnels}.  The system described in this article can be seen
either as extending the MBone capabilities or, (since we also support
IP-Multicast) as a set of tools for managing MBone broadcasts.  The MBone
relies on a multicast distribution engine that is hard-wired into the
networking infrastructure, making it difficult to deploy new technologies for
distribution. Our approach not only uses user-level entities that can be
replaced easily, but it also supports dynamic reconfiguration of running
systems, allowing for easy incremental evolution of the communication
mechanisms with respect to QoS, security, and reliability.

Amir, McCanne and Katz developed an \emph{active service framework}
\cite{amir98:active-service} that provides support for the dynamic
instantiation of server agents (or \emph{servents}), providing the desired
service, in a collection of distributed nodes running their host manager (HM)
daemon. They used this framework to implement a Media Gateway (MeGa) service
\cite{amir95:video-gateway}. Like our Reflector, the MeGa service can be used to
transcode multimedia streams. In fact, their research has focused on
algorithms for efficient transcoding and down-sizing and, more recently, on
adaptive bandwidth allocation algorithms \cite{amir97:scuba} and on the
dynamic instantiation of media gateways between MBone sessions to deal with
heterogeneous networks. Our research on the Reflector architecture shares some
concerns with their active service framework (which has some similarities with
our Automatic Configuration Service\index{automatic configuration}) and with
their MeGa service (which could be implemented in our architecture with
customized \class{Connection} classes loaded into the
Reflector). Nevertheless, we also focus on providing scalable multimedia
distribution using multiple communication protocols, reconfiguration of the
network topology to deal with failures, and scalable code distribution and
dynamic reconfiguration.

Baldi, Picco, and Risso designed a videoconference system based on active networks
\cite{baldi98:video-active-nets}. Their proposed architecture allows
clients to customize their videoconference server (or Reflector) by uploading
mobile Java code. The main difference is that, in their approach, the
Reflector is designed to run in active network routers while ours is designed
as a user-level application to be executed on networked workstations. Our
infrastructure for mobile reconfiguration agents\index{agents} plays the same role as the
active network in their system. We chose to implement our system in C++ because
our experience shows that Java is not yet ready to provide the
high-performance and predictability that most QoS-sensitive applications
require.

\index{Reflector|)}

\subsection{\dTAO}
\index{dynamicTAO@\dTAO|(}

Recent research in middleware have identified a number of limitations on
first-generation CORBA implementations. This has led to ORB extensions for
dealing with specific aspects such as real-time~\cite{schmidt:rt-events},
group communication~\cite{maffeis:group}, and
fault-tolerance\index{fault-tolerance} \cite{maffeis:ft-corba}. The goal of
\dTAO, on the other hand, is to provide a generic infrastructure in which
different kinds of customizations can be performed using reflection.

Other research groups have addressed the problem of middleware customization
by using different approaches.  The Operating Systems group at the
Friedrich-Alexander University of Erlangen-N\"{u}rnberg is developing AspectIX
\cite{AspectIX}, a configurable middleware architecture based on
the fragmented object model.  AspectIX clients would interact with a fragment
of the global object (the fragment implementation) by using an interface (the
fragment interface).  The global object could be configured by using
``profiles'' which in turn specify ``aspects''\index{AOP} that must be
supported by the fragment implementations.  AspectIX Aspects can be compared
to \dTAO category implementations, the difference being that \dTAO
implementations can be added on-the-fly. The AspectIX group plans to implement
a prototype of their model where each object running within a single ORB would
be able to specify its own policies and protocols. In \dTAO, a similar effect
could be achieved by using different ORBs inside a single process and
configuring each of the ORBs in a different way. In the \LegORB
model\index{LegORB}, on the other hand, the ORB can be configured to support
either of the two approaches.

Blair and others at Lancaster University has proposed a
reflective\index{reflection!reflective ORB} architecture for next generation
middleware \cite{blair98:next-gen-mid,costa99:reflective-mid,blair:rm2000}. They
developed a prototype using the Python interpreted language in which the
programmer is able to inspect and change the implementation at runtime. The
level of reflection is much higher than in \dTAO since, in their Python
system, it is possible to add or remove methods from objects and classes
dynamically and even change the class of an object at runtime. Their research
has emphasized dynamic configurability through a well-defined \emph{open
binding} model which allows multiple reflective levels. In contrast, our
research concentrates on a simpler reflective model, focusing on high
performance. In our model, the reflective mechanisms are not included in the
normal flow of control, they are only invoked when needed. The group is now
investigating (1) an efficient implementation of their reflective architecture
using lightweight components in a COM/C++ environment and (2) the use of
\emph{component frameworks} \cite{parlavantzas:rm2000} to manage the
development of meta-interfaces in a robust and meaningful way.

COMERA \cite{wang:comera} (COM Extensible Remote Architecture) provides
a framework based on COM that allows users to modify several aspects of
the communication middleware at run-time.
It relies on the \emph{Custom Marshaler} interface exported by COM, as well as
 a componentized architecture design that allows the use of user-specified
 components. 
Like in \dTAO, by using COMERA, system developers can customize the middleware 
 according to application requirements.

Our work in \dTAO is an extension of previous work in reflective middleware
\index{reflection!reflective middleware} carried out by Ashish Singhai in our
research group. Singhai developed a prototype of a reflective ORB that could
be customized at startup time by selecting policies for real-time invocation,
fault-tolerance, and load balancing \cite{singhai97:reflectiveORB}. His PhD
thesis presented \emph{Quarterware}\index{Quarterware}, a middleware
construction technique and a toolkit to help developers build customized
middleware systems. Using Quarterware components, one can build communication
middleware systems as diverse as MPI and Java RMI
\cite{singhai98:qw,ashishPhD}.

%We believe that our work in reflective middleware has influenced a number of
%middleware researchers. 

\vspace{5mm}

The middleware community \index{reflection!reflective middleware} is starting
to realize that static middleware infrastructures are not appropriate for the
highly dynamic environments of the future. A trend towards more flexible
middleware architectures could be observed in the recent IFIP/ACM Middleware
conference \cite{middleware2000} and its Workshop on Reflective Middleware
\cite{RM2000}.

\index{dynamicTAO@\dTAO|)}