% $Id: motivation.tex 4129 2006-11-09 20:44:15Z gokhale $

% Jai, I am no longer including this file. However keep this around
% since we will include the overviews of our technologies in the
% solution section.
\subsection{DRE System Case Study}
\label{sec:uav-casestudy}

Developing and deploying emergency response systems is hard. For example,
there are multiple modes of operations for the UAVs, including aerial
imaging, survivor tracking, and damage assessment. Each of these modes is
associated with a different set of QoS requirements. For example, a key QoS
criteria involves the latency requirements in sending images from the
flying UAVs to ground stations under varying bandwidth availability.
Similar QoS requirements manifest themselves in the traffic management,
rescue missions, and fire fighting operations.

To examine XXX's capabilities in the context of a representative
DRE system, in conjunction with colleagues at BBN Technologies and Washington
University, we have developed a prototype of the UAV portion of the
emergency response system~\cite{Schantz:04} described above using the CCM
and Real-time CORBA capabilities provided by CIAO~\cite{Schmidt:03m}.
This section describes (1) the key capabilities of the QoS-enabled middleware 
used to develop, deploy and configure the UAV case study, 
(2) the structure/\-functionality of our UAV case study and 
(3) the key requirements that XXX framework had to address.  
Naturally, XXX's capabilities can be applied to many DRE systems -- 
we focus on the UAV case study in this paper to make our design 
discussions and performance experiments concrete.

\subsubsection{Key Capabilities of the QoS-enabled Middleware}
\label{sec:uav}

The XXX framework and the UAV case study are developed using
a QoS-enabled middleware infrastructure consisting of the
{\em Component-Integrated ACE ORB} (CIAO)~\cite{Schmidt:03m}, the
{\em Deployment And Configuration Engine} (DAnCE)~\cite{Schmidt:05y},
the {\em Resource Allocation and Control Engine} (RACE)~\cite{Schmidt:05u},
and the {\em \em Component Synthesis of Model Integrated
Computing} (CoSMIC)~\cite{Schmidt:06a}.

\subsection{Key Capabilities of the LwCCM}
\label{keyccm}

The OMG Lightweight CCM (LwCCM)~\cite{CCM-light:03} specification
standardizes the development, configuration, and deployment of
component-based applications.  LwCCM uses CORBA's distributed object
computing (DOC) model as its underlying architecture, so applications
are not tied to any particular language or platform for their
implementations.  {\em Components} in LwCCM are the implementation
entities that export a set of interfaces usable by conventional
middleware clients as well as other components. Components can also
express their intent to collaborate with other components by defining
{\em ports}, including (1) {\em facets}, which define an interface
that accepts point-to-point method invocations from other components,
(2) {\em receptacles}, which indicate a dependency on point-to-point
method interface provided by another component, and (3) {\em event
sources/sinks}, which indicate a willingness to exchange typed
messages with one or more components.  {\em Homes} are factories that
shield clients from the details of component creation strategies and
subsequent queries to locate component instances.

\begin{figure}[htbp]
  \centering
  \includegraphics[width=5in,height=2in,keepaspectratio]{CCM-Layers}
  \bfcaption{Layered LwCCM Architecture}
  \label{fig:Layers}
\end{figure}

Figure~\ref{fig:Layers} illustrates the layered architecture of LwCCM,
which includes the following entities:
\begin{itemize}

\item LwCCM sits atop an {\bf object request broker} (ORB) and
provides {\bf containers} that encapsulate and enhance the CORBA
portable object adapter (POA) demultiplexing mechanisms.  Containers
support various pre-defined hooks and strategies, such as persistence,
event notification, transaction, and security, to the components it
manages.  

\item A {\em component server} plays the role of a process that
manages the homes, containers, and components.

\item Each container manages one type of component and is responsible
for initializing instances of this component type and connecting them
to other components and common middleware services.

\item The {\bf component implementation framework} (CIF) consists of
patterns, languages and tools that simplify and automate the
development of component implementations which are called as {\bf
executors}. Executors actually provide the component's business logic.

\item Component Implementation Definition Language (CIDL) is a
text-based declarative language that defines the behaviour of the
components. In order to shield the component application developers
from many complexities associated with programming POAs like servant
activation and deactivation, a CIDL compiler generates infrastructure
glue code called {\em servants}.  Servants (1) activate components
within the container's POA, (2) manage the interconnection of a
component's ports to the ports of other components, (3) provide
implementations for operations that allow navigation of component
facets, and (4) intercept invocations on executors to transparently
enact various policies, such as component activation, security,
transactions, load balancing, and persistence.

\item To initialize a instance of a component type, a container
creates a component home.  The component home creates instances of
servants and executors and combines them to export component
implementations to external world.

\item Executors use servants to communicate with the underlying
middleware and servants delegate business logic requests to
executors. Client invocations made on the component are intercepted by
the servants, which then delegate the invocations to the
executors. Moreover, the containers can configure the underlying
middleware to add more specialized services such as integrating event
channel to allow components to communicate, add Portable Interceptors
to intercept component requests, etc.
\end{itemize}

\subsubsection{Overview of CIAO.}
\label{overview-ciao}

CIAO is an open-source\footnote{CIAO is available from
\url{www.dre.vanderbilt.edu/CIAO}.} implementation of the OMG
Lightweight CCM and Real-time CORBA~\cite{RTCorba:02} specifications
built atop The ACE ORB (TAO)~\cite{Schmidt:97q}.  CIAO's architecture
(shown in Figure~\ref{fig:ciao}) is designed based on (1) patterns for
composing component-based middleware~\cite{Markus:02} and (2)
reflective middleware techniques to enable mechanisms within the
component-based middleware to support different QoS
aspects~\cite{Schmidt:04w}.

\subsubsection{Overview of Model-Driven Development (MDD) and CoSMIC.}
\label{core}

To simplify the development of applications based on Lightweight CCM,
we have developed the {\em Component Synthesis of Model Integrated
Computing} (CoSMIC), which is an open-source\footnote{CoSMIC is
available for download from \url{www.dre.vanderbilt.edu/cosmic}.} set
of model-driven development (MDD) tools that support the deployment,
configuration, and validation of component-based DRE systems.  A key
capability supported by CoSMIC is the definition and implementation of
{\em domain-specific modeling languages} (DSMLs), which use concrete
and abstract syntax to define the concepts, relationships, and
constraints used to express domain entities~\cite{Janos:03}.

A key CoSMIC DSML called {\em Platform
Independent Component Modeling Language} (PICML)~\cite{Schmidt:04z}
enables graphical manipulation of modeling elements and
performs various types of generative actions, such as synthesizing
XML-based deployment plan descriptors defined in the OMG D\&C
specification~\cite{DandC:03}.

\subsubsection{Overview of DAnCE.}
\label{overview-dance}

DRE system application component assemblies developed using CIAO are
deployed and configured via DAnCE, which implements the standard OMG
{\em Deployment and Configuration} (D\&C)
specification~\cite{DandC:03}.  DAnCE
manages the mapping of MLRM and application components onto nodes in
our target environment.  The information about the component
assemblies and the target environment in which the components will be
deployed are captured in the form of standard XML assembly descriptors
and deployment plans.  DAnCE's runtime framework parses these
descriptors and plans to extract connection and deployment information
and then automatically deploys the assemblies onto the CIAO component
middleware platform and establishes the connections between component
ports.

\subsubsection{Overview of RACE.}
\label{overview-race}

RACE is an adaptive resource management framework
built atop our CIAO QoS-enabled component middleware, that provides 
(1) {\em resource monitor} components that track 
utilization of various system resources, such as
CPU, memory, and network bandwidth, (2) {\em QoS monitor} components
that track application QoS, such as end-to-end delay, (3) {\em
resource allocator} components that allocate resource to components
based on their resource requirements and current availability of
system resources, (4) {\em configurator} components that configure QoS
parameters of application components, (5) {\em controller} components
that compute end-to-end adaptation decisions to ensure that QoS
requirements of applications are met, and (6) {\em effector}
components that perform controller-recommended adaptations.


\subsubsection{The UAV Case Study}
\label{sec:uav}

\begin{figure}[htbp]
  \centering
  \includegraphics[width=0.9\linewidth,keepaspectratio]{single_stream}
  \vspace{-0.1in}
  \caption{Emergency Response System components }
  \label{fig:ers_arch}
\end{figure}

Figure~\ref{fig:ers_arch} illustrates the architecture for the application suite
that is motivating the specific directions for our work currently
being developed and evaluated. In the UAV example, each
UAV is associated with a stream of images.  Each image stream is composed
of {\tt Sender}, {\tt Qosket}, and {\tt Receiver} components.  {\tt Sender}
components are responsible for collecting the images from each image sensor
on the UAV.  The {\tt Sender} passes the images to a series of 
{\tt Qosket}~\cite{Schmidt:03m} components that perform operations on the
images to ensure that the image requirements are satisfied.  Some Qosket
components include \texttt{CompressQosket, ScaleQosket, CropQosket}, 
and a \texttt{PaceQosket}.  The final {\tt Qosket} then
passes the images to a {\tt Receiver} component, which collects the images
from the UAV and passes them on to a display in the control room of the
emergency response team.

\subsubsection{Network QoS Requires of UAV Scenario}
\label{challenges-network-qos}


The UAV application suite described in Section~\ref{sec:uav} presents
a wide variety of characteristics that are representative of many
DRE applications that operate under constrained resources, varying 
conditions and varying environments, including:

\begin{itemize}
\item {\bf Varying data formats}, including MPEG and PPM, with different
data sizes and compression characteristics, with which the {\tt Sender}
component could send images or video to the {\tt Qosket}, and 
{\tt Receiver} components.
\item {\bf Varying network transports}, including wireless, LAN and WAN,
with variable and constrained bandwidth channels, over which the
different {\tt Sender}, {\tt Qosket}, and {\tt Receiver} components
could be deployed, depending on the different modes of UAVs deployed
in the emergency response system.
\item {\bf Varying importances}, depending on the mission importance
of the emergency response system, which gives importance to the
images being tracked and sent by the UAVs to the control room
of the command center.
\item {\bf Varying deployments}, depending on the availablility
of the nodes, which means that the UAVs could be deployed
under any node, and still expect the same network QoS requirements
when they were deployed in a different node.
\end{itemize}
