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` `\| 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. `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.

<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.
XML DTD	`<!ELEMENT destination (#PCDATA) >`
Parents	`homeplacement` `executableplacement` `processcollocation` `hostcollocation`
Attributes	None.
Children Elements	None.
Examples	`<destination>` `CS:ComponentServer1` `</destination>` or `<destination>` `NODE:MainNode` `</destination>`
OpenCCM Deployment Support
Status	Fully supported: The `destination` element is fully supported, but its description format may changed in the futur with the integration of new deployment functionalities.
Implementation Behavior	The `destination` PCDATA information must follow the following format: `prefix:name`. The `prefix` can be `CS`, `NODE` or `DCI`. `CS` prefix refers a Component Server started manually with the `jcs_start <component_server_name>` command. In that case the `name` element refers to the `component_server_name`. `NODE` prefix refers to a node started manually with the `node_start <node_name>` command. This node provides `ServerActivator` and `ComponentInstantiation` interfaces and must be registered in the CosNaming Service. In that case the `name` element refers to the `node_name`. `DCI` prefix refers to a `DCIManager` started manually with the `dci_start <dci_name>` command. In that case the `name` prefix is used to specify that the `DCIManager` services must be used to retreived a node reference. So the `name` element is the `dci_name` to search with `DCIManager` services. In the case of `NODE` and `CS` prefixes, the reference of this two kind of hosts will be retrieved via the CosNaming Service using the `name` such as a key name. So the host must be registered in the CosNaming Service. The `destination` processing will provided to the `homeplacement` the `ComponentServer` and `ComponentInstallation` interfaces required to deploy the home.

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

Table of Contents