What are hierarchical components, and how can I add hierarchical components to the ACS CDB?
The deployment of Components is very important to understand and maintain complex systems. In a small system with few Components each Component can be given a simple name and they can just be deployed using this name and writing entries in the But with growing complexity of the system, this file becomes very large and it is difficult to see the relations between components. Most systems have a naturally hierarchical logical structure, i.e. it is possible to group Components according to functional groups and sub-groups and to logical and/or physical (for hardware devices) containment rules. The ACS CDB allows deployment of Components according to these rules. See also Chapter 14 of the Configuration Database user manual. TOC
Updated with XInclude directives -- GianlucaChiozzi - 06 Sep 2005 Example CDBWe will describe how this can be done using an example CDB, attached here:
As of ACS 5.0, the module Logical architecture of the exampleIn this example CDB the componenents have been deployed in the following logical hierarchical structure:
This set of components allows us to show various deployment alternatives and to compare them. Here the names in BOLD correspond to actual components, while the other names are simply logical grouping names and do not correspond to actual components. From the logical point of view, the complete name of each component is built taking the hierarchical path using the '/' path separator. For example:
Deployment configuration optionsThe configuration of the deployment of the system is done in the branch
of the configuration database. Components.xmlThe simplest option consists in listing all Components in the For our example we have simply put here two <?xml version="1.0" encoding="utf-8"?> <Components xmlns="urn:schemas-cosylab-com:Components:1.0" xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xi="http://www.w3.org/2003/XInclude"> <_ Name="ALMA_DOOR" Code="acsexmplDoorImpl" Type="IDL:alma/acsexmplBuilding/Door:1.0" Container="Container" /> <_ Name="ALMA_BACK_DOOR" Code="acsexmplDoorImpl" Type="IDL:alma/acsexmplBuilding/Door:1.0" Container="Container" /> </Components> Hierarchical components as directory treeThe first option to build hierarchies consist in putting the layers as:
With this solution the xml file in each directory describes just _one single component, looking like the following Component xml file:_ <?xml version="1.0" encoding="utf-8"?> <Component xmlns="urn:schemas-cosylab-com:Component:1.0" xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="FRONTDOOR" Code="acsexmplDoorImpl" Type="IDL:alma/acsexmplBuilding/Door:1.0" Container="Container" /> On one side this structure makes it very easy to add and remove components. On the other side, it is more difficult to see the the overview of CDB structure from the UNIX command line compared to doing the cut of a single Components.xml file. Hierarchical components as single fileThe second option is to group the entire sub-hierarchy into one single file.
<?xml version="1.0" encoding="utf-8"?> <HierarchicalComponent xmlns="urn:schemas-cosylab-com:HierarchicalComponent:1.0" xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="TOWER_H" Code="acsexmplBuildingImpl" Type="IDL:alma/acsexmplBuilding/Building:1.0" Container="Container" > <_ Name="FRONTDOOR" Code="acsexmplDoorImpl" Type="IDL:alma/acsexmplBuilding/Door:1.0" Container="Container"/> </HierarchicalComponent> This structure gives an advantage when we are dealing with true hierarchical component that must be deployed always together. Deep hierarchy with pure-logical nodesIn many cases it is useful to group Components under logical nodes that do not correspond to actual Components. For example we want to group all Components in the In this case it is just sufficient to create a The Hierarchy with pure-logical nodes and sub-nodes in one fileOne might also want to put multiple sub-nodes inside the same logical node. This is a parallel to the previous case where we have put the definition of both the Let's assume we want to do a similar thing for Since But we can use the <?xml version="1.0" encoding="utf-8"?> <Components xmlns="urn:schemas-cosylab-com:Components:1.0" xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xi="http://www.w3.org/2003/XInclude"> <_ Name="MOUNT" Code="acsexmplMountImpl" Type="IDL:alma/MOUNT_ACS/Mount:1.0" Container="Container"/> <_ Name="POWER_SUPPLY" Code="acsexmplPowerSupplyImpl" Type="IDL:alma/PS/PowerSupply:1.0" Container="Container" /> </Components> In principle, the whole Putting multiple XML files in the same directory using XIncludeIn all these examples we always have just one single xml file per directory in the hierarchy. Since ACS 4.1.0, it is also possible to put multiple xml files in the same directory, each with a number of Components inside, by using the recent XInclude and XPointer XML specification. See CDBProblems#Multiple_Xml_Files_In_Cdb_Direct for a detailed discussion about usage and implementation of XInclude and Xpointer in xercel-2 java, our parser (and the patches we have implemented).
<xi:include href="<relative path>/MyIncludeFile.xml" xpointer="element(/1)" />
Guidelines, conventions and other approved usages of the XInclude facility are not part of this proposal and will have to be adressed with HLA, SE and IT at a later time.
Example
<?xml version="1.0" encoding="utf-8"?> <Components xmlns="urn:schemas-cosylab-com:Components:1.0" xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <_ Name="TestInclude_01" Code="acsexmplPowerSupplyImpl" Type="IDL:alma/PS/PowerSupply:1.0" Container="Container"/> <_ Name="TestInclude_02" Code="acsexmplPowerSupplyImpl" Type="IDL:alma/PS/PowerSupply:1.0" Container="bilboContainer" /> <_ Name="TestInclude_03" Code="acsexmplPowerSupplyImpl" Type="IDL:alma/PS/PowerSupply:1.0" Container="bilboContainer" /> </Components>
<?xml version="1.0" encoding="utf-8"?> <Components xmlns="urn:schemas-cosylab-com:Components:1.0" xmlns:cdb="urn:schemas-cosylab-com:CDB:1.0" xmlns:baci="urn:schemas-cosylab-com:BACI:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xi="http://www.w3.org/2001/XInclude"> <_ Name="ALMA_DOOR" Code="acsexmplDoorImpl" Type="IDL:alma/acsexmplBuilding/Door:1.0" Container="Container" /> <xi:include href="IncludeTest.xml" xpointer="element(/1)" /> <xi:include href="CORRELATOR/IncludeComponents.xml" xpointer="element(/1)" /> </Components> This technique is particularly useful to define Dynamic Components in multiple files per each subsystem. See FAQDynamicComponentsAndCDBStructure for details. Limitations and glitchesWith ACS 4.1.3 there a few problems/glitches using all options described here. In summary:
%ACTION{ closed="" closer="" cost="1d" created="2005-09-06" creator="Main.GianlucaChiozzi" due="2005-09-15" notify="Main.GianlucaChiozzi" package="jmanager" pri="high" proposer="Main.GianlucaChiozzi" state="open" uid="002445" who="Main.MatejSekoranja" }% Important ACS 5.0 Yesterday and today I have been merging all the examples with hierarchical ocmponents in the acsexmpl test CDB. While doing this I have uncovered a problem with the Manager.
LAMP is supposed to be hierarchically nested under ALMA_BACK_DOOR. With this specification, the Manager recognises ONLY ALMA_BACK_DOOR and I do not see any ALMA_BACK_DOOR/LAMP Everything is fine in the CDB, because the cdbBrowser shows what is expected. If I remove the entry for ALMA_BACK_DOOR, then ALMA_BACK_DOOR/LAMP appears and I can activate it without problems. For more details see: ZLegacy/ACS.CDBProblems %ENDACTION% * The
For more details see: ZLegacy/ACS.CDBProblems %ACTION{ cost="1d" created="2005-02-21" creator="Main.GianlucaChiozzi" due="2005-04-30" package="cdb" pri="normal" proposer="Main.GianlucaChiozzi" state="open" uid="001962" who="Main.AlessandroCaproni" }% FAQHierarchicalComponentsAndCDBStructure - Cleanupo the list of problems when they are solved. %ENDACTION% Characteristic Components and CDB for instances configurationCharacteristic Components keep their own instance configuration in the CDB in the Each component has a node there with the same hierarchical structure as the Component name. So the component:
has an entry in the CDB at:
See also ZLegacy/ACS.FAQGeneralCompCDB for details. How to try out the example CDB
-- GianlucaChiozzi - 06 Sep 2005 |
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.
|