Table of Contents
Supported Formal Public Identifier (FPI)
Supported tags in CCM Deployment descriptors
Using OpenCCM's Packaging / Assembling Tool
Writing CCM XML meta files
Conforming to the CCM specification, you should have to provide three kinds of meta files,
Corba Component Descriptor will be generated from CIDL.
Supported Formal Public Identifier (FPI) in CCM Deployment descriptors
OpenCCM tools support the following FPIs in CCM descriptors:
In CORBA Software Descriptors:
<!DOCTYPE softpkg PUBLIC "-//OMG/DTD CORBA
Software Descriptor 3.0//EN"
In CORBA Component Descriptors:
<!DOCTYPE corbacomponent PUBLIC "-//OMG/DTD
Component Assembly Descriptor 3.0//EN"
In Component Assembly Descriptors:
<!DOCTYPE componentassembly PUBLIC "-//OMG/DTD
Component Assembly Descriptor 3.0//EN"
In Component Property Files: <file>.cpf
<!DOCTYPE properties PUBLIC "-//OMG/DTD
Component Property File 3.0//EN"
Supported tags in CCM Deployment descriptors
The Software Package Descriptor:
This descriptor provides every information concerning a particular package:
IDL reference, various implementations for specific languages, OS, compilers...
Again, the OpenCCM's deployment tool does not need/support each of the tags from
the CCM specification. Meta information such as title, license, author,... are not
used by the deployment tool, but should be filled in order to
At current stage, the
ccm_deploy tool supports ONE
implementation tag; that means you should need more than one CSD file
in case of testing various OS, for example.
The important tags are the
code. They refer to the JAR file containing
your business code, and to the public static
create_home method of the
The CORBA Component Descriptor:
This descriptor is not currently supported by the OpenCCM deployment tools.
The Component Assembly Descriptor:
This is the main descriptor you must take care about when setting up
a distributed application. It allows you to point out which packages will be involved,
which network hosts will be the targets for the homes (as Component Servers,
or DCI Nodes), and which connections to do at deployment time.
A full documentation about the CAD descriptor is available
here. It details each XML tag
with information about how to use it and how it's supported by OpenCCM deployment.
The Property File Descriptor:
Setting properties on components is done using this meta descriptor. In CCM
specification, you should be able to refer a properties file anywhere in the
Assembly Descriptor, at home level or component level, or in the
Software Package Descriptor, at package level or
The OpenCCM's deployment tool remains quite limited on properties. First, it
only looks for a
propertyfile reference into the
Assembly Descriptor, at component level. Second, it does not accept
simple tags, with each possible primitive type
specified by the CCM (
Using OpenCCM's Packaging and Assembling Tools
OpenCCM provides Graphical User Interfaces to help developers writing the meta
information needed by a CCM XML deployment. This GUI is based on the external
ObjectWeb tool Apollon,
which produces base graphic elements that can be assembled in a whole editor
for XML files based on any DTD. Here is a snapshot of the tool while editing
the assembly descriptor for the Dining Philosophers demonstration.
This tool is launched with following command :
$ ccm_assembling [ <file> ]
This will display the OpenCCM's Packaging/Assembling Tool,
where one can use the graphical menus to open any
modify them, and save them. Optional argument can be any file of these types,
and is directly opened in the editor tool.
The initiated GUI is an extended version of default Apollon frame. It allows
edition of XML files based on each DTD of the CCM deployment specification
properties). Following capture shows opened the File
Using this File menu, users can select classical
New, Open, Save operations,
or Exit the tool.
Creation and Edition of a Software Package Descriptor
When creating a new descriptor, the extension given to the file tells the tool
which kind of descriptor is being created from scratch. Following capture shows
the edition of a newly created
The Context Menu
A right click on the root element
my_package.csd displays the
menu associated to this element. Each possible additions are listed in the
first part of this menu, compliant with the specification of this descriptor.
This avoids any invalid file with respect to the DTD.
The second part of the menu consists of the other tasks relevant to a descriptor :
Actually, this part is not present in the context menus associated to sub-elements.
These operations will be described as special ones for all descriptors
The SOFTPKG Root Panel
This figure shows too the GUI panel associated to the selected root
element of a Software Package Descriptor. A custom widget allows the user
to enter the version number of this package, following the CCM specified
On each panel, an OK button ensures that each entered information
will be kept in the edited descriptor and saved to the disk. At current stage,
this button only saves the values ; in future versions, it will warn the user
in case of misuse in the panel.
Following capture shows a completed descriptor (here for a philosopher package
from the Dining Philosophers demonstration) :
The Description Panel
Associated GUI panel to a
description element allows the
providing of a small text, in place of a single line. This conforms to the DTD
which specifies PCDATA as a multiple lines text.
External Information Associated to a Software Package
The Browser tree displays some information that facilitates the edition and
reading of CCM Package descriptors. For example, the
of the Component is visible directly in the Browser, so that the user has
an overview just reading the tree.
In the same manner a philosopher package points a CORBA Component Descriptor
(CCD) and a Property File Descriptor (CPF). These files are pointed by
their relevant sub-elements (
Propertyfile), so the tree displays their locations in the node.
For the providing of external descriptors linked to a Software Package
Descriptor, the package designer can ship them in the package archive, or just
link them with a URL (XML tag
link). In case the files are shipped
in the archive, the Packaging Tool provides a file browser to select existant files
in the file system:
This GUI custom panel contains a Browse button, that displays a
Java File Selector opened on the current directory. The designer can then easily
point the right file (in this example, a CORBA Component Descriptor), to avoid
any mispell in the file name.
The IMPLEMENTATION element
Providing of information about the implementation of a Software Package
is a major part in the descriptor. This element must be specific to each
variant of an implementation, regarding the supported Operating System,
processor, runtime, compiler, or of course, the implementation language.
To avoid confusion between each
implementation branch, the
tree displays the unique identifiant directly on the node. To complete the
overview of this branch which can have numerous sub-elements of same
kind, the name each one contain is displayed in the tree too.
Here is a snapshot of the OpenCCM implementation for the philosopher package :
Fixed Attributes Values
As seen on the capture above, the CCM specification limits the range
of possible values for some of the XML attributes. This is the case for
type attribute in the
code providing an
implementation. These possible values are proposed in a custom GUI
scrolling list, so that selection of a bad value is made impossible.
Creation and Edition of a CORBA Component Descriptor
This descriptor is originally specified as generated by a CIDL compiler.
Anyway, there's the possibility to tune the generated file manually using
the Packaging/Assembling Tool.
The generation feature will be present in future releases of the OpenCCM
platform, so at current stage, the package designer has to fully provide
the CORBA Component Descriptor by hand.
A few custom GUI panels are available for the edition of the CORBA Component
Descriptor. When providing a Property File (CPF), the usual file browser
helps to select the right one in the file system, to be included in the archive.
Here is a snapshot of the Tool editing the Fork Manager CCD descriptor,
from the Dining Philosophers demo.
Creation and Edition of a Component Assembly Descriptor
Edition of the Component Assembly Descriptor constitutes the proper assembling
of a distributed application, by selecting involved components, setting them
on remote hosts, and setting the connections between each of them.
Figure above shows how the same feature as for the edition of Software
Package Descriptor (CSD), i.e. displaying an overview in the tree, is
used for the edition of assembly descriptors. In this case, the assembly
designer can see useful information for each of the packages he/she points to
while building the Component Assembly: the
for each component, which is to be used in placements, and the
fileinarchive associated, basically a SOFTPKG file.
When opening the context menu associated to a
element, an extra operation can be found. The Edit the
CSD action uses the pointer defined in sub-element
fileinarchive to open the referenced file descriptor.
Several behaviour are possible. The designer can use pre existing files
which must be referenced using the file browser of a
fileinarchive panel. In this case,
Edit the CSD will simply open these files and add
their representation to the tree.
An other proceeding, even if being in opposition to the CCM separation
of concerns, is to write the package descriptors at same time that
the assembly. Warning, the menu action will not accept
references to non-existent files. The only way to create new files is
to use the File menu.
As nested elements of the
homeplacement tag, the
componentinstantiation list represents each instance that the
home will have to bring alive during initial deployment.
On this example, the assembly designer has chosen to put every philosopher
on the same
destination, and to register some of them with
the CosNaming Service (
registerwithnaming elements). These operations
are simply done by the addition of sub-elements ; for example, the designer
adds as many
componentinstantiation branches as he/she needs. For
each, the user adds as many
sub-branches he/she wants.
The tool keeps displaying entered names in the tree, so that the view of the
whole things stays clear. It's usefull when setting applications engaging
a lot of components.
The demonstrated panel represents the selection of the component kind.
homeplacement refers to a single component file
declared in the assembly descriptor. To help the designer and avoid errors,
the Tool provides a dynamic list, that contains any possible component
package declared in the assembly descriptor. In our Dining Philosophers
example, three of them are defined:
Following figure presents how are managed collocations of homes on a
destination. Actually, these kinds of XML elements are
partitioning children, so that the Assembly
Designer just has to follow the menus without fear of invalid syntax.
The selected panel on the picture above is the
to be used for the declared
hostcollocation. There are no
automated means for entering the right destination, regarding the
format or the proper content. Assembly Designers must handle this
by hand, following the specification of
OpenCCM given here.
OpenCCM 0.8 Assembling Tool still manages
between component instances as individual elements that need to be fed
sequentially. In order to facilitate their writing, though, some custom GUI
lists are provided for involved parties selection. Here is a snapshot of
the tool, while doing the edition of a
As it can be seen on this capture, the Assembly Designer can make
selections in scrolling lists amongst components to connect together.
Content of these lists changes according to the state of the descriptor :
it refers to instances declared in the
Identification of connections, while not usefull in proper CCM deployment,
is more important considering the visual impact and interactivity. In large
applications with huge amounts of connections, each of them should be
more easily identifiable while editing, AND deploying. OpenCCM's Deployment
Infrastructure uses these identifiers to point out damaged and/or
Creation and Edition of a Property File Descriptor
This descriptor contains a few different XML elements. It allows to set
up properties at various levels: for a component instance, for
an implementation, for a package, for a CORBA Component... Each of these
refers to Property Descriptors, which can be opened in the Tool to be tuned.
Here is a snapshot of the Packaging/Assembling tool while edition of some
specific value for a philosopher name (from Dining Philosophers). Setting
simple property imposes to select its
amongst precise list :
This is the only customised GUI for the Property File Descriptor.
Saving XML and Building Archives
This operation will reload the existing descriptor file from disk.
The tool looses then any change made since last saved version.
This is the basic save operation that will backup the current state
of descriptor on disk. The file name used is always known in advance,
since the user has to provide one when choosing to write a
New descriptor in menu.
Same backup as basic Save File, but here a dialog opens
so that the user can choose a different filename.
Generating Package Archive
This operation can be called through the context menu of Software Package
Descriptors. Its goal is to build a ZIP archive containing everything
needed to use the package component.
Any provided information like
fileinarchive descriptors, IDL,
code libraries, licenses or any resources will be added to the ZIP file.
This action asks first for the selection of a file name and location, then
processes data and outputs the Package.
Generating Assembly Archive
This operation can be called through the context menu of Component
Assembly Descriptors. It acts as the package archive generator, displaying
a dialog to select an output file, and processes each information contained
within the assembly to grab local dependencies that are to be shipped with
the assembly archive.