Schema Design

The schema design process begins once required information and capabilities have been identified. The first prerequisite is to define use models. It is important to understand what information and capabilities clients require, and also how they support given tasks. If such information is unavailable, these requirements may come from an external view of what information is correctly exposed via a standard (for example SNMP or DMI), a command line interface (CLI), an application program interface (API), or an internal view of what information and capabilities exist for the managed resources.

A second prerequisite is to determine data sources for the management information and control points from which a provider can implement desired functions. Within this context meaningful schema design can begin.

The schema design process can be viewed as a process consisting of seven (7) steps:

For further reference, DMTF also has a simple set of steps for schema design defined in the CIM tutorial at http://www.dmtf.org/education/.

STEP 1: Define High-Level Client-Use Models

In developing a schema, it is not enough to simply understand what data is available. Of greater importance is understanding how an end user would use the data in a management application. A thorough analysis and understanding of how an end user and associated administrative client application will use the management data will usually result in a simpler, more useful schema.

Strategies for identifying client-use models include:

Consider one or more client use cases or scenarios (potential clients may be GUI-based tools or CLIs).
Identify which information needs to be provided.
Determine which actions must be performed.
Determine logical groupings of the information/actions.

In addition, one may need to consider how the client-use model would be affected if the schema is hosted on several heterogeneous platforms. Early scoping of the model to the target platforms assists in achieving interoperability, a high-level goal of WBEM. Clients would then be able to use common access schemes to obtain the information from all platform types. The information derived from these analyses serves as a basis for creating a draft object model.

STEP 2: Draft Object Model

An analysis of managed objects entails identifying the objects and determining relationships between them. There are several types of objects that should be considered in designing a schema, including:

Managed Elements are the most commonly considered objects. They are used to track the state of some managed entity and perform changes as required. Examples uses of these include devices, systems, and software elements.
Associations are objects which relate two other objects. (Note that CIM associations can also have their own properties.) An example use of associations is to represent the relationship between a device driver and its associated device.
Aggregations are a special type of association, with the notion that an object is made up of an aggregation of some number of other objects. For example, various logical devices can be aggregated to make up a complete computer system.
Services are objects describing services and service access points implemented by managed elements. An example use is a print spooler service associated with a printer.
Settings are a description of settings for managed elements. An example use is representing the kernel parameters associated with an operating system;
Statistics are statistical information relevant to a given managed element. An example use is representing resource utilization of a running process.
Diagnostics are diagnostic invocation, settings, and results. An example use is disk diagnostics.
An Indication is the representation of the occurrence of an event. An example use is disk errors.
Services for Provider Control are schema that allow control by a client of a provider's internal operations.

The process of identifying appropriate objects and their relationships is referred to as Object Oriented Design and Analysis (OOD/OOA). While a full discussion of OOD/OOA is out of the scope of this document and a comprehensive understanding is not required for effective CIM modeling, a general understanding of the concepts of object modeling is helpful. A good overview of the most useful concepts can be found in the DMTF CIM Tutorial, posted at http://www.dmtf.org/education/ , which has a more theoretical approach to Chapter 3 “Schema Design and Implementation”. Still, the most important prerequisite for effective modeling is expertise in the domain being modeled.

Creating a draft model of a specific domain is usually best begun by sketching diagrams using the Unified Modeling Language™ (UML™). UML provides a simple visualization of object classes and their relationships. Thinking of objects as being of the types listed above can be helpful. It is best to identify the managed elements first. These are the primary entities that are to be managed.

Next, determine the associations and aggregations that relate these entities. All associations and aggregations have at least two (2) properties, the references to the classes being associated. These relationships have a cardinality or minimum/maximum count on the number of objects that can relate to another object. Cardinality is represented in UML by placing the ranges next to the classes at the ends of the association or aggregation (for example "1..n" indicates there can be 1 to "n" instances of the object tied by that relationship to another object). If the cardinality is labelled “*” or if no cardinality is explicitly specified, it is assumed to be "0..n".

Note that associations and aggregations inherit. That is, if a superclass has an association to another class x, all subclasses also inherit an association relationship to x. Also, it is possible to create specialized subclasses of the association if required (for example to define additional properties or methods).

Next consider ancillary objects that should be associated with the primary managed elements. These include entities such as services, settings, and statistics. Services and services access points (SAP) are ways of representing services and the availability of those services as supported by managed element. A service class provides methods for enabling and disabling those services. Settings represent managed elements operational parameters. Several settings can be associated with an entity. Statistics represent statistical information or metrics related to a managed element. Each of these ancillary object classes should be associated with a managed element with appropriate cardinalities.

Next, consider what diagnostics and indications may be associated with a managed element. Diagnostics, as modeled using the Common Diagnostics Model (CDM), enable one to represent the diagnostic test itself (including status, characteristics, and methods to start and stop the diagnostic test), settings for the diagnostic, and results of previously run diagnostic tests.

Finally, in some cases it may be useful for a client to be able to communicate with the provider itself (as opposed to the resources for which it acts as a gateway), treating the provider as a resource to be managed. This may be the case if the provider has "side effects": state or resources of its own that affect its operation. Examples of such resources could include configuration information (of the provider itself), logging behavior (stopping, starting), databases, communication facilities, and other features.

When such a need exists, it is not appropriate to model the provider's own resources in the classes it serves. These classes must be reserved for the management of the underlying platform resources. Instead, it is appropriate to define a new class by extending CIM_Service and/or related areas of the CIM model (it is permissible to define a class at the root level of the hierarchy, but this is not generally recommended). This class can define local properties or methods as necessary. The provider being managed should be the provider for this class of object, as well as for the classes representing the resources that it instruments.

STEP 3: Consult DMTF Model

DMTF has developed a general-purpose, implementation-independent schema for use in a large variety of applications, such as general computer systems, network devices, embedded systems, and storage arrays. The CIM schema is divided into several major categories:

Core: base classes from which all other schemas are derived
System: high-level representations of systems, with additional details for computer systems
Application: used to manage the lifecycle of software products, drivers, firmware, and applications
Device: logical representations of configuration and operation on hardware devices
Event: representation of indications and subscriptions
Metrics: classes for units of work and associated metrics
Network: representations of network cloud and associated services
Physical: the descriptions of entities which can be labeled, occupy space, and are subject to physical laws (that is physical vs. logical entities in the Device schema)
Policy: representation of rules and their dependencies
Support: models of service incidents
User: the CIM user and security models

Analysis of a schema for a specific domain can usually be confined to 2 to 4 of the above categories. For example, modeling a managed resource such as a Network Interface Card (NIC) would encompass objects in the physical (the card itself), the device (the logical representation), the network (the protocol stack), and the application (the driver) schemas. The basic task is to identify DMTF CIM classes intended to represent similar information to that of draft classes for the domain. This exercise may result in either dividing the draft classes (identified in Step 1 above) into multiple DMTF-derived classes (extensions to the DMTF model) with appropriate associations, or merging draft classes to correspond to a defined DMTF class. Use of the classes from the DMTF schema facilitates interoperability between clients and providers. Providers can be confident that clients which have implemented using the standard CIM schema will be able to find desired management data in expected places in the schema hierarchy.

During this process of refining the draft schema through examination of the DMTF CIM schema, it may also be interesting to identify properties and methods for some of the classes as a means to better understand the objects being modeled. A high-level look at the DMTF classes can be seen through their Visio or PDF UML diagrams. Further detail is available in the Managed Object Format (MOF) file class, property, and method descriptions. (Note: MOFs are text files describing CIM schema. This is similar to the way MIBs describe SNMP and MIFs describe DMI.)

Note that classes may not only be those specifically defined by the DMTF, but also may be DMTF-derived classes. This class extension is facilitated through the objected oriented concept of inheritance, wherein a class may be specialized to add more specific properties and methods. Thus, if the DMTF schema does not have the richness required for the domain being modeled, a provider can add additional properties and methods through the use of subclassing.

While a provider can (and is encouraged to) instrument a DMTF CIM class, there are several good reasons to subclass. Reasons for extending the DMTF CIM schema include:

Needing to add properties/methods to the subclass.
Needing to override properties/methods to add/change qualifiers.
Allowing clients to easily enumerate (list) a subset of the instances as represented by a particular subclass.
Allowing multiple providers to implement instances of the class. (For example, if a given provider isn't sure that it owns all the instances and another not-yet identified provider may have additional instances.)
Needing to derive a concrete class from an abstract one defined by the DMTF. (For example, needing to derive a concrete type of service from the abstract CIM_Service class).

In some cases, there may appear to be no significant coverage of the modeled domain within the DMTF CIM schema. In this case, one should focus on the aspects of the Core Schema which most closely resemble the domain. Generally it is best to subclass from some DTMF class rather than making up an entirely new schema from scratch.

When searching the DMTF schema for applicable modeling elements, one may discover that the structure of the CIM data does not readily match the domain of interest. This is usually recognized by noting that the designed management data is broadly scattered across many classes, and that for most classes a provider would be able to fill in very few values for properties or instrument very few of the methods. The implication is that clients will have to search many classes and traverse many associations to get the wealth of management data they require, causing potential performance issues through too many interactions between client and provider. Discarding the DMTF schema at this point is probably NOT a good solution for resolving this issue. Instead it calls for schema optimization, as discussed in “STEP 7: Optimize” below.

STEP 4: Identify Properties and Methods

Having selected the objects and relationships to represent managed resources, the next step is to refine the schema by identifying properties and methods. The properties and methods for a given class define the unique characteristics of that class of object. Via inheritance, a subclass also has all the properties and methods of its superclass. The DMTF has already defined an extremely rich set of classes, properties, and methods. Therefore, it is highly advantageous to derive a sub-class from an existing CIM superclass and to use the superclass's already defined properties as this enables a greater degree of interoperability for clients and providers. Clients which need information at the superclass level can obtain the superclass derived information from any subclass (assuming the subclass provider chooses to implement the inherited property or method).

Properties can be added to describe additional attributes of a given class not present at the superclass level. It is important to ensure that a property makes sense for all instances of a class. Otherwise additional subclassing may be required wherein one subclass has the property and others do not. Some other factors for consideration when identifying new properties in a subclass include:

Ensure that a similar property does not exist in any superclass or any closely associated class (this check helps eliminate redundant information or a difference in modeling approach than what a general-purpose management client might expect).
Try to place the property as high in the class hierarchy as possible while maintaining appropriate meaning. Note that changes to the DMTF schema need to be worked through an appropriate DMTF working group as discussed in “MOF File Content Guidelines” below.
Consider if the property would still make sense in a lower subclass derived at some point in the future.
Make sure that qualifiers on the property (those special attributes characterizing a property, see the DMTF web site on qualifiers) are all necessary and sufficient; important qualifiers such as "Description" will ensure that there is a common understanding of the property between clients and providers.
Consider what values a property will hold across various platforms. Providers on various operating systems and platforms could choose different values for properties in instrumenting similar objects. Will this implementation create confusion for client applications? Does there need to be a clearer Description of a property or a whitepaper to clarify a property's usage?
Consider the client need to identify resources shared across multiple servers as being the same (making shared resources both cluster-aware and SAN-aware). If two servers share some resource (for example a disk array, backup device, or SAN element), is it important that a management client managing both platforms be able to identify that the resource being modeled is in fact the same resource? If so, it may be important to ensure that the definition of one or more properties ensures an easy recognition of the common resource (for example a common GUID or a serial number property).

Key Properties

One or more properties for a given class are specified as being key properties via the Key qualifier. Key properties are used to uniquely identify each instance of a given class within a namespace. A CIM class cannot redefine (change, add to, or delete from) key properties defined in a superclass. For the most common case, where a given class is derived from a DMTF class which already has keys defined, key identification is trivial. However, in some rare cases where a high-level, "non-keyed" class is used for inheritance, definition of key properties is necessary. Care must be taken to ensure that the properties are defined in a way that will facilitate that uniqueness and ensure interoperability across multiple platforms (for example IA-32, IPF, PA-RISC, Sparc).

Rules about Key properties when creating a subclass include:

If a superclass already has (or inherits) key properties, no key properties may be added to or deleted from its subclasses.
All concrete classes must have keys. (A concrete class is a class that may have instances.)

In conjunction with the identification of keys for a given class, one must consider possible associations with the class. To effectively implement a reference ("REF") property on an association (or aggregation), the provider for the association must know the values for all key properties for all the instances which will be referenced by that association class.

Methods

Methods specific to classes are sometimes called extrinsic methods to differentiate them from intrinsic methods, such as enumerateInstances or getInstance which are available to all classes. Extrinsic methods identify that a class possesses some capability which a client could request be performed on a particular instance of that class. Class-specific methods have very similar considerations to those of properties. However, they have some additional considerations in determining when to define methods within a class which include:

Implement a method when it is necessary to model an operation on an instance that is not clearly modeled by setting the value of a property, especially if one or more result values must be returned. For example, while setting the operational state of a device or service could be modeled by setting the value of a property (perhaps named State), running a diagnostic or installing a software component which may involve several input and output parameters.
If the method could be implemented using an intrinsic method supported by the CIM ServerCIM Server (for example deleteInstance, createInstance, setProperty), consider documenting that as an appropriate client usage (perhaps in a profile or whitepaper describing schema usage), rather than implementing a redundant extrinsic method.

STEP 5: Finalize Schema Details

This step finalizes the schema by considering it in the larger context of standard schemas, other providers, and client usage. There are several considerations that may be applicable for a given schema:

Validate Schema with Client Use Models

At this point in the process, it is useful to refer back to the client-use models derived in “STEP 1: Define High-Level Client-Use Models” above. A successful schema design will be clear and simple to use for management applications. Aspects of the client-use models and scenarios to consider include:

Ensure that all the information required is available as properties on the expected objects.
Validate that the defined operations provide the capabilities required to support the use cases without unintended side effects.
Verify that management applications will be able to traverse associations and aggregations with reasonable efficiency to obtain the necessary information. Otherwise, it may necessary to optimize the schema, as described in “STEP 7: Optimize” below.
General purpose applications may use portions of the schema at a superclass-level. Validate that appropriate properties, methods, and associations/aggregations are in place for expected functions of these management applications. Consider what information a general-purpose client which only accesses classes defined in the DMTF CIM schema.
Any of the above considerations may surface a performance issue. These should be considered in the “STEP 7: Optimize” step below.

Compatibility with Industry Initiatives

Understanding the efforts of DMTF working groups, industry groups using the CIM schema (for example Storage Networking Industry Association), and the WBEMsource schema consistency community helps ensure that the schema will be accessible by cross-platform and general purpose management applications. The work of on-going initiatives may be helpful in evaluating applicable parts of the schema. Areas of general community interest which are not currently being discussed in a forum may suggest that a new effort should be initiated to gain community consistency and consensus.

Schema Interfaces Between Providers (Associations and Aggregations)

A significant consideration (see also below) in understanding a provider's interaction with other providers is that of how classes instrumented by separate providers are related. In CIM, classes are related via associations and aggregations. When two related classes are supported by two separate providers, the association (or aggregation) linking the classes is an interface point between those providers.

Providers for all association (aggregation) classes must know the values of the key properties for instances on both sides of the association. However, the classes referenced by an association are not necessarily supported by the same provider as the association itself. It is important that all providers supporting instances or references to the instances have a common understanding of the values for the key properties in the instances. In selecting a provider to support the association class, there are several considerations:

The provider must know the values for the keys on both sides of the association.
Is it possible that both providers would not be installed? It may be important that the provider supporting the association have an installation script dependency on the other provider.
Is there some third provider that knows how to associate these classes, perhaps at a higher level in the schema hierarchy? Careful definition of the key properties is essential.

Based on these considerations, determine which provider should own and implement the association.

Future Schema Enhancements/Extensions

If capabilities which may become future enhancements can be identified, it is also helpful to consider how these areas would affect the schema. Backward compatibility of schema is highly desirable. It ensures that existing clients will not be adversely affected by upgrading to a new version of the schema. A simple rule is that CIM schemas can be ensured to be backward compatible by just adding (not deleting or changing) classes, properties, methods, and relationships. Additional details are discussed in “Rules for Updating Schema” below.

Standard CIM practice does not permit removal of classes, properties, or methods for minor version updates; instead deprecation is permitted through the Deprecate qualifier. Thus, while deprecation is possible, it does imply continued provider support of the deprecated schema, enabling clients to continue functioning with deprecated schema, re-implementing to the new schema over time. Hence, providers must support both the deprecated and revised schema elements.

General Schema Use Cases

One may find several situations when doing schema design that require further analysis. While the list below is by no means complete, it is an initial reference list from which to analyze a proposed schema.

Common Properties
When implementing weak associations, some key properties are propagated from their scoping class. It is important to ensure consistency among these properties. Information is also available in the “Key Properties” section. An example of a weak association is the CIM_SystemDevice aggregation of CIM_LogicalDevice to CIM_System. If more than one instance of CIM_System exists, it is particularly important to ensure that the key properties propagated from CIM_System to CIM_LogicalDevice (SystemName and SystemCreationClassName) match between instances to ensure that it is clear which devices are a part of a particular system.
"Unknown" Subclass
There may be situations in which a single provider is unable to appropriately place all instances in specific subclasses. Thus, the appropriate subclass for a particular instance is unknown. An approach in this case to create a special subclass indicating the unique properties that are unknown. (There are probably no additional properties on the subclass from those present in the superclass.) Use of this special "unknown" subclass facilitates discovery of the instance when enumerating instances of the superclass. If at some point, additional information becomes available to the provider to determine the specific subclass, the "unknown" instance can be reclassified and a more appropriate subclass instance created.
An example of this use case would be a provider for instances of devices attached to a USB port. The provider(s) would be able to recognize devices attached to the port for which drivers are currently installed, identifying them as appropriate subclasses of CIM_USBDevice (for example ACME_USBPrinter or ACME_USBMouse). However, very little is known about an attached device which does not have a driver. Such an unknown device could be modeled as a separate "unknown" subclass such as ACME_UnknownUSBDevice. If at some time, the required driver were installed to permit identification of the device, the provider could then delete the instance of ACME_UnknownUSBDevice and create an instance of the appropriate subclass (for example ACME_USBScanner) to represent the additional attributes of the device.

In-Schema Documentation

Each class and property may have a Description qualifier. The Description qualifier, which can be obtained and displayed by client programs, supplies important information about the schema element it is describing. In the case of a property, for example, it can elaborate on the meaning of specific values that the property could have. In the case of a method, it could discuss the intended use of parameters, the meaning of return values, or other information.

STEP 6: Write MOF Files

The next step is creation of Managed Object Format (MOF) files. MOF files are used to specify schema to the CIM Server via the MOF Compiler (really a MOF Loader). This step details the process and other considerations in creating MOF files. Specifics on MOF file syntax are available in the and the CIM Specification. Guidelines for creating MOF files are described in the section below on “Schema Implementation”.

Identify Property Types and Method Signatures

Identify the appropriate type for each property and method within a class. Also be sure that the parameters within the method are typed appropriately. It is better to select a larger data type if size is in doubt (for example uint16 vs. uint32) since property types and method signatures cannot be changed in future schema versions without breaking backward compatibility.

In addition, one should consider if it is necessary to override a property (via the Override qualifier) from a superclass (perhaps to add a Write or more detailed Description qualifier) as discussed below.

Determine Qualifiers

Qualifiers are attached to classes, properties, and methods. Select necessary and sufficient qualifiers for each. Particular qualifiers to consider include:

Association to indicate a class is an association;
Description which should be used for all properties, methods, and classes to describe their purpose;
Version which is required to ensure clarity of which definition is being used for a given class.

A list of all possible qualifiers is available for reference on the DMTF web site.

STEP 7: Optimize

The final step before designing the provider itself is to "desk-test" the draft schema and perform schema optimizations as required. Having the released management client which will use the schema is ideal, but if one is not available, several other options exist:

The wbemexec command is a simple client supplied with HP WBEM Services for HP-UX that can be used to exercise all provider functions (please refer to the wbemexec man page).

Key things to consider include:

Availability of the data to be displayed and methods to be invoked
Ease of accessing the required data (not too many association traversals)
Performance of the client interaction

Considerations (1) and (2) would suggest that a non-inherited property or method may need to be moved/copied from one class to another. Consideration (2) is of particular interest when there are too many interactions between client and provider, and the resultant latency adversely impacts client performance. If it is necessary to make a copy of a property in a second location within the schema to permit simpler access, be sure that the data comes from the same underlying managed resource so the data is kept consistent as viewed by the clients and providers.

Performance considerations in case (3) usually involve situations where a large number of instances are retrieved (and perhaps filtered) to obtain the necessary information.

An example of this case would be an application which wishes to show the total disk space available on a platform. Retrieving all disk instances and adding up the disk space available on each would be fine for a small number of disks, but as the number of disks grows to the hundreds or even thousands, performance of sending large XML messages across the network may become a concern. An alternative would be to use another class to represent the total disk space (such as a subclass of CIM_PhysicalCapacity) which when queried would have the provider (instead of the client) add up the total space before sending a smaller message with the data required to the client application.

A second example would be a client looking for instances of CIM_SoftwareElement which correspond to device drivers. In this case enumerating all instances of CIM_SoftwareElement and then filtering those of interest could be very inefficient. Instead, creating a separate subclass of CIM_SoftwareElement for the device drivers would allow the client to enumerate just those instances of interest.