XML .cca files

CCA software integration tools (particularly the majority of them that involve code generation or the compilation of generated code) often require more information than is readily available in either source code or compiled libraries in order to assemble larger applications. The usual solution adopted is to install, along with a component binary library, a meta-data file that contains the extra information in XML format.

What kind of information does "meta-data" include? Well, a lot. The CCA Metadata details are a big topic. At least one xml DTD has been produced and is available from CVS
cvs -d cca-forum.org:/cvs/cca-spec/repositories co cca-xml-spec.

Given all the details, though, there are two persistent questions:

• What can/do we do with it?
• Why does it need to be in a separate file instead of embedded in the binaries?

The answers to these questions are of course related. Some answers are tabulated. CCA has picked a solution that is general. Specific application frameworks (Ccaffeine is an example of a general framework) can make more restrictive assumptions about the installation of their components. With enough assumptions and a limited set of target platforms, one can find ways to get around having a meta-data file. The Ccaffeine framework provides extension hooks (Loader, ComponentFactory CCA ports) for an application framework to implement its own component loading mechanisms. Most other general CCA frameworks do as well.

What can/do we do with it?
Off-line GUI	We can compose applications graphically. Building a component-based parallel application may mean composing an executable from a set of dynamically loaded components that exist on a large machine where (due to queuing system restrictions or whatever) a human cannot interact with hundreds or thousands of nodes just to discover the public interfaces and wire the applications together. Worse, some of the components may not even be instantiable except in the parallel environment. Thus, the CCA component meta-data includes a description of the Ports available and a GUI-based builder can support app. composition based on XML solely without having the component libraries present on the desktop where the GUI runs.
Static-link	We can generate custom main() or custom framing subroutine source-code and compile to an optimized binary. This requires information about source code header and library installation locations. On parallel systems, these locations rarely follow any particular standard.
Why does it need to be in another file?
Portability	Querying binaries to extract particular strings (for example embedding the XML data into a binary library) can be done on any platform but it varies widely.
Cross-compiling	XML in a text file can be read with a wide variety of utilities in any desktop environment. Data extracted from XML can then be used to generate source code even if the libraries and headers referred to in the XML are not present on that desktop (as is often the case with parallel machines). Source code can then be moved to the final runtime environment for compilation.
Late location	Embedding the XML string requires knowing the full final installation location details at compile time. Especially in the case of relocatable binary RPM packages, this is often not possible. Separate XML text files are easily edited automatically at installation time while binaries are not.
Registry	Under MS Windows, the data in an XML file could equally well be stored in the registry. As registry entry, it is less prone to user corruption.
Lack of standards	Unix software environments and software projects are notoriously variable. There is no common, language independent standard for naming or location of component libraries and headers.
Multi-components	Often one binary library will house a collection of component classes. Thus, in a generic framework a component cannot be found by matching its name to names found on the filesystem.