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


\section{Benefits of Container-based Real-time Event Services}
\label{benefits}

The real-time event service framework described in Section~\ref{integration}, 
in combination with the modeling technology described in Section~\ref{modeling},
reduces the development effort of DRE applications.  This section
evaluates how MDM helps alleviate key sources of complexity in a 
representative mission critical event-driven DRE application.

The integration and deployment of real-time event services
within component middleware is a classic case of {\em
crosscutting concerns} that need to be refactored, modularized, and
then composed back into the middleware.  The real-time event service 
modeling tool helps to automate this process.  We illustrate the 
merits of MDM below by comparing it with the accidental complexities 
incurred by existing {\em ad hoc} techniques used to manually integrate 
and deploy real-time event services within QoS-enabled 
component middleware.

With the earlier generation of DOC middleware, developers had to
explicitly handle the complexity of connecting to and configuring the
policies of underlying middleware. For example, in the CORBA 2.x DOC
model, developers often manually configured the policies of middleware
entities, such as real-time event services, transaction
services, and security services.  Moreover, with DOC middleware, event
channels were deployed by handcrafting application servers to create
and destroy event channels and gateways.

Figure~\ref{fig:object-middleware} shows how application developers
using CORBA DOC middleware write code manually in the ``Server'' and
``Impl'' files.
\begin{figure}[htbp]
\center{\includegraphics[width=6cm]{../figs/object_middleware.png}}
\bfcaption{Generated vs. Handwritten Code in the CORBA DOC Model}
\label{fig:object-middleware}
\end{figure}
These manual programming activities result in the production of
considerable repetitive ``glue-code'', which can actually be larger
than the application logic requiring the publisher/\-subscriber
functionality!  Moreover, these activities are error-prone since they
require application developers to have expertise in the low-level
details of the underlying middleware, which are often proprietary to
the DOC middleware.

In contrast, CCM defines the container and component server elements
to handle most of glue code.  As discussed in
Section~\ref{ccm-runtime}, the container provides the execution
context in which components run and acts as a manager for application
components by mediating access to underlying middleware services.
Consequently, the container shields component developers from
low-level details of the underlying middleware.  Likewise, component
servers provide a standardized OS process for composing and running
components and event channels, thereby alleviating the need to write
servers on which event channels will be deployed.

As illustrated in Figure~\ref{fig:component-middleware}, CCM
middleware increases the amount of generated code compared with
handwritten code because the component server code, XML component
descriptors, servants, and other glue code is now generated
automatically.  Likewise, the configuration and deployment of
publisher/\-subscriber services is automated by CCM middleware.
\begin{figure}[htbp]
\center{\includegraphics[width=6cm]{../figs/component_middleware.png}}
\bfcaption{Generated vs. Handwritten Code in the CORBA Component Model}
\label{fig:component-middleware}
\end{figure}

Although component middleware reduces the effort required to handcraft
code, there are many instances where code and/or XML descriptors are
required to configure federation of publisher/subscriber services.
The effort is increased if real-time versions of these services must
be configured as described below.  The following highlights how EQAL
can automatically generate code that would otherwise be written
manually.

\sqzhuge\paragraph{$\bullet$ Creating event channels.}
To create an event channel, five sequential steps must be carried out:
(1) declaring the channel -- where a name is assigned to the channel,
(2) setting channel attributes -- where the appropriate service
configurator file is specified for the channel, (3) instantiating the
channel -- where memory is allocated for the channel and its
constructor is called, (4) activating the channel -- where the
channel's servant is enabled, and (5) registering the channel -- where
the channel must be registered with a portable object adapter (POA).

\sqzhuge\paragraph{$\bullet$ Specifying service policies.}
When configuring a real-time service, the QoS requirements for a
supplier or consumer must be specified, which involves the following
two steps: (1) building a filter -- where a consumer specifies the
logical conditions, based on the supplier and type of an event, under
which an event should be delivered and (2) specifying real-time
properties -- where desired QoS properties, including priorities and
required execution times, and given for each event supplier and
consumer.

\sqzhuge\paragraph{$\bullet$ Connecting suppliers and consumers.}
Connecting a supplier or consumer to a channel comprises four steps:
(1) obtaining an administrative object -- where the channel supplies a
reference to a configuration entity known as an admin object, (2)
obtaining a proxy -- where the admin supplies a reference to a
connection point, known as a proxy object, (3) creating a
consumer/supplier servant -- where a servant is declared,
instantiated, and activated, and (4) connecting to the event channel
-- where a reference to the servant is passed to the proxy object.

\sqzhuge\paragraph{$\bullet$ Implementing supplier and consumer servants.}
Implementing a supplier or consumer servant involves inheriting from
an abstract base class and implementing several hook methods. The
supplier and consumer servant methods are called back when an event is
pushed or when a disconnection occurs. Code to handle these
occurrences in accordance with specific requirements of an application
must be provided by application developers.


