Loose Coupling
Document Actions
Modeling inheritance in CMDBf records (continued)
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 models 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!
_____
tags:
Last time I posted a question - to see if we can move toward a resolution on the question about modeling a CIM association using CMDBf relationships. William Vambenepe replied to me on his blog here: http://stage.vambenepe.com/archives/212.
Basically his answer can be summarized as: (a) Some authoritative group like the CMDBf workgroup defines a convention for mapping CIM association roles to CMDBf source and target, and/or (b) CMDBf workgroup provides an ontology language that allows records to be related to each other (e.g. RDF/OWL semantics.)
While I like his proposal about a naming convention for relationship records (such as CIM_Dependency_from_Antecedent_to_Dependent), it would allow any implementation to model the source/target direction either way. At least it would be definitive about the role of source and target for that relationship. I also like the idea of having an ontology language to describe the record types more thoroughly, but I would not want to force MDRs and consumers to read and understand the ontology in order to use the interface.
I guess in a perfect world everyone would model it the same way, so if we said "source is always the first role and target is always the second role" we would at least have a simple match most of the time, and the naming convention would confirm the roles of source and target.
Note that an ontology language or some embeded mapping of data models allows an MDR to return records it considers to match your query, even if the record type has a different name. Here's an example.
Assume I could have this i1 -r1-> i2 <-r2- i3 graph in a CIMOM where:
- i1 has a CIM_ComputerSystem record
- r1 has a CIM_ParticipatingCS_from_Antecedent_to_Dependent” record
- i2 has a CIM_Cluster record
- r2 has a CIM_ConcreteDependency_from_Dependent_to_Antecedent” record
- i3 has a CIM_Organization record
So in English I have an organization which depends on a cluster of computer systems.
Now I want to see what computer systems support this organization. I can invert r2 as CIM_ConcreteDependency_from_Antecedent_to_Dependent (vr2) and have this: i1 -r1-> i2 -vr2-> i3. Now I can query i1 to i3 via CIM_Dependency_from_Antecedent_to_Dependent with depthLimit 2 or more and find this graph. Great! But I made a couple of assumptions that the casual observer might not have noticed:
- CIM_Dependency is a superclass of CIM_ConcreteDependency and CIM_ParticipatingCS. We have decided it is OK to match a record type which is considered to be of the same type as the request, even if there is no strict XSD extension model to validate this.
- We are also considering defining a way (via RDF/OWL) to expose these
class relationships.
An MDR could respond with an inverse relationship that satisfies your query, even though this relationship record does not actually exist in that form (really a special case of the previous item).
Reversing direction in the underlying data store query could be challenging, but that’s why we hire geniuses (well maybe we need a few more).
_____
tags:
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.
_____
tags:
Here's an example that will illustrate how multiple records are used to represent a configuration item in CMDBf notation.
Let's assume I have an MDR that has information about VMWare guest systems. The question for CMDBf is - how will I expose this information to a federating CMDB or other CMDBf query client? One really good way is to map the information to the Common Information Model (I'll use version 2.16 for this example).
CIM_VirtualComputerSystem in CIM 2.16 is a subclass of CIM_ComputerSystem, which is a subclass of CIM_System, which is a subclass of CIM_EnabledLogicalElement, ...
In CMDBf parlance, there is an item representing this virtual machine (virtual "lump of plastic and steel" as some in the committee call it.) Then there are records describing this item.
Now, I could take all the inherited attributes from those CIM classes and make one big CIM_VirtualComputerSystem record. This would be really easy to process, but it leaves out some important functionality. What if I want to query for all Computer Systems or all Systems in general? This could only be done with a very complex query searching for all possible subclass record types.
Alternatively (and recommended), I can model the VM as an item with a CIM_VirtualComputerSystem record plus a CIM_ComputerSystem record, plus a CIM_System record, all the way to a CIM_ManagedElement record. This will allow maximum flexibility for the query client to find exactly the items it needs to query.
Now a more difficult question - if I want to use the Registration service of CMDBf and mass-register all my VMs, should I register each item with all these records? That could be a lot of network and parsing overhead. Plus, I wouldn't expect the federating CMDB to replicate and store all this information.
Probably the best answer is to associate another record with the item that provides just enough information to identify the item. This record should indicate that the item is a virtual computer system with a certain name and other identifying properties, possibly combining attributes from multiple superclasses. There is no standard schema for these identifying records today - this is an open question for the community to answer. Your feedback is welcome!
_____
tags:
I just got a "blast from the past" question about applications that are packaged with process models and monitoring (see http://talk.bmc.com/blogs/blog-wiles/van-wiles/PROCESSDOC1).
The new wave of applications are things like Oracle Fusion Applications (http://www.oracle.com/applications/fusion.html), the next generation of SAP Business Suite built on NetWeaver ESOA (http://www.sap.com/usa/solutions/business-suite/index.epx), and even the latest BMC Remedy IT Service Management built on the Remedy Service Process Management platform( http://www.bmc.com/products/products_services_detail/0,,0_0_0_1805,00.html).
The trend then and now (since it’s been almost a year since I posted that) is to build the business logic and rules using tools that business people can understand, then use this business logic to generate the technical implementation required to execute and monitor the processes. Since I wrote that, many of these companies have acquired additional SOA technology through M&A and partnerships, including the BMC acquisition of RealOps for IT service automation.
Note: for SAP, Oracle and some other packaged business applications, you can get higher-level process models that are application-independent from IDS Scheer AG (http://www.ids-scheer.com). For business rules, many of these vendors use Corticon (http://www.corticon.com/Partners/Software-Partners.php) or similar Business Rules Engines.
_____
tags:
Here are a few ways the CMDBf 1.0 spec (not a standard yet) can be implemented.
First - it is important to understand that the spec describes web services. These services can be written and delivered by anyone, not just the vendor of a particular CMDB or MDR. So let's say there are three scenarios (there may be more):
1. Each CMDB and MDR vendor produces its own CMDBf services for its own
product lines
2. Third-party software vendors produce CMDBf services for popular CMDB and
MDR products and market these adapters independently
3. Consulting service providers produce CMDBf services for custom
applications to be used with other CMDBf implementations
I will guess that these are all viable options and could very well come to market in the reverse order from above (custom implementations first).
Second, the spec can be implemented in many ways - "push-mode", "pull-mode" or both, varying levels of query support, varying record types, etc.
Now comes a tricky question - can you market these adapters without a common data model, or an exponentially-expanding set of data-mapping objects? The point here is that some maturity will be required before this is really plug-and-play.
So, leaving the modeling/mapping question aside for now, let's see how a third-party could produce adapters for a pair of MDR's. I'll start with a picture.
In the picture above, all the CMDBf services and processes are provided by a third-party (call it Lavender Software.) Lavender has adapters for each MDR proprietary interface, plus transformers to register items and relationships from Vendor A to Vendor B CMDB, and a User Interface to query the registered CMDBf Query Services.
This picture could change if one or both vendors produce their own CMDBf services and the customer wants to switch. In this case, Lavender Software might provide a way to switch services to another vendor. In this case, you can imagine that it would be much less painful to exchange information between CMDBf services in a common format, at least in the case of registration. Additionally, it would be really helpful to the query UI if items of like-kind had common type-names (like Incident or Computer System for example).
In the final picture, vendors A and B have provided XML schemas and registration processes for their services, and a contract integrator has been hired to connect the services. All that is required is for the contractor to use the registered services and provide a query client interface for the customer.
Final note: open standards and open source go together like shoes and
socks (except that standards smell better with age.) There is an open
source project giving some very interesting insight on a CMDBf
implementation over SML/CML starting here: http://wiki.eclipse.org/Leveraging_CMDBf.
This is part of the Eclipse COSMOS project which is sponsored by some
of the original consortium companies. It should be a useful starting
point if you are interested in implementing CMDBf.
_____
tags:
I haven't posted lately - if you subscribe to this blog, I'm still here!
The CMDBf consortium work has wrapped up - I plan to be actively participating in the DMTF committee to support CMDB federation now. I'm working on another post about CMDBf records in the meantime, while the DMTF committee is getting ready to launch.
In other areas, I'll be supporting development efforts to integrate with BMC Atrium technology. I expect this technology to expand well beyond CMDB this year, so remember that "BMC Atrium" is not synonymous with "CMDB". As always this will involve a lot of learning for new releases and features. It will also require some leadership as we develop a methodology for validating and certifying interoperability.
Anyway - I wish you a safe and prosperous New Year wherever you are!
_____
tags:
It's official - continuing work on CMDBf specification will be done within the context of a new DMTF working group. Here's the press release:
That's a relief - it's public!
_____
tags:
I bought a new driver a couple of months ago, and just got a chance to try it on the golf course. On the driving range I found that I got about 50 more yards of distance. On the course I got the Rest of the Story. That last 50 yards was usually on the wrong trajectory, leaving me in deep trouble most of the time. But it sure is fun to use on the driving range!
I heard a similar story from a customer that makes Formula 1 race cars. The problem to be solved in Formula 1 racing is not speed, but control - keeping the car on the track.
This same principle applies to IT process automation. The fun part of automation is making things work. The important part of automation is approval and auditing. Make sure that approvals can be automated and that any automated changes can be tracked to a change request, audited, and backed out. Automate the backout process too - ahead of time!
I guess this is obvious if you are an ITIL guru, but I thought the analogies would be interesting.
_____
tags:
Like many simple and powerful things, records could be used the wrong way, leaving a so-called "hole in your foot". Thus I am offering a bit of explanation.
An item can be "associated" with many records. This may be implemented as some sort of join by property on the item ID, or a set of unexposed relationships. The important thing to remember is that a query for an item may return a mixed bag of records, some of the same record format (record type), and some of different formats.
The first thing to know about records is that they could give you a clue what the item actually is. (If you hadn't noticed this, items and relationships don't have a "type".) So if your item has a "ComputerSystem" record, it's probably some sort of computer system. If it has a "ComputerSystem" record and a "Switch" record, well - I hope you get the picture. The committee chose this approach to allow maximum flexibility that supports but does not require a hierarchical or object-oriented data model.
The specification does not differentiate between an "is-a" association and a "has-a" association. For example, if an item has a "ComputerSystem" record and a "SupportContract" record, is the item a computer system or a contract? That could be the first "hole in your foot". There are two ways to deal with this. You could decide that in your world a support contract could be associated with any item and will never be a separately managed item. Thus you may structure your items as I just described.
The problem comes up when this type of MDR is federated with another MDR that manages support contracts as separate items. In that federation, a query for contracts may yield more items than the client expects. The other way to deal with this is to create a separate item with a "SupportContract" record and create a relationship with a "SupportedBy" record, where the relationship source is the item with the "ComputerSystem" record and the target is the item with the "SupportContract" record.
This is a better way to model this, because in the most likely scenario, one MDR may have all the support contracts and know very little about the supported configuration items.
Think carefully about whether a record represents something that could be managed, or whether it is simply a collection of properties that could be associated with any item or relationship.
I guess I'll post more entries on this subject since there are several other tips to be considered.
_____
tags:
Forgot your password?
New user?
