% $Id: Introduction.tex,v 1.40 2005/10/06 15:29:44 arvindk Exp $
\section {Introduction}
\label{intro}
%%%%
% Reviewer #1: Very good motivation. So I am keeping the motivation in
% tact.
%%%
\sqzlarge\paragraph* {\bf Emerging trends \& challenges}
Software development organizations must innovate rapidly, provide
capabilities that meet user needs, and sustain their competitive
advantage in the face of time-to-market pressures and limited software
resources.
\iffalse  
As a result, many organizations are trying to reuse
existing artifacts and resources for a range of products, rather than
handcrafting software for each product from scratch.  
\fi
A promising
technology for systematically addressing the challenges of large-scale
mission-critical software systems is {\em product-line architectures}
%%%
% Reviewer comment: In the introduction to PLA, you may want to think 
% about citing the earliest paper in the area, which appears to be 
% by Parnas:
%%%
(PLAs)~\cite{Parnas:76,Clements:02}.
In contrast to conventional software processes that produce separate
point solutions, PLA-based processes develop families of {\em product
variants}~\cite{Sharp:98} that share a common set of capabilities,
patterns, and architectural styles.  PLAs can be characterized using
{\em scope, commonality, and variabilities} (SCV)
analysis~\cite{Weiss:98}, which is an engineering process that
identifies the scope of the product families in an application domain
and then determines the common and variable properties among them.
Domain/\-systems engineers and software architects use SCV analysis to
guide decisions about where and how to address possible variability
and where the common development strategies can be used.

PLAs have been developed and applied to a variety of
domains~\cite{Ommering:00,Greenfield:04}; recently
PLAs have been applied to {\em distributed, real-time and embedded (DRE)
systems}~\cite{Sharp:98,Doerr:99,Sharp:03}.  Examples of DRE systems
include applications with hard real-time requirements, such as
avionics mission computing~\cite{Wendy:03}, as well as
those with softer real-time requirements, such as telecommunication
call processing and streaming video~\cite{Schmidt:98v}.
\iffalse
These DRE
systems are characterized by their stringent QoS requirements (such as
low memory footprint, power consumption, latency, and predictability),
which often makes them harder to develop, maintain, and evolve than
conventional desktop and enterprise software.
\fi
The QoS challenges (such as low memory footprint, latency, and 
predictability) of DRE systems have hitherto led developers to
(re)invent custom applications that are tightly coupled to specific
hardware/\-software platforms, which is tedious, error-prone, and
costly to evolve over product lifecycles.  During the past decade,
therefore, a key technology for alleviating the tight coupling between
applications and their underlying platforms has been {\em
middleware}~\cite{Schmidt:04l}, which (1) functionally bridges the gap
between applications and platforms, (2) controls many aspects of
end-to-end QoS, and (3) simplifies the integration of components
developed by multiple technology suppliers.

Although middleware has been used successfully in DRE
systems~\cite{Sharp:98,Doerr:99,Sharp:03,Wendy:03}, key challenges
must be overcome before it can be applied seamlessly to support the
QoS needs of {\em PLA-based} DRE systems.  In particular, there is a
need for R\&D to resolve the tension between: (1) the {\em generality
of standards-based middleware}, which benefits from a reusable
architecture designed to satisfy a broad range of application
requirements and (2) {\em application-specific product variants},
% Arvind, should we call this ``application-specific product
% variants'' or ``PLA & product variant-specific QoS demands'' - andy
%%%
% Arvind: Would prefer the latter. Not sure what others feel...
%%%
which benefit from highly-optimized, custom PLA middleware
implementations.  In resolving this tension, solutions should retain
the portability and interoperability capabilities provided by standard
middleware.

\sqzlarge\paragraph* {\bf Specializing Middleware for PLAs}
This paper extends our earlier work on middleware optimizations~\cite{Schmidt:98v,Schmidt:99h}, by
% Arvind, let us give a couple of good citations for our earlier work
% on optimizations - maybe one TAO paper and one CIAO paper - andy
%%
% Arvind: Yet to write a CIAO paper on optimization. So I got these
% two.  Please see if this works.
%%%
providing a framework for resolving the generality/\-specificity
tension by automating the {\em specialization} of general-purpose,
standards-based middleware to meet the needs of specific PLA-based DRE
systems.  Our initial focus is 
%
% Arvind, you asked me to remove the real-time word here but isn't our
% work for DRE systems, or is it because so far the FOCUS techniques
% are applied to the normal CORBA path? I am still keeping it since RT
% CORBA has all the underlying CORBA features plus more - andy
Real-time CORBA~\cite{RTCorba:02}, 
which is a general-purpose, standard
middleware that is increasingly used in PLA-based DRE
systems~\cite{Sharp:98,Sharp:03,Wendy:03}.  We provide the following
contributions to research in this area:
\sqztiny
\begin{enumerate}\crunchlist

% Arvind, this may spoil our chances i.e., excessive generality does
% not exist in one specific implementation but is part of the
% spec. So I feel we should not say ``in a popular
% ... implementation''. It should exist in all CORBA implementations -
% andy
%%%
% Arvind: Yes I agree. I have made this more broadly applicable.
%%%%
\item We identify the different dimensions of excessive
generality in standards based Real-time CORBA middleware using using
an industry strength DRE PLA scenario.  

\item We then describe how {\em
context-specific specializations techniques}~\cite{Hatcliff:98} (such
as code refactoring~\cite{Fowler:99}, and code
weaving~\cite{zhang03refactoring}) can be used to customize Real-time
CORBA implementations to remove excessive generality and thus better
support the application-specific QoS needs of product variants.
% Arvind, the above point also deals with generality, so how can we
% say it differently from #1? How are specialization points different
% from context-specific specializations? Maybe let #1 focus on
% specializing the critical paths while #2 deal with excessive
% generality - andy
%%%
% Arvind: I made #1 the challenge and #2 the solution approach.
%%%

\item We present and analyze {\em quantitative results} that validate
the improvement in performance and predictability of specializations
applied to the TAO~\cite{Schmidt:97q} Real-time CORBA middleware
implementation. 
% Arvind, we probably need to say that we did this in the context of a
% case study because how else did we do the context-specific
% things. Moreover, somehow we need to give a feel that such
% context-specificity can be captured in the middleware as special
% metadata, which then drives the automation mentioned in the next
% bullet - andy
%%%%
% Arvind: I have put the case study in the first bullet as even the
% techniques are context specific. As for the annotation comment, all
% the points here are at very high level. May be we can keep the 
% actual design of the automation framework separate for now? 
% What do you think?

\item Finally, we illustrate the design of languages and tools 
for automating 
the different specialization techniques discussed in this paper.

\end{enumerate}
\noindent Our results show that middleware specialization -- driven by
context-specific information -- can significantly improve the QoS of
middleware for PLA-based DRE systems, while preserving standards
compliance wherever possible.

\sqzlarge\paragraph* {\bf Paper organization}
The remainder of the paper is organized as follows:
Section~\ref{challenges} identifies key middleware specialization
challenges pertaining to PLA-based DRE systems;
Section~\ref{mw-spl-solution} explains how context-specific
specializations of middleware implementations help address these
challenges and examines the results of experiments conducted to
validate our approach; Section~\ref{FOCUS-approach} describes our
framework for automating the specializations; Section~\ref{related}
compares our work with related research; and Section~\ref{conclusions}
presents concluding remarks.
