next up previous
Next: Zusammenfassung und Ausblick Up: Implementierung multiarchitektureller Agenten Previous: Transformation von SNMP-MIBs in

Überführung bereits existierender Managementfunktionalität

 Nachdem die Beschreibung der Objektklassen mit ihren Attributen und Methoden erzeugt wurde, muß nun in einem zweiten Schritt die Umsetzung der Funktionalität erfolgen, die die Nutzung der Managementinformation erst ermöglicht. Der zu erweiternde Agent soll sowohl weiterhin unter SNMP genutzt werden als auch von einem CORBA-konformen Managementsystem aus zugreifbar sein.

Dies ist gleichbedeutend mit der in zahlreichen Bereichen der Informatik auftretenden Fragestellung, wie bestehende Altsysteme (legacy systems) schonend in die objektorientierte Welt migriert werden können. Zentraler Gedanke ist hierbei, unter Zuhilfenahme sogenannter Wrapper bestehenden Code geeignet in Objektklassen zu kapseln und somit für neue objektorientierte Systeme zugreifbar zu machen. Der betrachtete SNMP-Agent ist in der Programmiersprache C implementiert worden und genügt damit keinesfalls objektorientierten Prinzipien. Dies ist jedoch für die Migration ohne Bedeutung, da für objektorientierte Applikationen der Begriff des ,,Perception is reality`` gilt. Es ist also nicht erforderlich, daß ein System objektorientiert implementiert worden ist; maßgeblich ist jedoch, daß seine Bestandteile wie Objekte aussehen.

Sehr wichtige Voraussetzungen für eine Kapselung in hinreichend feiner Granularität sind, daß das zu migrierende System einerseits genügend modular implementiert worden ist und andererseits die Schnittstellen seiner Prozeduren offengelegt sind bzw. die Prozeduren im Quellcode vorliegen. Beides ist in unserem Fall gegeben: Jede MIB-Variable ist in einem eigenen Modul implementiert worden und verfügt über eine bzw. zwei Schnittstellen je nachdem, ob auf die Variable nur lesend oder auch schreibend zugegriffen werden kann. Die ausschließlich lesbare MIB-Variable sysName wird durch Aufruf der Prozedur get_sysName ermittelt; eine schreib- und lesbare Variable wie sysLocation wird durch die Prozeduren get_sysLocation und set_sysLocation implementiert.

Wir sind daher folgendermaßen vorgegangen: Die IDL-Schnittstellenbeschreibungen, die durch die in Teilabschnitt 4.1 erläuterten Umsetzungen erhalten wurden, werden nun einem IDL-Compiler übergeben, der einerseits die Schnittstellen der neu erstellten Objektklassen (hier: die Wrapper für die bereits bestehenden Prozeduren) innerhalb des ORB-Laufzeitsystems bekanntmacht und andererseits die Datenstrukturen und Schnittstellen des CORBA-Agenten in einer herkömmlichen Programmiersprache (im betrachteten Fall: C) generiert.

Die so entstandenen C-Programmrümpfe des CORBA-Agenten können nun um die entsprechenden Aufrufe von Prozeduren des bestehenden SNMP-Agenten ergänzt werden, deren Aufgabe lediglich darin besteht, die erhaltenen Parameter auf die Parameter der bestehenden Agentenprozeduren abzubilden und anschließend diese Prozeduren aufzurufen. Hierbei ist es von großem Vorteil, daß der Agent modular aufgebaut ist und die Schnittstellen des Agenten sowohl zu den Ressourcen als auch zum Managementprotokoll hin klar definiert sind. Nach Abschluß dieser Arbeiten ist der bestehende SNMP-Agent um eine CORBA-Schnittstelle erweitert; der entstandene multiarchitekturelle Agent kann nun sowohl unter SNMP als auch unter CORBA genutzt werden.

In den von uns durchgeführten Arbeiten konnte die Erfahrung gewonnen werden, daß sich der Aufwand für die Kapselung des bestehenden Programmcodes durch die neu entwickelten Schnittstellen dank der modularen Implementierung des SNMP-Agenten in sehr engen Grenzen hält: Die vollständige Kapselung des Agenten, dessen MIB aus insgesamt 165 Variablen und 15 Tabellen besteht, wurde innerhalb einer Mannwoche durchgeführt.

Zur Performance des Systems ist folgendes anzumerken: Da der Zugriff über die SNMP-Schnittstelle unverändert geblieben ist, ergibt sich unter dem SNMP-Gesichtspunkt verständlicherweise keinerlei Veränderung zum vorherigen Stand; CORBA-seitig sind insbesondere beim Transfer größerer Datenmengen, wie sie z.B. beim Auslesen der Prozeßtabelle anfallen, signifikante architekturbedingte Performancevorteile ersichtlich. Diese werden jedoch durch Unzulänglichkeiten der momentan verfügbaren CORBA-Implementierungen kompensiert, im Falle einfacher skalarer Variablen sogar (leider) überkompensiert. Die architekturbedingten Performancevorteile liegen darin begründet, daß das unter SNMP sehr ineffiziente Durchlaufen von Tabellen mit dem get-next-Operator entfällt. Die Unzulänglichkeiten der CORBA-Toolkits beruhen auf der Implementierung des Interface Repository in Form einfacher Dateien, deren Verzeichnisse von den Maschinen, auf denen der Object Request Broker läuft, wechselseitig über das Network File System exportiert bzw. gemountet werden müssen.

Es handelt sich hierbei jedoch um ,,Kinderkrankheiten``, mit denen neue Systeme zwangsläufig behaftet sind und an deren Behebung die Hersteller arbeiten; zukünftige CORBA-Implementierungen werden andere Verfahren nutzen, um den Zugriff auf verteilte Daten effizient handhaben zu können.

Insgesamt konnte die prinzipielle Eignung von CORBA für die Belange des Systemmanagements nachgewiesen werden, da das zugrundeliegende Objektmodell die Möglichkeit bietet, Klassen von Managementobjekten sowie deren Attribute und Methoden eleganter und intuitiver zu implementieren, als dies unter der Internet-Managementarchitektur möglich ist. Die Migration vorhandener, modular aufgebauter SNMP-Agenten ist unproblematisch, sofern die Schnittstellen der Agentenprozeduren offengelegt sind.


next up previous
Next: Zusammenfassung und Ausblick Up: Implementierung multiarchitektureller Agenten Previous: Transformation von SNMP-MIBs in
Copyright Munich Network Management Team