|
DMTF Tutorial
> CIM > Extension
Schema
 |
Extension Schema
|
 |
Overview | CIM Specification | CIM Schema | Extension Schema
Utilizing extensions developers can leverage the basic model
classes and associations to add their own model to address their
own management needs. One of the many goals of CIM is that it is
a much broader and cleaner modeling language for capturing
management characteristics.
Extension Schemas represent technology-specific extensions of the
Common Schema. Extending the CIM or a proprietary schema can mean
several things. It can mean:
- Adding a property to an existing class or subclass of the CIM
or a proprietary schema.
- Adding new classes to the CIM or a proprietary schema.
- Creating your own namespace and schema.
Below is a list of supported schema modifications,
some of which, when used, will result in changes in application
behavior.
- A class can be added to or deleted from a schema.
- A property can be added to or deleted from a class.
- A class can be added as a subtype or supertype of an existing
class.
- A class can become an association as a result of the addition
of an Association qualifier, plus two or more references.
- A qualifier can be added to or deleted from any Named Element.
- The Override qualifier can be added to or removed from a property
or reference.
- A class can alias a property (or reference, if the class is
a descendent of an association), using the Alias qualifier.
Both inherited and immediate properties of the class may be
aliased.
- A method can be added to a class.
- An inherited method can be overridden.
- Methods can be deleted, and the signature of a method can
be changed.
- A trigger may be added to or deleted from a class.
In defining an extension to a schema, the schema designer is expected
to operate within the constraints of the classes defined in the
Core Model. With respect to classification, it is recommended that
any added component of a system be defined as a subclass of an appropriate
Core Model class. It is expected that the schema designer will ask
the following question of each of the Core Model classes: "Is the
class being added a subtype of this class?" Having identified the
Core Model class to be extended, the same question should be asked
with respect to each of the subclasses of the identified class.
This process, which defines the superclasses of the class to be
defined, should be continued until the most detailed class is identified.
Certain modifications to a schema can cause failure in applications
that operated against the schema prior to the modification. These
modifications are:
- Deletion of classes, properties, or methods.
- Movements of a class anywhere other than down a hierarchy.
- Alteration of property type or method signature.
- Altering a reference range to anything other than the original
specification.
Modeling Techniques and Models
Schema design can be a complex process. There are numerous questions
to answer when designing a schema, ranging from:
- From which schema do you need to start?
- Where does your application or device fit in that particular
schema?
- What are the associations and dependencies?
- What future scenarios could come up that relate to your extension?
While there are any number of methods you can use to come up with
answers to these questions, the most important factors to keep in
mind when designing a schema are efficiency and usability.
Purpose of a Schema
Before beginning to extend or design a schema, it is helpful to
be cognizant of the purpose of a schema. A schema comes about because
there is a need to model "things" that exist in the real world. So
that others can understand us when we refer to these real things,
we formalize them into statements in a language of some sort. The
rules and procedures that link the real world to the formal world
are known as operational semantics.
People use operational semantics to interpret the information supplied
by a schema. For example, an operator, seeing that a database audit
file is 70 percent full, switches to a new audit file, backs up
the old one, and removes it. The operator's interpretation
of the information ("audit file is 70 percent full") is what lends
it meaning. Without the interpretation, or to put it another way,
if the schema has no consequence, the schema and the information
it provides is literally meaningless.
A schema is dependent on the existence of operational semantics;
on its own, the schema is not meaningful. It acquires meaning only
if someone is willing and able to interpret it. As a schema designer,
you are dependent on, and must cater to, the level of understanding
of the users and developers that will make use of your schema.
A schema is worthless if no one understands it or is willing to
use it. The operational semantics (i.e., the ability of someone
to interpret the schema) is an integral part, possibly the most
important part, of the schema, and should always be in the forefront
of your mind when designing a schema.
When designing a schema, keep in mind that you are creating a language
with which to communicate the structure of information (both physical
and logical elements) within a managed environment. This structure
will grow over time and will be interpreted by its various consumers.
In the nature of things, you cannot define the absolute meaning
of the structure, but you must strive for a reasonable balance between
level of detail and understandability. You need to provide enough
detail to be useful, but not so much as to make the schema overwhelmingly
complex.
Design Approaches
Schema design, like any human activity, takes place as a sequence
of steps. A phased iteration approach is a commonly favored means
of building up the schema through a series of "passes" over the
same material. One such approach to schema design involves working
through iterations of three design phases.
Remember that schema design is an iterative process. Coming
up with an effective schema requires that you try things that don’t
work and then start again until you come up with something that
does work.
Relational Model
Since many software developers are familiar with relational databases,
it often helps to take the relational data model as a starting point
for schema design. For schema design, it is important that you understand
the relational model in that this model has a strong theoretical
foundation that applies to data modeling in general. For the most
part, if you can’t express something in a relational model, there is
a good chance you can’t express it at all.
General Goals of Relational Design
In creating a schema using the relational model, you generally
strive to:
- Avoid redundancy
- Avoid inconsistencies between values
- Avoid modification anomalies (inconsistencies that occur when
you insert or delete data)
Record Design Issues
Records represent a convention for presenting information that
has been elaborated upon in many different ways. Essentially, a
record is a block of information arranged as a sequence of fields,
each of which has an identifier, a type, and a value. For a given
type of record the sequence of fields is generally the same from
one record to the next.
Records are a convenient way of storing information and representing
information in contexts such as user interfaces and reporting systems.
Records have some severe limitations with respect to the information
they are able to represent. Following are some of these limitations
together with a discussion of their implications for designing records
in a relational model. These implications also apply to schema design
in the CIM and WBEM object-oriented models.
Identifiers and Naming
There are a host of issues in the area of how to identify a record,
not the least of which is that identifiers have at least two quite
different uses. An identifier may be used to identify things to
the system, commonly referred to as a surrogate
or object identifier. A record may also be used to identify
things to the user, commonly referred to as a label.
In the relational model, CIM keys are used for both purposes.
Relationships
Relationships are equally as important to an object-oriented model
as to a relational model. Following are some issues related to relationships
that you should keep in mind when designing schema.
Although there are no specific recommendations as to how to handle
many of the relationship issues in object-oriented modeling, it
is usually possible to come up with a reasonable, workable solution
if you design with these issues in mind.
Object Model
Any object model implies a set of rules that should be observed
in formulating a schema:
-
Distinct entity rule. You should not have more than
one instance of the same class that refers to the same object
in the environment. It is quite acceptable to have instances
of different classes that refer to the same object in
the environment. For example. a network-attached printer may
be represented by a system instance, a network node instance,
and a logical device instance and a physical device instance.
It should not be represented by two logical device instances.
-
Hierarchy rule. The instances of every subclass should
be a subset of the instances of its superclass. The subclass
shouldn’t have any instances that are not members of the superclass.
-
Attribute placement rule. Attributes must be placed
as low in the inheritance hierarchy as possible. This avoids
null values. Attributes must be attached to the class to which they
apply. For example, it is a bad practice to represent Manufacturer
as a property of a software feature if the manufacturer really
is a property of the product of which the feature is a part.
Manufacturer may be represented as a derived property,
but its original definition must be attached to the class to
which it properly applies.
-
Attribute derivation rule. If you have a derived property,
you should state that it is derived and from where in the schema
it is derived. (Currently you may state this derivation in the
description. In future versions of the CIM there will be a "derivation"
qualifier).
-
Referential integrity rule. Referential integrity is
intact when structures do not break when you add and delete
data. In particular, look for associations that represent two
different directions of the same thing. If these kinds of associations
exist, you may have a problem with referential integrity. For
example, consider the context of Manufacturer and Product
classes. Assume that a "supplied-by" relationship relates a
product to a manufacturer and a "supports" relationship is between
manufacturer and product. This can be represented as follows.
Further assume that it must be the case that if a manufacturer
supplies a product it must also support it. And, if a product is
supplied by a manufacturer, the product must also be supported by that
manufacturer and none other. The schema must be reformulated as follows.
That is, the dual relationship, "Supports" and "Supplied-by"
has been replaced by a single relationship, "Supplier." Note that
whereas in the first schema example, a product can be supported
by a manufacturer other than the one that supplied it, this is
impossible in the second schema.
Property Constraints
When extending an object model, you must also work with these Property
Constraints:
- Intrinsic Types
- REQUIRED
- Max/Min
- MaxLen
- Range restrictions—syntax
- Key
These object property constraints are what are available in the
CIM. Not everything you want to model can be expressed in these
terms. You may need to write code or add information in the MOF
descriptions to accommodate your particular needs.
Design Issues with Object Models
There are certain issues that you will encounter when extending
schemas. Many of these issues revolve around what you need to do
to minimize maintenance issues that will invariably arise as
the schema changes or evolves.
-
Be careful with relationships that have attributes.
These kind of relationships have a natural solution in WBEM
in that the CIM directly supports relationships that
have attributes. Be careful with this feature, however, as it
is rare for relationships to have attributes without the relationship
becoming an object in its own right. Always ask, "Does it make
sense for these attribute values to disappear if the object
on either end of the association disappears?"
-
Avoid N-ary relationships. Relationships between more
than 2 objects are rare in CIM. Beware of creating
multi-faceted relationships. It is almost always preferable
to represent the objects as classes and then use associations
between them.
-
Avoid complex entities. A complex entity implies embedded
objects. It is preferable to create objects with associations
around them.
-
Beware of instances that contain instances. If you end
up with instances that contain instances, you will have to deal
with a wide range of modification anomalies.
-
Handle time and state issues on your own. CIM and WBEM
do not currently include any structures designed to handle time,
such as capturing "state," or saving logs or generating historical
records. If your schema extension requires that kind of data
modeling, you will need to come up with creative solutions on
your own.
-
Look out for unknown values and uncertain values, (as
opposed to inapplicable values). There are three basic types
of these values:
The value exists, but you can’t get to it at that point
in time. For example, once data that relates to the boot sequence
is booted, that information is not available if it wasn’t
saved anywhere.
The value is inapplicable. The value of "radius" is not
applicable to a triangle.
The value is invalid. For example, a value that’s not in
the value map in the CIM Object Manager. It is possible for
the CIM Object Manager to return a value that isn’t in the
value map, but that value is invalid and so there’s nothing
you can do with it.
|
|
|
