Previous section.
Systems Management: Common Information Model (CIM)
Copyright © 1998 The Open Group
Introduction
There are many ways in which the Common Information Model (CIM)
can be used. This introductory Chapter provides a context
in which the details described in subsequent Chapters and
Appendices can be understood.
Overview
Ideally, information used to perform tasks is organized or structured
to allow disparate groups of people to use it. This can be
accomplished by developing a model or representation of the details
required by people working within a particular domain. Such an
approach can be referred to as an information model.
An information
model requires a set of legal statement types or syntax to capture the
representation, and a collection of actual expressions necessary to
manage common aspects of the domain (in this case, complex computer
systems).
Because of the focus on common aspects,
this information model is referred to as
the Common Information Model (CIM).
This document describes an object-oriented metamodel based on the
Unified Modeling Language (UML). This model includes expressions for
common elements that must be clearly presented to management
applications (for example, object classes, properties, methods and
associations). This document does not describe specific CIM
implementations, APIs, or communication protocols.
Further development work on CIM is planned by the Desktop Management
Task Force (DMTF) CIM Technical Development Committee. Up-to-date
information on this work may be found at their Web site, at
http://www.dmtf.org/work/cim.html.
CIM Management Schema
Management schemas are the building blocks for management platforms
and management applications, such as device configuration, performance
management, and change management. CIM is structured in such a way
that the managed environment can be seen as a collection of
interrelated systems, each of which is composed of a number of
discrete elements.
CIM supplies a set of classes with properties and associations that
provide a well-understood conceptual framework within which it is
possible to organize the available information about the managed
environment. It is assumed that CIM will be clearly understood by any
programmer required to write code that will operate against the object
schema, or by any schema designer intending to make new information
available within the managed environment.
CIM itself is structured into three distinct layers:
-
Core model - an information model that captures notions that are
applicable to all areas of management.
-
Common model - an information model that captures notions that are
common to particular management areas, but independent of a particular
technology or implementation. The common areas are systems,
applications, networks and devices. The information model is specific
enough to provide a basis for the development of management
applications. This schema provides a set of base classes for extension
into the area of technology-specific schemas. The Core and Common
models together are referred to in this document as the CIM schema.
-
Extension schemas - represent technology-specific extensions of the
Common model. These schemas are specific to environments, such as
operating systems (for example, UNIX or Microsoft Windows).
Development of CIM schema is being undertaken as a continuing activity
that of necessity has to follow behind the definition of the CIM
language described in this document. The current set of approved
schema will be referenced from the on-line version of this
specification, which can be
found at http://www.opengroup.org/pubs/catalog/c804.htm
At the time of publication it has not been determined
whether the management schema will be made
available in printed form.
Core Model
The Core model is a small set of classes, associations and properties
that provide a basic vocabulary for analyzing and describing managed
systems. The Core model represents a starting point for the analyst in
determining how to extend the common schema. While it is possible
that additional classes will be added to the Core model over time,
major re-interpretations of the Core model classes are not
anticipated.
Common Model
The Common model is a basic set of classes that define various
technology-independent areas. These areas are:
-
Systems
-
Applications
-
Networks
-
Devices
The classes, properties, associations and
methods in the Common model are intended to provide a view of the area
that is detailed enough to use as a basis for program design and, in
some cases, implementation.
Extensions are added below the Common model,
in platform-specific additions that supply concrete classes and
implementations of the Common model classes. As new extensions
become available, the Common model will offer a broader range
of information.
Extension Schema
The Extension schemas are technology-specific extensions to the Common
model. It is expected that the Common model will evolve as a result of
the promotion of objects and properties defined in the Extension
schemas.
CIM Implementations
CIM is a conceptual model that is not bound to a particular
implementation. This allows it to be used
to exchange management information in a variety
of ways. Four of these ways are illustrated in
Four Ways to Use CIM
,
and described below.
It is possible to use these ways in combination within a management
application.
Figure: Four Ways to Use CIM
As a repository, the constructs defined in the model are stored in a
database. These
constructs are not instances of the object, relationship, and so on;
but rather are
definitions for someone to use in establishing objects and
relationships. The metamodel used by CIM is stored in
a repository that becomes a representation of the
metamodel. This is accomplished by mapping the metamodel constructs
into the
physical schema of the targeted repository, and then populating it
with the classes
and properties expressed in the Core schema, Common schema, and
Extension schemas.
For an application Data Base Management System (DBMS),
the CIM is mapped into the physical schema of
a targeted
DBMS (for example, relational). The information stored in the database
consists of actual instances of the constructs. Applications can exchange
information when they
have access to a common DBMS and the mapping occurs in a predictable way.
For application objects, the CIM is used to create a set of
application objects in a
particular language. Applications can exchange information when they
can bind to the application objects.
For exchange parameters, the CIM (expressed in some agreed-to
syntax) is a
neutral form used to exchange management information by way of a
standard set of object APIs.
The exchange can be accomplished via a direct set of API
calls or it can
be accomplished by exchange oriented API which can create the
appropriate object in the local implementation technology.
Conformance
The ability to exchange information between management applications is
fundamental to CIM. The current mechanism for exchanging management
information is the Management Object Format (MOF). At the present
time, no programming interfaces or protocols are defined by this
CIM document, and hence t does not provide an exchange mechanism.
Therefore, a
CIM-capable system must be able to import and export properly formed
MOF constructs. How the import and export operations are performed is
implementation-defined for the CIM-capable system.
Objects instantiated in the MOF must, at a minimum, include all key
properties and all properties marked as required. Required properties
have the
REQUIRED
qualifier present and set to TRUE.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.