The most important
source of the difficulties  in provisioning system dependability is
the degree of freedom possible to the system designer.  The spectrum
of fault-tolerant systems ranges from totally application controlled
fault-tolerance at one end to completely application-agnostic or 
infrastructure-controlled fault tolerance to the other.  Application
controlled fault tolerance solutions are usually ad-hoc and are
not reusable across multiple applications. The most important reason
behind the immobility of the fault-tolerance solutions is that they
are engineered everytime in their own unique way using third generation
system programming languages. 

On the other hand, infrastructure controlled fault-tolerance solutions
may not fit the requirements of the application and have to be extended
in meriad ways only to make it less reusable. Moreover, there are several 
other concerns that must be resolved simulaneously to provide a working
falut-tolerance solution.


---------------

Providing such capabilities programmatically in an
enterprise DRE system that is assembled and deployed using component
middleware capabilities severely reduces the ease of
composability because the availability solution has to change as the system
composition changes. 
For example, consider a system shown in figure X. Components A, B and C together
form a protected unit of the system. The system is lateron refactored and two
more components D and E are added and should be protected. The fault tolerance
solution must be implemented in the new components as well. Depending upon 
whether the solution is infrastructure comtrolled or application controlled 
amount effort requried will vary but will not vanish. If lateron it turns out that
the peorformance of the new refactored design is suboptimal and the designer
decides to merge the components D and E together then again some part of the
availability solution needs to change to reflect the change in the applicatoin
topology. This slows down the application's development lifecycle and reduces
productivity.


-----------

\iffalse
%  Sumant, let us elaborate this for the next paper we write - andy
%
% I think there is a point in the thing I am trying to describe below 
% but it has not come out well.
\item \textbf{Synchronizing the application topology with the changing
  FT topology:} 
In case of simultaneous QoS provisioning, FT requirements may result
in degradation of other QoS such as real-time behavior, performance,
resource consumption.  Thus it is intrusive.

Transparent provisioning of fault-tolerance in high-availabile,
component-based systems is difficult because FT is a kind of
non-functional system reuqirement 
that has intrusive effect on the parts of the system that are not protected.
for example, consider a simple component based system having 2 componenents A 
and B, where component B is actively replicated and we desire both, component
as well component B should be oblivious to the fact that one or more
of the components are replicated. Almost always in such situations,
request/response suppresion has to happen at one of the sides. If COTS
components are used, which were not designed to operate in replicated
services environment, then the client, which otherwise 
would have been oblivious to the replication, has to exercise proper care to
while communicating with the replicated protected component.
\fi

\iffalse
\item \textbf{Reconfiguring dependability mechanisms with application
  changes:}     
The unit of protection in an enterprise DRE system can have different
granularities as alluded to earlier.  For example, in
Figure~\ref{fig:sample} the \texttt{Planner1} and \texttt{Planner2}
form a single protection unit.  This protection unit can be considered
a subassembly of a larger assembly of components that together realize
the enterprise DRE system.  Application developers determine how best
to modularize the critical functionality of an application resulting
in these components that are assembled and deployed.  Often times,
however, these decisions may not satisfy the desired performance goals
of the application although the software design may be cleaner.
This may require further modularization or even merging of the
functionality.   

\hspace{0.1in}
These changes in the software design of the application in turn
impacts the dependability mechanisms that have already been
provisioned.  Existing mechanisms offered by component middleware
platforms either require programmatic reconfiguration or modifications
to low-level XML deployment metadata to effect these changes to the
assembled and deployed system, both of which tend to be tedious,
non-scalable and error-prone approaches.  The design tool therefore
must enable easy and intuitive reconfiguration of design decisions and
automated modifications to the deployment metadata.
Section~\ref{sec:modeling} describes how the modeling abstractions
make it easy to effect the changes in the unit of protection.
Moreover, Section~\ref{sec:gen} describes how the generative
programming capabilities in our tool automate the regeneration of
deployment metadata in enterprise DRE systems.

% Sumant, I am not sure if we are addressing this in this paper - andy
\item \textbf{Integrating COTS components having different
  dependability architecture:}  
An important benefit of using component-based middleware to develop
eDRE systems is the ease with which COTS components can be integrated
and deployed into the system.  COTS components may or may not have
been developed with availability requirements in mind. For those which
are not, some of the concerns mentioned above are observed.  For those
which are developed keeping availability requirements in mind may
provide configuration knobs.  If several such COTS components are in
the system then managing the availability requirements of each in a
consistent manner becomes more and more difficult as the size of
system grows.
\fi

The most common technique of provisioning fault-tolerance to the critical system
component is to create multiple replicas of it. It is the most trusted and
popular solution of providing fault tolerance in the highly available systems.
It has an undesirable side-effect of manually creating multiple copies of all
the protected system components and creating a potentially large number
of deployment metadata for the components. For example, all the connections that
a primary component has to other protected/unprotected components must
be manually 
carried over to the replicas of the primary component. Depending upon
the replication 
style used by the primary component and the underlying infrastructure
support, the number and the types of replicated connections vary a
lot. 
We show in section  x.x that actually the number of connections
increase multiplicatively as we increase 
the degree of replication.

Such a process is extremely mechanical, time-consuming, and error
prone for a human.  Great productivity benefits can be achieved if the
complexity of explicitely modeling the replicas and the connectivity
between  them is taken away from the developer. System development
time can be reduced if the necessary components can be auto-generated
from the annotated system models along with the complex
interconnectivity between them. What is ideally desired is the
automatic generation of availability solution  or atleast parts of it
based on the composition of the component-based system. 
Section x.x shows how we generate infrastructure components automatically 
reducing the manual efforts required by the programmer.


-------------------

It turns out that although, we eliminate the obvious mistake of putting
replicas on the same host, it is still possible in the above formulation
to generate a deployment where replicas are not collocated but are closely
located in the shared risk group hierarchy.  

--------------

\subsubsection {Architecture of CQML and the generative toolchain}
As mentioned in an earlier section x.x, CQML is domain specific modeling
language that builds on top PICML. It ''inherits'' the capabilities of
PICML such as composition and structuring of the component-based
systems. CQML has been designed to be extensible such that the basic 
modeling elements provided by PICML can be enhanced with differnt QoS annotations
associated with them. CQML reuses PICML as ''library'' \footnote{GME tool
literally provides a mechanism for language composition  by virtue of a feature called
language libarary.} By virtue of this feature, we are developing 
automatic PICML to CQML model transformations that allows platform independent
representatoin of QoS requirements into concrete QoS characteristics directly
supported by our CIAO container-based component middleware. 
Extensibility of CQML makes it easy for a language designer to
add support for a new kind of QoS charateristics without affecting the 
existing QoS modeling capabilities. QoS indipendent modeling capabilities of
CQML can be leveraged in developing support for new kinds of QoS.

-----------------


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "isas07"
%%% End: 
