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.