This chapter is from the book
This chapter is from the book
This chapter is from the book
Namespaces
The purpose of a namespace is to group a set of classes and instances that relate to a particular managed environment logically. The CIMV2 namespace, for example, groups a set of classes and instances that relate to aspects of the local Windows environment. This philosophy would not support defining a network router (its classes, and so forth) within the CIMV2 namespace. It would be logical instead to define a router in the CIM repository by creating a new namespace and populating it with the relevant router classes. To combine instances from both local and nonlocal elements in the same namespace could lead to confusion, because there is no immediate way to distinguish between the two. Placing them in separate namespaces further clarifies the distinction between the nonlocal router's management environment and the local Windows host. If, however, you were defining the manageable aspects of a local internal modem, then it would be most likely that you would place your classes in the CIMV2 namespace. The CIMV2 namespace derives its name from the DMTF's CIM schema that is the basis of its classes.
Using the CIMV2 Namespace
Table 4.2 lists an array of hardware- and software-managed objects that you might find in the enterprise. The purpose of the table is to illustrate which devices most likely
Table 4.2 Likely Management Object Locations
|
Device |
Location |
Description |
Namespace |
|
Network card |
Local |
Network card residing on host machine. |
CIMV2 |
|
External modem |
Local |
56K modem attached to COM1. |
CIMV2 |
|
Custom designed software application |
Local |
Simple standalone application that runs on Windows 2000, NT4, and 9x. |
CIMV2 |
|
Distributed database application |
Distributed, Machine A, n |
A distributed database with error-recovery and data integrity/fault tolerance built in. |
Requires a separate namespace because the CIMV2 namespace does not accommodate distributed applications. |
|
Fax gateway software application |
Local |
Located on host machine. Runs under Windows. Allows other users on network to send faxes using host machine's fax card. |
CIMV2 |
|
E-mail gateway |
Remote |
Located remotely on network. Transmits all external email onto the PSTN. |
A separate namespace is required as the CIMV2 namespace merely represents the local managed environment. |
|
Network card |
Local |
Located on host machine. Instrumented using the DMTF's DMI management architecture. |
A separate namespace is required as this object does not use or derive from the CIM schema or object definitions.* |
|
Smart Array SCSI controller card* |
Local |
Controls a RAID 5 array of hard disk using the SNMP protocol. |
A separate namespace is required as this object does not use or derive from the CIM schema or object definitions.* |
should appear in the CIMV2 namespace and which should be placed elsewhere. With a technology as complex as WMI, there is always a danger of over-simplifying the issues. For instance, in text we have ignored the fact that a managed object can appear in multiple namespaces in the same CIM repository, but the table shows when it is and is not appropriate to use the CIMV2 namespace. The Location field states where the device is located, either on the local host machine, or on another machine on the network.
The DMTF specifies the following points as valid criteria for defining a namespace:
To define chunks of management information (objects and associations) to limit implementation resource requirements, such as database size
To define views on the model for applications managing only specific objects, such as hubs
To pre-structure groups of objects for optimized query speed
WMI Namespaces and the CIM repository
In a typical WMI installation, you will find a number of namespaces defined in the CIM repository. The exact number of namespaces will depend largely upon the version of your operating system and the applications or hardware on your machine. Figure 4.4 shows an example of the namespaces found on an installation of Windows XP.
)
Figure 4.4 Example of namespaces found in a Windows XP installation
Table 4.3 Windows XP Namespaces
|
Namespace |
Description |
|
Root |
The lowest level in the namespace hierarchy. |
|
CIMV2 |
Defines the manageable aspects of the host system. |
|
CIMV2\Applications |
Defines miscellaneous application-specific data. |
|
Cli |
Defines the default WMIC aliases (Windows XP only). |
|
Default |
Default namespace (a good place to experiment with your own classes!). |
|
Directory |
Groups directory related namespaces. |
|
Directory\LDAP |
Defines management information for the Lightweight Directory Access Protocol. |
|
Microsoft |
Groups Microsoft technologyÐspecific namespaces, for example, the HomeNet subnamespace on Windows XP, which defines the management information for home networking. |
|
MSAPPS10 |
Defines class information for the Microsoft Office suite of applications. |
|
NetFrameworkv1 |
Defines class information for the .NET framework (.NET must be installed on the computer for this to be present). |
|
Perfmonscriptexample |
Monitors performance of script-specific information. |
|
Policy |
Defines policy-specific management information. |
|
RSOP |
Defines resultant set of policy security-related classes for centralized policybased administration (Windows XP/.NET only). |
|
SECURITY |
Defines the WMI system security-related management information. |
|
Subscription |
Defines consumer-related classes for triggering scripts in response to an event and sending an e-mail (Windows XP/.NET only). |
|
WMI |
Defines management information for the WMI for WDM provider. |
|
<namespace>\MS_XXX |
Defines locale-specific information (e.g., MS_409 is the namespace that defines US English locale-specific information). |
Table 4.3 provides a quick roundup of the namespaces found in a Windows XP
Defining and Using Your Own Namespace
By using your own namespace, you effectively rid yourself of a number of the constraints of populating a proprietary namespace, such as seeking permission from the owner of the namespace.
You also create potentially more work for yourself because you must define everything from the root up. As we see in Figure 4.5, the CIMV2 namespace contains a col
)
Figure 4.5 Namespaces and the CIM repository
If you decide to create a new namespace to define the manageable aspects of your environment, you are not obliged to use or to derive from all (or any) of the classes defined in the CIM Schema or Win32 extended schema. Indeed, as the CIM repository currently stands, a number of namespaces populated by legacy schemas such as the SNMP and DMI exist. Schema designers are required to populate their namespaces only with classes and associations that are pertinent to the managed environment under scrutiny. If, however, you decide not to derive from any of the classes in the CIM schema, then you must question whether the object that you are defining belongs to the enterprise modeled within the CIM. Remember that the CIM schema models the most basic manageable aspects of the enterprise from which you can derive. (If you feel that a vital class that will enable you to instrument your product is missing within the CIM schema, then you are encouraged to e-mail the DMTF at cim@dmtf.org with a change request and open a channel of discussion with them. For the Win32 extended schema, e-mail Microsoft at wmgmts@microsoft.com.)