% $Id: challenges.tex 16887 2009-02-21 02:40:43Z gokhale $
\section{Impediments to the Quality of DRE System Software Architectures}
\label{sec:chal}
We now present the deployment and configuration-imposed impediments to
the quality of DRE systems software architectures.  We focus on issues
that are both innate to the underlying middleware platforms as well as
those that are accidental.

\subsection{Overview of a Real-time Component Middleware}
\label{sec:rtcorba}

To better articulate the challenges we address in this paper, we first
present an overview of a representative component middleware, which
forms an integral part of a DRE system software architecture.  Note,
however, that our solution approach is general and not specific to the
outlined middleware.  Figure~\ref{fig:lwccm} illustrates the Lightweight
CORBA Component Middleware (Lw\-CCM)~\cite{LWCCM} architecture.  DRE
system developers can realize large-scale DRE systems by assembling and
deploying LwCCM components.  The applications within these DRE systems
can use publish/subscribe communication semantics (by using the
component event source and sink ports) or request/response communication
semantics (by using the facet and receptacle ports).  

\begin{figure}[htb]
  \centering
  \vspace{-.2in}
  \includegraphics[width=0.85\textwidth,keepaspectratio]{lwccm}
  \vspace{-.2in}
  \bfcaption{Lightweight CORBA Component Model Architecture}
  \label{fig:lwccm}
\end{figure}

In the context of component middleware platforms, such as LwCCM, a
container is an execution environment provided for hosting the
components such that they can access the capabilities of the hardware,
networking and software (OS and middleware) resources.  In particular,
containers act as a higher-level of abstraction for hosting the
components in which all the developer-specified QoS policies can be
properly configured.  Components with similar QoS configuration
specifications are hosted within the same container so that all
components in that container obtain the same QoS capabilities.   Note
that the bin packing algorithms described earlier cannot make these
fine-grained decisions.

LwCCM -- and in particular its container -- leverages Real-time CORBA
(RTCO\-RBA)~\cite{RTCORBA:05} to support the real-time QoS properties.
RTCORBA in turn extends traditional CORBA artifacts, such as (a) the
object request broker (ORB), which mediates the request handling between
clients and servers, (b) the portable object adapter (POA), which
manages the lifecycle of CORBA objects, (c) stubs and skeletons, which
are generated by an interface definition language (IDL) compiler that
hide the distribution aspects from the communicating entities, with
real-time policies and interfaces. 

RTCORBA (and hence LwCCM) defines standard interfaces and QoS policies
%shown in Figure~\ref{fig:rtcorba_features} 
that allow applications to configure and control (1) \emph{processor
  resources} via thread pools, priority mechanisms, intra-process
mutexes, and a global scheduling service, (2) \emph{communication
  resources} via protocol properties and explicit bindings, and (3)
\emph{memory resources} via buffering requests in queues and bounding
the size of thread pools. For example, the  priority at which requests
must be handled can be propagated from the client to the server (the
\texttt{CLIENT\_PRO\-PAG\-ATED} model) or declared by the server (the
\texttt{SER\-VER\_DECL\-ARED} model).  

% \begin{figure}[htb]
%   \centering
%   \includegraphics[width=0.85\textwidth,keepaspectratio]{rtcorba_features}
%   \bfcaption{Real-time CORBA Middleware Features}
%   \label{fig:rtcorba_features}
% \end{figure}


\subsection{Inherent and Accidental Complexities in Deployment and Configuration}
\label{sec:challenges}

In the CBSE paradigm, application developers must determine how to
deploy components within the containers, and grapple with the multiple
different configuration options provided by the containers.  In this
context we outline two critical challenges impeding the quality of DRE
system software architectures. 

\noindent\textbf{Challenge 1: Inherent Challenges in Deployment and
  Configuration.}   
The different analyses techniques used in the development of DRE systems
(\emph{e.g.} schedulability and timing analysis) and deployment and
resource allocation decisions (\emph{e.g.}, where each component resides
in the available computing node farm) dictate what QoS configurations
are chosen for individual components of the application.  For example,
as shown earlier, LwCCM provides configuration mechanisms to assign
priorities to  every component, defines a fixed/variable priority
request invocation and handling model (\texttt{PriorityModelPolicy}),
allows defining the number of thread resources, their type (\emph{i.e.},
static or dynamic), and concurrency options (\texttt{ThreadPool}).  

For a component-based application, the mapping of the above analyses
onto these available policies results in a number of unique QoS
configurations, and naturally, as many containers.  Unfortunately, the
principles of separation of concerns in the design of containers in
component middleware architectures force service request invocations
between components hosted on different containers to go through the
typical request demultiplexing layers and marshaling/demarshaling and
mechanisms even though they may be hosted in the same address space of
the application server.  Therefore, such invocations are considerably
slower than the invocations between components that share the same
container~\cite{Schmidt:00c}.  

Thus, in effect, components placed on different containers (which are in
turn created from unique QoS configurations) are unable to exploit the
collocation optimizations performed by the middleware.\footnote{Many
  middleware optimize the communication path for entities that reside in
  the same address space.}  As such, the sub-optimal QoS configuration
of the application leads to increased average end-to-end latencies.
Since DRE systems are made up of hundreds of components, as the number
of components in the system that are sub-optimally configured increases,
the adverse impact on end-to-end latencies can significant.  

\noindent\textbf{Challenge 2: Accidental Complexities in Deployment and
  Configuration.} It may be argued that the developers can keep track of
the QoS configurations that are produced, and depending on DRE system
QoS needs, make decisions on how to minimize the containers.  Such a
manual approach, however, introduces several non-trivial challenges for
the application developers:   

\begin{BulletList} 
\item Large-scale DRE systems typically consist of hundreds of
components spanning multiple assemblies of components.  Manually keeping
track of all the configurations (and potentially combining them to
minimize the number of containers) in such large-scale systems is very
difficult and in some cases infeasible.

\item Development of DRE systems is often an iterative process where new
requirements are added.  Thus, the system configuration needs to evolve
accordingly to cater to new requirements, and the optimizations listed
above need to be performed at the end of each reconfiguration cycle. 

\item The configuration optimization activity forces the developers to
have a detailed  knowledge of the middleware platform.  Further, the
activity itself is not central to the development of application logic
and may in fact be counter-productive to the promise of CBSE.  

\end{BulletList} 

Addressing both these challenges calls for automated tools and
techniques to perform the deployment and configuration optimizations so
that the quality of the resulting DRE system software architecture is
enhanced.
