AdCIM

Distributed Storage Layer

This layer provides transparent repository services for the CIM data interchanged by the rest of the framework. Since the data is in XML form, a native XML database or a XML-to-relational mapping can be used directly, we also developed a XSLT-based module that translates XML-based CIM information to LDIF files for direct insertion on an LDAP directory.The framework can be adapted in a similar way to other repository formats.

LDAP Repository module

An LDAP directory is very useful for storing configuration information, that doesn't need strong transactions or great write throughput. LDAP directories allow transparent physical distribution and redundancy with one logical central secured point of access.

In the first figure an overview of the transformation to LDAP format is seen. XSLT code translates the naming of CIM objects to LDAP-compatible names, and types and properties (like cardinality) to LDAP syntax. For example, LDAP attributes must have an unique Object Identifier (OID), a string of dot-delimited numbers assigned by the IANA, also used in the naming of SNMP objects. Other properties of LDAP attributes are cardinality or type information.

The handling of associations is more complicated. Associations are first order, separate citizens on CIM, but in the LDAP mapping, associations can be of two types with respect to their representation:

• Auxiliary classes can be attached to a preexisting LDAP node to add more information. This information usually is independent of the particular type of node and optional. For example, fax numbers can be attached both to people and to organizations each of these possibly having none or more than one.
• Structural classes are separate, independent nodes. Theoretically, the two end nodes of the association could be left unchanged, but for the sake of performance, auxiliary helpers are attached to both ends to allow O(1) time finding the association from a endpoint

A example of the output for the particular case of inetd services:

dn: orderedCimKeys="DSM_InetdService.
CreationClassName=ccname,Name=ftp,
Protocol=tcp", dc=udc
changetype: add
orderedCimKeys: DSM_InetdService.CreationClassName=
ccname, Name=ftp,Protocol=tcp
objectClass: DSM-InetdServiceInstance
CreationClassNameCIM-Service: ccname
NameCIM-Service: ftp
SocketTypeDSM-InetdService: stream
ProtocolDSM-InetdService: tcp
UserDSM-InetdService: root
CommandDSM-InetdService: /usr/sbin/tcpd

dn: orderedCimKeys="CIM_ComputerSystem.
CreationClassName=CIM_ComputerSystem, 
Name=shalmaneser", dc=udc
changetype: modify
add: objectClass
objectClass: DSM-HostedInetdServiceAuxClass

dn: orderedCimKeys="CIM_ComputerSystem.
CreationClassName=CIM_ComputerSystem, 
Name=shalmaneser", dc=udc
changetype: modify
add: DependentCIM-HostedService
DependentCIM-HostedService: orderedCimKeys="
DSM_InetdService.CreationClassName=ccname,
Name=ftp,Protocol=tcp", dc=udc

dn: orderedCimKeys="DSM_InetdService.
CreationClassName=ccname,
Name=ftp,Protocol=tcp", dc=udc
changetype: modify
add: objectClass
objectClass: DSM-HostedInetdServiceAuxClass

dn: orderedCimKeys="DSM_InetdService.
CreationClassName=ccname,
Name=ftp,Protocol=tcp", dc=udc
changetype: modify
add: StartedDSM-HostedInetdService
StartedDSM-HostedInetdService: TRUE
-
add: StartModeDSM-HostedInetdService
StartModeDSM-HostedInetdService:Automatic

dn: orderedCimKeys="DSM_InetdService.
CreationClassName=ccname,
Name=ftp,Protocol=tcp", dc=udc
changetype: modify
add: AntecedentCIM-HostedService
AntecedentCIM-HostedService:orderedCimKeys="
CIM_ComputerSystem.CreationClassName=
CIM_ComputerSystem,Name=shalmaneser", dc=udc

Each paragraph in the LDIF file represents a new or updated node in the repository as controlled by the changetype field. The node name is declared with the dn field, which represents the LDAP class name. The add field inserts a new attribute in the node. To insert attributes gained thought auxiliary classes, a new value for the objectClass attribute corresponding to the auxiliary class must be inserted.

CIM data can be extracted from the directory using a transformation from DSML, an XML equivalent of LDIF that some LDAP clients support. DSML avoids the hassle of parsing LDIF, and a XSLT template coupled with the original schema can restore the original file. The net effect is that repository independence is achieved.