Ergebnis

von Thomas Hütsch (thomas.huetsch@huetsch.de)


Bewertung

Der Klasse IPropertyMapping sollte, entsprechend ihrer Aufgaben, in zwei Komponenten z.B: INameMapping und IValueMapping aufgeteilt werden um eine höhere Wiederverwendbarkeit zu erreichen.

Bei der Abbildung der Werte wird der Datentyp String als varianter Datentyp verwendet. Dadurch gehen allerdings die Typinformationen und Typsemantik verloren. Die Werteabbildung sollte in zwei Komponenten z.B. ILogicalMapping und IPhysicalMapping aufgeteilt werden. Das PhysicalMapping übernimmt dann die Aufgabe den logischen Wert in den entsprechenden Zieldatentyp zu wandeln (casting).

Beim Erstellen von CIM-Modell und Mapping-Modell ist es sehr aufwendig und fehlerträchtig die beiden Modelle konsistent zu halten. Es ist denkbar beide Modelle aus einem zentralen Modell zu generieren.

Nicht alle Eigenschaften der MIB sind reine Key/Value Paare. Z.B. Die Eigenschaft (Name=at.atTable.atEntry.atNetAddress.1.192.168.x.x Wert=192.168.y.y) kann in zwei voneinander abhängige Key/Value Paare aufgelöst werden: (Name1=at.atTable.atEntry.atNetAddress.1 Wert1=192.168.x.x) und (Name2= at.atTable.atEntry.atNetAddress.1.+{Wert1} Wert2=192.168.y.y). Eine Änderung von Wert1 hat Seiteneffekte.

Zusammenfassung

Es konnte gezeigt werden, dass es möglich ist einen generischen Provider zu realisieren, der die Informationen der MIB in das CIM überführt. Darüber hinaus kann das Verfahren auch auf nicht SNMP-fähige Quellen angewendet werden um deren Management Informationen in CIM abzubilden. Das vorgestellte Metamodell kann als Ansatz für eine allgemeine Lösung zur Abbildung von Modellen gesehen werden.


$Id: modelmapping.html 60 2005-02-22 16:55:21Z thuet $