[This is preliminary documentation and subject to change.]
A namespace is a unit for grouping classes and instances and controlling their scope and visibility. Namespaces are not physical locations; they are more like logical databases containing specific classes and instances. Namespaces are represented by the __Namespace system class or a class that derives from the __Namespace class. The __Namespace class has a single property: Name. It is the Name property that distinguishes a namespace from all other namespaces.
Namespaces can be nested within each other to form an arbitrary hierarchy of classes and instances. The nesting model resembles that used for a hierarchical file system, where each namespace needs to have a unique name within the scope of its immediate parent object.
The namespace hierarchy is represented by individual namespaces delimited by a backward slash:
Namespace1\Namespace2\Namespace3........\LastNamespace
Classes are defined for use within one namespace, but associations can span namespaces. An association can contain references to instances in two different namespaces.
Typically a namespace contains a set of classes and instances that represent managed objects in a particular environment. For example, the classes and instances defined to manage objects in the Microsoft® Win32® environment are created in their own unique namespace. WBEM recommends that a given class name and its associated properties and methods not conflict with a class of the same name in another namespace.
All WBEM installations have three predefined namespaces:
The Root namespace is primarily designed to contain other namespaces. The Security namespace, created under the Root namespace, contains the classes and instances that are used for WBEM's security subsystem.
Another child namespace, the Cimv2 namespace contains the classes and instances that represent the host machine such as:
Most operations occur against the Cimv2 namespace. However, if the WBEM installation is also acting as a proxy for a logical or network device, then the classes and instances associated with the logical or network device need to be located in a different namespace, as shown in the following illustration. Having classes and instances of both the local machine and the network device in a common list is confusing; there is no immediate way to determine which instances belong to the local machine and which are part of the network device. By separating these into separate namespaces, it becomes easier to distinguish between the classes and instances for the local machine and those for the network device.
In the following example, two namespaces are nested beneath the Root namespace: Cimv2 and UnixProxy. The Cimv2 namespace models the local machine, and the UnixProxy namespace holds two other namespaces, UnixA and UnixB. The UnixA and UnixB namespaces each model a complete Unix machine.
Namespaces can be arranged in a hierarchical format, as is shown in the preceeding example, or in a lateral format. Either way, the relationship has nothing to do with inheritance of classes or instances. That is, a child namespace does not automatically receive the classes and instances of its parent namespace.
Because namespaces are represented as instances of the __Namespace class, creating instances of the class is how new namespaces are created and deleting instances of the class is how namespaces are deleted. When a namespace is deleted, it is only marked for deletion. All clients of that namespace can continue to access it for as long as necessary. Events continue to be delivered. A namespace is not physically removed until there are no longer any users needing to access it.