% $Id: model.tex,v 1.1 2005/01/14 06:03:18 gokhale Exp $

\section{Middleware Configuration and Customization Variability
Management Model}
\label{sec:var-model}

Section~\ref{sec:intro} describes the additional sources of
variability incurred due to the tangling of middleware configuration
and customization (C\&C) options. This tangling yields the following
three challenges:  
\begin {itemize}\crunchlist
\item {\bf Handling the diversity of option tuning}, {\em e.g.},
      option settings that optimize performance for particular DRE
      system requirements/\-environments may not be suitable for
      different ones including product variants in a product line
      architecture, 

\item {\bf Maintaining semantic consistency}, {\em e.g.}, certain
      groups of option settings may be semantically invalid due to
      subtle dependencies between options that crosscut layers and
      lifecycle phases, and 

\item {\bf Assuring software quality in the face of change}, {\em
      e.g.}, as middleware evolves to support new types of DRE system
      requirements/\-environments, new configuration and customization
      options are often added, which motivates the need for quality
      assurance (QA) processes that can detect functional and QoS
      regressions quickly and reliably.
\end{itemize}

\noindent 
The remainder of this section describes a model for middleware C\&C
variability management. We propose a three dimensional C\&C variability model 
illustrated in Figure~\ref{fig:var-model}. We envision middleware
developers to use such a model to partition their C\&C space across
the three dimensions shown in order to manage the C\&C
variability. The encircled area represents the set of options chosen
across all dimensions to support product line architectures. 
\begin{figure}[htb]
\center{\includegraphics[width=3.2in]{../figures/config-space.eps}}
\vspace{-0.6in}
\bfcaption{Middleware C\&C Variability Management Model} 
\label{fig:var-model}
\vspace{-0.1in}
\end{figure}

In the following we explain the three dimensions of the middleware C\&C
variability we have proposed.
\begin{enumerate}\crunchlist
\item {\bf Per layer C\&C variability} --
Middleware developers provide numerous configuration options to
customize the behavior of individual building blocks of their system,
such as Reactor or Acceptor~\cite{Schmidt:00a}.  This flexibility
is provided to suit individual needs of product variants at individual
layers of the middleware, such as those shown in
Figure~\ref{fig:var-model}. 

For example, a Reactor building block that provides event
demultiplexing capabilities could be configured in many
different ways depending on the event demultiplexing capabilities
provided by an OS and the concurrency requirements of an
application. For example, the demultiplexing capabilities of a Reactor
could be based on the {\tt select()} or {\tt poll()} system calls
provided by POSIX-compliant operating systems or {\tt
WaitForMultipleObject()} available on Win32.  Moreover, the handling
of the event in the event handler could be managed by the same thread
of control that was listening for events giving rise to a
single-threaded Reactor implementation. Alternately, the event could
be delegated to a pool of threads to handle the events giving rise to
a thread-pool Reactor (other variants are also possible).  

\item {\bf Lifecycle stages C\&C variability} --
This variability dimension reflects the choices to be made at
different stages of the lifecycle, such as compile-time,
deployment-time and run-time. In the Reactor example mentioned
earlier, compile-time options could decide the platform to use, such
as Win32 or POSIX. The deployment-time options could decide whether to
use a single-threaded model or a thread-pool model, while at run-time,
the size of the thread-pool could be varied depending on current load
on the system.

It should be noted, however, that at every stage in the lifecycle, the
right C\&C choices must be made for all the layers of the middleware
simultaneously. 


\item {\bf Per product-line C\&C variability} --
The per-layer and lifecycle stages dimensions must further be
constrained by partitioning the C\&C space across QoS requirements of per
product line architecture. For example, in telecommunications call
processing systems, the QoS requirements center around reliability and
throughput, while in domains, such as avionics, the QoS requirements
could center around real-time behavior and ultra high
reliability. 
\end{enumerate}

\noindent
The middleware C\&C variability management model proposed above
partitions the tangled C\&C space into the three dimensions. DRE
system developers are then required to make the right choices of C\&C
options that will deliver the desired QoS to their
systems. Section~\ref{sec:approach} describes a proposed tool-driven
approach that helps DRE systems developers to make the right choices
such that the three challenges described earlier are resolved.
