% $Id: Concluding.tex,v 1.18 2005/10/18 16:27:53 arvindk Exp $
\sqztiny
\section {Concluding Remarks}
\label{conclusions}
\iffalse
%%%
% Arvind: Commented this out as we may need this space. If not
% we can put this right back.
%%%
Product-line architectures (PLAs) enable organizations to reconfigure
their software quickly to respond to new missions and new business
opportunities~\cite{Clements:02}.  PLAs are particularly applicable
for large-scale distributed real-time and embedded (DRE) systems since
reusable software families can be built for a domain (such as
avionics, vetronics, or ship-board computing) where applications share
many functional and architectural properties and then customized to
meet the specific needs of product variants.  Standards-based
middleware is a key infrastructure technology for PLAs since it
provides many reusable policies and mechanisms to simplify the
development, customization, and deployment of product variants.  The
stringent demands of DRE systems, however, require conservation of
resources, while simultaneously providing the desired QoS.  It is
therefore essential to optimize standards-based middleware
implementations by eliminating extraneous functionality and
extensibility not needed for particular product variants.
\fi

This paper describes how specializations can be automated and applied
to optimize excessive generality in standards-based middleware
implementations used for PLAs.  We show how context-specific
specializations based on the Bold Stroke avionics mission computing
PLA can be used to optimize the TAO Real-time CORBA implementation.
Our middleware specialization results collectively improved the
throughput of Bold Stroke {\em BasicSP} scenario by $\sim$65\%, its
average- and worst-case end-to-end latency measures by $\sim$43\% and
$\sim$45\%, respectively, and its predictability by a factor of two,
without affecting portability, standard middleware APIs, or
application software implementations, while preserving
interoperability wherever possible.  These improvements are
particularly notable since TAO has already been tuned via many
general-purpose middleware
optimizations~\cite{Schmidt:98v,Schmidt:99h,Schmidt:02r}.  We also
described how GNU {\tt autoconf}, FOCUS DSL and tools were used
to automate the middleware specializations described in the paper.

% Arvind, I think the concluding remarks below are a good place to
% cut.  Can you please see how much room is left after you add in the
% rest of the results and we'll add some of this stuff back in, albeit
% more concisely!
%%%
% Arvind: Added some of them back in a shortened format.
%%%

The remainder of this section discusses the consequences and
implications of our specialization techniques and tools.

\sqzlarge\paragraph* {\bf Implications on QoS} The
specializations discussed in this paper had no inter-dependencies,
{\em i.e.}, the specializations do not overlap in the end-to-end code
path.  As middleware and system architects develop a catalog of
specializations, it will be necessary to document the interplay
between the specializations and analyze the implications on mixing and
matching different specializations.  Similarly, not all the
specializations will be applicable to every PLA application scenario,
so PLA developers will need to work in conjunction with middleware
developers to determine the applicability of the different specialization
techniques to product variants.

Quantitative results show that improvements from applying our
specializations can be scenario-specific.  For example, the
demarshaling results showed how a complicated structure benefited more
from the specialization than a simple type.  When the specialized path
is traversed more often, therefore, its influence on end-to-end
performance is more significant.


\iffalse
% Arvind, if we're running out of space please comment out this
% paragraph since I think it's ``risky'' to state this in this paper...
%%%
% Arvind: Ok commented this paragraph out.
%%%
\sqzlarge\paragraph* {\bf Implications on applicability to different
middleware implementations} The magnitude of the QoS improvements from
our specialization are specific to a particular implementation (TAO).
% Arvind, does this paper actually show these results?
Preliminary results~\cite{daugherty:04} from applying context-specific
specializations to ZEN (which is an open-source Real-time Java
implementation of Real-time CORBA available at \url{www.zen.uci.edu})
were somewhat better than those shown in this paper.  The difference
stems in part from the fact that TAO is much more mature and optimized
than ZEN, so there was less time/\-space overhead to optimize.  To
enable other middleware developers to analyze and implement the
specializations we are working on developing a comprehensive CORBA
\emph{specialization model} based on~\cite{daugherty:04} that --
independent of a particular CORBA implementation -- identifies (1)
points in an ORB architecture where specialization is beneficial and
(2) API extensions to the architecture that provide {\em hooks} for
achieving effective specialization.

Another observation is that our dispatch resolution optimization
improved latency measures by 16\% beyond active demultiplexing and
perfect hashing general-purpose optimizations.  These optimizations
ensure $O(1)$ lookup time bound for all dispatch operations in TAO for
the general case and incur the least overhead compared to other
strategies~\cite{Schmidt:98v}.  Naturally, using other lookup
techniques (such as linear search, which incurs $O(n)$ time bound)
would yield an even greater payoff from our specializations.

\fi

\sqzlarge\paragraph* {\bf Implications on adaptability} The
specialization mechanisms discussed in this paper do not consider
adaptation costs, {\em i.e.}, the overhead of handling and recovering
from situations where the invariance assumptions are violated.  Adding
such mechanisms require activities (such as loading new libraries or
adding run-time checks) that can incur considerable jitter, and thus
are not desirable for DRE systems.

\sqzlarge\paragraph* {\bf Implications on schedulability} In many DRE
systems, real-time tasks are scheduled and analyzed offline to ensure
they complete before their deadlines.  Latency overheads caused by
general-purpose middleware implementations may cause deadline misses
for critical tasks scheduled a priori.  Applying our specializations
could reduce middleware overhead considerably, helping ensure
that critical tasks complete before their deadlines.  Our
optimizations might also enable such tasks to finish well ahead of
their deadlines, thereby increasing the total {\em slack}, {\em i.e.},
time interval available for scheduling other tasks (such as soft
real-time tasks), in the system.  More available slack could
potentially increase the number of schedulable soft real-time tasks in
the system.

\iffalse
% Arvind, do we really need this paragraph?  It doesn't seem like it's
% very profound and I'm not sure that this is what people think of
% when they hear the term ``scalability,'' which for me doesn't relate
% to concurrency strategies, but instead deals with how many
% clients/requests can be handled simultaneously.
\sqzlarge\paragraph* {\bf Implications on Scalability}
All the specializations discussed in this paper have been implemented
to preserve middleware scalability.  In particular, specializations
work with the thread-per-connection and thread-pool concurrency
strategies in TAO.  In TAO, the concurrency strategies are decoupled
from the request/response processing code-path.  Other middleware
implementations following a similar model can leverage our
specializations without compromising scalability.
\fi
