% $Id: design.tex,v 1.13 2004/05/16 14:24:25 gokhale Exp $

\section{Architectural Design Choices for Composing Real-time Event
Services in QoS-enabled Component Middleware} 
\label{design}

The CORBA Component Model (CCM) standard does not specify how
publisher/\-subscriber services can be composed within component
middleware. This issue is further complicated by the need for
real-time publisher/\-subscriber services to be integrated within
QoS-enabled implementations of CCM, such as our Component Integrated
ACE ORB (CIAO)~\cite{CIAO}. 

This section describes three possible architectural choices for
integrating real-time publisher/\-subscriber services within the CORBA
Component Model. In this paper we focus on integration of a 
real-time event channel, which is a manifestation of the
publisher/\-subscriber communication
paradigm. Figure~\ref{fig:ec-choices} illustrates how these
\begin{figure}[htb]
\center{\includegraphics[width=2.5in]{figs/ccm_pubsub_choices.png}}
\bfcaption{Architectural Choices for Integrating Publisher/\-Subscriber
Services in CCM}
\label{fig:ec-choices}
\end{figure}
architectural choices vary based on where within the component middleware
architecture does an event channel gets composed. The three
architectural choices include (1) {\em component-based} -- where the
event channel can be represented as an application-level component,
(2) {\em container-based} -- where the event channel can be
encapsulated within the container, and (3) {\em component
server-based} -- where the event channel can reside within the
component server. This section describes each architecture choice in detail
analyzing the advantages and disadvantages of each
approach. Section~\ref{benchmarking} subsequently provides empirical
guidance to support our analysis.

\subsection{Component-level Event Channels}
\label{component-level}

\paragraph{$\bullet$ Design}
The first architecture choice for providing real-time event services
in component middleware is to instantiate event channels as
application-level components as illustrated in
Figure~\ref{fig:ec_as_component}. In this 
architecture, the interface normally provided by the event channel is
exposed as a facet. This interface contains methods to connect to the
event channel, configure real-time properties, and push events. The
event channel interface is transformed from that of a standard CORBA
object into that of a CORBA component. 

\begin{figure}[htb]
\center{\includegraphics[width=2.8in]{figs/pubsub_as_component.png}}
\bfcaption{Publisher/Subscriber Service As CCM Component}
\label{fig:ec_as_component}
\end{figure}

\sqzpar\paragraph{$\bullet$ Analysis}
The primary advantage to this approach is its simplicity. The
complexity needed to implement an event channel component is
rudimentary since the encapsulated service already implements the
event channel functions. Also, this architecture does not restrict
event channel 
capabilities in any way. The full set of event channel features is
available to other components. Instantiating and deploying multiple
event channels is straightforward and follows the same rules as apply
to standard components. 

There are a number of disadvantages to using component-level event
channels. Generally speaking, the shortcomings of the object model
remain present in this architecture. First, the component glue-code,
or servant, must manipulate event service interfaces directly, which
exposes low-level CORBA programming details. Second, the component
servant logic must encapsulate QoS and RT properties, which inhibits
the flexibility and reusability of components across different
operating contexts and environments. Third, it is impossible to
substitute or interchange different publisher/\-subscriber services
without recompilation of components. Fourth, application level
components must now be responsible for managing event channel
lifecycles. 

The net result of these effects is that component-level
composition of event channel configurations must be decided at
design-time, rather than at deployment time. Additionally, the event
channel component architecture conflicts with the standard CCM
container programming model, which establishes the container to be
sole mediator between application-level components and common
middleware services, such as real-time event services. Ironically, in
this case the event service itself is encapsulated within the
component. Finally, this architecture always results in a remote call to
transmit an event to the event channel component, which must be
handled by the ORB and requires additional processing and levels of
indirection. Given the number of unfavorable consequences of utilizing
this architecture, it is not appropriate for the majority of
component-based DRE applications that require stringent QoS guarantees
at a low cost. 

\subsection{Container-level Event Channels}
\label{container-level}

\paragraph{$\bullet$ Design}
Figure~\ref{fig:ec_in_container} depicts a second possible
architecture for providing real-time event services 
in component middleware where an event channel is encapsulated  within
the container. In this architecture, the container is responsible for
managing event channel lifecycles, initializing channels and gateways
that are necessary in the context of a federation,
connecting publishers and subscribers, configuring QoS and RT
properties, implementing publisher and subscriber servants, and
terminating services. The container also exposes two distinct
interfaces. One interface provides configuration methods and is
invoked by the component deployment framework based on the properties
specified in XML descriptors that describe configuration
decisions. The second interface provides a push method and is invoked
by application-level components.  

\begin{figure}[htb]
\center{\includegraphics[width=3.3in]{../figs/ciao-container-framework.png}}
\bfcaption{Publisher/Subscriber Service Within CCM Container}
\label{fig:ec_in_container}
\end{figure}

\sqzpar\paragraph{$\bullet$ Analysis}
There are many advantages to this architecture. First, application
components are totally isolated from event service implementation
details. This reduces the memory footprint of individual components
and preserves their lightweight nature. Although the component
deployment framework is exposed to the implementation details of the
real-time event service (since the deployment framework must
instantiate and configure channels) rather than component servant glue
code, it is not important for the deployment framework to be
lightweight. 

Second, QoS properties are specified via XML and
encapsulated within the container. This maximizes the flexibility and
reusability of components by allowing them to be reconfigured with
different QoS properties and/or services as required by new and
changing operating contexts, without making any changes to the
component logic or glue-code thereby obviating the need for
recompilation. Third, this architecture aligns with the CCM container
programming model and delays event configuration-related decisions
until deployment time, which allows additional optimizations to be
incorporated depending on the knowledge of the deployment context.
For example, it may not be known until deployment time which network links 
have high latency or low reliability, yet this information is critical to 
determining the best possible real-time event service configuration.

The disadvantage to the container-level event channel architecture is
the difficulty encountered in actually implementing it effectively and
efficiently for multiple dissimilar services. There are a number of
design challenges that arise when pursuing this method of event
channel integration. The various design challenges and patterns-based
solutions appear in Section~\ref{integration}.

\subsection{Component Server-level Event Channels}
\label{server-level}

\paragraph{$\bullet$ Design}
The third possible architecture for providing real-time event services
in component middleware is to place event channels within the
component server. In this architecture, event channels are still
accessed and manipulated via the container. However, the component
server-level architecture is fundamentally different from the
container-level architecture because the component server is a
lower-level entity. Only a single component server exists on each host
in the distributed computing environment, so this architecture results
in all the components that execute on a given host sharing the same
event channel. 

\begin{figure}[htb]
\center{\includegraphics[height=2.3in]{figs/pubsub_in_comp_server.png}}
\bfcaption{Publisher/Subscriber Service Within Component Server}
\label{fig:ec_in_comp_server}
\end{figure}

\sqzpar\paragraph{$\bullet$ Analysis}
The advantages present in the container-level architecture are also
applicable to the component server-level architecture: components are
still isolated from event services in such a way that they remain
configurable after compilation, their memory footprint is minimized,
and push operations result in only local method invocations. However,
the component server-level architecture is more coarse-grained {\em i.e.},
a large number of components may be required to share a single
channel. This result may be an advantage or disadvantage depending on
the specific component application. 

For applications that require either multiple event channels on a
single host or that wish to maximize component flexibility to allow
for future enhancements or modifications, the component server-level
architecture may be too restrictive. On the other hand, for
applications that do not require these capabilities, the component
server-level architecture results in a simpler configuration and
deployment process, which reduces developer effort. In the case of
very large-scale DRE systems, the savings may be
substantial. Ultimately, the question of whether to employ container
or component server event channels can only be answered by the
application developer.  

\smallskip\noindent
Based on our analysis of the pros and cons of each
design choice, we have selected the container-based event channel as
the target to obtain additional guidance on its applicability and
performance. The container-based architecture provides the most
flexible real-time event service, while preserving the benefits of the
CCM container programming model. As described in~\cite{Schmidt:04e},
this architecture can be implemented in a way that is very fast,
lightweight, and flexible enough to accommodate new services in the
future with little modification. Consequently, the container-based
architecture will be useful for the widest range of DRE component applications.
