% $Id: conclusions.tex,v 1.4 2006/04/14 22:53:03 gokhale Exp $
\section{Conclusions}
\label{sec:conclusions}

This paper has described an ambitious effort we undertook to make a
realistic DRE system fault tolerant.  We had two goals in mind when
undertaking this endeavor.  The first, obviously, was to make the DRE
system fault tolerant.  The second was to advance the state of the art
in middleware support for fault tolerant DRE applications.  This second
goal intended to help us avoid building a one-of-a-kind point
solution and to provide artifacts that would be reusable in future
versions of this, and other, DRE systems. 

The main conclusion we can draw from this work is that there is no
one-size-fits-all fault tolerance solution.  The tendency for real
system builders to build hand-crafted solutions has come as much from
necessity as from any immaturity of fault tolerance solutions.  The
development of a fault tolerance solution must start with the primary
fault tolerance {\em requirement}, which in our case was near constant
availability, or very rapid recovery of the MLRM infrastructure.  These
requirements lead one in the direction of a solution, in our case
active replication.  The characteristics of the application then start
to come into play and affect the applicable techniques, for example

\begin{itemize}
\item Whether the application is accessible to modification
\item Whether the application is nondeterministic and whether the
      nondeterminism is necessary or accidental
\item How much state the application has and how often the state is changed
\item Whether the application is always a client, always a server,
      sometimes a client and sometimes a server, or whether it is
      simultaneously a client and server 
\item Other characteristics, including whether it is object-based,
      component-based, or database-based.
\end{itemize}

Each of these, and many more factors, influence the fault tolerance
techniques that are applicable and how they must be applied.  The state
of the art of fault tolerance technologies when we started this
project was a number of available fault tolerance software bases, but
which usually provided fault tolerance only to a limited subset of
application types.  For example, several solutions based on the Fault
Tolerant CORBA specification provide fault tolerance for replicated
servers in single-tiered, client-server, single language applications
and were pervasive.  Many of these were pervasive, forcing the entire
system to be placed under control of a fault tolerance manager or on
top of a group communication package.  Other fault tolerance software,
such as MySQL, provide replication of databases with strict
transactional semantics, but no support for the fault tolerance of
other elements besides the database.  In contrast, few large software
systems, including the DRE system we are working with, have such
simple, restricted characteristics.  The DRE system we describe in the
paper is multi-language; with elements requiring different levels and
types of fault tolerance (some needed constant availability, others
less so); includes databases, clients, servers, and client/servers;
and a combination of CORBA objects, CORBA components, and non-CORBA
applications.  This required us to make some significant advances in
the state of the existing fault tolerance capabilities: 

\begin{itemize}
\item Enabling the coexistence of multiple fault tolerance strategies
      (active and passive replication, as well as replicated DB
      elements) in the same system 
\item Enabling the coexistence of group communication and non group
      communication 
\item Supporting multiple ORBs within the same fault tolerant system
\item Supporting peer-to-peer interactions, i.e., elements that could
      be clients or servers at any time and simultaneously
\item Supporting multiple language applications, C++ and Java
\item Supporting CORBA components
\item Supporting multi-tiered applications
\end{itemize}

As much as possible, we have developed these additional capabilities
to be independent of the application and to be part of the middleware
fault tolerance infrastructure.  Part of the significant challenge of
the effort described in this paper has been the seamless integration
of these new technologies to form the right fault tolerance solution
for our DRE system.  Our next step is to capture this integration and
configuration process to form the basis for a {\em toolkit} approach
to fault tolerance.  The objective is to develop a fault tolerance
toolkit, initially populated with the fault tolerance infrastructure
pieces we have developed.  The toolkit would support the development
of fault tolerance solutions tailored to the needs of the application,
constructed by integrating, configuring, and customizing the
elements of the toolkit, without having to start from scratch and
build one-of-a-kind solutions. 


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "middleware-2006"
%%% End: 
