Some Theoretical Background

Sections 6 and 7 of the CIM Specification (DSP0004) discuss various ways to map between modelling paradigms . In particular they describe the technique, recast and domain approaches. I have illustrated these in Figure 14.5 which I have modified slightly from the paper "Semantic Management: Advantages of Using an Ontology-Based Management Information Meta-Model " by de Vergara, Villagr, and Berrocal.

Figure 14.5: Different Mappings

In Figure 14.5, "source domain" might be your legacy management system which you wish to map into CIM, the "destination domain." This would reflect scenario 1. Alternatively, CIM could be the "source domain" and your legacy system the "destination domain" ”as in scenario 2.

I mentioned at the beginning of Chapter 6 that, in addition to the core and common models, the DMTF has also produced a meta-model. This model describes the modelling terms themselves ”the concept of a class, the fact that classes can have properties and methods , etc. If you find the concept of a meta-model a little abstract, then you should be aware that the Object Management Group (OMG) defines four layers of models in its meta-object facility (another mof !) specifications: the information (instances, in our terms), the model which describes how instances may be created, the meta-model which describes how models may be created, and the meta-meta-model which describes how meta-models may be created.

I assume that, whatever legacy management system you are using, it will have some form of implicit or explicit meta-model. In many cases of proprietary management systems, this model was never made explicit but it exists in the minds of the designers. Given this, the three basic techniques are as follows :

1. Recast mapping: If it is feasible , this is the cleanest way of providing a mapping. The manual work involved is to match meta-constructs in each modelling language and write a compiler to convert one language to the other. For example, it might be possible to say that attributes in your legacy system correspond exactly with properties in CIM, that components in the legacy system correspond to classes in CIM, etc. If such a mapping can be defined, then conversion of one model into the other can be carried out in an automated manner. This technique has been used successfully to inter-translate SNMP MIBs, CORBA IDLs, and TMN MIBs (see "Inter-Domain Management: Specification and Interaction Translation," published by the Open Group as document C802).

2. Technique mapping: As Figure 14.5 shows, this is a cross-layer approach. The idea is to take concepts in the legacy meta-model (e.g., an attribute) and map these not to the destination meta-model but to the destination model (e.g., classes in CIM). This idea was used many years ago in the DMTF's standard DSP0002 published in 1997 to define a mapping between SNMP and the desktop management interface (DMI). Although the document is now only of archeological interest, the technique it used is still relevant.

   Sun Microsystems' mib2mof utility uses this technique to translate Solaris SNMP MIBs into mof files.

3. Domain mapping: This is the most labour- intensive technique and it commonly results in an incomplete mapping. It can, however, be used in circumstances where recast is not applicable . Domain mapping is a content-to-content mapping: mapping, for example, the LocalDateTime property of the CIM_OperatingSystem class to the HOST-RESOURCES-MIB.hrSystemDate field of the IETF's SNMP MIB. The equivalence is indicated by the MappingStrings qualifier.

   Because there is no attempt to map the meta-model, semantics are lost in the mapping: the field may be equivalent in the syntactical sense but is it actually used in the same way in both the source and the destination models?

Generally, with the possible exception of those systems where a recast mapping is possible, semantic information is lost in any translation: between SNMP and CIM, for example, hierarchical information must change its meaning from has a to is a. This means that some process with semantic intelligence must be present, possibly a provider or client interface, to make the necessary semantic transformations.

There is still much research being carried out on the automated, lossless conversion between management models. The state of the practical art today is that semantic information will almost certainly be lost in anything other than transformations between systems with isomorphic meta-models.