% $Id: intro.tex 19213 2009-08-17 10:06:43Z gokhale $
\section{Introduction}
\label{sec:intro}

Contemporary component middleware technologies, such as Enterprise Java
Beans (EJB) and CORBA Component Model (CCM), help to decouple the
development of application logic from the provisioning of non functional
properties of the system, such as domain-specific quality of service
(QoS) policies, which are key to the correct functioning of
distributed real-time and embedded (DRE) systems.  Examples of DRE
system QoS properties that can be configured in the middleware
includes different types of concurrency, handling multiple levels of
priorities of system tasks, publish/subscribe event-driven
communication mechanisms, reliability, security, and multiple
scheduling algorithms, among others.  

Although component middleware separates the QoS configuration complexity
from the application logic, the need to support a variety of
domain-specific QoS policies has made the middleware itself very
complex, which in turn makes the middleware QoS configuration activity
very complex.  Middleware QoS configuration thus involves mapping the
system-level \emph{QoS policies}---which are dictated by domain
requirements---onto the solution space comprising the \emph{QoS
  mechanisms} for tuning the underlying middleware.    

Examples of domain-level QoS policies include (1) the degree of
concurrency required to provide a service, (2) the priorities at which
the different components should run, (3) the alternate protocols that
can be used to request a service, (4) the granularity of sharing among
the application components of the underlying resources, such as
transport level connections, (5) the number and size of outstanding
requests that are permissible at any instant in time, and (6) the
maximum and minimum amount of time to wait for completion of requests,
among many others.  All these domain-specific QoS policies must
eventually be mapped onto the right middleware QoS configurations, which
includes choosing the right set of middleware configuration parameters
and assigning the right values to them. 

An additional dimension of complexity stems from the need to determine
these QoS configurations at different time scales.  This includes
\emph{statically}, \emph{e.g.}, directly hard coded into the
application or middleware; \emph{semi-statically}, \emph{e.g.},
configured at deployment time using metadata descriptors; and/or
\emph{dynamically}, \emph{e.g.}, by modifying QoS configurations at
runtime.   

The complexity involved in the middleware QoS configuration process
raises the following questions: 
\begin{BulletList}
\item How can the domain-specific QoS policies of the system be
 mapped onto QoS configurations of the underlying middleware,
 particularly by DRE system developers who are domain experts but seldom
 possess detailed knowledge of the middleware and its configurability?

\item How are the right set of configuration parameters determined and
  how are valid values for the selected set of QoS configuration
  parameters determined?  Are there any \emph{patterns of usage,}
  \emph{i.e.}, best practices in configuration that can be used across
  a variety of application domains?

\item How can dependency relationships between configuration parameters
  be resolved while ensuring that their interactions do not 
  adversely impact QoS?  These issues arise at the individual component
  level (local) as well as at aggregate intermediate levels, such as
  component assemblies, all the way through the entire application
  (global), and all of these at different time scales, \emph{i.e.},
  design-, deployment- and run-time. 

\end{BulletList}

Without scientific techniques and effective tools to address these
questions, existing approaches to middleware QoS configurations will
often result in QoS mis-configurations that are hard to analyze and
debug.  As a result, failures will stem from a new class of
configuration errors rather than (just) traditional
design/\-implementation errors or resource failures. 

\noindent\textbf{Solution approach $\rightarrow$ Model-to-model
  Transformations:} We address these questions by presenting a technique
based on model-to-model transformations, which is realized in the
context of a tool-chain called \emph{QUality of service pICKER}
(QUICKER)~\cite{Schmidt:06x}.  QUICKER is designed to bridge the gap
shown in Figure~\ref{fig:QoSConfiguration} between: 
\begin{figure}[htb]
\centering
\includegraphics[width=0.5\textwidth,keepaspectratio]{QoSConfiguration}
  \caption{QoS mapping landscape}
  \label{fig:QoSConfiguration}
\end{figure}
\begin{BulletList}
\item \textbf{Functional specification and analysis tools}, such as PICML
  and Cadena~\cite{Hatcliff:03}, that allow specification and analysis of
  application structure and behavior,
\item \textbf{Schedulability analysis tools}, such as
  TIMES~\cite{TIMES:03}, AIRES~\cite{AIRES:03}, VEST~\cite{VEST:03}, that
  perform schedulability and timing analysis to determine the exact
  priorities and time periods for application components, and
\item \textbf{Dynamic QoS adaptation frameworks}, such as the Resource
  Adaptation and Control Engine (RA\-CE)~\cite{Schmidt:06w} and
  QuO~\cite{Quo:97}, that allocate resources to application components,
  monitor the QoS of the system continuously, and apply corrective control
  to modify the QoS configuration of the middleware at runtime.
\end{BulletList}

QUICKER makes the following contributions in addressing the questions
raised above:

\begin{BulletList}
\item QUICKER provides domain-specific modeling languages
      (DSMLs)~\cite{WhenHow_DSL_Mernik:05} that 
      enable DRE system developers to use intuitive abstractions to
      model system-level QoS policies.

\item QUICKER provides a model-to-model transformation process to
      automate the mapping of domain-specific QoS policies expressed
      in the DSML into middleware-specific QoS configurations.  This
      transformation process is verified for correctness using
      structural correspondence~\cite{Karsai_ECEASST:08}. 

\item Dependencies among the configuration options and the correctness
      of the generated configurations at all time scales is resolved
      using automated model checking provided by the
      Bogor~\cite{Bogor:03} model-checking framework. 

\end{BulletList}

% To make the discussion concrete, we present the scientific principles
% behind the model-to-model transformations in QUICKER in the context of
% two domain-specific modeling languages (DSMLs).

The remainder of this paper is organized as follows:
Section~\ref{sec:qos-challenges} describes the key challenges in QoS
configuration of component middleware; Section~\ref{sec:transform}
describes the QUICKER model-to-model transformation approach;
Section~\ref{sec:correctness} discusses how we have employed structural
correspondence and model-checking techniques to verify the correctness
of the QoS configuration process; 
% Section~\ref{sec:eval} provides empirical validation of the generated
% QoS configurations for a representative DRE system; 
Section~\ref{sec:related} compares QUICKER
with related work on model-driven QoS config/-uration/\-adapta/-tion;
and Section~\ref{sec:conclusion} presents concluding remarks.
