% $Id: ccm_overview.tex,v 1.5 2004/05/16 11:29:34 gokhale Exp $

%% To be decided whether to keep this as appendix or a section
% I think we should make it an appendix, since it doesn’t describe
% any of our work. George
\section*{Appendices}
\appendix
\section{Overview of CORBA Component Model}
\label{ccmover}
The CORBA Component Model (CCM) forms a key part of the CORBA 3.0
standard~\cite{CORBA:02b}.  CCM is designed to address the limitations
with earlier versions of CORBA 2.x middleware that supported a
distributed object computing (DOC) model~\cite{Schmidt:02l}.
Figure~\ref{fig:container} depicts the layered architecture of the CCM
model.
\begin{figure}[htb]
\vspace{0in}
\center{\includegraphics[width=3.3in]{../figs/CCM-Layers.png}}
\bfcaption{Layered CCM Architecture}
\label{fig:container}
\vspace{0.1in}
\end{figure}
The remainder of this section describes the key CCM elements in
Figure~\ref{fig:container}.

\noindent{\bf Components.}
{\em Components} in CCM are implementation entities that collaborate
with each other via {\em ports}.  CCM supports several types of 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.

\noindent{\bf Container.}
A {\em container} in CCM provides the run-time environment for one or
more components that manages various pre-defined hooks and strategies,
such as persistence, event notification, transaction, and security,
used by the component(s).  Each container is responsible for (1)
initializing instances of the component types it manages and (2)
connecting them to other components and common middleware services.
Developer-specified metadata expressed in XML can be used to instruct
CCM deployment mechanisms how to control the lifetime of these
containers and the components they manage.  The meta-data is present
in XML files called {\em descriptors}.

\noindent{\bf Component assembly.}
In a distributed system, a component may need to be configured
differently depending on the context in which it is used. As the
number of component configuration parameters and options increase, it
can become tedious and error-prone to configure applications
consisting of many individual components.  To address this problem,
the CCM defines an {\em assembly} entity to group components and
characterize the meta-data that describes these components in an
assembly.  Each component's meta-data in turn describes the features
available in it ({\em e.g.}, its properties) or the features that it
requires ({\em e.g.}, its dependencies).  CCM assemblies are defined
using XML Schema templates, which provide an
implementation-independent mechanism for describing component
properties and generating default configurations for CCM components.
These assembly configurations can preserve the required QoS
properties~\cite{Schmidt:02dd} and establish the necessary
configuration and interconnections among groups of components.

\noindent{\bf Component server.}
A {\em component server} is an abstraction that is responsible for
aggregating {\em physical} entities ({\em i.e.}, implementations of
component instances) into {\em logical} entities ({\em i.e.},
distributed application services and subsystems).  A CCM component
server is a singleton~\cite{Vlissides:94} that plays the role of a
factory to create containers and standardizes the role of a server
process in the CORBA 2.x object model.  Each component server is
typically assigned a particular set of capabilities within a
distributed system.

\noindent{\bf Component packaging and deployment.}
In addition to the run-time building blocks outlined above, the CCM
also standardizes component implementation, packaging, and deployment
mechanisms. Packaging involves grouping the implementation of
component functionality -- typically stored in a dynamic link library
(DLL) -- together with other meta-data that describes properties of
this particular implementation. The CCM Component Implementation
Framework (CIF) helps generate the component implementation skeletons
and persistent state management automatically using the Component
Implementation Definition Language (CIDL).

