% $Id: intro.tex 16638 2009-01-29 19:00:10Z gokhale $
\sqzlarge
\sqzlarge
\section{Introduction}
\label{sec:intro}
\sqzlarge
Contemporary component middleware technologies, such as Enterprise Java Beans
(EJB) and CORBA Component Model (CCM), have helped to decouple application logic
from the quality of service (QoS) configuration of distributed real-time and
embedded (DRE) systems by moving the QoS configuration activity to the
middleware platforms that host these systems.  Middleware provides
out-of-the-box support for traditional concerns affecting QoS in DRE systems
including multi-threading, assigning priorities to tasks, publish/subscribe
event-driven communication mechanisms, security, and multiple scheduling
algorithms.  

Although component middleware has helped move the configuration
complexity away from the application logic, the middleware itself has
become more complex to develop and configure properly.  To achieve the
desired QoS characteristics for DRE systems, therefore, system
developers and integrators must perform \emph{QoS configuration} of
the middleware.  This process involves the binding of application
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 number of threads necessary
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 must be mapped to
middleware-specific configurations.

QoS configuration bindings can be performed at several time scales,
including \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, or
\emph{dynamically}, \emph{e.g.}, by modifying QoS configurations at
runtime.  Regardless of the binding time, however, the following
challenges must be addressed:
\begin{BulletList}
\item How can we translate the domain-specific QoS policies of the
  application into QoS configuration options of the underlying
  middleware?
\item How can we choose valid values for the selected set of QoS
  configuration options? 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 we resolve the dependency relationships and understand the impact
  between the different QoS configuration options, both at individual
  component level (local) as well as at aggregate intermediate levels,
  such as component assemblies, through the entire application
  (global)?
\item How can we validate the local and global QoS configurations,
  which include the values, the dependency relationships, and the
  semantics of QoS configuration options at all times throughout the
  DRE system lifecycle?
\end{BulletList}
Without effective tools to address these challenges, the result will
be 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-driven QoS
mapping:} To address QoS configuration challenges, we developed the
\emph{QUality of service pICKER} (QUICKER)~\cite{Schmidt:06x} model-driven engineering
(MDE) toolchain. QUICKER extends  the \emph{Platform-Independent
Component Modeling Language} (PICML)~\cite{Schmidt:04z} and enables 
developers of component-based DRE systems to annotate
% Amogh, I added this sentence so that the use of PICML is made clear.
%
% OK, this sounds fine.
component-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 binding the
same QoS policy to other middleware technologies.


Before the components in a DRE system can be deployed, however, their
platform-independent QoS policies must be transformed into
platform-specific configuration options.  QUICKER therefore uses
model transformation techniques~\cite{Czarnecki:06} to translate the
platform-independent specifications of QoS policies into a
platform-specific model defined using the \emph{Component QoS Modeling
Language} (CQML), which models the QoS configuration options required
to implement the QoS policies of the application specified in PICML.
Unlike PICML (whose models are platform-independent), CQML models are
specific to the underlying middleware infrastructure.

QUICKER subsequently uses generative techniques on the CQML model to
synthesize:
\begin{BulletList}
\item The input to the Bogor~\cite{Bogor:03} model-checking framework,
  which validates the transformation-generated application
  component-specific middleware QoS configuration and identifies all
  permissible changes to these configuration options that can be performed
  at runtime, while maintaining the validity of QoS configuration across
  the entire application, and
\item The descriptors in a middleware-specific format (such as XML)
  required to configure the functional and QoS properties of the
  application in preparation for deployment in a target environment.
\end{BulletList}

QUICKER is designed to bridge the gap shown in
Figure~\ref{fig:QoSConfiguration} between:
\begin{figure}[htb]
\centering
\includegraphics[width=0.65\columnwidth,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}

By combining model transformation and generative techniques with
advanced model-checking technologies, QUICKER automates the mapping of
QoS policies of applications to QoS configuration options for a
specific middleware technology.  In particular, QUICKER's separation
of platform-independent and platform-dependent concerns enables the
use of PICML models to specify QoS policies that can be mapped to
other types of middleware, such as Web Services and EJB.
%~\cite{EJB:01}.
As a result, developers can concentrate on inherent complexities in
the application domain rather than wrestle with low-level
middleware-specific configuration options.
QUICKER also helps ensure the validity of the values for the QoS
configuration options, both at the individual component (local) level and
at the aggregate application (global) level.

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 transformation approach; Sections~\ref{sec:corresp} and 
~\ref{modelcheck} discuss how we have employed
% Amogh, is it possible to split the V&V part into a separate section so
% it corresponds to the 4 contributions we mention in abstract.
%
% Andy, actually this was a mistake since we already have separate section
% for modeling checking and structural correspondence. I added the two
% references accordingly above.
% Ok, can we reverse the order since it is showing up as 4.2.2 and then
% 4.2.1 - andy
structural correspondence and model-checking techniques to evaluate the
correctness of the QoS configuration process; Section~\ref{sec:related}
compares QUICKER with related work on model-driven QoS
configuration/\-adaptation; and Section~\ref{sec:conclusion} presents
concluding remarks. 
