A Practical Approach to WBEM[s]CIM Management

If you have scanned the mof for the core and common models, you will have noticed the property CreationClassName appearing repeatedly. The definition of CIM_LogicalDevice which I have reproduced on page 192 is a particular example.

CreationClassName is something of an embarrassment. It was introduced to keep keys of instances of subclasses unique. Assume, for example, that you have defined classes A, B, and C and that a C is a B which is an A:

If A defines a key property, myKey, then this is inherited by all instances of classes B and C. If this is the only key, then it is awkward to ensure that instances of classes B and C have unique keys. This problem was worked around by introducing an additional key into classes like A: CreationClassName. An instance of B might then have the keys

myKey=27,CreationClassName="B"

and an instance of C might have the keys

myKey=27,CreationClassName="C"

Although both instances have myKey set to 27, they are still unique because of the second key: myKey only needs to be unique between the instances of one class.

Such a key, when used in this manner, also has the effect of providing what in C++ would be called a downcast . If I am given an instance of class A, I can find out by inspecting the keys whether it is also an instance of class B or class C. This can often be useful.

However, the general feeling within the DMTF is that CreationClassName is becoming something of a liability ”it is proliferating like wild rabbits throughout the CIM schema. There is therefore a move away from CreationClassName towards arbitrary and opaque instance identifiers. An example is given in the class CIM_SettingData which I reproduce in slightly abbreviated fashion here:

[Key, Description ( "Within the scope of the instantiating Namespace, " "InstanceID opaquely and uniquely identifies an " "instance of this class. In order to ensure " "uniqueness within the NameSpace, the value of " "InstanceID SHOULD be constructed using the " "following 'preferred' algorithm:\n" "<OrgID>:<LocalID>\n" "Where <OrgID> and <LocalID> are separated by a " "colon ':', and where <OrgID> MUST include a " "copyrighted, trademarked or otherwise unique name " "that is owned by the business entity " "creating/defining the InstanceID, or is a " "registered ID that is assigned to the business " "entity by a recognized global authority (This is " "similar to the <Schema Name>_<Class Name> structure " "of Schema class names.)\n" "If the above 'preferred' algorithm is not used, " "the defining entity MUST assure that the resultant " "InstanceID is not re-used across any InstanceIDs " "produced by this or other providers for this " "instance's NameSpace.\n") ] string InstanceID;

The InstanceID is therefore a structured but otherwise opaque key. The Acne Manufacturing company could assign InstancelDs of the form ACNE:0000001, ACNE:0000002, ACNE:0000003, etc., incrementing the number for each created instance.

Actually, as the role of CreationClassName is simply to ensure uniqueness, there is really no need for you to set them to the genuine class name. If you wish, you may set them to anything which makes the instance unique, including the format of the InstanceID described above.