\chapter{Future Work}
\label{chap:future-work}

As noted by a forgotten scientist, ``We live on an island surrounded by a sea
of ignorance. As our island of knowledge grows, so does the shore of our
ignorance''.  The work on this thesis contributed immensely for the
enlargement of the shore of the author's ignorance. In the following sections,
we discuss six topics for future research that we consider particularly
important.

\section{Libraries of Customized Component Configurators}
\index{component configurator!future work}

The software infrastructure resulting from this thesis includes a few basic
types of component configurators providing some basic functions. According to
our model, component developers are responsible for implementing
application-specific (or component-specific) policies by implementing
customized subclasses of component configurators.

In future research, we intend to investigate the possibility of developing
various libraries containing customized versions of component configurators
that can be reused in different applications and systems.  In the same way that
component-based programming lets developers build complex applications by
selecting appropriate off-the-shelf components, we envision a future in which
application developers will be able to add a wide range of non-functional
features, simply by selecting appropriate versions of component configurators.
\index{component configurator}

In the near future, we will study the design of libraries of component
configurators supporting reconfiguration, fault-tolerance, adaptability,
scalability, and migration.

\section{Automatic Prerequisite Generation and Verification}
\index{prerequisites!future work}

In the current implementation of our architecture, we rely on developers to
write consistent prerequisite specifications for the components and
applications they create. It would be desirable to automate the
creation of prerequisite specifications and to develop tools to verify their
correctness.  This is a difficult problem that will require many years to be
solved. Tools like QualProbes \cite{nahrstedt00:qualprobes} address part of
the problem by automating the creation of prerequisites specifying application
resource requirements.

The prerequisite resolver should also be extended to detect inconsistencies on
the prerequisite specifications. These inconsistencies could lead to deadlocks
or infinite loops, compromising system liveness.

\section{Dynamic Adaptability}
\label{sec:future-adaptability}
\index{adaptation}

Although the prerequisites are primarily used for loading new components into
the system and making sure that their quality of service expectations are met,
they are also useful for dynamic adaptation in case of changes in
resource availability. Resource requirements expressed in the
prerequisites should specify ranges of acceptable service. A
video-on-demand application, for example, could specify that it requires a
network bandwidth of 1.2Mbps on average, but that it may utilize peak rates of
up to 2Mbps. Finally, it could add that, even though 1.2Mbps is the desirable
average bandwidth, it would still be able to function by using as little as
53Kbps by changing the characteristics of the video stream. In that case, the
application would be able to support mobile computers moving from ATM to
wireless, to modem connections, adapting to these changes dynamically. Thus,
prerequisites should be available to the system at runtime so that it can
reorganize its allocation of resources to fulfill better the
requirements of all applications sharing the system.

An interesting topic for future research is how to use, modify, and generate
prerequisite specifications at runtime with minimal interference in performance.

\section{Integration with ADLs}

As noted in section \ref{sec:comparison}, we believe that our component
configurators and Architectural Description Languages\index{ADL} address
complementary issues. Our model is dynamic and focuses on localized
inter-component dependence, while ADLs are static and focus on global
architectures. Combining both approaches in a single model is a fascinating
challenge. Since the two approaches are not completely orthogonal to each
other, their integration is non-trivial.

\section{Component Repository}
\label{sec:future-comp-rep}
\index{component repository!future work}

The current implementation of the \twoK component repository is very simple
and works as a CORBA repository of files that can be organized in a
hierarchical directory structure. As future work, it would be important to
develop a more sophisticated component repository with support for security,
version control, garbage collection, and fault-tolerance. 

To provide scalability it will be required to replicate the repository and
offer mechanisms to update collections of repositories with new
components. This could be achieved with the help of our mobile agents
infrastructure. In this case, it would be important to investigate policies
for maintaining the consistency among the repository replicas.

The security requirements include (1) mutual authentication between the
repository and its users, (2) controlling the access to the repository
contents, and (3) digitally signing the components stored in the repository.

\section{Security}
\label{sec:future-security}
\index{security!future work}

In networked environments, it becomes necessary to secure
the configuration system from unauthorized access.  A hostile agent that
obtains access to component configurators may be able to totally
disrupt system activities. Even read-only access may be dangerous as sensitive
information about the internal structure of an institution's system may be
stolen. Therefore, it is important to provide support for controlling the
access to the configuration system. In some cases, it is also desirable to
avoid eavesdropping by encrypting the messages exchanged by components and
component configurators, for example, those containing
reconfiguration events.

To support security in environments such as Java with RMI, it is necessary to
extend the configuration model, making it security-aware.  On the other hand,
in environments supporting reflection\index{reflection} and in CORBA, it is
possible to define security policies and deploy security mechanisms without
modifications to our model.

Using the CORBA Security Service \cite{CORBA:services}, it is possible to add
\emph{message-level interceptors} into the ORB so that data exchanged
between CORBA objects are properly encrypted. In addition, \emph{request-level
interceptors} can control the access to each individual operation on
component configurators based on who is issuing the call, based on
capabilities, or based on any other customized mechanism defined by the
programmer.

\section{Concurrency}
\label{sec:future-concurrency}

In multi-threaded and multi-process environments, we must take additional care
with regard to reliability and consistency since two threads accessing the
same object concurrently may leave the system in an inconsistent state or
cause its failure. One of the \class{ComponentConfigurator} subtypes offered
by our framework uses locks to protect the configurator from simultaneous
updates by multiple clients. These locks can also be used by clients to
perform a sequence of operations on a single configurator without interference
from other clients.

At the present moment, our framework does not provide any guarantee that a
group of reconfiguration actions performed in a collection of configurators
will be processed as a single unit.  In a CORBA environment, one could
coordinate the access to distributed configurators by using  the standard
Concurrency Control Service \cite{CORBA:services}.  Ideally, a reconfiguration
system should provide support for grouping operations into atomic transactions
satisfying the ACID properties, i.e., atomicity, consistency, isolation, and
durability. This requires further research but it could be achieved with the
help of the CORBA Object Transaction Service \cite{CORBA:services}.

