% $Id: mlrm-mw.tex 2503 2005-11-16 15:46:20Z jai $


%folks, all this is sidebar stuff and does not actually show us how
%this has been applied to the MLRM solution - andy
%%
%% JAI : Andy, should we use some kind of case study to motivate how
%% the technologies were applied.
%%
\subsubsection{Overview of LwCCM}
\label{lwccmoverview}

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}.

Figure~\ref{fig:picml} shows a key CoSMIC DSML called {\em Platform
Independent Component Modeling Language} (PICML)~\cite{Schmidt:04z}
that 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}

In Lightweight CCM, component assemblies are deployed and configured
via the OMG D\&C~\cite{DandC:03} specification, which manages the
mapping of application components onto nodes in a target environment.
The information about the component assemblies and the target
environment in which the application components will be deployed are
captured in the form of standard XML descriptors.  To support
automatic deployment and configuration of components based on their
descriptors, we developed the {\em Deployment And Configuration
Engine} (DAnCE), whose architecture is shown in
Figure~\ref{fig:dance}. DAnCE's runtime framework parses XML assembly
descriptors and deployment plans, extracts connection and deployment
information from the descriptors and plans, and then automatically
deploys the system into the CIAO component middleware platform and
establishes the connections between component ports.\footnote{In the
context of this paper, a {\em connection} refers to the high-level
binding between an object reference and its target component, rather
than a lower-level transport ({\em e.g.}, TCP) connection.}

DAnCE implements a set of runtime interfaces defined by the OMG D\&C
specification that handle the instantiation, installation, connection
establishment, monitoring, and termination of components on nodes in a
target environment.  The D\&C specification calls this target
environment a {\em domain}, which consists of {\em nodes}, {\em
interconnects}, {\em bridges}, and {\em resources}.  The standard D\&C
interfaces implemented by DAnCE include (1) the {\tt
Execution\-Manager} and {\tt Node\-Manager}, which manage the
lifecycle of the deployment process to help configure component
servers on the nodes, install components into containers, and set up
connections among components that may be distributed across multiple
nodes, and (2) the {\tt Domain\-Application\-Manager} and {\tt
Node\-Application\-Manager}, which split a deployment plan across
multiple domains so that various QoS concerns (such as security and
fault isolation) can be enforced.  The {\tt Execution\-Manager} and
{\tt Domain\-Application\-Manager} operate at the global domain level,
whereas the {\tt Node\-Manager} and {\tt Node\-Application\-Manager}
operate at each node of the domain.
