% $Id: intro.tex,v 1.12 2004/05/16 18:13:29 dengg Exp $

\section{Introduction}
\label{intro}

Large-scale, distributed real-time and embedded (DRE) systems are
increasingly being used to control critical aspects of global
infrastructure.  For instance, DRE systems are now deployed in
commercial air traffic control, military systems, electrical power
grid, industrial process control, and medical imaging domains. Below
we illustrates current trends in the software
development of DRE systems while identifying core requirements of DRE
systems that must be addressed to fulfil the promise held by these
trends.

\subsection{Increasing Use of Component Middleware for DRE Systems
Software Development} 
\label{dre_comp_mw}

To meet the challenges of developing and maintaining DRE
systems, research over the past decade has focused on developing,
optimizing, and standardizing \emph{object-oriented
middleware}~\cite{Vinoski:98}, which is systems software that (1)
resides between applications and the underlying operating systems,
network protocol stacks, and hardware and (2) helps shield DRE
applications from the accidental complexities of heterogeneous
platforms by defining communication abstractions that can be
implemented over a variety of networks and operating systems.
Object-oriented middleware also implements reusable
\emph{services} (such as asynchronous event-based communication,
global scheduling, and dynamic resource management) that provide
functionality common to many DRE applications.  Examples of
object-oriented middleware for DRE systems include Real-time
Java~\cite{RTSJ:00} run-time environments ({\em e.g.},
jRate~\cite{Schmidt:03b}) and Real-time CORBA object request brokers
(ORBs)~\cite{RTCorba:02} ({\em e.g.}, TAO~\cite{Schmidt:97q}).

More recently, {\em component
middleware}~\cite{Heineman:01,Szyperski:99} has defined additional
capabilities that enhance object-oriented 
middleware for DRE systems, as follows:
\begin{itemize}\crunchlist
\item It defines a component abstraction that consists of a collection
of (1) \emph{interface ports}, exposing operations that clients can invoke
to use a service provided by the component, or indicating the
methods/\-services that the component itself depends on to achieve its
functionality and (2) \emph{event ports} that are used to publish and
consume events.

\item It allows developers to focus on programming their application
``core logic'' ({\em i.e.}, primary functionality), rather than
wrestling with lower-level tasks ({\em e.g.}, network programming,
scheduling, security, and event processing).  Instead, the application
functionality is associated with the configuration-related
capabilities via auto-generated component ``glue code'' that
standardizes the interaction with other components and the middleware.

\item It supports component \emph{containers} that define a common
operating environment in which a set of related components execute.
Containers also provide components with key resources ({\em e.g.},
priority levels, real-time threads of control, and transparent state
replication) and shield components from many tedious, error-prone, and
non-portable complexities of the underlying networks, operating
systems, and object-oriented middleware.

\item It makes a significant attempt to address problems of
configuring and deploying DRE applications throughout networks of
heterogeneous computing nodes by providing standardized component
assembly, packaging, and distribution formats.  These configuration
and deployment mechanisms enable the core functional issues to be
decoupled from QoS-related issues so that QoS properties can be
developed, configured, monitored, and managed not by those developing
application functionality, but by a separate set of specialists ({\em
e.g.}, middleware developers, systems engineers, and administrators)
who are often much better positioned to make the appropriate
configuration and deployment choices.

\end{itemize}

\sqztiny
\noindent Examples of component middleware for DRE systems
includes Prism~\cite{Sharp:03} and the Lightweight CORBA Component
Model (CCM)~\cite{CCM-light:03} ({\em e.g.},
CIAO~\cite{Schmidt:03m}). 
Appendix~\ref{ccmover} provides an overview of the capabilities of CCM.

\iffalse
% probably too much
Component middleware is already having a
positive impact on the quality and productivity of developing DRE
systems, such as distributed interactive
simulations~\cite{Noseworthy:02}, avionics mission computing
systems~\cite{Sharp:03}, and distributed multimedia
applications~\cite{Gill:01a}.  By defining additional capabilities and
common services -- as well as standardizing configuration and
deployment mechanisms -- component middleware enables DRE application
developers to concentrate on the application-specific aspects of their
systems, and leave the application-independent communication,
deployment, and QoS-related details to DRE middleware developers.  As
a result, an increasing number of DRE systems are being developed
using component middleware.
\fi

\subsection{Importance of Publisher/\-Subscriber Communication
Paradigm in DRE Systems} 
\label{ec_need}

An increasing number of DRE systems require real-time transfer of
control and data among large number of heterogeneous entities that
coordinate with each other in a loosely coupled fashion. Examples of
such systems include military systems like the Joint Battlespace
Infosphere (JBI), telecommunications systems involving large scale
network monitoring and management, environmental 
emergency response systems requiring real-time coordination between
various civilian emergency response units, industrial process control 
requiring large scale automated system instrumentation and
sensing/\-actuation, or supervisory control and data acquisition
(SCADA) systems requiring real-time robust control and data
communications. 
\iffalse
% seems out of place. so I commented it out - andy
Recently the Object Management Group (OMG) standards
organization has adopted the Data Distribution Service (DDS)~\cite{}
standard to 
%TODO
meet the real-time data distribution requirements of loosely
coupled large-scale DRE systems. 
\fi

Perhaps the most critical middleware service, therefore, for the types
of DRE systems outlined above are a publisher/\-subscriber
service~\cite{Buschmann:95b,NDDS:99}. 
The publisher/\-subscriber design is a powerful architecture
for event-based communication because it provides anonymity, by
decoupling event publishers and subscribers, and asynchronism, by
automatically notifying subscribers when a specified event is
generated. 
Moreover, the publisher/\-subscriber services reduces software
dependencies through anonymity and asynchrony, thereby supporting the
loose coupling required of these DRE systems. Publisher/\-subscriber
services are particularly relevant for large-scale DRE systems because
they can support a changing set of requirements and environments by
defining clear and crisp boundaries between various entities of an
application. 

One such publisher/\-subscriber service that supports several
important features required by event-driven DRE applications is a
real-time event service~\cite{Schmidt:97i} available as part of the
TAO~\cite{Schmidt:97q} project, which is our open-source implementation
of real-time CORBA. The real-time event service provides
low-latency/\-jitter event dispatching, support for periodic processing,
centralized event filtering, and efficient use of network and
computational resources.  Additionally, many of the requirements of
these DRE systems can be met scalably and robustly via federations of
such real-time publisher/\-subscriber services.  

With the increasing use of QoS-enabled component middleware to develop
DRE systems compounded by the need for real-time
publisher/\-subscriber services to support a class of DRE systems,
therefore, requires integration of real-time publisher/\-subscriber
services within QoS-enabled component middleware. However,
standards-based component middleware do not specify how
publisher/\-subscriber services can be robustly supported within
component middleware. Although performance evaluation metrics for
real-time publisher/\-subscriber object-oriented middleware services
are available~\cite{Schmidt:02e}, there is a general lack of
information and insights into the design and performance evaluation of
real-time publisher/\-subscriber services within QoS-enabled component
middleware. This paper focuses on addressing this dimension of
research. 

\noindent
Our earlier work in the space of integrating publisher/\-subscriber
services and supporting a federation of these within QoS-enabled
component middleware has focused on (1) how software design
patterns can be used to provide a robust
integration of event-based communication services within QoS-enabled
component middleware~\cite{Schmidt:04e}, (2) how a federation of real-time
publisher/\-subscriber services can be configured and deployed in the
context of QoS-enabled component middleware~\cite{FESML_ACMSE:04}, and
(3) how  model-driven generative tools can be used
to alleviate accidental complexities in configuring and deploying
these services within QoS-enabled component middleware~\cite{Schmidt:04o}. 

This paper extends our previous work by (1) analyzing the pros and
cons of different design choices for integrating real-time
publisher/\-subscriber services within QoS-enabled component
middleware (2) illustrating how container-based RT
publisher/\-subscriber services  
leverage the benefits of the component-oriented software development
paradigm, and (3) demonstrating empirically that QoS-enabled component
middleware-based RT publisher/\-subscriber services (specifically the
TAO Real-time 
Event Service) can successfully maintain the QoS requirements of
large-scale DRE applications.  

\sqzhuge\paragraph{Paper organization.}
The remainder of this paper is organized as follows:
Section~\ref{design} describes three different architectural choices
for integrating real-time publisher/\-subscriber services within
QoS-enabled component middleware illustrating the pros and cons of
each approach; Section~\ref{integration} describes the challenges in
integrating real-time event services within component middleware and
our solutions to address these; 
% TO-DO -- need to decide whether to keep these 3 or not
\iffalse
Section~\ref{modeling} explains how modeling tools can be used to
configure and deploy event services; 
Section~\ref{benefits} demonstrates how container-based RT
event services reduce the development costs of DRE systems;
\fi
Section~\ref{benchmarking} provides the results of benchmarking
experiments that establish the feasibility of container-based RT event
services; Section~\ref{related} compares our results to related research;
and Section~\ref{conclusion} presents concluding remarks. 

