% $Id: challenges.tex 5104 2007-01-07 15:40:35Z gokhale $

\section{Design Considerations for Automated Dependability Provisioning}
\label{sec:challenges}

Several factors must be considered when developing a dependability
provisioning tool, such as MDDPro, for enterprise DRE systems.  In
this section we use a sample enterprise DRE system as a guiding
example to outline the requirements of such a design-time tool.


\subsection{Enterprise DRE System Case Study}
\label{sec:sample}

Figure~\ref{fig:sample} illustrates a sample enterprise DRE system
drawn from representative domains, such as avionics mission computing
or shipboard computing, where variables of interest are sensed by the
sensor equipment, which are software controlled and fed to a set of
planners who determine the appropriate control action to be taken, and
subsequently relay this information to the actuator software
components.

\begin{figure}[htb]
  \centering
  \vspace{-0.5in}
  \includegraphics[width=4in,keepaspectratio]{figs/slice}
  \vspace{-1in}
  \caption{A Sample Enterprise DRE System}
  \label{fig:sample}
\end{figure}


Enterprise DRE systems are often deployed over heterogenous platforms,
which consist of multiple different networks, hardware and several
layers of software.  We consider the fact that failures may occur in
any of these entities.  For example, node failures, operating system
crashes, middleware broker process failures, and even network link
failures are common.  In our current discussion we do not consider
multiple cascaded failures. 

Quite often the critical functionality of enterprise DRE systems is
spread across multiple components.  For example, the planning activity
in Figure~\ref{fig:sample} is spread across two planning components,
which could be deployed in separate application servers on different
hosts.  Since these distributed set of components form a unit of
critical functionality, for high availability and even for the
correct operation of the system, it may be required that all such
components in the critical path be protected against failure.  

Moreover, if any of these individual components fail, it may not be
sufficient to recover only the failed component but rather the
failover should recover a group of critical components.  This is
because failure recovery takes finite amount of time and therefore by
the time the failed functionality is recovered, the system may lose
some critical system events.  Therefore, it is highly desirable in
such situations to failover to another identical replica of the
protected group of components although the failure may occur in only a
single component.  Thus, the fault recovery granularity can be much
larger than the system elements affected by the single failure.  
 
Risk management and availability considerations in enterprise DRE
systems involve how individual or groups of critical components are
replicated and deployed.  Effective deployment of replica (or replica
groups) minimize the risk of simultaneous failures in individual
replica groups thereby improving the availability of the system.  

\subsection{Design Considerations}
\label{sec:factors}

Using the enterprise DRE system case study illustrated in
Figure~\ref{fig:sample} and the dependability management requirements
outlined above, we now describe the design considerations for an
automated dependability provisioning tool for enterprise DRE
systems. In the following we describe the desired characteristics of
such a design tool. 

\begin{NumList}

\item \textbf{Variable granularity of system protection:}
Enterprise DRE systems are composed of several independently
deployable assemblies of components that communicate together in a
workflow fashion to carry out the system's functionality.  Quite often
the unit of modularity in the system design is larger than a single
deployed component and results in some critical functionality of the
system being spread across multiple components and/\-or assemblies.
As outlined in the case study, in terms of the availability
perspective, the entire critical functionality which is spread across
multiple components must now be protected from failures.  Moreover,
failure of any one component in the workflow now implies the failure
of the entire flow.  In such a situation, the system must failover to
a redundant workflow as opposed to a single component.    

\hspace{0.1in}
A design-time tool must allow the specification of these requirements
of enterprise DRE system.  Section~\ref{sec:modeling} describes how
MDDPro provides intuitive abstractions to capture these
dependability requirements of enterprise DRE systems.

\item \textbf{Mixed-mode dependability requirements:}
Enterprise DRE systems are large-scale and comprise several different
components each of which accomplishing specific tasks of the entire
system functionality.  Some parts of the system may require ultra high
reliability mandating active replication schemes.  However, due to the
overhead associated with active replication and the non determinism
issues~\cite{PFPN:IeeeTocs,Mead:CCPE} involved in active replication,
it may be necessary to restrict the use of active replication to a
small part of the enterprise DRE systems.  Other parts of the system
may then use other forms of replication, such as passive replication,
or depend on simple restart mechanisms depending on the criticality of
the component and available resources in the system.

\hspace{0.1in}
The design-time tool must enable enterprise DRE system developers to
capture these mixed-mode dependability semantics of the system.  When
combined with the granularity of protection units and other
performance requirements of the system, this provisioning task becomes
complex to perform manually using ad hoc and programmatic
techniques.  Section~\ref{sec:modeling} describes how MDDPro provides
intuitive abstractions to capture these mixed-mode dependability
requirements of enterprise DRE systems. 

\item \textbf{Effective replica deployment for maximising availability:} 
As alluded to above, enterprise DRE systems may have a number of
different protected units of functionality that are assembled together
to form the system.  Moreover, different parts of the system may use
different replication schemes.  Considering both these requirements,
it is now necessary to introduce redundancy in the system
that accounts for the units of protection used and the replication
styles used.  Redundancy in the system improves system availability,
however, high levels of reliability are realized only when replicas
are placed in such a way that the risk of simultaneous failures of
replicas is minimized.  Effective replica placement also impacts
several other performance characteristics of the entire system.  For
example, effective replica placement may be necessary to maintain a
bounded and fast state synchronization among the replicas. 

\hspace{0.1in}
A design-time tool can be used to ensure that the system
simultaneously satisfies multiple QoS requirements such as
performance, predictability and availability, by incorporating
deployment state space search algorithms that automatically find
effective deployments.  This feature boils down to the general problem
of constraint satisfaction.  Optimality is a harder problem than
constraint satisfaction, however, we do not consider it yet in our
design.  Section~\ref{sec:placement} describes how we have designed
our MDDPro tool that can plug in different replica placement
algorithms that find effective deployments for enterprise DRE
systems. 

\item \textbf{Automated provisioning of dependability:}
Even though the modeling techniques can help capture dependability
requirements while replica placement algorithms can provide effective
deployment decisions, these must ultimately be realized in the context
of the underlying hosting platforms, such as the component middleware.
Component middleware often use XML metadata that describes how
components of an enterprise DRE system should be hosted in the
middleware and how they must be connected to each other.  For
large-scale systems, the amount of metadata becomes very large and ad
hoc techniques, such as handcrafting these descriptors becomes
infeasible and error prone.

\hspace{0.1in}
Dependability provisioning makes this task harder since the metadata
must now account for the protection units and provisioning the
multiple replication schemes within the enterprise DRE system.  This
requires substantial degree of middleware configuration by allocating
different resources end-to-end.  Replication adds to the number of
connections that must be established between the different protection
units and their replicas.  The replication style makes this task even
harder.  For example, when active replication is used, the middleware
must be configured to use a group communication substrate that is used
by the communication between replicas.  On the other hand, in passive
replication, the secondary replicas must be provisioned on the
middleware to accept periodic state updates from the primary.
Section~\ref{sec:gen} describes how generative
programming~\cite{Generative:Programming:00} 
techniques used within our MDDPro tool automates the metadata
generation to provision dependability for enterprise DRE systems
within the middleware platforms.

\end{NumList}

\paragraph*{Solution Approach:}
Model Driven Engineering (MDE)~\cite{Schmidt:06a} is a promising
approach to provision the dependability requirements for enterprise
DRE systems because it raises the level of the abstraction of system
design to a level higher than third-generation programming languages
by providing a scalable and intuitive abstractions that are closer to
the domain.  The \emph{model-per-concern} paradigm within MDE
alleviates system complexity because it abstracts away the irrelevant
details from the developer's current ``view'' of the system. 
Generative tools provided by MDE approaches can seamlessly integrate
multiple views of the system and produce a consistent set of metadata
used by underlying hardware/software platforms for configuration.  The
MDDPro tool described in this paper is therefore based on the MDE
approach. 
