CIM Naming addresses these requirements:
The KEY qualifier is the CIM Metamodel mechanism used to identify the properties that uniquely identify an instance of a class (and indirectly an instance of an association). CIM Naming enhances this base capability by:
MOF files can be used to populate a technology that understands the semantics and structure of CIM. When a MOF file is consumed by a particular implementation, there are two operations that are actually being performed, depending on the file's content. First, a compile or definition operation is performed to establish the structure of the model. Second, an import operation is performed to insert instances into the platform or tool.
Once the compile and import are completed, the actual instances are manipulated using the native capabilities of the platform or tool. In other words, in order to manipulate an object (for example, change the value of a property), one must know the type of platform the information was imported into, the APIs or operations used to access the imported information, and the name of the platform instance that was actually imported. For example, the semantics become:
Namespaces can be used to:
Another viable operation is exporting from a particular management
platform - see
For example, information is exchanged when the source system is of
type Mgmt_X and its name is EastCoast. The export produces a MOF file
with the circle and triangle definitions and instances 1, 3, 5 of the
circle class and instances 2, 4 of the triangle class. This MOF file
is then compiled and imported into the management platform of type
Mgmt_ABC with the name AllCoasts. See
The import operation involves storing the information in a local or
native format of Mgmt_ABC so its native operations can be used to
manipulate the instances. The transformation to a native format is
shown in
For each instance placed in the MOF file, the management tool must maintain a mapping from the MOF file keys to the native key mechanism.
A weak association is defined using a qualifier. For example:
The key(s) of the referenced class includes the key(s) of the other participants in the WEAK association. This situation occurs when the referenced class identity depends on the identity of other participants in the association.
In the context of a weak association definition, the Computer System class is a scoping class for the Operating System class, since its keys are propagated to the Operating System class. The Computer System and the Operating System classes are both scoping classes for the Local User class, since the Local User class gets keys from both. Finally, the Computer System is referred to as a Top Level Object (TLO) because it is not weak with respect to any other class. The fact that a particular class is a top-level object is inferred because no references to that class are marked with the WEAK qualifier. In addition, Top Level Objects must have the possibility of an enterprise-wide, unique key. An example may be a computer's IP address in a company's enterprise-wide IP network. The goal of the TLO concept is to achieve uniqueness of keys in the model path portion of the object name. In order to come as close as possible to this goal, TLO must have relevance in an enterprise context.
Objects in the scope of another object can in turn be a scope for other objects; hence, all model object instances are arranged in directed graphs with the Top Level Object's (TLO's) as peer roots. The structure of this graph - in other words, which classes are in the scope of another given class - is defined as part of CIM by means of associations qualified with the WEAK qualifier.
instance of Acme_has
{
anOS = "ComputerSystem.Name=UnixHost,OperatingSystem.Name=acmeunit";
aUser = "ComputerSystem.Name=UnixHost,OperatingSystem.Name=acmeunit,uid=33";
};
A Namespace path resolves to a namespace hosted by a CIM-Capable implementation (in other words, a CIM Object Manager). Unlike the Model Path, the details of the Namespace path are implementation-specific. Therefore, the Namespace path provides two pieces of information: it identifies the type of implementation or namespace type, and it provides a handle that references a particular implementation or namespace handle.
Fundamentally, a namespace type implies an access protocol or API set that can be used to manipulate objects. These APIs would typically support:
A particular management platform may have a variety of ways to access management information. Each of these ways must have a namespace type definition. Given this type, there would be an assumed set of mechanisms for exporting, importing and updating instances.
The details of the handle are implementation-specific. It might be a simple string for an implementation that supports one namespace, or it might be a hierarchical structure if an implementation supports multiple namespaces. Either way, it resolves to a namespace.
It is important to note that some implementations can support multiple namespaces. In this case, the implementation-specific reference must resolve to a particular namespace within that implementation.
There are two important observations to make:
The namespace path can be provided in one of two ways:
The value for the pragma and the qualifier is exactly the same:
When the information is provided as a pragma, it is assumed to be the
same for all instances in the MOF file. This pragma is shown in
#pragma source("Mgmt_X:\EastCoast") class Figs_Circle { [key] uint32 Name; string Color; }; class Figs_Triangle { [key] uint32 Label; string Color; uint32 Area; }; [Association] class Figs_CircleToTriangle { Figs_Circle REF ACicrle; Figs_Triangle REF ATriangle; }; [Association] class Figs_Covers { Figs_Triangle REF Over; Figs_Triangle REF Under; }; | instance of Figs_Triangle {Label=2;Color="Blue";Area=12}; instance of Figs_Triangle {Label=4;Color="Blue";Area=12}; instance of Figs_Circle {Name=1;Color="Blue"}; instance of Figs_Circle {Name=3;Color="Blue"}; instance of Figs_Circle {Name=5;Color="Blue"}; instance of Figs_CircleToTriangle { ACircle="Circle.Name=1"; ATriangle="Triangle.Label=2"; }; instance of Figs_CircleToTriangle { ACircle="Circle.Name=5"; ATriangle="Triangle.Label=2"; }; instance of Figs_CircleToTriangle { ACircle="Circle.Name=5"; ATriangle="Triangle.Label=4"; }; instance of Figs_Covers { Over="Triangle.Label=2"; Under="Triangle.Label=4"; }; |
The import operation must preserve namespace path information so if either this platform or another platform understands how to manipulate an implementation of type <namespacetype> and has access to the <namespace_handle>, it can manipulate one or more of the instances in the source.
The namespace path can also be specified using the instance-based
Source qualifier. This qualifier marks a particular object or an
association. This is illustrated in
class Figs_Circle { [key] uint32 Name; string Color; }; class Figs_Triangle { [key] uint32 Label; string Color; uint32 Area; }; [Association] class Figs_CircleToTriangle { Figs_Circle REF ACicrle; Figs_Triangle REF ATriangle; }; [Association] class Figs_Covers { Figs_Triangle REF Over; Figs_Triangle REF Under; }; | [source("Mgmt_X:\EastCoast")] instance of Figs_Triangle {Label=2;Color="Blue";Area=12}; [source("Mgmt_X:\EastCoast")] instance of Figs_Triangle {Label=4;Color="Blue";Area=12}; [source("Mgmt_X:\EastCoast")] instance of Figs_Circle {Name=1;Color="Blue"}; [source("Mgmt_X:\EastCoast")] instance of Figs_Circle {Name=3;Color="Blue"}; [source("Mgmt_X:\EastCoast")] instance of Figs_Circle {Name=5;Color="Blue"}; [source("Mgmt_X:\EastCoast")] instance of Figs_CircleToTriangle { ACircle="Circle.Name=1"; ATriangle="Triangle.Label=2"; }; [source("Mgmt_X:\EastCoast")] instance of Figs_CircleToTriangle { ACircle="Circle.Name=5"; ATriangle="Triangle.Label=2"; }; [source("Mgmt_X:\EastCoast")] instance of Figs_CircleToTriangle { ACircle="Circle.Name=5"; ATriangle="Triangle.Label=4"; }; [source("Mgmt_X:\EastCoast")] instance of Figs_Covers { [nonlocal("Mgmt_X:\EastCoast")] Over="Triangle.Label=2"; Under="Triangle.Label=4"; }; |
The Nonlocal qualifier is similar to the Source qualifier since its
value is a string:
The content of Mgmt_ABC after importing only circle
information looks like the example in
In particular, the two instances of triangle are not imported, and the references to triangle in the associations are also marked with the nonlocal qualifier.
The above schema also allows intelligent import operations to avoid importing all the objects if there are associations between the objects.
class Figs_Circle { [key] uint32 Name; string Color; }; class Figs_Triangle { [key] uint32 Label; string Color; uint32 Area; }; [Association] class Figs_CircleToTriangle { Figs_Circle REF ACicrle; Figs_Triangle REF ATriangle; }; [Association] class Figs_Covers { Figs_Triangle REF Over; Figs_Triangle REF Under; }; | instance of Figs_Circle {Name=1; Color="Blue"}; instance of Figs_Circle {Name=3; Color="Blue"}; instance of Figs_Circle {Name=5; Color="Blue"}; instance of Figs_CircleToTriangle { ACircle="Circle.Name=1"; [nonlocal("Mgmt_X:\EastCoast")] ATriangle="Triangle.Label=2"; }; instance of Figs_CircleToTriangle { ACircle="Circle.Name=5"; [nonlocal("Mgmt_X:\EastCoast")] ATriangle="Triangle.Label=2"; }; instance of Figs_CircleToTriangle { ACircle="Circle.Name=5"; [nonlocal("Mgmt_X:\EastCoast")] ATriangle="Triangle.Label=4"; }; instance of Figs_Covers { [nonlocal("Mgmt_X:\EastCoast")] Over="Triangle.Label=2"; [nonlocal("Mgmt_X:\EastCoast")] Under="Triangle.Label=4"; }; |
| Contents | Next section | Index |
