The Common Data Model (CDM) is a consistent, integrated, logical data model that defines the general characteristics of information stored in the IT registry. The model specifies how this data is organized to correspond to real-world entities and defines the relationships between the entities. The CDM represents management information in a way that is easy for consuming management applications to use.
Based on the Unified Modeling Language (UML), the CDM represents management information in terms of entities (called ManagedElements or Configuration Items) and the relationships among those entities. The CDM strives to include information from all of the logical models in use (such as CIM, BPEL, ITIL, SNA, and TMf) and integrates them into a single consistent model. The CDM and associated documents can be viewed at the Tivoli CDM Web site, which is included on the TDI product DVD. To access the Web site, copy and unzip the CDMWebsite.zip file from the TDI DVD. The CDM draws most of its concepts from UML, and the contents of the model can be used in UML development tools, such as IBM Rational Software Architect.
At the most basic level of granularity, the CDM represents atomic data as an attribute, as defined by UML. An attribute has an associated data type, a possible default value, and a specification of whether the attribute is single-valued or multi-valued. Certain data types, and enumerations, limit the actual values that an attribute can contain. All attributes in the CDM are globally defined, which means that an attribute with the same name has the same meaning, regardless of the context in which it is used. This is to foster consistent definition and use of the attribute in various environments and circumstances, such as events.
Following are examples of attributes:
Attributes are grouped within the CDM into entities that correspond to items in the real world, such as computers, users, or business processes. This grouping of attributes is called a class. Classes in the CDM are arranged into a single-inheritance hierarchy that enables attributes to be shared among classes.
In some cases, classes are abstract: abstract classes contain common characteristics of entities, but instances of these classes cannot be created. ModelObject, the root of the class hierarchy, is an example of an abstract class. A vast majority of the classes in the CDM are concrete, which means that instances of them can be created in the IT registry.
Note that the class hierarchy of the CDM is rooted in the class ModelObject, not ConfigurationItem. In addition to CIs, other kinds of data will be stored in the IT registry and modeled using the CDM.
Many situations that commonly occur in the real world lead people to use multiple inheritance, which is supported by UML but not by the CDM. In order to handle these situations, the CDM includes the concept of an interface, which is a consistent collection of attributes (or a consistent source or target of a relationship) that can be "included" in a class definition anywhere in the class hierarchy. This is similar to the way in which Java handles interfaces, except that the CDM includes only data, not methods.
Interfaces themselves can be derived from other interfaces, thus forming another inheritance hierarchy. However, while an interface hierarchy can have multiple roots, the derivation hierarchy cannot mix interfaces and classes. Classes can be derived only from other classes, and interfaces can be derived only from other interfaces.
One of the most important purposes of the IT registry is to store relationships between entities in the real world. The CDM therefore places a lot of focus on the definition of relationships between classes and interfaces, and assigns a specific semantic meaning to the relationship. For example, a relationship called "runsOn" may represent the fact that a piece of software executes in a particular environment.
Relationships in the CDM are related to, but differ from, a similar concept in UML called associations. An association is a semantic link between classes in UML; an example is a realization, where one entity makes a particular interface available. Nothing in UML forces a user to express the meaning of an association; we can simply draw a line between two entities. In the CDM, all associations (other than generalization and realization) are named or typed. The name of the association gives it a corresponding meaning, therefore making the association a relationship. All associations with the same name have the same meaning.
In addition to representing and storing relationships between entities, the IT registry provides a correlation mechanism between entities. For example, two management products might discover a single computer system and call them different names; it is important to represent this as a single entity. In order to foster consistent identification of entities in the IT registry, the CDM formally defines the ways in which each type of entity (each class) is identified. To do so, the model uses naming rules.
Naming rules list the attributes that provide identifying characteristics, the combination of attributes are needed to identify the entity, and the context that makes the identification unique. Following are two examples of naming rules:
Correlation in the IT registry is fostered by a consistent use of these rules and an understanding of which rules identify instances of the same type. When multiple names for the same instance arise, they are called aliases, and the IT registry represents the duplicates as a single instance. Consistent formation of names using the naming rules also allows the IT registry (or applications) to generate useful binary tokens known as globally unique identifiers (GUIDs) for the instances.
To incorporate the CDM ideas of handling management information - its representation, naming and identification, TDI relies on an IT registry. In essence, the IT registry implements these ideas and provides a way to work with the managed data. It consists of two parts:
The most important functionality provided by the IT registry is naming and reconciliation. Let us assume that we have two products that manage the same resource, but identify it differently based on their capabilities. Then the two products cannot effectively work together in collaborative fashion. Each of them will have only a subset of the resource's data, so they will not know it is the same resource at all. To solve this situation, users can rely on the combination of TDI and IT registry. TDI will communicate with each product, take that data and register it the IT registry using its Java API. This way the IT registry will handle the resource naming, representation and storage. Additionally, it will employ the available Naming Rules and check if the two products are "talking" about the same resource. This way, only a single resource will be kept in IT registry and it will contain the information obtained from both products.
Another possible issue in this scenario is that the two products can use different terms to describe the same entity (for example, use both "IBM" and "IBM Corporation" to signify the resource's manufacturer). This is handled by the IT registry through a simple string-mapping functionality. For the key term "IBM" there is a set of acceptable representations (for example, "IBM", "IBM Corporation", "IBM Corp") and if the provided values match any of them the key term is returned. Thus, the original value has been cleansed. The result of using this solution is a clearer, smaller, and more consistent resource representation that can be used by multiple other products.
Besides the naming and reconciliation, TDI relies on IT registry for providing the Common Data Model meta-data. When registering resources, users need to specify their class and attributes. Without knowing the ones supported (or required) by the CDM this would be impossible. Thus, TDI uses the IT registry's meta-data functionality to obtain the needed definitions and significantly ease users in this process.
TDI provides Components that will utilize the described functionalities and permit their use in its integration solutions; see section Components of the suite for details.
The IT registry provides a suitable way for handling resources in a unified manner. However, there is another technique for communication among software components that use the Common Data Model - Discovery Library Adapters. These are runtime components that exploit mechanisms native to Management Software Systems (or OMPs) to extract specific details about resources and resource relationships. Then, they transform this information into files that conform to the IdML schema. The purpose of Discovery Library Adapters, therefore, is to discover and keep current sets of resources and relationships that comprise business applications and support business and infrastructure processes.
The IdML (Identity Markup Language) is the Discovery Library XML schema specification that provides a standard way for storing Management Software Systems (MSS) data and operation sets that define groups of operations for creating, updating, and deleting managed resources. For more details on IdML refer to section Introduction.