Consortium    Solutions    Middleware    Forge    MyObjectWeb 
ObjectWeb Consortium
Print

Advanced - Powered by Google





OpenCCM

Project Links
· Home
· Download
· Documentation
· Mailing Lists
· Wiki
· Partners
· License
· History
· Related projects

Developers' Corner
· How to Contribute
· Workplan
· Resources
· CVS Repository
· Bug Tracking
· ObjectWeb Forge Site
· User Mailing List
· Team Mailing List

About
· Team
· Contacts

Table of Contents

  1. Component Assembly Descriptor (CAD)
  2. Root Element
    1. <componentassembly> Element
  3. Component Files Elements
    1. <componentfiles> Element
    2. <componentfile> Element
  4. Partitioning Elements
    1. <partitioning> Element
    2. <homeplacement> Element
    3. <homeproperties> Element
    4. <processcollocation> Element
    5. <hostcollocation> Element
    6. <executableplacement> Element
    7. <invocation> Element
    8. <destination> Element
    9. <componentinstantiation> Element
    10. <componentproperties> Element
    11. <registercomponent> Element
    12. <componentfileref> Element
    13. <componentimplref> Element
  5. Registration Elements
    1. <registerwithnaming> Element
    2. <registerwithhomefinder> Element
    3. <registerwithtrader> Element
  6. Trader Elements
    1. <traderexport> Element
    2. <traderservicetypename> Element
    3. <traderproperties> Element
    4. <traderproperty> Element
    5. <traderpropertyvalue> Element
    6. <traderquery> Element
    7. <traderpolicy> Element
  7. Connections Elements
    1. <connections> Element
    2. <connectinterface> Element
    3. <usesport> Element
    4. <providesport> Element
    5. <componentsupportedinterface> Element
    6. <componentinstantiationref> Element
    7. <existinginterface> Element
    8. <homeinterface> Element
    9. <homeplacementref> Element
    10. <connectevent> Element
    11. <consumesport> Element
    12. <emitsport> Element
    13. <publishesport> Element
    14. <connecthomes> Element
    15. <proxyhome> Element
    16. <destinationhome> Element
    17. <findby> Element
    18. <namingservice> Element
    19. <stringifiedobjectref> Element
    20. <homefinder> Element
  8. Identifier Elements
    1. <consumesidentifier> Element
    2. <emitsidentifier> Element
    3. <providesidentifier> Element
    4. <publishesidentifier> Element
    5. <usesidentifier> Element
  9. Common Elements
    1. <codebase> Element
    2. <description> Element
    3. <extension> Element
    4. <fileinarchive> Element
    5. <impltype> Element
    6. <link> Element
    7. <usagename> Element

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
DescriptionThe 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
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
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 traderp