% $Id: challenges.tex,v 1.8 2004/05/16 15:15:56 dengg Exp $

\section{CIAO Container Framework Design Goals and Implementation Strategies}
\label{integration}

This section describes how the CIAO publisher/\-subscriber service
architecture, shown in Figure~\ref{fig:ec_in_container}, employs
patterns to address the 
design goals of the container programming model outlined in
Section~\ref{design}.  For example, while maintaining efficiency
and reliability requirements, CIAO preserves the lightweight nature of
components. An individual component need know nothing about the
services that implement event-passing -- the container encapsulates
that complexity. It therefore follows that component application
developers need not be concerned with these details, further
simplifying the design of the core component logic.

For each design goal mandated by the CCM container programming model,
our pattern-oriented solution is detailed
below. Figure~\ref{fig:container-patterns} illustrates a pattern
language~\cite{Alexander:77} demonstrating the interactions between
patterns in the publisher/\-subscriber service framework integrated
within a container. 
\begin{figure}[htb]
\center{\includegraphics[width=3.3in]{../figs/ciao-container-patterns.png}}
\bfcaption{Pattern Interactions in the CIAO Publisher/Subscriber
Service Framework} 
\label{fig:container-patterns}
\end{figure}

\sqzpar\paragraph{Design goal 1:} Provide a service-independent representation 
of real-time properties. 
\sqzhuge\paragraph{Solution approach $\rightarrow$ Adapter pattern:}
Different publisher/\-subscriber services depend on different representations 
of real-time properties. The CIAO container implements an adapter that converts 
a service-independent representation of real-time properties (as
specified in XML) into a service-specific representation. The benefits
of this design are twofold: (1) component developers need not concern
themselves with peculiar configuration interfaces and (2) no matter
what changes occur to the underlying publisher/subscriber services,
the interface exposed to components does not change.

\sqzpar\paragraph{Design goal 2}: Enhance reuse and extensibility by allowing
new publisher/subscriber services to be easily plugged-in.
\sqzhuge\paragraph{Solution approach $\rightarrow$ Strategy pattern:}

This design results in
service implementations that are interchangeable from the container
perspective. After object creation, the container has no knowledge of
the actual algorithm being used, which enables fast operation
delegations and simplifies container design.

\sqzpar\paragraph{Design goal 3:} Reduce the memory
footprint of the container by decoupling the creation of
publisher/subscriber service instances from their representation.
% George - decouple it from what?
% Done. -Gan
\sqzhuge\paragraph{Solution approach $\rightarrow$ Builder pattern:}
The creation of real-time event channel instances is somewhat complex in CIAO
since they must be initialized properly.  CIAO defines a builder class that
encapsulates the complexity of creating and initializing event channels. 
The result is finer control of the construction process, isolation of
construction code, and the ability to vary the publisher/subscriber
service implementation.

\sqzpar\paragraph{Design Goal 4:} Ensure components incur only the
cost of services that are required by deferring 
publisher/subscriber service selection and configuration decisions
until run-time.  
\sqzhuge\paragraph{Solution approach $\rightarrow$ Component
Configurator pattern:}
In CIAO, publisher/subscriber service libraries are loaded dynamically
on-demand to avoid encumbering the application with unused services,
while still allowing components to wait until deployment time to
select a particular service.  This mechanism provides the flexibility
to initiate, suspend, resume, and terminate services.   

\sqzpar\paragraph{Design Goal 5:} Enable component access
to the full set of QoS features available in publisher/subscriber
services by encapsulating service-specific QoS specification
operations within a high-level interface.
\sqzhuge\paragraph{Solution approach $\rightarrow$ Wrapper Facade pattern:}
The CIAO container framework implements a high-level configuration 
interface that forwards invocations to the corresponding service-specific
operations for each publisher/subscriber service. This design results
in a concise and robust programming interface capable of configuring
the QoS features in multiple dissimilar publisher/subscriber services.

\iffalse
%%%%%%%%%% commented out %%%%%%%%%%%
\section{Integrating Real-time Event Services in Component Middleware}
\label{integration}

Before DRE application developers can derive benefits from QoS-enabled
components, real-time publisher/\-subscriber services must be integrated
with component middleware platforms. This section describes how we
enhanced the Component-Integrated ACE ORB (CIAO) to support a range of
publisher/\-subscriber services, including the TAO Real-time Event
Service. CIAO is a CORBA Component Model (CCM) implementation built on
top of TAO. 

\sqzhuge\paragraph{Context.} 
In CCM, the {\em container programming model} establishes a paradigm for
component interaction with a run-time execution
environment. Specifically, the container programming model designates
a software entity, {\em i.e.},the {\em container}, to manage a set of
components.  The container supports an API framework through which
developers control component lifecycles and access common middleware
services, including publisher/\-subscriber services. The container
architecture decouples components from application server
implementations, thereby enhancing flexibility and reuse.

A CCM container provides component implementations with access to
common CORBA services, including (but not limited to) two distinct
publisher/subscriber services: the Event
Service~\cite{CORBAService:01a} and the Notification
Service~\cite{CORBAService:02a}.  CIAO supports both these services,
as well the Real-time Event Service.  Each publisher/subscriber service
that CIAO supports has different capabilities and is accessed via a
distinct interface. Components can also elect to have events
propagated {\em directly}, which causes the container itself to play
the role of an event channel, bypassing other intermediate
publisher/subscriber components.  

Although the direct mechanism is lightweight and efficient for
components collocated in the same process, it does not scale well for
distributed components, such as remote event channel configurations
that place one or more event channels between the publisher and
subscriber components~\cite{Schmidt:01t}.

\sqzhuge\paragraph{Problem.} 
The standardized CCM container interface is designed to encapsulate
only a subset of the Notification Service, rendering the broader range
of CORBA-based publisher/subscriber services inaccessible.  The
container interface is generic by design, simplifying its use and
enabling component interoperability among CCM implementations.  Its
design, however, prevents access to any advanced publisher/subscriber
service capabilities, such as QoS guarantees.  For example, the
standard container interface lacks any mechanism to specify
priorities, timeouts, or event correlation, which are essential
capabilities for effective DRE application operation.  Likewise,
exposing components to dissimilar and proprietary publisher/subscriber
services requires developers to manipulate overly complicated and
confusing interfaces, prevents compliance with relevant OMG standards,
and bloats component memory footprint. As shown in
Figure~\ref{fig:generic-framework}, component QoS policies must be
captured within the component logic. 

\begin{figure}[htb]
\center{\includegraphics[width=3.3in]{../figs/genericframework.png}}
\bfcaption{A generic CCM container framework}
\label{fig:generic-framework}
\end{figure}

\sqzhuge\paragraph{Solution approach $\rightarrow$ Enhance containers
to encapsulate, implement, and configure publisher/subscriber
services.} 
CIAO's container framework presents application components with a
uniform interface (shown as the {\em QoS adapter} in
Figure~\ref{fig:container-framework}) through which various
\begin{figure}[htb]
\center{\includegraphics[width=3.3in]{../figs/ciao-container-framework.png}}
\bfcaption{CIAO Publisher/Subscriber Service Framework}
\label{fig:container-framework}
\end{figure}
publisher/subscriber services can be selected and configured.  This
interface enables application components to use any combination of the
publisher/subscriber services supported by CIAO.  More importantly, by
encapsulating service-specific QoS specification operations within a
high-level interface, the container framework supports QoS
configuration of publisher/subscriber services ({\em e.g.}, assignment
of priorities and latency thresholds), without exposing components to
service implementation details.  Components can therefore invoke these
services in a straightforward manner ({\em i.e.}, without becoming
tightly coupled to low-level CORBA programming details), while
preserving the flexibility and customizability of the underlying
services. Figure~\ref{fig:container-framework} illustrates the
different aspects of QoS-enabled publisher/subscriber service support
within the CIAO container framework. In contrast to
Figure~\ref{fig:generic-framework}, the QoS policies are decoupled
from application component logic via the QoS adapter encapsulated
within the container. 

\section{Configuring and Deploying Real-time Event Services}
\label{modeling}

This section describes how we have employed modeling techniques to
reduce the complexity associated with the configuration and deployment
of publisher/subscriber services. 

\sqzhuge\paragraph{Context.} 

\sqzhuge\paragraph{Problem.}

\sqzhuge\paragraph{Solution approach $\rightarrow$ Develop a modeling tool to
create publisher/\-subscriber service configuration and deployment models.}

\fi

