% $Id: intro.tex,v 1.2 2005/01/14 06:07:24 gokhale Exp $

\section{Introduction}
\label{sec:intro}

\paragraph*{\bf Variability management in contemporary middleware}
Distributed real-time and embedded (DRE) systems form the basis of
mission- and safety-critical applications, such as avionics mission
computing systems, air traffic control, automated manufacturing
systems, and electrical power grids.  As these systems are
increasingly linked together to form network-centric ``systems of
systems,'' they must handle a wider range of variability stemming from
the need to:
\sqztiny
\begin{itemize}\crunchlist
\item Run on multiple hardware/software platforms and interoperate
      with multiple versions of software frameworks/tools and 
\item Provide support for multiple end-to-end quality of service (QoS)
      properties, such as low latency and bounded jitter; fault
      propagation/\-recovery across distribution boundaries;
      authentication and authorization; and weight, power consumption,
      and memory footprint constraints.
\end{itemize}

Over the past several years, various R\&D
efforts~\cite{Ritter:03,Miguel:02,Schmidt:97q,Schmidt:03m} have focused on
developing {\em QoS-enabled middleware} to address these concerns and
enhance the quality, time-to-market, and reuse of large-scale DRE
systems.  These QoS-enabled middleware have evolved by systematically
\begin{enumerate}\crunchlist
\item identifying the variability points at (a) different layers of
      middleware, such as the infrastructure layer, distribution layer
      and services layer, and (b) across different life-cycle stages,
      such as compile-time, deployment-time and run-time, 
\item mapping these variability points to DRE system quality {\em
      concerns}~\cite{Tarr:99,Schmidt:04m,Herrmann:00}. For example,
      the need to run on multiple platforms can be mapped to {\em
      portability} concerns, the need for bounded jitter can be mapped
      to {\em predictability} concerns, and the need to interoperate
      with related tools and frameworks can be mapped to {\em
      maintainability} and {\em interoperability} concerns, and 
\item applying patterns~\cite{Vlissides:94,Schmidt:00a} and pattern
      languages~\cite{Schmidt:03s}.  
\end{enumerate}
\iffalse
Figure~\ref{pattern-language} illustrates
how the ACE+TAO~\cite{ACE,TAO} DRE middleware we have developed
applies patterns and pattern languages, and identifies the different
variability points across layers of the middleware.

\begin{figure*}[htb]
\centerline{\epsfxsize=12cm \epsffile{../figures/Variability-Frameworks.eps}}
\bfcaption{Addressing Variability via Patterns \& Pattern Languages}
\label{pattern-language}
\end{figure*}
\fi
%
Figure~\ref{fig:mw-var-points} illustrates a contemporary QoS-enabled
middleware, such as ACE+TAO+CIAO~\cite{ACE,TAO,CIAO}, showcasing the
different variability points and their mappings to QoS concerns.
\begin{figure}[htb]
\center{\includegraphics[width=3.2in]{../figures/Concern-CCMapping.eps}}
\bfcaption{Identifying Variability Points and Mapping to Concerns in Middleware}
\label{fig:mw-var-points}
\end{figure}

\paragraph*{\bf Additional sources of variability}
Although many QoS-enabled middleware platforms now provide the
flexibility to address key DRE systems QoS concerns, the
multi-layered architecture of middleware often {\em tangles} the
configuration and customization (C\&C) strategies of different layers of
middleware with one another and across lifecycle stages as illustrated
in Figure~\ref{fig:tangling}. The individual points shown in
Figure~\ref{fig:tangling} can be thought of as a particular C\&C
option forming the entire middleware C\&C space, whereas the lines
joining them are the dependencies among each other that crosscut
layers of middleware and across lifecycle stages. The dotted ellipse
indicates a C\&C subspace that might be chosen to support a particular
DRE system.
\begin{figure}[htb]
\center{\includegraphics[width=3.2in]{../figures/CC-Visualization.eps}}
\bfcaption{Conceptual Illustration of Tangling of Configuration and
Customization Concerns} 
\label{fig:tangling}
\end{figure}

As a concrete example, consider ACE+TAO+CIAO which provide various
security mechanisms for encryption authentication/\-authorization of
communication. The configuration and customization options provided to
provision the security mechanisms crosscut multiple middleware layers
in the following manner: 
\sqztiny
\begin{itemize}\crunchlist
\item At the {\em host infrastructure} middleware layer, these
      influence the choice of encryption algorithms, protocol
      selection and linking of OS libraries that provide this
      functionality, 

\item At the {\em distribution} middleware layer, these influence how
      the security information is encoded within the object references
      and code to (de) marshal the context information encoded within
      these references, and 

\item At the {\em services} middleware layer, these necessitate the
      use of CORBA security service implementation and in the context
      of component middleware, translating the container level
      security policies to the appropriate policies expected by the
      security service. 
\end{itemize}

\noindent These options also simultaneously crosscut the DRE system
lifecyle stages in the following manner: the OS specific libraries to
provide security need to specified at {\em compile-time} where as the
policies are encoded in XML descriptors at {\em deployment time} and
the end-point and protocol information is provided at {\em
run-time}. 

This problem is significantly compounded when supporting product line
architectures~\cite{Greenfield:04}, custom solutions must be
(re)invented to manage the C\&C variability incurred in supporting
several different variants of products belonging to a product line
architecture.  

\paragraph*{\bf Paper organization}

The remainder of this paper describes our approach to managing the
variability incurred due to middleware C\&C options for product line
architectures. Section~\ref{sec:var-model} describes our model of the 
middleware C\&C option variability; Section~\ref{sec:approach}
describes our proposed approach to managing the middleware C\&C
variability; 
Section~\ref{sec:related} compares our approach with related research;
and Section~\ref{sec:conclusions} presents concluding remarks.
