% $Id: intro.tex 16655 2009-02-01 11:42:48Z 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 quality of service (QoS) properties,
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 multiple kinds of QoS
properties has made the middleware itself very complex, which in turn
makes the middleware QoS configuration activity very complex.
Middleware QoS configuration 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 requirements 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 requirements 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 perform 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 requirements 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 individual component
  level (local) as well as at aggregate intermediate levels, such as
  component assemblies, all the way through the entire application
  (global) and 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
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}.  We present the scientific principles
behind the model-to-model transformations in QUICKER concretely in the
context of two domain-specific modeling languages (DSMLs).  

The first language is called \emph{Platform-Independent Component
  Modeling Language} (PICML)~\cite{Schmidt:04z}.  PICML enables
developers of component-based DRE systems to annot\-ate com\-ponent-based
application models developed in PICML with QoS policies.   These
policies are specified at a higher-level of abstraction using
\emph{platform-independent} models, rather than using low-level,
platform-specific configuration options typically found in middleware
configuration files.  QUICKER thus allows flexibility in mapping the
same QoS policy to other middleware technologies.

QUICKER uses model-to-model transformation
tec\-hniqu\-es~\cite{Czarnecki:06} to translate the
platform-independent PICML specifications of QoS policies into
middleware QoS configurations modeled in another DSML called
the \emph{Component QoS Modeling Language} (CQML).  CQML enables the
modeling of platform-specific QoS configurations  provided by the
CIAO~\cite{Schmidt:06r} real-time CORBA Component Model middleware.

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

\begin{BulletList}
\item QUICKER provides DSMLs that enable DRE system developers to use
      intuitive abstractions to model system QoS policies.  The
      model-to-model transformations subsequently automate the
      middleware QoS configuration process. 

\item The model-to-model transformations in QUICKER determine the right
      set of configuration parameters and their values.  We use
      structural correspondence to verify the correctness of our
      transformation process. 

\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}

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.
