MIBcomposer

Die Aufgabe des MIBcomposers ist es, C++-Implementierungen der Managementobjekte für den Agenten zu generieren:

1.

Der MIBcomposer generiert den C++-Code für die Managementobjekt-Klassen und die Attribute, die der Agent schließlich verwalten soll. Dieser automatisch generierte Code unterstützt dabei folgende CMIS-Funktionalitäten:

(a)

CMIS/CMIP Filteroperationen

(b)

Allomorphismus, das heißt, eine Instanz einer Managementobjekt-Klasse kann sich genau so verhalten, als wäre sie eine Instanz einer anderen Managementobjekt-Klasse

(c)

Laufzeitüberprüfung für das Einbinden von conditional packages

(d)

selbständige Namensgebung für die Instanzen.

Aufgrund dieser Eigenschaften ist es möglich, einen kompletten und eigenständigen TMN-konformen Agenten zu erstellen. Dies erfolgt ohne irgendwelche Eingaben oder explizite Informationen eines Entwicklers, außer der Definition, welche Klassen dieser Agent unterstützen soll (entspricht den ASN.1- und GDMO-Dokumenten in Abbildung 3.2). Dieser neue, ,,sterile`` Agent besitzt noch keine Anbindung an eine zu verwaltende Ressource. Er stellt also eine Containment-Hierarchie zur Verfügung, auf der die vollständige CMIS-Mächtigkeit ausführbar ist, aber bei dem die Klassen/Instanzen und Attribute keine Funktionalität ausführen. Ein derartiger Agent eignet sich zum Beispiel für ,,Rapid Prototyping`` und damit für eine sukzessive Weiterentwicklung bis schließlich hin zu einem fertigen Produkt.
Sobald nun das Verhalten der Klassen und Attribute vom Entwickler implementiert wird (entspricht dem User defined Behavior in Abbildung 3.2), zum Beispiel durch einen mit einer Ressource kommunizierenden Code, entsteht ein fertiger, voll funktionsfähiger TMN-/OSI-Agent.

2.

Diese Kodierung des Verhaltens von Klassen und Attributen erfolgt auf eine einfache und intuitive Weise. So existieren 20 verschiedene Callbacks, die als verschiedene Arten von Fragestellungen angesehen werden können. Ein Entwickler muß nun bei der Bearbeitung eines CMIP-Requests eine feste Anzahl und vordefinierte Reihenfolge dieser Callbacks/Fragestellungen implementieren/beantworten. So wird zum Beispiel während der Ausführung eines CMIP-GET-Requests zuerst ein Callback mit dem Namen ,,Precondition Check`` aufgerufen. Dieser überprüft vor dem Zugriff auf den Wert des Attributes eventuelle Vorbedingungen. Anschließend wird über den ,,Real Value Access``-Callback auf den Wert des Attributes zugegriffen. Dabei kann es sich um einen einfachen Variablenzugriff handeln, es kann aber auch ein komplexer Zugriff auf eine darunterliegende Ressource sein. Bei Bedarf können vom Agenten auch weitere CMIP-Requests ausgelöst werden, um den Wert des Attributs zu bestimmen. Zuletzt werden in dem ,,Postcondition Check``-Callback eventuelle Aufgaben nach einem Attributzugriff ausgeführt.
Bei der Implementierung einer Klasse werden automatisch alle zu dieser Klasse gehörenden und die von den Vaterklassen geerbten Attribute dargestellt. So wird in einer komplexen Vererbungshierarchie von einer Vielzahl an Klassen und Attributen immer nur der Ausschnitt gezeigt, der für die gerade aktuelle Bearbeitung wirklich notwendig ist.

3.

Durch dieses Callback-Konzept werden implementierungsspezifische Details von Managementobjekt-Klassen und Attributen von der Standard-Bearbeitung getrennt. Die jeweiligen Callbacks werden in eigenen Dateien verwaltet. Auf diese Weise können, ohne den bisherigen Callback-Code zu verändern, neue Klassen und damit Attribute dem Agenten hinzugefügt werden.

Sobald der MIBcomposer gestartet wird, muß der Benutzer die ,, Metadata`` (GDMO- und ASN.1) Dateien bestimmen, die geladen werden sollen. Damit wird festgelegt, welche Managementobjekt-Klassen der Agent unterstützen soll.
Weiterhin ist der Name eines Verzeichnisses notwendig (,, workspace``), in welchem die implementierungsspezifischen Details enthalten sind bzw. in welchem sie abgespeichert werden sollen. Nach dem Parsen der Eingabe-Dokumente kann der Entwickler die Callbacks für die Klassen und Attribute implementieren. Anschließend generiert der MIBcomposer Konfigurationsdateien (z.B. ein Makefile) und den Code für die Klassen und Attribute, indem er die Metadata-Informationen und den Code in dem workspace-Direktory geeignet verbindet. Das Resultat ist die vollständige C++-Implementierung aller Managementobjekt-Klassen. Damit ist der Agent konform zu der oben durch die GDMO- und ASN.1-Dateien definierten MIB.