Es liegt nahe, das Gateway in verschiedene Komponenten, die jeweils eine bestimmte Aufgabe erfüllen, zu zerlegen. Die Moduln des Gateways sind in Abbildung 4.2 dargestellt. Sie werden in der folgenden Aufstellung beschrieben:
Die Schattenobjekte sind die Instanzen der IDL-Klassendefinitionen, die zu einer Agenten MIB gehören. Sie liegen auf dem Gateway. Der Manager greift auf die Schattenobjekte zu, indem er die Methoden der Schattenobjekte mittels CORBA-Requests aufruft. Die Schattenobjekte antworten ihrerseits mit CORBA-Responses. Prinzipiell kann der Manager über die statische und die dynamische Aufrufschnittstelle Methoden der Schattenobjekte aufrufen. Die statische Aufrufschnittstelle ist allerdings nicht geeignet, da dazu die Client-Stubs aus der IDL-Beschreibung der Schattenobjekte zu den Client-Programmen der Managementanwendung dazugebunden werden müssen. Jedesmal, wenn neue Schattenobjektklassen hinzukommen und verwendet werden sollen, muß die Managementanwendung also neu übersetzt werden, ganz abgesehen von der Vielzahl der Client-Stubs, die letztendlich zum Manager dazugebunden werden müssen.
Für die dynamische Aufrufschnittstelle benötigt die Managementanwendung Objektreferenzen auf die Schattenobjekte, auf die zugegriffen werden soll. Solche Objektreferenzen werden dem Manager beispielsweise durch den Naming Service oder durch Events (etwa vom Gateway, wenn es ein Schattenobjekt erzeugt hat) zur Verfügung gestellt. Beim Methodenaufruf gibt der Manager in einem Request die Objektreferenz des adressierten Schattenobjektes, die aufzurufende Methode sowie dazugehörige Parameter an. Anhand der Objektreferenz lokalisiert der ORB das Schattenobjekt und ruft dort die gewünschte Methode auf. Die Requests werden immer genau an das Schattenobjekt weitergeleitet, das als Ziel angegeben wurde. Der ORB unterstützt nicht die Möglichkeit, beispielsweise einen Request für Objekt X an ein Objekt Y weiterzugeben, das die Aufgaben von X übernimmt.
Die von einem Sprachcompiler erzeugten
IDL-Klassendefinitionen einer Agenten-MIB werden
in das Interface Repository des ORB eingetragen
(Abb. 4.3), also nicht direkt in die
CORBA-Managementanwendung, wie es bei SNMP-Managern und
SNMP-Plattformen notwendig ist. Für jede neu hinzukommende
oder geänderte Agenten-MIB wiederholt sich dieser Vorgang.
Der snmpserver ist die Komponente für die Kommunikation mit der SNMP-Umgebung. Hauptaufgabe des snmpserver ist das Senden von SNMP-PDUs und das Empfangen der dazugehörigen Response-PDUs. Außerdem muß der snmpserver u. U. Response-PDUs (bzw. deren Inhalt) auf Schattenobjekte verteilen.
Der snmptrapd ist jenes Modul des Gateways, welche SNMP-Trap-PDUs von Agenten empfängt. Seine Aufgabe besteht darin, diese Traps auf CORBA-Events abzubilden. Zusammen mit dem snmpserver bildet der snmptrapd den in Abbildung 4.1 dargestellten SNMP-Manager. Die Komponente snmptrapd wird im Abschnitt 4.5 ausführlich behandelt.
Ein weiteres Gateway-Modul ist der Discovery-Dämon. Es soll zuständig sein für die Erfassung der einzelnen SNMP-Agenten im Internet (z. B. durch ein SNMP-Walk). Diese Komponente ist demzufolge auch zuständig für die Erzeugung von Schattenobjekten.
In den nun folgenden Abschnitten wird diskutiert, wie diese Komponenten kombiniert werden können. Die unterschiedlichen Varianten werden in Hinsicht auf Realisierbarkeit und Eignung bewertet, sodaß insgesamt ein Gateway entsteht, das die oben besprochenen Anforderungen erfüllt. In Kapitel 5 wird beschrieben, welche Möglichkeiten und Einschränkungen die Entwicklungsumgebung SOM/DSOM hat, um das entstandene Konzept zu implementieren.
