|
OpenCCM
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
|
Table of Contents
Warning: The OpenCCM User's Guide is now split
into the following documents:
-
Environment for using OpenCCM
-
The OpenCCM's Compilation Chain
-
Generation and implementation rules
-
The OpenCCM's Execution Chain
-
Demonstrations
-
Writing an application with OpenCCM
-
Writing CCM XML meta files
-
Using deployment functionnalities
-
Browsing and managing your application
-
The Persistent State Service
Writing CCM XML meta files
Conforming to the CCM specification, you should have to provide three kinds of meta files,
since the Corba Component Descriptor will be generated from CIDL.
Supported tags in CCM Deployment descriptors
-
The Component Assembly Descriptor:
<assembly>.cad
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 Component Servers will be the targets for the homes, and which connections to do at
deployment time.
The actual version of OpenCCM's deployment tool (ccm_deploy ) supports
hostcollocation and processcollocation . That
means you can describe your partitioning with these features, using
homeplacement .
For each homeplacement , you select packages using a
componentfileref refering to pre-defined packages.
This is done in the componentfiles part of the file, using
componentfile tags that will point to CSD files.
Another important part is the connections one. For each
connectinterface or connectevent you have to operate, you
must simply fill the tags with references to components (with
componentinstantiationref pointing the IDs defined in
partitioning ), and identifiers to specific connectors:
usesidentifier , providesidentifier ,
consumesidentifier , publishesidentifier .
You also have to fill the destination tag for each homeplacement
or hostcollocation . You have to choose between two kinds of destinations,
a component server or a node. The component server destination refers to the name of a component
server manually started with the jcs_start command.
For example, a component server started with the command jcs_start ComponentServer1
can be used such as destination into the .CAD file using the following
syntax:
<destination>CS:ComponentServer1</destination>
The node destination refers to a couple of ServerActivator and ComponentInstallation
started with the node_start command.
For example, a node started with the command node_start MainNode
can be used such as destination into the .CAD file using the following
syntax:
<destination>NODE:MainNode</destination>
-
The Software Package Descriptor:
<package>.csd
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 informations such as title, license, author,... are not
used by the deployment tool, but should be filled in order to
share components.
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 fileinarchive and entrypoint
contained in code . They refer to the JAR file containing
your business code, and to the public static create_home method of the
implementation.
-
The Property File Descriptor:
<file>.cpf
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
implementation level.
The OpenCCM's deployment tool remains quite limited on properties. First, it
only looks for a propertyfile reference into the Component
Assembly Descriptor , at component level. Second, it only accepts
simple tags describing string values.
Using OpenCCM's Packaging and Assembling Tools
OpenCCM now provides Graphical User Interfaces to help developers writing the meta
information needed by a CCM XML deployment. They are both based on the external
ObjectWeb tool Apollon,
which produces GUIs for the editing of XML files based on any DTD.
These tools can be launched with ccm_packaging and
ccm_assembling
scripts, without any
argument. The initiated GUI is the default Apollon frame allowing the edition of
XML files based on wether the softpkg DTD for the Packaging tool,
or the componentassembly DTD for the Assembling tool. Here is a
snapshot of the Packaging tool editing the philosopher component software
descriptor of the well known Dining Philosophers example.
With a single instance of each GUI Tool, one can open several files at a time, the
tool will simply add the XML arborescent content to a new first level branch of the
browsing tree.
Edition of the descriptor's elements is made possible through the visualisation panel
on the right, where its attributes are displayed and can be modified by hand. To add
sub-elements or remove them, it is still possible to use context menus accessible with
a right click rightly on the tree node, as seen here :
The standard representation for attributes is a simple text field, that can be fed
by hand. For some specific information, the Apollon model used for the building of
the tools changes this setting for customized panels, enhancing usability. For example,
when the descriptor needs to point out an external file, such as licenses, archives,
IDL files, extra descriptors and so on, the Name attribute of the
Fileinarchive element is mapped into a "path line" with a
browse button that opens a dialog to seek for files on the
filesystem:
Such customizations make it possible to have both Packaging and Assembling Tools
being more than XML editors, with adapted graphical widgets (e.g. the connections
of an assembly could be done by pulling lines between visible components).
Future improvements will consist in the providing of more and more customized
widgets specifically designed around CCM Deployment descriptors, that the Apollon
tool will integrate into the framework it generates for the GUIs. To reach a fully
operationnal Packaging/Assembling tool, merging every framework in a single frame
would allow to completely write the meta information for an application.
| |