% $Id: picml.tex,v 1.8 2005/11/02 13:44:16 kitty Exp $

\section{Applying MIC to Develop Component-based Applications}
\label{picml}

This section describes a DSML called Platform-Independent Component
% Kitty, since space is a premium, the benefits of component
% technologies could be commented out - andy
% I have reduced the motivation. - kitty.
Modeling Language (PICML).  First we describe the challenges in system
composition and integration when using component-middleware technologies
without adequate tool support.  Then we describe how we have applied the
MDD approach to develop PICML, and show how the features in PICML help
resolve the challenges with development, configuration and deployment of
component-based applications.

\subsection{Component-based Application Development Challenges}
\label{picml_motivation}

% Component technologies improve upon the advances in programming language
% mechanisms like object-oriented programming and aspect-oriented programming
% etc by reducing the coupling between the different elements in a system.
% Tight coupling is reduced by alleviating the dependency on any programming
% language thereby allowing systems to be composed from components built
% using different programming languages, and on different middleware
% platforms.  Some key features provided by component technologies include
% support for multiple views per component, transparent navigation and
% greater extensibility.  All of the features listed are possible due to
% changes to the middleware runtime like in the case of .NET Common Language
% Runtime, or by defining abstractions like containers on top of
% second-generation object technologies like CORBA as is done in the case of
% CCM\footnote{Strictly speaking, EJB is not programming language
%   independent, and requires usage of Java}.  Sidebar~\ref{ccm} defines the
% key elements defined in CCM.
A common trend in the transition to component middleware technologies is
the use of metadata to capture properties of applications that were
previously tightly coupled with the implementation.  This allows
declarative specification of properties of applications using
platform-agnostic technologies like XML, which are read by tools during
deployment, and allows for automating the deployment and configuration of
applications.

% \BeginSidebar{CORBA Component Model}
% \label{ccm}
% Key elements of the CCM~\cite{CorbaComponents:02} include:
% \begin{itemize}
% \item {\bf Component}, which is the basic building block used to
% encapsulate application functionality
% \item {\bf Component Home}, which is a factory that creates and manages
% components
% \item {\bf Container}, which provides components with an abstraction
% of the underlying middleware and regulate their shared access to the
% middleware infrastructure,
% \item {\bf Component Implementation Framework}, which defines the
% programming model for constructing component implementations, using
% the Component Implementation Definition Language (CIDL) descriptions
% for automating generation of programming skeletons,
% \item {\bf Component server}, which groups components and containers
% together to form an executable program.
% \item {\bf ORB Services}, which provide common middleware services,
% such as transaction, events, security and persistence.
% \end{itemize}
% \EndSidebar

% Kitty, the following is a key para. We need to figure out ways in
% which the above can be trimmed a bit.
% I have trimmed the content. - kitty.

The availability of higher-level abstractions like virtual machines,
execution containers, and extra information about systems via rich
metadata, has an indirect effect in allowing people to build systems that
are more heterogeneous than previously possible.  This results in an
increase in the amount of information that must be managed by the system
developer as well as an increase in the complexity of system integration.
However, the infrastructure for managing such complex deployment were
essentially lacking in previous generation middleware.  Most deployments
were done in an {\em ad hoc} basis and there was hardly any reuse of the
deployment infrastructure.  Moreover, these ad hoc techniques had no basis
for scientifically verifying and validating the correctness of the system.
The amount of heterogeneity in the systems being deployed was also less
compared to systems built using component-based middleware.  The lack of
simplification and automation in resolving the challenges outlined above
can significantly hinder the effective transition to -- and adoption of --
component middleware technology to develop systems, thereby negating the
benefits of component middleware technologies.

% Kitty, if we trim the motivation for using component technologies, then
% here or somewhere else we need to make sure that we stress the need to
% move to component technologies. Alternately, and better yet I think if we
% just say in two sentences or so that component technology is best suited
% to address the needs for systems integration, then we do not have to go
% into too much motivation of component technologies.
% I have done the latter. - kitty.
%
% I am also concerned that if the theme of the paper is about systems
% integration then does ECSL provide a good enough example to make the
% case - andy
% Andy, yes it does. - kitty.

\subsection{Platform-Independent Component Modeling Language}
\label{picml_features}

To address the problems outlined above, we have developed a DSML called
Platform-Independent Component Modeling Language (PICML).  PICML is an
open-source DSML available for download as part of the CoSMIC MDD framework
at \url{www.dre.vanderbilt.edu/CoSMIC}. PICML enables developers of
component-based systems to define application interfaces, QoS parameters,
and system software building rules, as well as generate metadata, XML
descriptor files, that enable automated system deployment.  PICML also
provides capabilities to handle complex component engineering tasks, such
as multi-aspect visualization of components and the interactions of their
subsystems, component deployment planning, and hierarchical modeling of
component assemblies.  Currently PICML is used in conjunction with the
Component-Integrated ACE ORB (CIAO), our CCM implementation, and Deployment
and Configuration Engine (DAnCE)~\cite{Schmidt:05y}, a QoS-enabled
deployment engine.  However, PICML's design has been driven by the goal to
allow integration of systems built using different component technologies
like Microsoft .NET and EJB.
% Kitty, I added the above sentence - andy
% I have modified it a bit. - kitty.

PICML is defined as a {\em metamodel} in GME for describing components,
types of allowed interconnections between components, and types of
component metadata for deployment.  From this metamodel, $\sim$20,000 lines of C$++$ code (which represents the
% % Kitty, by providing such statistics what do we intend to achieve as
% % an effect? - andy
% The PICML metamodel defines $\sim$115 different types of basic elements,
% with 57 different types of associations between these elements, grouped
% under 14 different folders.  The PICML metamodel also uses OCL to define
% $\sim$222 constraints that are enforced by GME's constraint manager
% during the design process.
% Kitty, I presume this is generated by MetaGME and not PICML, right? -
% andy They are generated using UDM when building the PICML interpreters. -
% kitty.
modeling language elements as equivalent C$++$ types) is generated.  This
generated code allows manipulation of modeling elements, {\em i.e.},
instances of the language types using C$++$, and forms the basis for
writing {\em model interpreters}, which traverse the model hierarchy to
generate XML-based deployment plan descriptors (described in
Sidebar~\ref{descriptors}) needed to support the OMG D\&C
specification~\cite{DandC:03}.
% Each interpreter is written as a DLL that is loaded at runtime into GME
% and executed to generate the XML descriptors based on models developed by
% the component developers using PICML.  % Kitty, we may need to provide short descriptions on what different % interpreters can do - andy

\begin{figure}[htbp]
  \centering
  \includegraphics[width=\columnwidth,keepaspectratio]{PICML-Pent}%
  \caption{Model-driven Application Development Lifecycle}
  \label{fig:tool-chain}
\end{figure}

Figure~\ref{fig:tool-chain} shows the typical steps involved in developing
component-based applications using the PICML's MDD approach.  The
following describes the key steps in component-based application
development, while describing the features in PICML used in this process:

\noindent {\bf 1. Visual component interface definition.} A set of
component, interface and other datatype definitions defined via CORBA's
Interface Definition Language (IDL) may be created in PICML using either of
the following two approaches: (1) {\em Adding to existing definitions
  imported from IDL.}  In this approach, existing CORBA software systems
can be easily migrated to PICML using its {\em IDL Importer}, which takes
any number of CORBA IDL files as input, maps their contents to the
appropriate PICML model elements, and generates a single XML file that can
be imported as a PICML model; (2) {\em Creating IDL definitions from
  scratch.}  In this approach, PICML's graphical modeling environment
provides support for designing the interfaces using an intuitive ``drag and
drop'' technique making this process largely self-explanatory and
independent of platform-specific technical knowledge.  CORBA IDL can be
generated from PICML enabling generation of software artifacts in languages
having a CORBA IDL mapping.

% Kitty, some of this may be commented out for space since it is
% secondary in importance. - andy
%     Most of the grammatical details are implicit in the visual language,
%     {\em e.g.}, when the model editor screen is showing the ``scope'' of a
%     definition, only icons representing legal members of that scope will be
%     available for dragging and dropping.

\noindent {\bf 2. Valid component interaction definition.}  By elevating
the level of abstraction via MDD techniques, the well-formedness rules of
DSMLs like PICML actually capture semantic information, such as constraints
on composition of models, and constraints on allowed interactions.  There
is a significant difference in the early detection of errors in the MDD
paradigm compared with traditional object-oriented or procedural
development using a conventional programming language compiler.  In PICML,
OCL constraints are used to define the static semantics of the modeling
language, thereby disallowing invalid systems to be built using PICML, {\em
  i.e.}, PICML enforces the {\em correct-by-construction} approach to
system development.

\noindent {\bf 3. Hierarchical composition.}  In a complex system with
thousands of components, visualization becomes an issue because of the
practical limitations of displays, and the limitations of human cognition.
Without some form of support for hierarchical composition, observing and
understanding system representations in a visual medium does not scale.  To
increase scalability, PICML defines a {\em hierarchy} construct, which
enables the abstraction of certain details of a system into a hierarchical
organization, such that developers can view their system at multiple levels
of detail depending upon their needs.  The support for hierarchical
composition in PICML not only allows system developers to visualize their
systems, but also allows them to compose systems from a set of smaller
subsystems.  This feature supports unlimited levels of hierarchy
(constrained only by the physical memory of the system used to build
models) and promotes the reuse of component assemblies.  PICML therefore
enables the development of repositories of predefined components and
subsystems.  The hierarchical composition capabilities provided by PICML
are only a {\em logical} abstraction, {\em i.e.}, deployment plans
generated from PICML flatten out the hierarchy to connect the two
destination ports directly (which if not done will introduce additional
overhead in the communication paths between the two connected ports),
thereby ensuring that at runtime there is no extra overhead that can be
attributed to this abstraction.

\noindent {\bf 4. Valid deployment descriptor generation.} In addition to
ensuring design-time integrity of systems built using OCL constraints,
PICML also generates the complete set of deployment descriptors that are
needed as input to the component deployment mechanisms.  The descriptors
generated by PICML conform to the descriptors defined by the standard OMG
D\&C specification~\cite{DandC:03}.  Sidebar~\ref{descriptors} shows an
example of the types of descriptors that are generated by PICML, with a
brief explanation of the purpose of each type of descriptor.

\noindent {\bf 5. Deployment planning.} Systems are often deployed in
heterogeneous execution environments.  To
% To support such environments, component middleware strives to be
% largely independent of the specific target environment in which
% application components will be deployed.
support these needs, PICML can be used to specify the target environment
where the system will be deployed, which includes nodes, interconnects
among nodes, and bridges among interconnects, all of which collectively
represent the target environment.  Once the target environment is
specified via PICML, allocation of component instances onto nodes of the
target target environment can be performed.  PICML currently provides
facilities for specifying static allocation of components.

\BeginSidebar{Deployment Metadata}
\label{descriptors}
PICML generates the following types of deployment descriptors based on the
OMG D\&C specification:
\begin{itemize}
\item {\bf Component Interface Descriptor (.ccd)} -- Describes the
      interfaces -- ports, attributes of a single component.
\item {\bf Implementation Artifact Descriptor (.iad)} -- Describes the
      implementation artifacts (e.g., DLLs, executables etc.) of a single
      component.
\item {\bf Component Implementation Descriptor (.cid)} -- Describes a
      specific implementation of a component interface; also contains
      component interconnection information.
\item {\bf Component Package Descriptor (.cpd)} -- Describes multiple
      alternative implementations (e.g., for different OSes) of a single
      component.
\item {\bf Package Configuration Descriptor (.pcd)} -- Describes a
      component package configured for a particular requirement.
\item {\bf Component Deployment Plan (.cdp)} -- Plan which guides the
      runtime deployment.
\item {\bf Component Domain Descriptor (.cdd)} -- Describes the deployment
      target {\em i.e.}, nodes, networks on which the components are to be
      deployed.
\end{itemize}
\EndSidebar



%%% Local Variables:
%%% mode: latex
%%% TeX-master: "IEEE06"
%%% End:
