% $Id: Approach.tex,v 1.58 2005/10/06 13:26:25 arvindk Exp $

\section{Middleware Specialization Cha\-llenges}
\label{challenges}

% Arvind, are we talking only about QoS or functional too? - andy
%%%
% Arvind: Do you want to rewrite this as "functional" and QoS
% requirements?
%%%
General-purpose standards based middleware implementations are
designed to be multi-use, {\em i.e.}, they are designed to satisfy a
broad range of application functional and QoS requirements.  Product
variants in a
% Arvind, this sentence is a bit confusing. Isn't PLA itself supposed
% to narrow down the scope and impose a common set of QoS
% requirements. Product variants then add a small bit of variability
% on top of it. I think this sentence needs more like how I added in
% the abstract - andy
PLA, however, are application specific, {\em i.e.}, have concrete QoS
requirements.  Resolving this tension is essential to ensure that
middleware can support the QoS requirements of PLA-based DRE systems.
Unfortunately, implementations of standards-based QoS-enabled
middleware technologies, such as Real-time CORBA~\cite{RTCorba:02} and
Real-time Java~\cite{RTSJ:00}, can be excessively general and thus
poorly suited to support PLAs for DRE systems due to excessive
time/\-space overhead for product variants.
% Arvind, in general I am finding things a little confusing by the
% existence of PLAs, the product variants and general-purpose. Could
% we focus simply on the families everywhere i.e., PLAs. I think even
% for supporting a family of products will need substantial
% specializations. We should then maybe show that these
% specializations are valid for the product-specific variants in that
% product family. Right now things are getting confusing due to the
% use of ``product-variant atop PLA'' and such phrases - andy
\iffalse
Removing unwanted
generality, such as redundant functionality, navigation of multiple
layers, and unnecessary checks, is therefore essential to optimize
general-purpose middleware implementations to meet the QoS
requirements of product variants.  In turn, removing this generality
helps identify opportunities for further optimizations, while still
maintaining standard interfaces and interoperability protocols.
\fi
This section uses a representative DRE system scenario to identify and
illustrate common types of excessive generality in middleware for
PLAs.  Section~\ref{mw-spl-solution} then outlines how
context-specific specialization techniques help to alleviate this
generality.

\sqztiny
\subsection {DRE PLA Case Study}
\label{DRE-case-study}

This section uses a concise, yet representative, DRE PLA scenario to
(1) illustrate how the challenges outlined above manifest in practice
and (2) identify system invariants that drive our
% Arvind, I presume these invariants are PLA-specific - if so we say
% it here that way - andy
specialization approach.  The scenario is based on the Boeing Bold
Stroke avionics mission computing PLA~\cite{Sharp:03}, which supports
the Boeing family of aircraft, including many product variants, such
as F/A-18E, F/A-18F, F-15E, F-15K, etc.  Bold Stroke is a
component-based, publish/\-subscribe platform built atop {\em
TAO}~\cite{Schmidt:97q}, which is a standards-based Real-time
CORBA~\cite{RTCorba:02} implementation, and {\em
Prism}~\cite{Wendy:03}, which is a avionics mission computing-specific
component middleware.
% Arvind, I removed the term ``QoS-enabled'' and instead wrote the
% above sentence. However, one may be inclined to ask why is PriSM not
% built with PLA focus in mind i.e., why did it have to be so general?
% Somehow we should say that though PriSM is a domain-specific m/w
% tuned to the needs of PLAs, the use of TAO brings unnecessary
% generality. This will immediately tell the people that we are
% showcasing our work in the space of the distribution middleware
% layer - andy
%
%influenced by the Lightweight CORBA Component Model
%(CCM)~\cite{LWCCM}.

Figure~\ref{fig:basicsp} illustrates the {\em BasicSP} application
% Arvind, how should we categorize BasicSP? It is not a PLA nor it is
% a product variant. But by saying ``application-scenario'' we may
% confuse things further. We should say something along the lines of
% ``is a reusable assembly of avionics mission computing components
% used in different product variants'' - andy
scenario that is the focus of this paper and is representative of
rate-based DRE systems in avionics, vetronics, and process control.
This scenario involves four avionics mission computing components that
periodically (at a rate of 20 Hz) send GPS position updates to a pilot
and navigator cockpit displays.  The time to process the inputs to the
system and present the output to cockpit displays should therefore be
less than a single 20 Hz frame.  Communication between components uses
the event-push/data-pull model, with data producing components pushing
an event to notify new data is available and data consuming components
pulling data from the source.  A {\tt Timer} component pulses a {\tt
GPS} navigation sensor component at a certain rate, which in turn
publishes the \url{data_avail} events to an {\tt Airframe} component.
Aware that new data is available, this component then calls a method
provided by the \url{Read_Data} interface of the {\tt GPS} component
to retrieve the current location.  After formatting the data, {\tt
Airframe} sends a \url{data_avail} event to the \url{Nav_Display}
component, which then pulls the location and velocity data from the
{\tt Airframe} component and displays this information on the pilot's
heads-up display.
\begin{figure}[htpb]
  \centerline{\includegraphics[width=8cm]{figures/BasicSP_revised.eps}}
  \bfcaption{{\em BasicSP} Application Scenario}
   \label{fig:basicsp}
\end{figure}
The {\em BasicSP} scenario illustrates the following commonalities and
variabilities in the Bold Stroke PLA: \sqztiny
\begin{itemize}\crunchlist
\item {\bf Commonalities} include the set of reusable components (such
as {\tt Display}, {\tt Airframe}, and {\tt GPS}) in Bold Stroke and
middleware capabilities (such as connection management, data transfer,
concurrency, synchronization, (de)marshaling, (de)multiplexing, and
error-handling) that occur in all product variants and

\item {\bf Variabilities} include application-specific component
connections (such as how {\tt GPS} and {\tt Airframe} components are
connected in an F/A-18E vs an F-15K), different implementations (such
as whether GPS or inertial navigation algorithms are used), and
components specific to particular customers (such as restrictions on
the use of encryption in certain countries).  The rates at which these
components interact is yet another variability that could change in
different product variants.
\end{itemize}

% Arvind, I feel that the outline above of the commonality and
% variability is good. But one could say that these are in some sense
% higher level (feature-level) descriptions. These in turn map to
% specific requirements and optimizations imposed on the underlying
% middleware. This is what our focus is.

\sqztiny
\subsection {Common Types of Excessive Generality in Middleware}
\label{mw-spl-challenges}

In this section we identify and describe the different types of
excessive generality in middleware relevant to PLA-based DRE systems.
In particular, we use the {\em BasicSP} scenario as shown in
Figure~\ref{fig:basicsp-specialization} to show how the generality
manifests itself in a real-world application.
%%%%%
% Arvind: Reviewer #1, Identified optimization are application specific
% (i.e., useful for this ONE application only) and not transferable.
%%%%%
It is important to note that the challenges exists within
general-purpose middleware, {\em i.e.}, they are not limited to the
{\em BasicSP} scenario.  The challenges of each type of generality are
discussed below.

\sqzlarge
\paragraph* {\bf Challenge 1. Redundant remoting functionality for
collocated objects}  In PLA-based DRE systems, such as Bold Stroke,
components are mapped to particular target nodes late in the design
process, {\em e.g.}, during the deployment phase.  Groups of
components may be {\em collocated} ({\em i.e.}, placed on the same
processor) to minimize network overhead in certain deployments.  To
optimize for this common case across different product variants or
contexts within a single product, middleware implementations provide
optimizations~\cite{Schmidt:99n} that bypass the network and I/O
subsystems when objects are collocated.  Even for collocated
deployments, however, standard middleware implementations often still
contain code capable of performing {\em remoting}, which performs the
(de)marshaling and framing logic used to send requests across a
network.
\begin{figure}[h]
\centerline{\includegraphics[width=8cm]{figures/BasicSP-Specialization-Points.eps}}
  \bfcaption{{\em BasicSP} Specialization Points}
  \label{fig:basicsp-specialization}
\end{figure}
In the {\em BasicSP} scenario, for instance, the {\tt Airframe} and
\url{Nav_Display} are collocated, {\em i.e.}, they do not send any
events across a network.  Unfortunately, the standard TAO Real-time
CORBA implementation is excessively general, {\em i.e.}, its generated
stubs contains code that can send remote CORBA requests, even though
it is not required for particular deployments.  A different variant of
this scenario, however, may deploy the {\tt Airframe} and
\url{Nav_Display} components on separate nodes.
%%%
% Reviewer comment: The injection of therefore in the middle of many
% sentences seems
% unnecessary. This occurs often at the end of EACH challenge (in italics)
% in section 2.2  I do not think this word is needed.
%%%
%%%
% Arvind: Removing the therefore.
%%%
{\em A challenge is to develop middleware specialization techniques
that can
identify redundant functionality (such as remoting code for collocated
deployments) and remove this functionality from selected parts of the
middleware for certain product variants or application-specific
contexts.}

\sqzlarge
\paragraph* {\bf Challenge 2. Redundant request creation and/or
initialization}  To send a request to the server, middleware
implementations create a {\em request}, which contains buffer space to
hold the header and payload information for each invocation.
Rate-based DRE systems often repeatedly generate periodic events, such
as timeouts that drive periodic system execution.  Since most request
information (such as message size, operation name, and service
context) does not change across events, middleware implementations can
use buffer caching~\cite{Schmidt:98v} strategies to minimize request
creation.  This approach, however, can still incur the overhead of
initializing the request header and payload for every request.
In the {\em BasicSP} scenario, for instance, the {\tt Timer} component
always sends the same {\tt timeout} event to the {\tt GPS} component.
Similarly, the {\tt GPS} and {\tt Airframe} components send the same
\url{data_avail} event to their consumers.  A different variant of
this scenario, however, may not send the same events to consumers
repeatedly.

{\em A challenge is to develop middleware
specialization techniques that can reuse pre-created requests (i.e.,
from previous invocations) partially and/or completely to avoid
redundant initialization for certain product variants or
application-specific contexts.}

\sqzlarge
\paragraph* {\bf Challenge 3. Repeated resolution of the same request
dispatch}  To minimize the time/\-space overhead incurred by opening
multiple connections to the same server, middleware often multiplexes
requests on a single connection between client and server processes.
Multiple client requests targeted for different request handlers in a
server process are therefore received on the same multiplexed
connection.  Standard Real-time CORBA servers typically process a
client request by navigating a series of middleware layers, {\em
e.g.}, ORB core, object adapter(s), servant, and operation.  To
optimize request demultiplexing, Real-time CORBA implementations can
combine active demultiplexing~\cite{Schmidt:98v} and
perfect-hashing~\cite{Schmidt:98v} strategies to bound worst case
lookup time to $O(1)$, irrespective of the nesting of the layers.
This optimization, however, can still incur non-trivial overhead when
navigating middleware layers and is redundant when the target request
handler remains the same across different request invocations.

In the {\em BasicSP} scenario, for instance, the {\tt Airframe} and
\url{Nav_Display} components repeatedly use the same \url{get_data()}
operation to fetch new GPS and Display updates.  In a connection
between {\tt GPS} and {\tt Airframe} components, therefore, the
\url{get_data()} operation is sent and serviced by the
same request dispatcher.  A different variant of this scenario,
however, may service operations via different request dispatchers.

{\em A challenge is to develop middleware specialization
techniques that avoid the expense of navigating layers of middleware
to resolve the same request dispatch for certain product variants or
application-specific contexts.}

\sqzlarge
\paragraph* {\bf Challenge 4. Redundant (de)marshaling overheads}
PLA-based DRE systems may be deployed on platforms with different
instruction set byte orders.  To support seamless request processing
irrespective of byte ordering, general-purpose Real-time CORBA
implementations therefore use the general inter-ORB protocol (GIOP),
which performs byte order tests when (de)marshaling
requests/\-responses.  These tests incur unnecessary overhead,
however, when the nodes a DRE system runs on have the same byte order.
The GIOP protocol also requires alignment of primitive types such as
long and double within a request/response for architectures that
require alignment.  Alignment forces middleware implementations to
maintain offset information within a request/response buffer and pad
buffers up to next readable/writable locations.  Frequent alignment
and padding can force buffer resizes.  The overhead associated with
alignment can be eliminated in homogeneous environments, {\em i.e.},
when the same ORB implementation is used for both (de)marshal\-ing.

In the {\em BasicSP} scenario, for instance, the two nodes on which
the components are deployed ({\em NodeA} and {\em NodeB}) have the
same byte order.  However, the general-purpose TAO Real-time CORBA
middleware residing on these nodes still tests whether (de)marshaling
is needed when requests/responses are exchanged between nodes.  A
different variant of this scenario, however, may run on nodes with
different byte orders.  Similarly, both nodes run the same middleware
implementation and consequently the same (de)marshaling mechanisms.
In this situation data can be sent unaligned over the network.
{\em A challenge is to develop
middleware specialization techniques that evaluate ahead-of-time
deployment properties to remove redundant (de)marshaling overheads for
certain product variants or application-specific contexts.}

\sqzlarge
\paragraph* {\bf Challenge 5. Overly extensible middleware frameworks}
Middleware is often developed as a set of frameworks that can be
extended and configured with alternative implementations of key
components, such as different types of transport protocols ({\em
e.g.}, TCP/IP, VME, or shared memory), event demultiplexing mechanisms
({\em e.g.}, reactive-, proactive-, or thread-based), request
demultiplexing strategies ({\em e.g.}, dynamic hashing, perfect
hashing, or active demuxing), and concurrency models ({\em e.g.},
thread-per-connection, thread pool, or thread-pre-request).  A
particular DRE product variant, however, may only use a small subset
of the potential framework alternatives.  As a result, general-purpose
middleware may be {\em overly} extensible, {\em i.e.}, contain
unnecessary overhead for indirection and dynamic dispatching that is
not needed for use cases in a particular context.
In the {\em BasicSP} scenario, for instance, the transport protocol is
VME, the event demultiplexing mechanism is reactive, the request
demultiplexing mechanisms are perfect hashing and activate demuxing,
and the concurrency model is thread pool.  A different variant of this
scenario, however, may use an alternative set of framework components.

{\em A challenge is to develop middleware specialization
techniques that can eliminate unnecessary overhead associated with
overly extensible middleware framework implementations for certain
product variants or application-specific contexts.}

%%%%
% Why are these significant/and or why are we solving them? We
% did not discuss them earlier.
%%%
\subsection {Summary}
This section described the different dimensions of middleware
generality that are applicable to CORBA based middleware
implementations.  These challenges, however, are also applicable to
other middleware standards for PLAs such as .NET~\cite{DotNet:02} and
J2EE~\cite{J2EE:01} as follows: Challenge 1 deals with enhancing the
collocation optimization present in many CORBA ORB implementations.
.NET and J2EE implementations that provide some variation of the
collocation optimization can benefit from resolving this challenge.
Similarly, challenge 4 which deals with specializing (de)marshaling
can be applied to RPC based middleware implementations such as Java's
Remote Method Invocation.  Repeated resolution of same dispatch
(Challenge 3) pertains to CORBA based middleware implementations.
However, middleware implementations that require navigation of
multiple layers/lookup tables to find the target request processor can
benefit from resolving this challenge.  Challenge 2 occurs in almost
all middleware implementations which provide notion of a
request/response object.  Middleware implementations apply design
patterns~\cite{Vlissides:94} to accommodate PLA variability such as
different protocols and concurrency mechanisms.  Resolving framework
generality (challenge 5) can lead to a more customized deployment
platform for the different product variants.
