6.6 Erfahrungsbericht zur Implementierung

Zuletzt soll stichpunktartig über einige Erfahrungen berichtet werden, die bei der Implementierung des Prototypen gewonnen wurden.

• Generierung von IDL-Dateien aus StP
  • Um den etwas umständlichen Anmerkungsmechanismus zur Definition von eigenen IDL-Datentypen für Attribute einer Objektklasse in StP zu umgehen, kann folgendes Vorgehen gewählt werden: Alle Datentypen werden außerhalb von StP in einer globalen Datei types.idl definiert. Den von StP generierten IDL-Dateien wird ein entsprechendes Include-Statement hinzugefügt.
  • StP sollte Objektklassen innerhalb sog. OMT-Subsysteme auf IDL-Module abbilden. Dies würde zu einer besseren Gliederung der Klassen führen, da der IDL-Compiler die Objekte eines IDL-Moduls in einem Java-Package zusammenfaßt. Diese Abbildung funktioniert in der verwendeten Version von StP/OMT laut Aonix-Support nicht. Hier war ebenfalls ein manueller Workaround erforderlich.
• Implementierung des CORBA-Agenten
  • Aufgrund der Spezifika der Systeme ist eine Vererbung von Code und somit die Wiederverwendung für die Klassen des Objektmodells nur sehr eingeschränkt möglich. Im wesentlichen müssen die Klassen in den Blättern der Vererbungshierarchie jeweils neu implementiert werden, da die Ermittlung der gleichen Information für unterschiedliche Systeme auch unterschiedlich realisiert werden muß. Diese Probleme, die bereits von der Implementierung der SNMP-Subagenten für diverse UNIX-Derivate bekannt sind, übertragen sich somit auch auf die Klassen für den CORBA-Agenten. Keinesfalls darf aufgrund der plattformunabhängigen Programmiersprache Java auf die Plattformunabhängigkeit des Agenten geschlossen werden.
  • Die Wiederverwendung von C-Funktionen zur Ermittlung von Managementinformation durch das JNI funktioniert prinzipiell gut. Die Implementierung der Wrapper ist weit weniger aufwendig als eine Neuimplementierung der übernommenen Funktionalität. Als problematisch hat sich jedoch herausgestellt, daß die Modularität der C-Funktionen des bestehenden SNMP-Agenten nicht konsequent durchgehalten war. Die Verwendung der Funktionen über das JNI erfordert dann aber die Einbindung aller abhängigen Objekt-Files in die Bibliothek.
  • Relativ gut eignet sich die Methode, Managementinformation durch Ausführen von UNIX-Kommandos aus dem Agenten heraus zu ermitteln. Gerade AIX stellt eine Vielzahl von Administrationskommandos bereit. Dies vermindert auch den Wartungsaufwand des Agenten bei neuen Versionen des Betriebssystems, da die Systemkommandos meistens zumindest abwärtskompatibel sind.
  • Das Polling von Attributen oder Zuständen einer Ressource kann in Java sehr einfach über Threads innerhalb eines Agentenobjekts realisiert werden. Hierzu muß lediglich die Methode run() für das Java-Interface Runnable implementiert werden.
  • Das Push-Modell des CORBA Event-Services bietet eine sehr gute Basis für asynchrone Meldungen eines Agenten. Da sich Ereigniskanäle leicht hierarchisch anordnen lassen, sind CORBA-Objekte denkbar, die Funktionen zur Ereignisfilterung und -korrelation bereitstellen.
  • Die Code-Größe der Java-Objektklassen ist sehr gering. Sie liegt durchwegs unter 10 kB pro Klasse. Die Klassen des ORBs einschließlich der Services besitzen eine Gesamtgröße von ca. 2.5 MB.
  • Aussagen über die Performance des Agenten sind nur schwer zu treffen. Die Antwortzeit bei Abfragen über das Management-Applet war subjektiv als gut einzuschätzen. Genaue Messungen müßten zeigen, wieviel Zeit die Ausführung einer Anfrage durch den Agenten benötigt und wieviel Zeit auf den Kommunikationsmechanismus entfällt. Auch bei der Leistung der Java-VM sind in Zukunft noch erhebliche Verbesserungen zu erwarten.
  • Auch die Systembelastung durch den Agenten ist aus zwei Gründen schwer zu beurteilen. Einerseits konnte für den Prototypen nur ein Teil der Klassen des Objektmodells implementiert werden. Andererseits handelte es sich bei der Testmaschine für den Agenten um eine relativ leistungsfähige, zugleich aber wenig belastete Workstation.
• Implementierung des Management-Applet
  • Java-Applets stellen eine gute Möglichkeit dar, mit relativ geringen Aufwand eine plattformunabhängige Managementanwendung mit graphischer Benutzeroberfläche zu realisieren. Ein Manager kann somit praktisch von jedem Rechner im Intra- bzw. Internet auf die Agenten zugreifen. Sobald die gängigen Browser das JDK 1.1 unterstützen, können auch die erweiterten GUI-Funktionen des AWT und das neue Ereignismodell genutzt werden.
  • Für den Entwurf der Oberfläche sollte dringend ein leistungsfähiger GUI-Builder eingesetzt werden, um Zeit bei der Implementierung des Applet zu sparen. Ohne GUI-Builder entfiel ca. 50% des Zeitbedarfs pro implementierter Klasse des Modells auf das Applet.
  • Wie im letzten Abschnitt beschrieben, traten einige Probleme in Form von Security Exceptions innerhalb des Netscape-Browsers auf. Diese sind darauf zurückzuführen, daß das Produkt Visibroker for Java noch sehr jung ist. Auch der Versionskonflikt zwischen dem im Communicator integrierten ORB und dem der Entwicklungsumgebung trug hierzu bei.