% $Id: relwork.tex,v 1.5 2006/04/14 22:53:03 gokhale Exp $


\section{Related Work}
\label{sec:relwork}

% Priya, please add whatever you can. We will supplement it. Maybe we
% can add some relwork on previous generation R&D, as well as some of
% the emerging multi-tier FT R&D by Kemme et al. - Andy


The Fault Tolerant CORBA standard~\cite{CORBAService:99c} specifies
reliability support through the replication of the CORBA servers, and
the subsequent distribution of the replicas of every server across the
nodes in the system.  The idea is that, even if a replica (or a node
hosting a replica) crashes, one of the other server replicas can
continue to uphold the server's availability.  While our
mechanisms target support for both GCS and TCP clients, the
consistency issues differ across the two kinds of clients because the
GCS clients can exploit totally ordered messaging guarantees while the
TCP clients cannot, making them more complicated to handle.

The Fault Tolerant CORBA standard outlines a list of interfaces that
constitute a fault-tolerance service and emphasizes that strong
replica consistency should be provided in order to ensure effective
fault-tolerance.  Several fault-tolerant CORBA systems (Eternal, OGS,
IRL, FTS, AQuA, DOORS, Orbix+Isis, Electra)~\cite{PFPN:IeeeTocs} have
emerged over the past decade. These systems have tended to require all
of the objects of the CORBA application to be replicated and hosted
over the fault-tolerant system. The Fault Tolerant CORBA standard,
driven in part by the needs of vendors and real-world customers,
incorporated the notion of fault-tolerance domains for scalability and
ease of administration.  Each fault-tolerance domain handled the
replication of only its constituent objects, thereby making it
possible to manage the large fault-tolerant applications by
decomposing them into appropriate fault-tolerance domains.

The standard introduced the idea of a gateway to allow unreplicated
clients running over non-fault-tolerant CORBA systems to invoke
replicated objects that were located within fault-tolerance
domains. However, the standard remains sketchy in its description of
the gateway's implementation details, merely mentioning that the
gateway's addressing information needs to be supplied to unreplicated
clients outside the domain.
Gateways~\cite{Felber:gateway,NMM:Middleware} and (predecessor)
gateway-like client-side support~\cite{Vaysburd:gateway} represent
successful designs for supporting 
two-tier CORBA applications with an unreplicated client. However, to
the best of our knowledge, this previous work does not include an
in-depth critical look at the end-to-end consistency issues in
mingling unreplicated/TCP and replicated/GCS semantics, and has also
not included any empirical assessment of the attendant scalability and
performance issues. The approach that we describe in this paper was
born out of the lessons that we learned first-hand in implementing
such a gateway~\cite{NMM:Middleware} -- thus, we aim to understand,
articulate and resolve the underlying consistency challenges, as well
as to quantify the actual performance overheads of the resulting
system.

Our work on MEAD~\cite{Mead:CCPE} goes beyond previous fault-tolerant
CORBA systems in aiming for adaptive fault-tolerance (where the key
replication properties of the system can be modified at runtime based
on various system conditions), proactive fault-recovery (where
pre-failure symptoms can be extracted from the system to provide
advance notice of an impending failure, thereby paving the way for
preemptive recovery action) and support for nondeterministic
applications (where the application is analyzed for nondeterministic
actions and appropriately handled, rather than forbidding programming
practices such as multithreading). 

GroupTransactions~\cite{Patino:2002} aim to take advantage of both group
communication and transactions through a new transactional model, where
transactional servers can, in fact, be groups of processes. This allows
for transactional applications to be built on top of computer clusters.

An e-Transaction~\cite{Frolund:2001} is one that executes exactly once
despite failures, and is targeted at three-tier enterprise
architectures with stateless middle-tier servers that are
replicated. This overcomes the limitations of current transactional
technologies that, for the most part, ensure at-most-once request
processing, which is not sufficiently reliable. The e-Transaction
abstraction builds upon an asynchronous replication scheme that
provides both the liveness feature of replication, as well as the
safety feature of transactions.

Another CORBA-related effort~\cite{Little:2000} aims to compare the two
different kinds of systems --- one with group communication and no
transactions, and the other with transactions and no group communication
--- from the viewpoint of replicating objects for availability. Their
study leads them to conclude that although transactions are effective in
their own right, using group communication infrastructures to support
transactional applications can lead to benefits, such as faster
failover in the event of a fault.

While all of the above replication schemes refer to objects or
servers, the notion of integrating group communication into a
transactional model has been extended to the replication of the entire
database itself~\cite{Kemme:1998}. This work attempts to eliminate the
centralized and, therefore, unreliable approach that databases adopt
today. The proposed family of replication protocols exploit group
communication semantics to eliminate deadlocks, improve performance,
and enhance reliability.


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