OpenCCM - Writing Component Assembly Descriptors

Component Assembly Descriptor (CAD)

The goal of this document is to provide information on the way to use the Component Assembly Descriptor (CAD) to describe CCM applications. Two kinds of information will be provided.

Firstly, formal information extracted from the OMG CCM specification describes all the elements of the CAD XML DTD. These elements are illustrated by various examples.

The second kind of information deals with the OpenCCM deployment behavior and implementation status for each element. The goal of this information is to explain how the OpenCCM deployment process uses component assembly descriptors to build applications. This also brings information on the current implementation status.

Root Element

<componentassembly> Element

componentassembly
Description	The `componentassembly` element is the root element of the Component Assembly Descriptor (CAD).
XML DTD	`<!ELEMENT componentassembly` `(description?` `,componentfiles` `,partitioning` `,connections?` `,extension*)>` `<!ATTLIST componentassembly` `id ID #REQUIRED` `derivedfrom CDATA #IMPLIED>`
Parent	None.
Attributes	`id ID`: `id` is an UUID that uniquely identifies the assembly. `derivedfrom CDATA`: The `derivedfrom` attribute is used to point to an assembly from which this assembly was derived. The `derivedfrom` attribute contains the `id` of the source assembly.
Children Elements	`description` : The `description` child is a text describing the assembly. `componentfiles` : The `componentfiles` child is used to refer all the component files required for this assembly. This element cannot be avoid because it is needed for example to retrieve the archive of components. `partitioning` : The `partitioning` child is used to describe how and where homes and components have to be deploy. This element cannot be avoid a component assembly must define a partition. `connections` : The `connections` child is used to describe all the connections to establish between components. This element can be avoid, an assembly can have none connection. `extension` : The `extension` child is used to describe vendor specific extensions.
Example	`<componentassembly id="ZZZ123">` `<description> Assembly example </description>` `<componentfiles>` `...` `</componentfiles>` `<partitioning>` `...` `</partitioning>` `<connections>` `...` `</connections>` `</componentassembly>`
OpenCCM Deployment Support
Status	Not fully supported: The `derivedfrom` attribute is not supported.
Implementation Behavior	The `componentassembly` processing is split in three steps. In a first time, all the component files required are read. Then in a second time, all the components are instantiated. In the last time, the component connections are established. This scheduling ensures that components are created and can be used to establish connections. Finally, all the components are configure completed following the order in which they appear in the component assembly descriptor. Lets note that the `id` attribute is used to register the assembly object in the CosNaming Service.

Component Files Elements

<componentfiles> Element

componentfiles
Description	The `componentfiles` element is used to list all of the component files that are used in the assembly. At least one component file must be specified. Each component file is uniquely identified for reference elsewhere in the descriptor. Multiple component instances may refer to a single component file.
XML DTD	`<!ELEMENT componentfiles` `(componentfile+) >`
Parent	`componentassembly`
Attributes	None.
Children Elements	`componentfile` : `componentfile` children are used to refer all the component files required by the assembly.
Example	`<componentfiles id="ZZZ123">` `<componentfile id="A">` `....` `</componentfile>` `<componentfile id="B">` `....` `</componentfile>` `</componentfiles>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentfiles` processing just traverses all the `componentfile` elements to require their processing.

<componentfile> Element

componentfile
Description	The `componentfile` element refers to a component software descriptor containing information regarding a component and home implementation. `componentfile` are referenced by `homeplacement` elements.
XML DTD	`<!ELEMENT componentfile` `(fileinarchive` `\|codebase` `\|link` `)>` `<!ATTLIST componentfile` `id ID #REQUIRED` `type CDATA #IMPLIED>`
Parent	`componentfiles`
Attributes	`id ID`: The `id` attribute must uniquely identify the `componentfile` element with in the descriptor. It will be used by `homeplacement` elements to found the component binary required to deploy homes. `type CDATA`: The optional `type` attribute specifies the type of component file in a string format. If unspecified, then the file is assumed to be CORBA component. An example use of the type attribute would be to specify an EJB component file.
Children Elements	`fileinarchive` : The `fileinarchive` element is used to retrieve the file to read in an archive. It must be a relative path in the specified archive. `codebase` : The `codebase` element is used to specify a resource. `link` : The `link` element is used to specify the link to find the component file.
Examples	`<componentfile id="A">` `<fileinarchive name="ca.csd">` `</componentfile>` or `<componentfile id="B">` `<fileinarchive name="cb.csd">` `<link href="ftp://www.xyz.com/cb.car">` `</fileinarchive>` `</componentfile>` or `<componentfile id="C">` `<link href="ftp://www.xyz.com/cc.csd">` `</componentfile>`
OpenCCM Deployment Support
Status	Not fully supported: Children `codebase` and `link` are not supported. The `type` attribute is not tested. Only CORBA components are supported.
Implementation Behavior	The `componentfile` processing just reads the file precised in the `fileinarchive` element. The XML tree resulting is stored in a internal table for later uses.

Partitioning Elements

<partitioning> Element

partitioning
Description	The `partitioning` specifies a deployment pattern of homes and components to generic processes and hosts. The pattern is expressed via collocation constraints. A particular usage of a component is always relative to a component home. Uses of component homes are recognized in the assembly as home placements. A home placement, and component instantiations relative to a home, may be collocated with other home placements and component instantiations in a process. Process and home placements may be collocated within a logical host. A home placement that is not part of a process or a `hostcollocation` may be deployed without constraints.
XML DTD	`<!ELEMENT partitioning` `( homeplacement` `\| executableplacement` `\| processcollocation` `\| hostcollocation` `\| componentplacement` `\| extension` `)* >`
Parent	`componentassembly`
Attributes	None.
Children Elements	`homeplacement` : Used to describe a home deployment and its component instantiations. `executableplacement` : Used to describe an executable placement, more details available in the related section. `processcollocation` : Used to deploy many `homeplacement` into the same process on a target location. `hostcollocation` : Used to specify collocation of homes in a same target location. `componentplacement` : Used to describe component instantiations using an already existing home. `extension` : Used to describe vendor specific extensions.
Example	`<partitioning>` `<homeplacement id="AaHome" >` `...` `</homeplacement>` `<processcollocation cardinality="" >` `...` `</processcollocation>` `<hostcollocation cardinality="" >` `...` `</hostcollocation>` `</partitioning>`
OpenCCM Deployment Support
Status	Not fully supported: `homeplacement` and `processcollocation` children are well-supported. `executableplacement` children are not supported.
Implementation Behavior	The `partitioning` processing traverses all the children elements to require their deployment.

<homeplacement> Element

homeplacement
Description	The `homeplacement` element describes a particular deployment of a component home. The `homeplacement` element may be a direct child of `partitioning` element which states that it has no collocation constraints; or it may be a child element of the `hostcollocation` or `processcollocation` elements that state specific host or process collocation constraints.
XML DTD	`<!ELEMENT homeplacement` `( usagename?` `, componentfileref` `, componentimplref?` `, homeproperties?` `, componentproperties?` `, registerwithhomefinder` `, registerwithnaming` `, registerwithtrader` `, componentinstantiation` `, destination?` `, extension*` `) >` `<!ATTLIST homeplacement` `id ID #REQUIRED` `cardinality CDATA "1" >`
Parents	`partitioning` `processcollocation` `hostcollocation`
Attributes	`id ID`: The required `id` attribute is used to uniquely identify the `homeplacement` in a storage way. This identifier could be used for later `homeinterface` connections. `cardinality CDATA`: The `cardinality` attribute specifies how many instances of this `homeplacement` may be deployed.
Children Elements	`usagename` : Human friendly name used to refer the `homeplacement` element. `componentfileref` : Used to retrieve the component file needed to deploy and instantiate the home. This one will be used to retrieve information such as the component archive path. `componentimplref` : Used to refer the component implementation to instantiate. `homeproperties` : Used to specify properties to set on the home. `componentproperties` : Used to specify default properties for all the `componentinstantiation` children. `registerwithhomefinder` : Used to describe a registration into the ComponentHomeFinder service. A home can be registered multiple times in this service with different names. `registerwithnaming` : Used to describe a registration into the CosNaming service. A home can be registered multiple times in this service with different names. `registerwithtrader` : Used to describe a registration into the CosTrading service. A home can be registered multiple times in this service. `componentinstantiation` : Used to describe a component instantiation. Several component instantiations could be done with the same home. `destination` : Used to define the target location where the home will be deployed. It can be avoided when the `homeplacement` element is part of a `hostcollocation` or `processcollocation` element. `extension` : Used to describe vendor specific extensions.
Example	`<homeplacement id="ServerHome" cardinality="1">` `<componentfileref idref="Server"/>` `<componentimplref idref="ServerImpl"/>` `<registerwithhomefinder name="ServerHome"/>` `<registerwithnaming name="ServerHome"/>` `<componentinstantiation id="Server">` `...` `</componentinstantiation>` `<destination> NODE:MyNode </destination>` `</homeplacement>`
OpenCCM Deployment Support
Status	Not fully supported: The `cardinality` attribute is not used. `componentproperties` and `homeproperties` children elements are not applied to configure homes and components.
Implementation Behavior	The `homeplacement` processing is quite complex. According to the target `destination` location, it is in charge to download the required archive on the target host using the associated `ComponentInstallation` instance. Then it is in charge to retrieve a `ComponentServer` instance, e.g. created via a `ServerActivator` instance, to create a `Container` instance on it, and to install the home on it. It uses the XML descriptor associated to the component file element in order to retrieve the archive path and the home entry point. The registration processing are delegated to `registerwithhomefinder` , `registerwithnaming` and `registerwithtrader` children elements. The component instantiations are delegated to `componentinstantiation` children elements. Remarks: The downloading of archives must be down by another tool in the CCM architecture. So the download code will be removed later.

<homeproperties> Element

homeproperties
Description	The `homeproperties` element specifies a property file for a home. The properties are used to configure the home after its instantiation. The property file may be specified by either a `fileinarchive` or a `codebase` child element.
XML DTD	`<!ELEMENT homeproperties` `( fileinarchive` `\| codebase` `) >`
Parent	`homeplacement`
Attributes	None.
Children Elements	`fileinarchive` : Point to the property descriptor to use. `codebase` : The `codebase` element is used to specify a resource.
Example	`<homeproperties>` `<fileinarchive name="META-INF/homeProperties.cpf" />` `<homeproperties>`
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	The `homeproperties` does not have any implementation. It is simply used to store the information that will be used by the home configuration processing.

<processcollocation> Element

processcollocation
Description	The `processcollocation` element specifies a group of homes and associated component instantiations that are to be deployed to a single process.
XML DTD	`<!ELEMENT processcollocation` `( usagename?` `, impltype?` `, ( homeplacement` `\| extension` `)+>` `, destination?` `) >` `<!ATTLIST processcollocation` `id ID #IMPLIED` `cardinality CDATA "1" >`
Parents	`partitioning` `hostcollocation`
Attributes	`id ID`: The `id` attribute uniquely identifies this process collocation in the component assembly file. `cardinality CDATA`: The `cardinality` attribute specifies how many instances of this process collocation may be deployed.
Children Elements	`usagename` : Identifies by a name the `processcollocation`. `impltype` : If `impltype` is specified, then each of the component instances must have implementations supporting the implementation type, else the implementation type of components depends of the target deployment platform implementation type. `homeplacement` : Used to describe a home and its component instantiations. At least one `homeplacement` must be specified. `extension` : Used to describe vendor specific extensions. `destination` : Used to describe the `destination` host on which the process will run. This child can be avoid if the `processcollocation` is part of a `hostcollocation`.
Example	`<processcollocation cardinality="*">` `<usagename> Example process collocation </usagename>` `<impltype language="JAVA"/><!--optional-->` `<homeplacement id="BbHome">` `. . .` `</homeplacement>` `<homeplacement id="CcHome">` `. . .` `</homeplacement>` `</processcollocation>`
OpenCCM Deployment Support
Status	Not fully supported: All the children parts of the `processcollocation` are executed on the same host but not in a unique process. Children `usagename` and `impltype` are not supported. The `cardinality` and `id` attributes are not used too.
Implementation Behavior	The `processcollocation` processing traverses all the `homeplacement` children and requires their deployment on a specified `destination`.

<hostcollocation> Element

hostcollocation
Description	The `hostcollocation` element specifies a group of homes and associated component instantiations that are to be deployed together to a single host.
XML DTD	`<!ELEMENT hostcollocation` `( usagename?` `, impltype?` `, ( homeplacement` `\| executableplacement` `\| processcollocation` `\| extension` `)+` `, destination?` `) >` `<!ATTLIST hostcollocation` `id ID #IMPLIED` `cardinality CDATA "1" >`
Parent	`partitioning`
Attributes	`id ID`: The `id` attribute uniquely identifies this `hostcollocation` in the component assembly file. `cardinality CDATA`: The `cardinality` attribute specifies how many instances of this `hostcollocation` may be deployed possible values are 0 or 1.
Children Elements	`usagename` : Identifies by a name the `hostcollocation`. `impltype` : If `impltype` is specified, then each of the component instances must have implementations supporting the implementation type, else the implementation type of component depends of the target deployment platform implementation type. `homeplacement` : Used to describe a home and its component instantiations. `executableplacement` : Used to describe an executable placement. `processcollocation` : Used to describe a process collocation. `extension` : Used to describe vendor specific extensions. `destination` : Used to describe the `destination` host on which the `homeplacement` , `executableplacement` , and `processcollocation` have to be deployed.
Example	`<hostcollocation cardinality="1">` `<usagename> Example of host collocation </usagename>` `<impltype language="JAVA"/><!--optional-->` `<processcollocation id="ProcessCol1">` `. . .` `</processcollocation>` `<executableplacement id="ExecutablePlac1">` `. . .` `</executableplacement>` `<homeplacement id="CcHome">` `. . .` `</homeplacement>` `</hostcollocation>`
OpenCCM Deployment Support
Status	Not fully supported: The `cardinality` attribute is not used to instantiate the `hostcollocation`, i.e. only one instance is build. The child `impltype` is not used to check the implementation type of each children. `executableplacement` and `processcollocation` children are not processed.
Implementation Behavior	The `hostcollocation` processing does not support all the functionalities only `homeplacement` are processed. In that case the `destination` child must be filled to specify the destination host. This `destination` will overlay imbricated `homeplacement` or `processcollocation` `destination`.

<executableplacement> Element

executableplacement
Description	The `executableplacement` element describes the deployment of an executable. The `executableplacement` element may be a direct child of the `partitioning` element, which states that it has no collocation constraints; or it may be a child element of the `hostcollocation` element.
XML DTD	`<!ELEMENT processcollocation` `( usagename?` `, componentfileref` `, componentimplref` `, invocation?` `, destination?` `, extension*` `) >` `<!ATTLIST executableplacement` `id ID #IMPLIED` `cardinality CDATA "1" >`
Parents	`partitioning` `hostcollocation`
Attributes	`id ID`: The `id` attribute uniquely identifies this executable placement in the component assembly file. `cardinality CDATA`: The `cardinality` attribute specifies how many instances of this executable placement may be deployed.
Children Elements	`usagename` : Identifies by a name the `executableplacement`. `componentfileref` : The `componentfileref` element specifies the component file. `componentimplref` : The `componentimplref` element refers to a specific implementation in the `softpkg` descriptor. Let's note that the implementation referred to by `componentimplref` must have a code type of "`Executable`". `invocation` : The `invocation` element specifies any arguments with which the executable should be invoked. `destination` : The `destination` element is used to record where the executable placement is to be deployed. `extension` : Used to describe vendor specific extensions.
Example	`<executableplacement cardinality="1">` `<usagename> Executableplacement1 </usagename>` `<componentfileref idref="META-INF/ComponentExample.csd">` `<componentimplref idref="componentImplem1">` `<invocation>` `. . .` `</invocation>` `<destination>` `. . .` `</destination>` `</executableplacement>`
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	None.

<componentplacement> Element

componentplacement
Description	The `componentplacement` element specifies components instantiations on an already existing home. The way to find the home reference is described by an `existinghome`element. Component instantiations are described with `componentinstantiation` elements. Be careful this tag is an OpenCCM extension of the CCM specification.
XML DTD	`<!ELEMENT componentplacement` `( usagename?` `, existinghome` `, componentproperties?` `, componentinstantiation` `) >`
Parent	`partitioning`
Attributes	None.
Children Elements	`usagename` : Identifies by a name the `componentplacement`. `existinghome` : Describes the way to find the home to use for component instantiations. `componentproperties` : Used to specify default properties for all the `componentinstantiation` children. `componentinstantiation` : Used to describe a component instantiation. Several component instantiations could be done with the same home.
Example	`<componentplacement>` `<usagename> myComponentPlacement </usagename>` `<existinghome>` `...` `</existinghome>` `<componentproperties>` `...` `</componentproperties>` `<componentinstantiation>` `...` `</componentinstantiation>` `...` `<componentinstantiation>` `...` `</componentinstantiation>` `</componentplacement>`
OpenCCM Deployment Support
Status	Not fully supported: The child `<componentproperties>` is not used to configure the components.
Implementation Behavior	The `componentplacement` retrieves the home reference and then instantiate the component.

<existinghome> Element

existinghome
Description	The `existinghome` element specifies the way to find an home reference using an `findby`element. Be careful this tag is an OpenCCM extension of the CCM specification.
XML DTD	`<!ELEMENT existinghome` `( findby` `) >`
Parent	`partitioning`
Attributes	None.
Children Elements	`findby`: The findby element points to an existing home that can be found within a home finder, naming service, or trader, or using a stringified object reference.
Example	`<existinghome>` `<usagename> myComponentPlacement </usagename>` `<findby>` `...` `</findby>` `</existinghome>`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `existing` just invokes the resoltion of its `findby`child and return the result.

<invocation> Element

invocation
Description	The `invocation` element is used to specify invocation arguments for an executable placement.
XML DTD	`<!ELEMENT invocation EMPTY ) >` `<!ATTLIST invocation` `args CDATA #REQUIRED >`
Parent	`executableplacement`
Attributes	`args CDATA`: The `args` attribute is a string containing the arguments to be used in invoking the executable. Let's note that `args` is just the arguments to the executable, it does not include the executable name.
Children Elements	None.
Example	`<invocation args="param1 param2"/>`
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	None.

<destination> Element

destination
Description	The `destination` element is used to record where a `homeplacement` , `executableplacement` , `hostcollocation` , or `processcollocation` is to be (or has been) deployed. This element was extended from the OMG standart specification see status for more details.
XML DTD	`<!ELEMENT destination` `( findby` `\| node` `) >` `<!ATTLIST destination` `type CDATA #IMPLIED >`
Parents	`homeplacement` `executableplacement` `processcollocation` `hostcollocation`
Attributes	`type CDATA`: The `type` attribute is a string precising the destination host type. Two standart identifiers are supported, `componentserver` to precise that the host is a CCM componentserver, and `nodemanager` to precise that the host is a a DCI node.
Children Elements	`findby`: The findby element points to the host home that can be found within a home finder, naming service, or trader, or using a stringified object reference. `node`: The node element describes the node name to use within the DCIInformation service of the current DCIManager.
Examples	`<destination type="componentserver">` `<findby>` `<namingservice name="ComponentServer1"/>` `</findby>` `</destination>` or `<destination type="node">` `<findby>` `<namingservice name="OpenCCM/NodeManagers/MainNode"/>` `</findby>` `</destination>` or `<destination>` `<node name="MainNode"/>` `</destination>`
OpenCCM Deployment Support
Status	Fully supported: The `destination` element is fully supported, the type attribute allows to support new host type just insering new identifier. The deployment machine provides extension features to integrate the deployment support of new host types.
Implementation Behavior	The `type` atribute must be filled to give information to the deployment machine on the host that will be involved in deployment. Two basis types are supported: `type="componentserver"` refers a Component Server started manually with the `jcs_start <component_server_name>` command. In that case the the `findby` element is required to precised the way to found the componentserver. `type="nodemanager"` refers to a node started manually with the `node_start <node_name>` command. This node provides `ServerActivator` and `ComponentInstantiation` interfaces. If `node` element is precised the default DCIInformation service of the current DCIManager is used to found it.using the name attribute of this element,.the type identifier can be ommited because the `type=nodemanager` is implicit. If `findby` element is precised the node will be founded using the service denoted. In that case the `homefinder` service cannot be used to found node. If type is precised when using a node element the default type="nodemanager" is replaced by the given type.

<node> Element

node
Description	The `node` element is used to precised that the node must be found using the current DCIManager DCIInformation service. The attribute `name` must be used as a research key.
XML DTD	`<!ELEMENT node EMPTY >` `<!ATTLIST node` `name CDATA #REQUIRED >`
Parents	`destination`
Attributes	`name CDATA`: The `name` attribute is a string precising the node name that must be founded using the current DCIManager.
Children Elements	None.
Examples	`<node name="MainNode"/>`
OpenCCM Deployment Support
Status	Fully supported:
Implementation Behavior	The node element is just used to store the node name and precised that the node must be found using DCIInformation service of the current DCIManager.

<componentinstantiation> Element

componentinstantiation
Description	The `componentinstantiation` element describes a particular instantiation of a component relative to a `homeplacement` . The `componentinstantiation` is a direct child of the `homeplacement` element.
XML DTD	`<!ELEMENT componentinstantiation` `( usagename?` `, componentproperties?` `, registercomponent` `, extension` `, destination?` `) >` `<!ATTLIST componentinstantiation` `id ID #REQUIRED >`
Parent	`homeplacement`
Attributes	`id ID REQUIRED`: It will be used to identify the component. It will be referred later by the `componentinstantiationref` element of the `connection` element.
Children Elements	`usagename` : Identifies by a name the component instantiation. `componentproperties` : Used to retrieve the XML property file needed to configure the component instance. `registercomponent` : Used to describe component registration. Multiple component registrations can be described. `extension` : Used to describe vendor specific extensions. `destination` : The `destination` element is used to record where the executable placement is to be deployed.
Example	`<componentinstantiation id="Aaa">` `<usagename>` `Example component instantiation` `</usagename>` `<componentproperties>` `. . .` `</componentproperties>` `<registercomponent>` `. . .` `</registercomponent>` `</componentinstantiation>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentinstantiation` processing is in charge to instantiate a component and to configure it with the componentproperties child specified. It builds a XML representation of the file pointed by the `componentproperties` to retrieve the instance configuration. The registration processing is delegated to registerwithnaming and registerwithtrader children. In the current implementation only primitive properties can be set with the `componentproperties` child.

<componentproperties> Element

componentproperties
Description	The `componentproperties` element specifies a property file for a component instance. If the component file has a default property file in the component package, the component file overrides the default. The property file may be specified by either a `fileinarchive` or a `codebase` child element.
XML DTD	`<!ELEMENT componentproperties` `( fileinarchive` `\| codebase` `) >`
Parents	`homeplacement` `componentinstantiation`
Attributes	None.
Children Elements	`fileinarchive` : Point to the configuration file to use. `codebase` : The `codebase` element is used to specify a resource.
Example	`<componentproperties>` `<fileinarchive name="AaaProperties.cpf" />` `</componentproperties>`
OpenCCM Deployment Support
Status	Not fully supported: The `codebase` child is not supported.
Implementation Behavior	The `componentproperties` does not have any implementation. It's simply used to store a pointer to the information that will be used by the `componentinstantiation` configuration processing.

<registercomponent> Element

registercomponent
Description	The `registercomponent` element is used to specify that a component, a provided interface, or a consumer interface should be registered with a CosNaming Service or a trader. If `providesidentifier` or `consumesidentifier` is specified, then that element is registered. If none of the above are specified, then it is implied that the component itself is to be registered.
XML DTD	`<!ELEMENT registercomponent` `( ( providesidentifier` `\| consumesidentifier` `)?` `, ( registerwithnaming` `, \| registerwithtrader` `, )+` `) >`
Parent	`componentinstantiation`
Attributes	None.
Children Elements	`providesidentifier` : Refers to the provided interface to register. `consumesidentifier` : Refers to the consumer interface to register. `registerwithnaming` : Describes a registration to process into the CosNaming Service. Multiple registrations can be done. `registerwithtrader` : Describes a registration to process into the CosTrading Service. Multiple registrations can be done.
Example	`<registercomponent>` `<registerwithnaming name="Sink" />` `<registerwithtrader>` `. . .` `</registerwithtrader>` `</registercomponent>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The registration processing is delegated to `registerwithnaming` and `registerwithtrader` children.

<componentfileref> Element

componentfileref
Description	The `componentfileref` element refers to a particular `componentfile` element of the `componentfiles` element.
XML DTD	`<!ELEMENT componentfileref EMPTY >` `<!ATTLIST componentfileref` `idref CDATA #REQUIRED >`
Parent	`homeplacement`
Attributes	`idref ID`: The `idref` attribute corresponds to a unique `componentfile` `id` attribute.
Children Elements	None.
Example	`<componentfileref idref="A"/>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentfileref` is simply used to retrieve the idref. This identifier will be used to find the binding `componentfile` information. The `componentfileref` does not have any implementation.

<componentimplref> Element

componentimplref
Description	The `componentimplref` element is used to refer to a particular implementation in a component file.
XML DTD	`<!ELEMENT componentimplref EMPTY />` `<!ATTLIST componentimplref` `idref CDATA #REQUIRED />`
Parent	`homeplacement`
Attributes	`idref ID`: The `idref` attribute refers to a unique `implementation` element `id` in the component descriptor.
Children Elements	None.
Example	`<componentimplref idref="an A impl" />`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentimplref` is simply used to store the `idref` reference and does not have any implementation.

Registration Elements

<registerwithnaming> Element

registerwithnaming
Description	The `registerwithnaming` element tells the installer to register CORBA interface such as components, provided facets or home interfaces.
XML DTD	`<!ELEMENT registerwithnaming EMPTY >` `<!ATTLIST registerwithnaming` `name CDATA #REQUIRED>`
Parents	`registercomponent` `homeplacement`
Attributes	`name`: The `name` is used such as a key for registering the interface into the CosNaming Service. The `name` string can contains slash delimiter to describes a NamingContext three representation. In that case the N-1 tokens are used to describe NamingContext path. The N token is the name of the object to associate with the last NamingContext. The name can also contains dot to specify name and kind. Back slash character can also be used as escape chararcter to insert special character such as slash in the name.
Children Elements	None.
Example	`<registerwithnaming name="OpenCCM/example.registration/object\/Name.type" />`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The CosNaming Service interface is retrieved and used to register the interface with the specified name. If the NamingContext path describes in the `name` attribute does not exist it will be created.

<registerwithhomefinder> Element

registerwithhomefinder
Description	The `registerwithhomefinder` element tells the installer to register a component home with the home finder.
XML DTD	`<!ELEMENT registerwithhomefinder EMPTY >` `<!ATTLIST registerwithhomefinder` `name CDATA #REQUIRED>`
Parent	`homeplacement`
Attributes	`name CDATA`: The `name` to use such as key for registering the home.
Children Elements	None.
Example	`<registerwithhomefinder name="homeName" />`
OpenCCM Deployment Support
Status	Not fully supported
Implementation Behavior	The component repid and home repid are not fill during the homefinder registration. Only the name of the home is used for registration.

<registerwithtrader> Element

registerwithtrader
Description	The `registerwithtrader` element tells the installer to register a component instance or home with a trader after it is created.
XML DTD	`<!ELEMENT registerwithtrader ( traderexport ) >` `<!ATTLIST registerwithtrader` `tradername CDATA #IMPLIED >`
Parents	`registercomponent` `homeplacement`
Attributes	`tradername:` The `tradername` is used to specify the trader in which the offer must be registered. The given name is a path composed of link names between traders from the starting trader up to the desired trader. Here we assume that the path has the following form: `link_name1/link_name2/link_nameN`, i.e. name of the trader links separeted by slashes. If no `tradername` were specified, the offer will be registered in the starting trader. If this name denotes an invalid path to a trader, the offer won't be registered.
Children Elements	`traderexport` : Contains all information about the offer to register in the trader.
Example	`<registerwithtrader tradername="link1/link2/link3">` `<traderexport>` `. . .` `</traderexport>` `</registerwithtrader>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The starting trader used during deployment is the one whose the IOR has been set in the command line. If the specified `tradername` doesn't exist or if no starting trader have been specifed, the offer is not registered but the deployment process is not stopped.

Trader Elements

<traderexport> Element

traderexport
Description	The `traderexport` element groups the description of a trading offer. A such offer will be exported in the trading service. An offer is related to a defined trading service type and have to provide a service, i.e. offering a CORBA Object reference compliant with the OMG IDL interface type of the related trading service type. The contained properties values have to be compliant with properties types (respecting property mode and IDL value type) defined in the related trading service type.
XML DTD	`<!ELEMENT traderexport` `( traderservicetypename` `, traderproperties` `) >`
Parent	`registerwithtrader`
Attributes	None.
Children Elements	`traderservicetypename` : The trading service type name on which this offer will be related. This service type has to be registered in the trader service type repository. `traderproperties` : The properties values of this offer.
Example	`<traderexport>` `<traderservicetypename>ComponentService</traderservicetypename>` `<traderproperties>` `...` `</traderproperties>` `</traderexport>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	If the specifed `traderservicetypename` doesn't exist or if a problem happened with the properties values or if no starting trader have been specifed, the offer is not registered but the deployment process is not stopped. Issue: An offer can be exported without any property values if all properties types modes are optional. This requires to modify the XML DTD by adding a `'?'` after the `traderproperties` element.

<traderservicetypename> Element

traderservicetypename
Description	The `traderservicetypename` element is used to describe the name of a trading service type.
XML DTD	`<!ELEMENT traderservicetypename ( #PCDATA ) >`
Parents	`traderexport` `traderquery`
Attributes	None.
Children Elements	None.
Example	`<traderservicetypename>ComponentService</traderservicetypename>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	Service type name validity depends of the used Trader product. As exemple, the OpenORB Trader doesn't support `"::"` in the service type name althought ORBacus and JacORB ones support such names.

<traderproperties> Element

traderproperties
Description	The `traderproperty` element groups the properties values of the trading offer.
XML DTD	`<!ELEMENT traderproperties ( traderproperty+ ) >`
Parent	`traderexport`
Attributes	None.
Children Elements	`traderproperty` : A service type property. This property type have to be already defined in the related trading service type.
Example	`<traderproperties>` `<traderproperty>` `...` `</traderproperty>` `<traderproperty>` `...` `</traderproperty>` `</traderproperties>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `traderproperty` elements are processed as they comes, and, if no problem, appended into a `CosTrading::PropertySeq`. If a problem occurs with the containd properties, the offer is not registered but the deployment process is not stopped.

<traderproperty> Element

traderproperty
Description	The `traderproperty` element is used to give a value to a property defined in a trading service type.
XML DTD	`<!ELEMENT traderproperty (` `( traderpropertyname` `, traderpropertyvalue` `) >`
Parent	`traderproperties`
Attributes	None.
Children Elements	`traderpropertyname` : The name of the property. A property with this name have to be already declared in the related trading service type. This name can only be used once in a `traderproperties` element. `traderpropertyvalue` : The value of the property. This value must be compliant with the OMG IDL type of the property specified in the related trading service type.
Example	`<traderproperty>` `<traderpropertyname>description</traderpropertyname>` `<traderpropertyvalue>This is my description.</traderpropertyvalue>` `</traderproperty>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The name specified in a `traderpropertyname` element is checked over the trading service type repository. A property with this name have to be already declared in the related trading service type. In the same way, the value specified in a `traderpropertyvalue` element must be compliant with the related property value type. This is done by interrogating the trading service type repository.

<traderpropertyvalue> Element

traderpropertyvalue
Description	The `traderpropertyvalue` element is used to define the value of a trading property. This value has to be compliant with the property value type defined in the related trading service type.
XML DTD	`<!ELEMENT traderpropertyvalue ( #PCDATA ) >`
Parent	`traderproperty`
Attributes	None.
Children Elements	None.
Example	`<!-- A numeric value -->` `<traderpropertyvalue>10</traderpropertyvalue>` or `<!-- A sequence of string values -->` `<traderpropertyvalue> ("This is", "a sequence", "of strings") </traderpropertyvalue>` or `<!-- A sequence of char values -->` `<traderpropertyvalue> ('a', ' ', 'c', 'h', 'a', 'r', ' ', 's', 'e', 'q') </traderpropertyvalue>` or `<!-- A sequence of boolean values -->` `<traderpropertyvalue> (false, false, true) </traderpropertyvalue>`
OpenCCM Deployment Support
Status	Partially supported: Only values of types boolean, char, long, unsigned long, short, unsigned short, long long, unsigned long long, float, double, char, wchar, string and wstring and sequences of these types can be used in the `traderpropertyvalue` element.
Implementation Behavior	Issue: The CAD DTD doesn't define any format in order to specify a sequence of values or any other complex type such as struct, union or Object reference. In this implementation we make the assumption that a sequence value starts with a `'('` and ends with a `')'`, each element separated from the others with a `','`. Elements of the sequence are given as this except for strings which are delimited with double quotes and characters which are delimited with simple quotes (see the Example section). The property value type is checked using the service type repository description facilities. If the value type doesn't match with the given value, the property is not constructed and the related offer is not registered.

<traderquery> Element

traderquery
Description	The `traderquery` element is used to query the trading service in order to find a service.
XML DTD	`<!ELEMENT traderquery` `( traderservicetypename` `, traderconstraint` `, traderpreference?` `, traderpolicy` `, traderspecifiedprop` `) >` `<!ELEMENT traderconstraint ( #PCDATA ) >` `<!ELEMENT traderpreference ( #PCDATA ) >` `<!ELEMENT traderspecifiedprop ( #PCDATA ) >`
Parent	`findby`
Attributes	None.
Children Elements	`traderservicetypename` : The name of the service type to query. `traderconstraint` : The constraint is the means by which the importer states those requirements of a service that are not captured in the signature of the interface. These requirements deal with the computational behavior of the desired service, non-functional aspects, and non-computational aspects (such as the organization owning the objects that provide the service). An importer is always guaranteed that any returned offer satisfies the matching constraint at the time of import. For more info on the OMG Constraint Language and on the constraint syntax rules, see The OMG Trading specification. `traderpreference` : The `traderpreference` is used to order those offers that match the `traderconstraint` so that the offers returned by the trader are in the order of greatest interest. Possible values are "first", "random", "min expression", "max expression" and "with expression" where "expression" is defined with in constraint language. If no preference is specified, the default value is "first". For more info on the OMG Constraint Language, see The OMG Trading specification. `traderpolicy` : The policies allows to specify how the search should be performed as opposed to what sort of services should be found in the course of the search. This can be viewed as parameterizing the algorithms within the trader implementation. `traderspecifiedprop`: The `traderspecifiedprop` elements define the set of properties describing returned offers that are to be returned with the object reference.
Example	`<!-- Offers which the description property contains a given string and return with random order -->` `<traderquery>` `<traderservicetypename>ComponentService</traderservicetypename>` `<traderconstraint>'openccm component' ~ description</traderconstraint>` `<traderpreference>random</traderpreference>` `</traderquery>` or `<!-- Offers which the num_prop property is less than ten and the name property is exactly "my service" -->` `<traderquery>` `<traderservicetypename>OtherService</traderservicetypename>` `<traderconstraint>num_prop < 10 and name == 'my service'</traderconstraint>` `</traderquery>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The query is executed in order to return only one matching offer, but the preference order specified in the `traderpreference` element is always applied. In this way only the offer of greatest interest is returned by the trader. If provided service type name, constraint and/or preference are invalid, the query is not performed. If one of the desired property named in a `traderspecifiedprop` element is inexistant, the query should be performed. If this name is illegal or duplicated, the query will not be performed. If one of the policies failed to be constructed, this policy is skipped and the query will be performed anyway. Issue: the `specifiedprops` element does not seem to provide usefull information. Returned offer properties cannot be used in any ways (unless the deployment tool is interactive).

<traderpolicy> Element

traderpolicy
Description	The `traderpolicy` element is a name-value pair. The names available depend on the implementation of the trader. However, some names are standardized where they effect the interpretation of other parameters or where they may impact linking and federation of traders.
XML DTD	`<!ELEMENT traderpolicy` `( traderpolicyname` `, traderpolicyvalue` `) >` `<!ELEMENT traderpolicyname ( #PCDATA ) >` `<!ELEMENT traderpolicyvalue ( #PCDATA ) >`
Parent	`traderquery`
Attributes	None.
Children Elements	`traderpolicyname`: The name of a trader query policy. `traderpolicyvalue`: A value for that policy.
Example	`<!-- Only match the exact service type offers -->` `<traderpolicy>` `<traderpolicyname>exact_type_match</traderpolicyname>` `<traderpolicyvalue>true</traderpolicyvalue>` `</traderpolicy>` or `<!-- Follow links if no local offers matching the query -->` `<traderpolicy>` `<traderpolicyname>link_follow_rule</traderpolicyname>` `<traderpolicyvalue>if_no_local</traderpolicyvalue>` `</traderpolicy>`
OpenCCM Deployment Support
Status	Partially supported.
Implementation Behavior	Only standardized query policies are supported by the deployment process. As remember, these policies are: `search_card` which is an unsigned long value, `match_card` which is an unsigned long value, `return_card` which is an unsigned long value, `hop_count` which is an unsigned long value, `link_follow_rule` which is set as a string value (valid values are "local_only", "if_no_local" and "always"), `starting_trader` which is set as a string value (see the registerwithtrader's tradername attribute format), `request_id` which is set as a string value, `exact_type_match` which is a boolean value, `use_modifiable_properties` which is a boolean value, `use_dynamic_properties` which is a boolean value, `use_proxy_offers` which is a boolean value. If the policy name is unknown or if the policy value supplied is incorrect, the policy is skipped.

Connections Elements

<connections> Element

connections
Description	The `connections` element is used to satisfy component uses and consumes dependencies and to connect home. The `connectinterface` element is used to connect component uses ports to interfaces. The `connectevent` element is used to connect components consumes, port to event producers. The `connecthomes` element is used to connect a proxy home to another home.
XML DTD	`<!ELEMENT connections >` `(connectinterface` `\|connectevent` `\|connecthomes` `\|connectevent` `)*>`
Parent	`componentassembly`
Attribute	None.
Children Elements	`connectinterface`: Used to describe an interface orientedconnection. Multiple `connectinterface` elements can be described. `connectevent`: Used to describe an event oriented connection. Multiple `connectevent` elements can be described. `connecthomes`: Used to connect a proxy home to another home.
Example	`<connections>` `<connectinterface >` `...` `</connectinterface >` `<connectevent >` `....` `</connectevent >` `<connecthomes >` `....` `</connecthomes >` `</connections >`
OpenCCM Deployment Support
Status	Not fully supported : The `connecthomes` child is not supported.
Implementation Behavior	The connections processing does not support `connecthomes`. In a first time all the `connectinterface` connections are traversed and established. In a second time all the `connectevent` connections are traversed and established.

<connectinterface> Element

connectinterface
Description	The `connectinterface` element is used to connect a component's uses port to an interface. The interface may be a provided or supported interface of another component, it may be an existing interface (other than those provided by components in the assembly), or it may be a home interface.
XML DTD	`<!ELEMENT connectinterface` `( usesport` `, ( providesport` `\| componentsupportedinterface` `\| existinginterface` `\| homeinterface` `)` `) >` `<!ATTLIST connectinterface` `id ID #IMPLIED >`
Parent	`connections`
Attributes	`idref ID`: The `id` is a unique identifier within the assembly.
Children Elements	`usesport`: Identifies the component and port where the connection is to be made. `providesport`: Identifies the component and provides port. `componentsupportedinterface`: Identifies a component that has a supported interface that satisfies the `usesport` element. `existinginterface`: Identifies a way to find an existing interface that will satisfy the `usesport` element. `homeinterface`: Identifies a home interface that the `usesport` element required.
Example	`<connectinterface id="ci1">` `<usesport >` `...` `</usesport >` `<providesport >` `....` `</providesport >` `</connectinterface >` or `<connectinterface id="ci1">` `<usesport >` `...` `</usesport >` `<componentsupportedinterface >` `....` `</componentsupportedinterface >` `</connectinterface >` or `<connectinterface id="ci1">` `<usesport >` `...` `</usesport >` `<existinginterface >` `....` `</existinginterface >` `</connectinterface >` or `<connectinterface id="ci1">` `<usesport >` `...` `</usesport >` `<homeinterface >` `....` `</homeinterface >` `</connectinterface >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	In a first part, the `connectinterface` processing retrieves the reference of the interface to connect. In a second part it retrieves the reference of the uses port and it connects the interface to the port. If registration service have to be used, the resolution is delegated to `findby` children.

<usesport> Element

usesport
Description	The `usesport` element specifies the interface using side of an interface connection relationship. The `usesidentifier` child element identifies the particular uses port. The component with this uses port is identified by a `componentinstantiationref` or a `findby` element.
XML DTD	`<!ELEMENT useport` `( useidentifier` `, ( componentinstantiationref` `\| findby` `)` `) >`
Parent	`connectinterface`
Attributes	None.
Children Elements	`usesidentifier`: The component's port to connect. `componentinstantiationref`: The component with this uses port. `findby`: Describes a way to find the component. In this kind of use of `findby` resolving a reference with home finder is impossible.
Example	`<usesport>` `<usesidentifier >` `abc` `</usesidentifier >` `<componentinstantiationref idref="Aaa"/>` `</usesport >` or `<usesport>` `<usesidentifier >` `abc` `</usesidentifier >` `<findby>` `...` `</findby>` `</usesport >`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `usesport` does not have it own implementation it's used to store information. This information are used by processing of `connectinterface` element.

<providesport> Element

providesport
Description	The `providesport` element specifies the interface providing side of an interface connection relationship. The `providesidentifier` child element identifies the particular provides port.
XML DTD	`<!ELEMENT useport` `( providesidentifier` `, ( componentinstantiationref` `\| findby` `)` `) >`
Parent	`connectinterface`
Attributes	None.
Children Elements	`providesidentifier`: The provides port of the component to connect. `componentinstantiationref`: The component with this provides port. `findby`: Describe a way to find the component. In this kind of use of findby resolving a reference with home finder is impossible.
Example	`<providesport>` `<providesidentifier >` `abc` `</providesidentifier >` `<componentinstantiationref idref="Aaa"/>` `</usesport >` or `<providesport>` `<providesidentifier >` `abc` `</providesidentifier >` `<findby>` `...` `</findby>` `</providesport >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `providesport` does not have it own implementation it's used to store information. This information are used by processing of `connectinterface` element.

<componentsupportedinterface> Element

componentsupportedinterface
Description	Specifies a component with a supports interface that can satisfy an interface connection to a uses port within a `connectinterface` element. The component is identified by a `componentinstantiationref` or a `findby` element.
XML DTD	`<!ELEMENT componentsupportedinterface` `( componentinstantiationref` `\|findby` `) >`
Parent	`connectinterface`
Attributes	None.
Children Elements	`componentinstantiationref`: The component which supports the needed interface. `findby`: Describe a way to find the component. In this kind of use of findby resolving a reference with home finder is impossible.
Example	`<componentsupportedinterface>` `<componentinstantiationref idref="Aaa" />` `</componentsupportedinterface>` or `<componentsupportedinterface>` `<findby >` `...` `</findby >` `</componentsupportedinterface >`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentsupportedinterface` element does not have it own implementation it's used to store information. This information are used by during the processing of the `connectinterface` element.

<componentinstantiationref> Element

componentinstantiationref
Description	The `componentinstantiationref` element refers to a particular `componentinstantiation` element in the assembly descriptor.
XML DTD	`<!ELEMENT componentinstantiationref EMPTY >` `<!ATTLIST componentinstantiationref` `idref CDATA #REQUIRED>`
Parents	`usesport` `providesport` `componentsupportedinterface` `consumesport` `emitsport` `publishesport`
Attributes	`idref ID`: The `idref` attribute corresponds to a unique `componentinstantiation` `id` attribute.
Children Elements	None.
Example	`<componentinstantiationref idref="Aaa"/>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentinstantiationref` element does not have it own implementation it only used as to found the component reference. The id attribute is used as key of search to retrieve the component reference into an internal table.

<existinginterface> Element

existinginterface
Description	Specifies an interface that can satisfy an interface connection to a uses port within a `connectinterface` element, or to an emits or publishes port within a `connectevent` element.
XML DTD	`<!ELEMENT existinginterface` `(findby)>`
Parent	`connections`
Attribute	None.
Children Elements	`findby`: Describe a way to find the component. In this kind of use of `findby` resolving a reference with home finder is impossible.
Example	`<existinginterface>` `<findby >` `...` `</findby >` `</existinginterface >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `existinginterface` element doesn't have it own implementation it's used to store information. This information are used by during the processing of the `connectinterface or connectevent` elements.

<homeinterface> Element

homeinterface
Description	Specifies a home with an interface that can satisfy an interface connection to a uses port within a `connectinterface` element.
XML DTD	`<!ELEMENT homeinterface` `( homeplacementref` `\|findby` `) >`
Parent	`connections`
Attribute	None.
Children Elements	`homeplacementref`: Refers to the home to connect within the assembly `findby`: Describes a way to find the component. In this kind of use of `findby` resolving a reference with home finder is allowed.
Example	`<homeinterface>` `<homeplacementref idref="AaaHome" />` `</homeinterface>` or `<homeinterface>` `<findby >` `...` `</findby >` `</homeinterface >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `homeinterface` element does not have it own implementation it's used to store information. This information are used by during the processing of the `connectinterface` element.

<homeplacementref> Element

homeplacementref
Description	The `homeplacementref` element refers to a particular `homeplacement` element in the assembly descriptor.
XML DTD	`<!ELEMENT componentinstantiationref EMPTY >` `<!ATTLIST componentinstantiationref` `idref CDATA #REQUIRED>`
Parent	`homeinterface`
Attribute	`idref ID`: The `idref` attribute correponds to a unique `homeplacement id` attribute.
Children Elements	None.
Example	`<homeplacementref idref="Aaa"/>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `componentinstantiationref` element doesn't have it own implementation it used to found the home reference. The `id` attribute is used such as a key to retrieve the reference from an internal table.

<connectevent> Element

connectevent
Description	The `connectevent` element is used in the `connections` element to specify a connection from a consumes port, of one component, or an existing interface to an emits or publishes port of another component.
XML DTD	`<!ELEMENT connectevent` `( (consumesport` `\|existinginterface` `)` `, ( emitsport` `\|publishesport` `)` `) >` `<!ATTLIST connectevent` `id ID #IMPLIED >`
Parent	`connections`
Attribute	`id ID:` The `id` is a unique identifier within the assembly.
Children Elements	`consumesport`: Identifies the component and associated consumes port. `existinginterface`: Identifies an exiting interface to subscribe. `emitsports`: Identifies a component associated emits port. `publishesport`: Identifies a component associated publishes port.
Example	`<connectevent id="ce1">` `<consumesport >` `...` `</consumesport >` `<emitsport >` `....` `</emitsport >` `</connectevent >` or `<connectevent id="ce1">` `<consumesport >` `...` `</consumesport >` `<publishesport >` `....` `</publishesport >` `</connectevent >` or `<connectevent id="ce3">` `<existinginterface >` `...` `</existinginterface >` `<emitsport >` `....` `</emitsport >` `</connectevent >` or `<connectevent id="ce4">` `<existinginterface >` `...` `</existinginterface >` `<publishesport >` `....` `</publishesport >` `</connectevent >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	In a first time the consumer reference is resolved. Then in a second time the emitter is resolved. In last time the consumer is subscribed to the emitter. The resolution of each part of the connection is delegated to imbricated `findby` element.

<consumesport> Element

consumesport
Description	The `consumesport` element specifies the event-consuming side of an event connection relationship.
XML DTD	`<!ELEMENT consumesport` `( consumesidentifier` `, ( componentinstantiationref` `\| findby` `)` `) >`
Parent	`connectevent`
Attributes	None.
Children Elements	`consumesidentifier`: Identifies the consumes port to connect on the component. `componentinstantiationref`: Identifies a component within the assembly. `findby`: Describes a way to found the component. In this context, `findby` can not contain a `homefinder` child.
Example	`<consumesport>` `<consumesidentifier >` `abc` `</consumesidentifier >` `<componentinstantiationref idref="Aaa"/>` `</consumesport >` or `<consumesport>` `<consumesidentifier >` `abc` `</consumesidentifier >` `<findby>` `...` `</findby>` `</consumesport >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `consumesport` element does not have its own implementation, it's only use to store information.

<emitsport> Element

emistport
Description	The `consumesport` element specifies the event-emiting side of an event connection relationship.
XML DTD	`<!ELEMENT emitsport` `( emitsidentifier` `, ( componentinstantiationref` `\| findby` `)` `) >`
Parent	`connectevent`
Attributes	None.
Children Elements	`emitsidentifier`: Identifies the emits port to use on the component. `componentinstantiationref`: Identifies a component within the assembly. `findby`: Describes a way to found the component. In this context, `findby` can not contain a `homefinder` child.
Example	`<emitsport>` `<emitsidentifier >` `abc` `</emitsidentifier >` `<componentinstantiationref idref="Aaa"/>` `</emitsport >` or `<emitsport>` `<emitsidentifier >` `abc` `</emitsidentifier >` `<findby>` `...` `</findby>` `</emitsport >`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `emitsport` element does not have its own implementation, it's only use to store information.

<publishesport> Element

publishesport
Description	The `publishesport` element specifies the event-publishes side of an event connection relationship.
XML DTD	`<!ELEMENT publishesport` `( publishesidentifier` `, ( componentinstantiationref` `\| findby` `)` `) >`
Parent	`connectevent`
Attribute	None.
Children Elements	`publishesidentifier`: Identifies the publishes port to use on the component. `componentinstantiationref`: Identifies a component within the assembly. `findby`: Describes a way to found the component.In this context, `findby` can not contain a `homefinder` child.
Example	`<publishesport>` `<publishesidentifier >` `abc` `</publishesidentifier >` `<componentinstantiationref idref="Aaa"/>` `</publishesport >` or `<publishesport>` `<publishesidentifier >` `abc` `</publishesidentifier >` `<findby>` `...` `</findby>` `</publishesport >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `publishesport` element does not have its own implementation, it's only use to store information.

<connecthomes> Element

connecthomes
Description	The `connecthomes` element is used to specify a connection between a proxyhome and another home. The `proxyhome` element refers to the proxy home.
XML DTD	`<!ELEMENT connecthomes` `(proxyhome` `\|destination` `) >` `<!ATTLIST connecthomes` `id ID #IMPLIED >`
Parent	`connections`
Attributes	`id ID:` The `id` is a unique identifier within the assembly.
Children Elements	`proxyhome`: The proxyhome element refers to the proxy home. `destinationhome`: The destinationhome element refers to the home to which the proxy home will be connected. The destination home can be either another proxy home or an actual home.
Example	`<connecthomes id="ch1">` `<proxyhome >` `...` `</proxyhome>` `<destinationhome >` `....` `</destinationhome>` `</connecthomest >`
OpenCCM Deployment Support
Status	Not Supported
Implementation Behavior	None.

<proxyhome> Element

proxyhome
Description	Identifies a proxy home that is to be connected to another home. The home is identified by a `homeplacementref` or a `findby` element.
XML DTD	`<!ELEMENT proxyhome` `( homeplacementref` `\| findby` `) >`
Parent	`connecthomes`
Attribute	None.
Children Elements	`homeplacementref`: The homeplacementref identifies a home within the assembly. `findby`: The findby element points to an existing home that can be found within a home finder, naming service, or trader, or using a stringified object reference.
Example	`<proxyhome id="ch1">` `<findby>` `...` `</findby>` `</proxyhome >` or `<proxyhome id="ch1">` `<homeplacementref idref="homeAAA"/>` `</proxyhome >`
OpenCCM Deployment Support
Status	Not Supported
Implementation Behavior	None.

<destinationhome> Element

destinationhome
Description	Identifies a home to be connected to by a proxy home. The home is identified by a `homeplacementref` or a `findby` element. The homeplacementref identifies a home within the assembly.
XML DTD	`<!ELEMENT destinationhome` `(homeplacementref` `\|findby` `) >`
Parent	`connecthomes`
Attributes	None.
Children Elements	`homeplacementref`: The homeplacementref identifies a home within the assembly. `findby`: The findby element points to an existing home that can be found within a home finder, naming service, or trader, or using a stringified object reference.
Example	`<destinationhome id="ch1">` `<findby>` `...` `</findby>` `</destinationhome >` or `<destinationhome id="ch1">` `<homeplacementref idref="homeAAA"/>` `</destinationhome >`
OpenCCM Deployment Support
Status	Not Supported
Implementation Behavior	None.

<findby> Element

findby
Description	The `findby` element is used to resolve a connection between two components. It tells the installation agent how to locate a party, usually a component, interface, or home involved in the relationship.
XML DTD	`<!ELEMENT findby` `( nameservice` `\| stringifiedobjectref` `\| traderquery` `\| homefinder` `\| extension` `) >`
Parents	`usesport` `providesport` `componentsupportedinterface` `existinginterface` `homeinterface` `consumesport` `emitsport` `publishesport`
Attribute	None.
Children Elements	`namingservice`: Specifies to search with the Name Service the reference bound to the `name` attribute. `stringifiedobjectref`: Gives an object IOR to resolve. `traderquery`: Describes a trader query to execute with the Trader Service. `homefinder`: Specifies to search with the home finder the reference bound to the `name` attribute.
Example	`<findby>` `<namingservice name="AaaPort"/>` `</findby >` or `<findby>` `<homefinder name="AaaHome"/>` `</findby >` or `<findby>` `<traderquery >` `</traderquery >` `</findby >` or `<findby>` `<stringifiedobjectref>` `IOR:000000000000003549444c3a6f7066f626a6563......` `.....` `...` `<stringifiedobjectref>` `</findby >`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `findby` implementation has a quite simple implementation. It simply test if one of its children is not null, then it orders its resolution. The child result will be return by the `findby` implementation. In the case of `stringifiedobjectref` specified the resolution is done by the findby implementation.

<namingservice> Element

namingservice
Description	The `namingservice` element is used to indicate that a component or interface should be found using a Naming Service.
XML DTD	`<!ELEMENT namingservice EMPTY >` `<!ATTLIST namingservice` `name CDATA #REQUIRED>`
Parent	`findby`
Attribute	`name CDATA:` The `name` attribute specifies the name to lookup into the Name Service.
Child Element	None.
Example	`<namingservice name="OpenCCM/example.registration/object\/Name.type"`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `namingservice` element have a quite simple implementation, it retrieves a `NamingContext` interface of the current Naming Service and invokes the `resolve_str` operation giving in parameter the name attribute. This invokation will process the slash delimiter has NamingContext separator. The 0 to N-1 tokens refers to imbricated NamingContext. The N token refers to the name of the CORBA reference to found. So the last token will be used to search the CORBA reference in the last NamingContext. The reference return is the result of the `namingservice` element. The NamingContext reference is retrieved with the TheNameService singleton. The name attribute can also contain kind information and special character using the escape character back slash.

<stringifiedobjectref> Element

stringifiedobjectref
Description	The `stringifiedobjectref` element is used to locate a component by its object reference.
XML DTD	`<!ELEMENT stringifiedobjectref (#PCDATA) >`
Parent	`findby`
Attribute	The stringified object reference is just put between `stringifiedobjectref` tags.
Child Element	None.
Example	`<stringifiedobjectref>` `IOR:000000000000003549444c3a6f7066f626a6563......` `.....` `...` `<stringifiedobjectref>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `stringifiedobjectref` does not have it's own implementation. But the string stored between the tags is used to invoke the string_to_object reference on the used ORB. This operation return the reference associated.

<homefinder> Element

homefinder
Description	The homefinder element is used to indicate a home finder name for a home.
XML DTD	`<!ELEMENT homefinder EMPTY >` `<!ATTLIST homefinder` `name CDATA #REQUIRED>`
Parent	`findby`
Attribute	`name CDATA:` The `name` attribute specifies the name of the home as registered with the home finder.
Child Element	None.
Example	`<homefinder name="homeName"/>`
OpenCCM Deployment Support
Status	Fully suppoted.
Implementation Behavior	Currently the implementation retrieves the `HomeFinder` interface by the Name Service. It invokes the resolve operation with the "HomeFinder" string parameter. The operation result is a facet of the HomeManager component. It'll be used the `find_by_name` operation giving parameter the specified `name`. The operation result is a home interface that will be returned too as result of `homefinder` element processing.

Identifier Elements

<consumesidentifier> Element

consumesidentifier
Description	Child of the consumesport and registercomponent elements, the `consumesidentifier` identifies which consumes port on the component is to participe in the relationship. The type of the consumes event must match the type of the connected emits or publishes event.
XML DTD	`<!ELEMENT consumesidentifier (#PCDATA) >`
Parents	`consumesport` `registercomponent`
Attribute	None. The port name is simply precised between `consumesidentifier` tags.
Children Elements	None.
Example	`<consumeidentifier>` `abc` `</consumeidentifier>`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `consumesidentifier` is simply used to memorize a selected consumer on a component. It does not have any implementation.

<emitsidentifier> Element

emitsidentifier
Description	Child of element `emitsport` , `emitsidentifier` identifies an emits port on the component. The identifier corresponds to an emits identifier specified in IDL.
XML DTD	`<!ELEMENT emitsidentifier (#PCDATA) >`
Parent	`emitsport`
Attribute	None. The port name is simply precised between emitsidentifier tags.
Children Elements	None.
Example	`<emitsidentifier>` `abc` `</emitsidentifier>`
OpenCCM Deployment Support
Status	Fully Supported
Implementation Behavior	The `emitsidentifier` is simply used to memorize a selected emitter on a component. It does not have any implementation.

<providesidentifier> Element

providesidentifier
Description	Child of the providesport and registercomponent elements, `providesidentifier` identifies a provides port on a component. The identifier corresponds to a provides identifier specified in a component IDL.
XML DTD	`<!ELEMENT providesidentifier (#PCDATA) >`
Parents	`providesport` `registercomponent`
Attribute	None. The port name is simply precised between `providesidentifier` tags.
Child Element	None.
Example	`<providesidentifier>` `abc` `</providesidentifier>`
OpenCCM Deployment Support
Status	Fully supported.
Implementation Behavior	The `providesidentifier` element is simply used to memorize a selected port on a component. It does not have any implementation.

<publishesidentifier> Element

publishesidentifier
Description	Child of the publishesport, element `publishesidentifier` identifies a publishes port on a component. The identifier corresponds to the identifier specified in IDL for the publishes port.
XML DTD	`<!ELEMENT publishesidentifier (#PCDATA) >`
Parent	`publishesport`
Attribute	None. The port name is simply precised between `publishesidentifier` tags.
Child Element	None.
Example	`<publishesidentifier>` `abc` `</publishesidentifier>`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `publishesidentifier` is simply used to memorize a publishes port on a component. It does not have any implementation.

<usesidentifier> Element

usesidentifier
Description	Child of the usesport element, `usesidentifier` identifies which uses port on the component is to participe in the relationship. The type using interface must match the type of connected provides interface.
XML DTD	`<!ELEMENT usesidentifier (#PCDATA) >`
Parent	`usesport`
Attribute	None. The port name is simply precised between `usesidentifier` tags.
Child Element	None.
Example	`<usesidentifier>` `abc` `</usesidentifier>`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `usesidentifier` is simply used to memorize a selected uses port on a component. It does not have any implementation.

Common Elements

<codebase> Element

codebase
Description	The `codebase` element is used to specify a resource. If the resource isn't available in the local environment, then a link specifies where it may be obtained. `codebase` has an EMPTY content model.
XML DTD	`<!ELEMENT codebase EMPTY>` `<!ATTLIST codebase` `filename CDATA #IMPLIED` `%simple-link-attributes;>`
Parents	`componentfile` `componentproperties` `homeproperties`
Attributes	`filename CDATA` : The relative path where ressource can be found. `%simple-link-attributes`: A link to the ressource out of the current environment.
Child Element	None.
Examples	`<codebase filename="ca.csd"/>` or `<codebase href="ftp://www.xyz.com/car/cc.zip"/>`
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	The `codebase` element does not have particular implementation. It's only used to store ressouce information.

<description> Element

description
Description	The `description` element contains a string description. It is used to describe its parent element. It contains string content.
XML DTD	`<!ELEMENT description(#PCDATA) >`
Parent	`componentassembly`
Attribute	None.
Child Element	None.
Example	`<description>` `This is a simple example of description` `<description>`
OpenCCM Deployment Support
Status	Fully supported
Implementation Behavior	The `description` is simply used to store information.

<extension> Element

extension
Description	The extension element is used to add experimental or vendor specific elements to the softpkg DTD. The content model of the extension element is PCDATA, meaning that it can have character data or markup.
XML DTD	`<!ELEMENT extension PCDATA>` `<!ATTLIST extension` `class CDATA #REQUIRED` `origin CDATA #REQUIRED` `id ID #IMPLIED` `extra CDATA #IMPLIED` `html-form CDATA #IMPLIED >`
Parents	`componentassembly` `componentinstantiation` `connections` `executableplacement` `findby` `homeplacement` `hostcollocation` `partitioning` `processcollocation`
Attributes	`class CDATA` : Used to distinguish this extension element usage. A processing application identifies extension elements that it understands by examining an extension element's class and origin attributes. `origin CDATA` : An origin attribute is required to identify the party responsible for the extension; for example, an ORB vendor. `id CDATA` : An optional ID attribute that must be unique in the file. `extra CDATA` : An extra attribute that may be used however the originator wishes. `html-form` : The `html-form` element is used for formatting. The content will be formatted per the html element type indicated.
Child Element	None.
Example(s)	None.
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	None.

<fileinarchive> Element

fileinarchive
Description	The `fileinarchive` element refers to a file into an archive.
XML DTD	`<!ELEMENT fileinarchive` `(link?)>` `<!ATTLIST fileinarchive` `name CDATA #REQUIRED>`
Parent	`componentfile` .......
Attributes	`name CDATA` : The relative path where the file can be found into the archive.
Child Element	`link`: Used to specify the link to an external archive when then file is not stored into the current archive. The current archive is the archive where is stored the current CAD file processed.
Example(s)	`<fileinarchive name="ca.csd">` or `<fileinarchive name="ca.csd">` `<link href="ftp://www.xyz.com/car/cc.zip">` `<fileinarchive/>`
OpenCCM Deployment Support
Status	Not fully supported : Child link not supported, the deployment process cannot yet read the component file into an archive.
Implementation Behavior	Not Fully supported. The file can not be denoted with the link element.

<impltype> Element

impltype
Description	None.
XML DTD	`<!ELEMENT impltype EMPTY >` `<!ATTLIST impltype;` `language CDATA #REQUIRED;` `version CDATA #IMPLIED >`
Parents	`processcollocation` `hostcollocation`
Attributes	`language CDATA` : The implementation language. `version CDATA` : The implementation version.
Child Element	None.
Example(s)	None.
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	None.

<link> Element

link
Description	The link element is used to specify a generic link. The href attribute indicates the link. The element can have string content.
XML DTD	`<!ELEMENT link PCDATA>` `<!ATTLIST link` `%simple-like-attributes;>`
Parents	`componentfile` `codebase` `fileinarchive`
Attribute	`href CDATA` : Used to specify the reference.
Child Element	None.
Example(s)	`<link href="http://wwww.acmecomponent.com/licence.html"/>`
OpenCCM Deployment Support
Status	Not supported.
Implementation Behavior	None.

<usagename> Element

usagename
Description	A user defined "friendly" name.
XML DTD	`<!ELEMENT usagename PCDATA>`
Parents	`componentinstantiation` `executableplacement` `homeplacement` `hostcollocation` `processcollocation`
Attribute	None.
Child Element	None.
Example(s)	`<usagename>` `MyComponent` `</usagename">`
OpenCCM Deployment Support
Status	Supported.
Implementation Behavior	None.

Table of Contents