Appendix A Common Information Model (CIM) Terms and Concepts

CIM Concepts

The following sections describe basic CIM terms and concepts that are essential to understanding how network entities and management functions are described and related within the context of CIM. For more detailed information about the Common Information Model and object-oriented modeling practices, including how to model your own schema, refer to the CIM Tutorial at http://dmtf.org/spec/cim_tutorial provided by the Distributed Management Task Force.

Object-Oriented Modeling

CIM uses the principles of Object-Oriented Modeling, a way to represent an object, entity, concept, or function that has a physical or logical existence. The goal of Object-Oriented Modeling is to set a representation of a physical entity into a framework, or model, to express the qualities and functions of the entity and its relationships with other entities. In the context of CIM, Object-Oriented Modeling is used to model hardware and software elements.

Uniform Modeling Language

Models are expressed in the form of visual representation and language. CIM conventions for rendering the model are based on the diagrammatic concepts of Uniform Modeling Language (UML). UML uses shapes to represent physical entities and lines to represent relationships. For example, in UML, classes are represented as rectangles. Each rectangle contains the name of the class it represents. A line between two rectangles represents a relationship between the two. A line that forks to join two classes to a higher-level class represents an association.

CIM diagrams add color to the diagrams to further express relationships:

• Red lines->Associations

• Blue lines->Inheritance relationships

• Green lines->Aggregation

CIM Terms

The following terms are innate to the CIM Schema.

Schema

The terms model, schema, and framework are synonymous. Each is an abstract representation of an entity that has a physical or logical existence. In CIM, a schema is a named collection of classes used for class naming and administration. Within a schema, classes and their subclasses are represented hierarchically using the following syntax: Schemaname_classname. Each class name in a schema must be unique. Solaris WBEM Services includes a Solaris Schema. It contains all classes specific to the Solaris extension to CIM.

Class and Instance

In WBEM, a class is a collection of objects that represents the most basic unit of management. For example, in Solaris WBEM Services, the three main functional classes include CIMClass, CIMProperty, and CIMInstance.

Abstractly, classes are used to create managed objects. Class characteristics are inherited by the child objects, or instances, that are created from a class. For example, using CIMClass, you can create an instance, CIMClass (Solaris_Computer_System).

This instance of CIMClass answers the question, "What is the computer system?" The value of the instance is Solaris_Computer_System. All instances of the same class type are created from the same class template. In the example, the name of the computer system provides a template to create managed objects of the type Computer_System.

Classes can be static or dynamic. Instances of static classes are stored by the CIM Object Manager and can be retrieved from the CIM Repository when a request is made. Instances of dynamic classes--classes containing data that changes regularly, such as system usage--are created by provider applications as the data changes.

Custom Classes: Extensions to CIM

For extensions to CIM, custom classes can be developed to support managed objects that are specific to their managed environment. The CIM Object Manager API provides new classes to extend CIM for the Solaris operating environment.

Property

A property defines a characteristic of a class, represented hierarchically as Schemaname_classname.propertyname. For example, using the CIMProperty class, you can define a key as a property of a particular CIM class. Values of properties can be passed back from the CIM Object Manager as a string or as a vector for a range of properties. Each property has a unique name and only one domain--the class that owns the property. A property of a given class can be overridden by a property of its subclass.

An example of a property is the CIMProperty, which denotes the properties of a CIMClass.

Method

Like properties, methods belong to the class that owns them. A method is an action the objects of a given class are programmed to complete. For example, the method public String getName() returns the name of an instance as a concatenation of its keys and their values. Collectively, these actions describe the behavior of the class. Methods can belong only to the class that owns them. Within the context of a class, each method must have a unique name. A method of a given class can be overridden by a method of its subclass.

New classes inherit the definition of the method from the superclass, but not the implemented method. The definition of the method, indicated by a qualifier, serves as a placeholder in which a new implemented method can be provided. The CIM Object Manager checks for methods by starting from the lowest-level class and moving up the tree to the root class searching for a qualifier type that indicates a method.

Domain

Properties and methods are declared within a class. The class that owns the property or method is referred to as the domain of the property or method.

Qualifier and Flavor

A CIM qualifier is a modifier used to characterize CIM classes, properties, methods, and parameters. Qualifiers have unique attributes, including Name, Type, and Value, that are inherited by new classes.

Indication

An indication, an object and a type of class, is created as a result of the occurrence of an event. Indications can be arranged in a type hierarchy. Indications may have properties, methods, and triggers. Triggers are system operations, such as a change made to an existing class, or events that result in the creation of new instances of an indication.

Association

An association is a class that represents a relationship between two or more classes. Associations enable the creation of multiple relationship instances for a given class. System components can be related in many different ways, and associations provide a way of representing the relationships of these components.

Because of the way associations are defined, it is possible to establish a relationship between classes without affecting any of the related classes. The addition of an association does not affect the interface of the related classes. Only associations can have references.

Reference and Range

A reference is a type of property that defines the roles of objects involved in an association. The reference specifies the role name of the class in the context of the association. The domain of a reference is an association. The range of a reference is a character string that indicates the reference type.

Override

The override relationship is used to indicate the substitution of a property or method inherited from a subclass for a property or method inherited from the superclass. In CIM, guidelines determine what qualifiers of properties and methods can be overridden. For example, if the qualifier type of a class is flagged as a key, then the key cannot be overridden, because CIM guidelines specify that a key property cannot be overridden.

Core Model Concepts

The following sections provide descriptive information about the Core Model of CIM.

System Aspects of the Core Model

The Core Model provides classes and associations you can use to develop applications in which systems and their functions are represented as managed objects. These classes and associations embody the characteristics unique to all elements that comprise a system: physical and logical elements. Physical characteristics refer to the qualities of occupying space and conforming to the elementary laws of physics. Logical characteristics represent abstractions used to manage and coordinate aspects of the physical environment, such as system state or the capabilities of a system.

In the Core Model, logical elements can include the following.

Table A-1 Core Model Elements

Element Name	Description
Systems	A grouping of other logical elements. Because systems are themselves logical elements, a system can be composed of other systems.
Network Components	Classes that provide a topological view of a network.
Services and Access Points	Provide a mechanism for organizing the structures that provide access to the capabilities of a system.
Devices	An abstraction or emulation of a hardware entity, that may or may not be realized in physical hardware.

The following sections describe the classes and associations provided by the Core Model to emulate the qualities of systems.

System Classes Provided by the Core Model

The following table lists the classes that represent system aspects of the Core schema. The instances of these classes will most often belong to the descendents of the objects contained within the class.

Table A-2 Core Model System Classes

Class Name	Description	Example
Managed System Element	Base class for the system element hierarchy. Any distinguishable component of a system is a candidate for inclusion in this class.	Software components, such as files; and devices, such as disk drives and controllers, and physical components, such as chips and cards.
Logical Element	Base class for all the components of the system that represent abstract system components	Profiles, processes, or system capabilities in the form of logical devices.
System	Logical Element that aggregates a set of ManagedSystemElements. The aggregation operates as a functional whole. Within any particular subclass of System, there is a well-defined list of Managed System Element classes, whose instances must be aggregated.	Local Area Network, Wide Area Network, subnet, intranet
Service	Logical Element that contains the information necessary to represent and manage the functionality provided by a Device and/or SoftwareFeature. A Service is a general-purpose object to configure and manage the implementation of functionality. It is not the functionality itself.	Printer, modem, fax machine

System Associations Provided by the Core Model

Associations are classes that define the relationships shared by other classes. Association classes are flagged with an ASSOCIATION qualifier that denotes the purpose of the class. An association class must have at least two references, the names of the classes that share a particular relationship. Instances of an association always belong to the association class.

Associations can have the following types of relationships:

• One to one

• One to many

• One to zero

• Aggregation, such as a containment relationship between a system and its parts

Associations express the relationship between a system and the managed elements that make up the system. Two broad types of associations are used to define the relationships between classes:

The CIM Schema defines two basic types of associations:

• Component associations, which indicate that one class is part of another

• Dependency associations, which indicate that a class cannot function or exist without another class

These association types are abstract, which means that association classes do not have instances alone. Instances must belong to one of their descendent classes.

Component Associations

Component associations express the relationship between the parts of a system and the system itself. Component associations describe what elements make up a system. Abstract classes that express component associations are used to create concrete associations of this type in descendent classes. The descendent concrete associations answer the question: "What composition relationships does the component, or class, have with other components?"

In its most specialized role, the component association expresses the relationship between a system and its logical and physical parts.

Dependency Associations

Dependency associations establish the relationships between objects that rely on one another. The Core Model provides for the following types of dependencies:

• Functional - the dependent object cannot function without the object on which it depends

• Existence - the dependent object cannot exist without the object on which it depends

The following types of dependencies are included in the Core Model.

Table A-3 Core Model Dependencies

Dependency Association	Description
HostedService	An association between a Service and the System on which the functionality resides. The cardinality of this association is one-to-many. A System may host many Services. Services are weak with respect to their hosting System.   Generally speaking, a Service is hosted on the System where the LogicalDevices or SoftwareFeatures that implement the Service are located. The model does not represent Services hosted across multiple systems. This is modeled as an ApplicationSystem that acts as an aggregation point for Services that are each located on a single host.
HostedAccessPoint	An association between a ServiceAccessPoint (SAP) and the System on which it is provided. The cardinality of this association is one-to-many and is weak with respect to the System. Each System may host many SAPs.   A feature of the model is that the access point of a service can be located on the same or a different host from the system to which the service provides access. This allows the model to depict both distributed systems (an ApplicationSystem with component Service on multiple hosts) and distributed access (a Service with access points hosted on other systems).
ServiceSAPDependency	An association between a Service and a ServiceAccessPoint indicating that the referenced SAP is required for the Service to provide its functionality.
SAPSAPDependency	An association between a SAP and another SAP indicating that the latter is required in order for the former to utilize or connect with its Service.
ServiceAccessBySAP	An association that identifies the access points for a Service. For example, a printer may be accessed by Netware, Apple Macintosh, or Windows ServiceAccessPoints, potentially hosted on different Systems.

Example of an Extension into the Core Model

It is possible to develop many extensions into the Core Model. One possible extension includes the addition of a Managed Element class as an abstraction of the Managed System Element class. Descendents of this Managed Element class--classes that represent objects outside the managed system domain, such as Users or Administrators--may be added to the Core Model.

Common Model Schemas

The Common Model provides a set of base classes for the following technology-specific schemas.

Systems

The Systems Model describes the computer, application, and network systems that comprise the top-level system objects that make up the managed environment.

Devices

The Devices Model is a representation of the discrete logical units on the system that provide the basic capabilities of the system, such as storage, processing, communication, and input/output functions. There is a strong temptation to identify the system devices with the physical components of the system. This approach is incorrect because what is being managed is not the physical components themselves but rather the operating system's representation of the devices.

The representation provided by the operating system does not have a one-to-one correspondence with the physical components of the system. For example, a modem may correspond to a discrete physical component. It may just as well be provided by a multi-function card that supports a LAN adapter as well as a modem, or the modem may be provided by an ordinary process running on the system. It is very important in using or making extensions to the model to understand this distinction between Logical Devices and Physical Components and not to get them confused.

Applications

The CIM Application Management Model is an information model designed to describe a set of details that is commonly required to manage software products and applications. This model can be used for various application structures, ranging from stand-alone desktop applications to a sophisticated, multiplatform, distributed, Internet-based application. Likewise, the model can be used to describe a single software product as well as a group of interdependent applications that form a business system.

A fundamental characteristic of the application model is the idea of the application life cycle. An application may be in one of four states: Deployable, Installable, Executable, and Executing. The interpretation and characteristics of the various objects used to represent applications are largely tied to the mechanisms used to transform applications from one state to another.

Networks

The Networks Model represents the various aspects of the network environment. This includes the topology of the network, the connectivity of the network, and the various protocols and services necessary to drive and provide access to the network.

Physical

The Physical Model provides a representation of the actual physical environment. Most of the managed environment is represented by logical objects, that is, objects that represent informational aspects of the environment rather than actual physical objects. Most of systems management is concerned with manipulating information that represents and controls the state of the system. Any impact on the actual physical environment (such as the movement of a read head on a physical drive, or the starting of a fan) is likely to only happen as an indirect consequence of the manipulation of the logical environment. As such, the physical environment is typically not of direct concern.

Apart from anything else, physical parts of the system are not instrumented. Their current state (and possibly even their very existence) can only be indirectly inferred from other information about the system. In the CIM, the physical model is a representation of this aspect of the environment and it is expected that it will differ dramatically from system to system and over time as technology evolves. It is also expected that the physical environment will always be very difficult to track and instrument, spawning the opportunity for a separate specialty, that of deploying applications, tools, and environments specifically aimed at providing information about the physical aspect of the managed environment.