Beispiel 2: Umsetzung von Internet-MIBs in das CORBA-Objektmodell: Der JIDM-Algorithmus

 

Die Abbildung bestehender Objektbeschreibungen in das CORBA-Objektmodell setzt analog zur Transformation von Internet-SMI nach GDMO die algorithmische Überführung der Spezifikationssprachen voraus, in denen die Managementobjekte beschrieben sind. Im vorliegenden Fall handelt es sich um die Übersetzung der in der Internet-Managementarchitektur verwendeten ASN.1-Templatesprache in OMG IDL. Hierfür existiert ein Algorithmus [#!jidmst97!#], der im Rahmen der Aktivitäten der Joint X/Open NM-Forum Inter-Domain Management Task Force (JIDM) entworfen wurde und sich zur Zeit in der Standardisierungsphase befindet. Aufgrund der Automatisierbarkeit des Verfahrens der direkten Übersetzung wurde daher auch in diesem Fall diese Transformationsvariante gewählt. Überdies kennt CORBA bisher keine generischen MOCs, die als Basis einer Vererbungshierarchie dienen könnten.

Wichtigster Gesichtspunkt bei der Überführung von Agenten einer Managementarchitektur in eine andere ist die unterschiedliche Mächtigkeit der jeweiligen Informationsmodelle. Während das Internet-Informationsmodell sämtliche Aspekte eines Agenten (Parameter und Aktionen) in Form von skalaren Datentypen bzw. Tabellen beschreibt und - im Gegensatz zu CORBA - keine Mechanismen wie beispielsweise Vererbung oder Datenabstraktion kennt, werden im CORBA-Objektmodell Agenten in Form von Objektklassen sowie deren zugehörigen Attributen und Methoden definiert. Die Transformation der in SNMPv2 vorhandenen Datentypen, Makros und asynchronen Ereignismeldungen in die CORBA-Entsprechungen geschieht folgendermaßen:

1.

Jedes einzelne Internet SMI-Modul wird einem IDL-Modul zugeordnet. In diesem werden alle durch die Übersetzung entstandenen Schnittstellen, Typen und Konstanten abgelegt. Wenn es mindestens ein NOTIFICATION-TYPE-Makro im SNMP Informationsmodul gibt, werden zusätzlich zwei IDL-Schnittstellen SnmpNotifications und PullSnmpNotifications für die typisierte push- respektive pull- Event-Kommunikation erzeugt.

2.

ASN.1-Typen werden auf IDL-Datentypen abgebildet; insbesondere werden die Typspezifikationen der TEXTUAL-CONVENTION-Makros zu IDL-Datentypen.

3.

MODULE-IDENTITY-, OBJECT-IDENTITY- und OBJECT-TYPE-Makros werden auf IDL-Konstanten vom Typ ASN1_ObjectIdentifier abgebildet.

4.

Für jedes Tabellenobjekt und für jede Gruppe des MIB-Moduls wird eine Schnittstelle definiert. Dabei wird

• zu jedem Spalteneintrag einer Tabelle und
• zu jeder MIB-Variable einer Gruppe

ein IDL-Attribut in der entsprechenden Schnittstelle deklariert, wobei Identifikator, Typ und Zugriffsrechte der Attribute aus den OBJECT-TYPE Makros der dazugehörigen Variablen abgeleitet werden. Dieses Vorgehen ist identisch zur oben beschriebenen Erzeugung von GDMO-Templates.

5.

Zu jedem NOTIFICATION-TYPE Makro werden ferner drei Funktionen deklariert:

• im Interface SnmpNotifications die Funktion <notification_name>, wobei <notification_name> der Identifikator des NOTIFICATION-TYPE-Makros ist,
• im Interface PullSnmpNotifications die beiden Funktionen try_<op> und pull_<op>. <op> ist der Name der korrespondierenden Funktion in SnmpNotifications. Diese sind notwendig, um sowohl das Push- als auch das Pull-Modell zur Zustellung asynchroner Ereignismeldungen zu unterstützen.

Auch hier haben wir aus Platzgründen die Anwendung dieses Algorithmus am Beispiel der MIB-II sowie die dazu notwendigen Erläuterungen in Anhang verlagert. Der JIDM-Algorithmus ist Bestandteil der OMG CORBA/TMN Interworking-Aktivitäten und befindet sich gegenwärtig in der Abschlußphase der Standardisierung durch die OMG (siehe dazu [#!omg980503!#]).