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!

First I must apologize for not posting anything for the last two months. I guess I had writer's block. Then again I know some who would prefer to get more meaningful posts less frequently, so at least I can satisfy the latter part of that preference!

So we have this question about how to expose an existing CIM association as a relationship using the CMDBf metamodel. Take CIM_Dependency for example. It seems that about half of all CIM associations are based on CIM_Dependency so answering this question may be generally useful.

CMDBf would require the MDR to represent a CIM_Dependency association as a relationship between two items, where the relationship has a record of type CIM_Dependency (and maybe other records too). So far, so good (a no-brainer if you have been following my blog or other CMDBf activities).

Now - how do you represent the Antecedent and Dependent properties of this record? The first part of the answer is not too hard - a concatenation of the existing Key properties of each CIM instance will work within a CIM Object Manager. But how do you relate Antecedent and Dependent to CMDBf source and target in the relationship metamodel? That's the tricky part (and very important for an MDR, I might add). In the picture below, can you tell whether Computer System depends on Person (like server depends on administrator) or Person depends on Computer System (like I depend on my laptop)?

If your MDR implementation decides that the Antecedent role maps to the relationship target and my MDR implementation decides that Antecedent maps to source, we won't have interoperability even though we are both using the same data model (!!) In other words, our MDRs may not reconcile or respond to a query with predictable results. A graph traveral from one MDR to the other may get stuck in between.

It would be a lot easier if every Association in CIM had a sense of direction, like "depends on" for example; then it would be grammatically obvious (at least to someone who understands English) - source depends on target. I suspect it's a bit late for that wish to come true.

There may be a couple of ways out of this modeling conundrum. The CMDBf workgroup at DMTF could define how to map these basic CIM association REFs to source and target and ask every MDR implementation that supports CIM to follow these conventions. That's a real possibility and easy to implement if we catch every MDR before they go with their own instincts.

I had another way out, but got lost in the maze. Help! I'm waiting for someone else in the workgroup or in my little blog world to make a better suggestion.