Since I am clarifying some things today, first I should clarify what I can clarify about CMDBf workgroup activities at DMTF.
I can state my opinions about what is going on in the CMDBf workgroup, including giving some insight about what I am thinking in the meetings, but I cannot really say what the workgroup has decided or is considering. Therefore, please note that whatever I say about this workgroup is my personal opinion and is subject to change or different interpretation from other members of the workgroup.
OK, disclaimers aside - things have changed slightly since we started the CMDBf workgroup at DMTF (as you would expect unless we are just wasting our time!)
In a previous posting about modeling CIM_VirtualComputerSystem I indicated that the best way to expose a sub-classed model in CMDBf is to associate an item with records of each class in the inheritance hierarchy. This would still work (and may suit your purposes), but an MDR is also allowed to return an item with a record that has the properties of the requested recordType even though the recordType has a different name.
Ah - let me clarify with an example. Let's assume (contrary to my last post on this subject) that the MDR implementation model
CIM_VirtualComputerSystem as one big record with CIM_ComputerSystem and all other parent-class attributes. The CMDBf client issues a query for items with CIM_ComputerSystem records and certain propertyValue constraints. It is legitimate for the GraphQuery operation to return these items with:
- One CIM_VirtualComputerSystem record (where the client must assume that the MDR considers CIM_VirtualComputerSystem to be a subclass of the requested CIM_ComputerSystem recordType).
- One CIM_VirtualComputerSystem record and one CIM_ComputerSystem record (thus the client can tell explicitly that this item matches the requested recordType). For efficiency the Query service may choose to factor out the common properties from the CIM_VirtualComputerSystem records that are returned.
If I were implementing a CMDBf Query service I would choose the latter approach because the client will not need knowledge of the inheritance model to understand why the operation returned CIM_VirtualComputerSystem in response to its CIM_ComputerSystem query. There is also the possibility that this knowledge could be conveyed in the XML schema or other mechanism, but this places a pretty big burden on clients who don't understand my data model.
One more note on the subject of CIM_VirtualComputerSystem - its usage is apparently being deprecated by CIM (see http://www.dmtf.org/standards/cim/cim_schema_v219/cim_schema_2.19.0Experimental-MOFs.zip) in favor of simply using CIM_ComputerSystem with a CIM_HostedDependency relationship to another CIM_ComputerSystem. What? This is presumably because so many management systems have a hard time distinguishing between virtual and physical systems.
There's also an issue of how a Query service interprets a request if the MDR has something like BMC_ComputerSystem when the client asks for CIM_ComputerSystem. The GraphQuery operation may return these items with:
- One CIM_ComputerSystem record (where the Query service maps its BMC data model to CIM), or
- One CIM_ComputerSystem record and one BMC_ComputerSystem record, so the client gets both perspectives
Again I would choose the latter approach, but I can't really factor out any properties from BMC_ComputerSystem because BMC_ComputerSystem is not formally derived from CIM_ComputerSystem and does not have an identical set of properties. It's just another record which the client may choose to use or ignore. If the client just wants CIM_ComputerSystem records, it can use the contentSelector/selectedRecordType to screen out the BMC_ComputerSystem noise.
I hope this gives you some more perspective and clarity. Things are a lot more clear for me, but that is mostly because I just cleaned my glasses!
