Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
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.4Figure 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.5Figure 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.)

  • + Share This
  • 🔖 Save To Your Account