Callbacks der OSI-Klassen, die SNMP-Ressourcen repräsentieren

Diese Klassen können entweder SNMP-Gruppen oder SNMP-Tabellenzeilen repräsentieren. Da das SNMP-Informationsmodell Gruppen bzw. Tabellenzeilen keine Werte bzw. Verhalten zuordnet, überträgt sich dies auch auf die OSI-Klassen. Sie dienen ,,lediglich`` als Strukturierungs- bzw. Containerobjekte. Damit erfolgt auch keine explizite Codierung der Callbacks, das heißt, das allgemeine Verhalten, das jeder OSI-Klasse automatisch vom MIBcomposer zugeordnet wird (siehe 3.2.1 Unterabschnitt MIBcomposer), ist für die Repräsentation von SNMP-Gruppen bzw. Tabellenzeilen ausreichend. Es gibt jedoch eine Ausnahme: Im Abschnitt 5.2.6 wird zur Einschränkung von Inkonsistenzen in der Gateway-MIB die Aktion ,, aktualisiereTabelle`` definiert. Diese Aktion wird in 5.2.6 bestimmten OSI-Klassen zugeordnet. Die Implementierung erfolgt mittels des Action Callbacks. Sobald ein OSI-Manager diese Aktion auf einer Instanz einer OSI-Klasse auslöst, die diese Aktion unterstützt, wird der Action Callback aufgerufen. Dieser Callback ruft die Methode CreateMOI der Klasse dynMOICreation_ofSNMP_Table aus 6.2 auf und führt somit die Replikation einer SNMP-Tabelle in der Gateway-MIB aus.

Im Übersetzungsalgorithmus in Abschnitt 3.1.1 wird definiert, daß der Relative Distinguished Name (RDN) einer Instanz einer Klasse, die eine SNMP-Gruppe repräsentiert, zu ASN.1 NULL wird. Dies hat sich in der Praxis als ungünstig herausgestellt, da die Managementplattform IBM TMN Support Facility for AIX (=OSI-Manager) zu sämtlichen Instanzen nur den RDN darstellt und nicht zusätzlich die Managementobjekt-Klasse der Instanz. Damit werden alle Instanzen, die eine SNMP-Gruppe repräsentieren mit ,,0`` bezeichnet und können nicht unterschieden und damit nur schwer ihrer Managementobjekt-Klasse zugeordnet werden. Aus diesen Gründen wurden die übersetzten OSI-MIBs dahingehend verändert, daß dieser RDN als ,, GraphicString`` definiert und ihm der OSI-Klassenname zugewiesen wurde. Damit ist nun eine sofortige Unterscheidung der Instanzen und eine Zuordnung zu ihrer jeweiligen Managementobjekt-Klasse möglich.

Weiterhin wird im Übersetzungsalgorithmus in Abschnitt 3.1.1 definiert, daß der RDN einer Instanz einer OSI-Klasse, die eine SNMP-Tabellenzeile repräsentiert, sich aus dem Index dieser SNMP-Tabellenzeile zusammensetzt. So wird zum Beispiel für die SNMP-Tabelle ,,tcpConnTable`` der Index für eine Tabellenzeile dieser Tabelle aus den folgenden vier SNMP-Variablen gebildet:

INDEX { tcpConnLocalAddress, tcpConnLocalPort,
        tcpConnRemAddress, tcpConnRemPort }

Der Übersetzungsalgorithmus bildet daraus einen ASN.1 Datentyp für das Naming Attribut der OSI-Klasse ,,tcpConnEntry``, die eine Tabellenzeile dieser SNMP-Tabelle ,,tcpConnTable`` repräsentieren soll :

TcpConnEntryIdValue ::=
        SEQUENCE {
                tcpConnLocalAddress   [1] IpAddress,
                tcpConnLocalPort      [2] Integer64k,
                tcpConnRemoteAddress  [3] IpAddress,
                tcpConnRemotePort     [4] Integer64k
        }

Um nun eine Instanz der Klasse ,,tcpConnEntry`` kreieren zu können, muß der RDN dieser Instanz festgelegt werden. Dazu muß dieser ASN.1 Datentyp ( TcpConnEntryIdValue) auf eine C++-Datenstruktur abgebildet werden. Weiterhin werden für diese neue C++-Datenstruktur mindestens die Methoden Konstruktur bzw. Destruktor und ein Vergleichsoperator benötigt. Damit müßte nun für jede SNMP-Tabelle und somit für den, den INDEX repräsentierenden, ASN.1 Datentyp eine C++-Datenstruktur aufgebaut werden. Aufgrund der verschiedenen C++-Datenstrukturen folgt eine unterschiedliche Bearbeitung (Replikation) jeder SNMP-Tabelle.
Dies wurde bei dieser Implementierung vermieden: Die verschiedenen ASN.1 Datentypen für die jeweiligen Naming Attribute wurden alle zu einem GraphicString. Der Wert dieses GraphicStrings setzt sich nun aus der ,,dotted Notation`` des Indizes der SNMP-Tabellenzeilen zusammen, wobei folgenden Beispiel den Sachverhalt verdeulichen soll:


SNMP-OID von ,,tcpConnTable``: .1.3.6.1.2.6.13
SNMP-OID von ,,tcpConnEntry``: .1.3.6.1.2.6.13.1
SNMP-OID der ersten Tabellenspalte: .1.3.6.1.2.6.13.1.1

Eine GetNextRequest-PDU auf die OID .1.3.6.1.2.6.13.1 ergibt:
Unter anderem enthält die GetResponse-PDU auch den OID der ersten Tabellenzeile:
.1.3.6.1.2.13.1.1.{'dotted Notation' des Index}
Die ,,dotted Notation`` wird schließlich zum Inhalt des Naming Attributs.


Dies hat vor allem diesen Vorteil:
Dadurch, daß alle Naming Attribute vom gleichen Typ (GraphicString) sind und dieser einfach in C++ als Zeiger auf char dargestellt werden kann, ist die Kodierung für das Zusammensetzen des RDN für alle Naming Attribute gleich. Dies stellt eine enorme Vereinfachung der Implementierung dar und wurde deswegen auf diese Weise realisiert.