This chapter is from the book
This chapter is from the book
This chapter is from the book
Namespaces and Schemas
Imagine a schema as a collection of classes aimed at instrumenting a particular management environment. The scope of a schema can be as diverse or as specialized as the schema designer sees fit, with the understanding that the objects defined within it are related. The DMTF designed the CIM schema to represent the different manageable aspects of the enterprise. Within it are numerous models that target specific aspects of that environment. The Network model, as it defines a group of classes and associations that represent the enterprise network managed environment, is an example. The Win32 extended schema then adds a further level of specialization to this by focusing on the Windows platform. Because schemas are diverse, they contain a large amount of information that may or may not be relevant to a particular managed environment. For example, a schema could contain classes that define every type of microprocessor architecture available. In a real machine, however, only a fraction of those classes may be relevant (perhaps only the x86). A namespace, then, represents the real managed environment by hosting only these relevant classes.
A namespace is a logical abstraction of classes, associations, and instances that limits the visibility and scope to suit a particular managed environment, such as the Windows OS. By limiting the scope, we can improve response times, reduce the resource overhead for managing the environment, and rationalize the amount of information presented to the end user. A namespace can contain many different classes from many different schemas.
The classes defined within a schema, such as the Win32 extended schema, can be contained in one or many namespaces of the same CIM repository without fear of conflict. The CIM repository can differentiate between these classes by examining the full object path of the class, which can include both the server and the namespace of the CIM repository.
Using Existing Schemas
If you use classes defined by the DMTF, Microsoft, or any other schema designer, then you must be careful to adhere to the guidelines and context for their use. Indeed, by using the schemas defined by a third party, you can provide a set of building blocks from which to derive your own classes. If you do not adhere to these rules, there is the risk that the new classes you define may violate the integrity of the schema, thus invalidating the entire class hierarchy. Put simply: your code won't work. The schema designers normally detail the classes that can have subclasses and/or be instantiated in their documentation. Microsoft provides this information in its WMI SDK and in the MSDN platform SDK documentation. If you are still in doubt, e-mail Microsoft at wmgmts@microsoft.com.
Subclassing and Instantiating Existing Classes in the CIMV2 Namespace
If your product populates the CIMV2 namespace, you must check with the schema designer for the conditions of its use when subclassing existing classes or creating instances of them. As part of the WMI SDK, Microsoft provides a text file that details which classes may be subclassed or instantiated and which may not. It is vital to check these details before you start designing your classes and deriving them from existing schema.