OpenCCM - Writing the XML meta files

Table of Contents

Warning: The OpenCCM User's Guide is now split into the following documents:

  1. Environment for using OpenCCM
  2. The OpenCCM's Compilation Chain
  3. Generation and implementation rules
  4. The OpenCCM's Execution Chain
  5. Demonstrations
  6. Writing an application with OpenCCM
  7. Writing CCM XML meta files
  8. Using deployment functionnalities
  9. Browsing and managing your application
  10. 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:


    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:


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

Packaging Tool editing a philosopher descriptor

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 :

Sample contextual menu on the SOFTPKG root element

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:

Sample dialog to select a file

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.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster | Last modified at 2005-07-07 02:04 PM