Beschreibung der Testumgebung für den Prototypen

 

 

Abbildung:  Testumgebung für den Prototypen

67#67

In diesem Abschnitt wird die Laufzeitumgebung des Prototyen, d.h. des CORBA-Agenten und des Management-Applet, beschrieben. Die Testumgebung ist in Abbildung 6.21 dargestellt. Für den CORBA-Agenten wurden einige Klassen des Objektmodells aus Kapitel 4 in Java implementiert, so daß die Tragfähigkeit der Realisierung demonstriert werden kann. Die Agentenobjekte ermitteln die Managementinformation zum Teil über AIX-spezifische UNIX-Kommandos oder durch Einbinden von C-Funktionen der AIX-Portierung eines SNMP-Agenten über das JNI. Daher ist der Agent trotz Implementierung in Java nur für IBM-Rechner unter AIX funktionsfähig. Zum Testen des Prototyps stand die Workstation ibmhegering1 unter AIX 4.2 zur Verfügung. Auf der Maschine war das IBM JDK 1.1.3 installiert. Das Server-Programm, welches die Agentenobjekte initialisiert, kann über das Kommando vbj SystemAgentServer gestartet werden.

Zur Lokalisierung der Agentenobjekte wird der VisiBroker Smart Agent verwendet (siehe Abschnitt 6.4.1). Dieser ist nur unter Solaris lauffähig. Für die Tests wurde er auf der Maschine sunhegering2 mit dem Kommando osagent [-v] [&] gestartet. Der Parameter «-v» veranlaßt die Ausgabe von Debug-Meldungen.

Das Management-Applet läuft innerhalb des Web-Browsers in einer abgeschotteten Umgebung (sandbox). Diese verbietet u.a. die Errichtung jeglicher Kommunikationsverbindungen zu Rechnern mit Ausnahme des Web-Servers, von dem das Applet geladen wurde. Der Visigenic Gatekeeper ermöglicht es, diese Beschränkung für die Kommunikation über CORBA zu umgehen. Wenn das Applet versucht, ein entferntes Objekt zu binden, tritt innerhalb der Java-VM eine Ausnahme (security exception) auf. Der Teil des ORBs innerhalb des Applet fängt diese Ausnahme auf und leitet die Anforderung an den Gatekeeper weiter. Dieser muß auf der Maschine gestartet sein, die auch den Web-Server enthält, damit diese Kommunikation erlaubt ist. Der Gatekeeper lokalisiert über den Smart Agent das betreffende Agentenobjekt und richtet bei sich ein entsprechendes Proxy-Objekt ein. Das Applet operiert von nun an auf dem Proxy-Objekt. Die Anfragen werden vom Gatekeeper jedoch an das eigentliche Agentenobjekt weitergeleitet. Der Gatekeeper muß sich im selben Subnetz wie der Smart Agent befinden. Außerdem besitzt er zwei weitere Funktionen. Für den Fall, daß sich zwischen Web-Browser mit dem Management-Applet und Web-Server ein Firewall befindet, der nur HTTP-Requests passieren läßt, unterstützt der Gatekeeper IIOP-Tunneling über HTTP. Darüber hinaus bietet der Gatekeeper auf dem Default-Port 15000 die Funktionalität eines Web-Servers. Da er aber komplett in Java implementiert ist, fällt die Leistung im Vergleich zu normalen Web-Servern schwach aus. Voraussetzung für den Betrieb des Gatekeepers ist das JDK 1.1.x und die Zugriffsmöglichkeit auf die VisiBroker-Klassen. Soll der Gatekeeper auch die Aufgabe des Web-Servers übernehmen, sollte er im gleichen Verzeichnis gestartet werden, das die Klassen des Applet enthält (CODEBASE). Er wird über das Kommando gatekeeper [-ORBdebug 1] aufgerufen. Auf allen drei bisher beschriebenen Rechnern müssen einige Umgebungsvariablen gesetzt sein (siehe Abschnitt 6.3.1 und Shellskript in Anhang B). Ebenfalls im Anhang B findet sich die HTML-Datei Manager.html, die der Rahmen für das Management-Applet ist. Die dort gesetzten Parameter sind zwingend für die Zusammenarbeit des Applet mit dem Gatekeeper erforderlich.

Das Management-Applet kann in jedem Java-fähigen (JDK 1.0.2) Web-Browser auf einem beliebigen Rechner aufgerufen werden. Der URL bei Benutzung des Gatekeepers als Web-Server lautet http://<gatekeeper-host>:15000/Management.html. Tabelle 6.2 enthält die Web-Browser, in denen das Applet erfolgreich getestet wurde. Hierbei wurde die Zusammenarbeit des Applet sowohl mit dem Gatekeeper als Web-Server als auch mit der Kombination Standard-Web-Server (httpd von IBM) und Gatekeeper überprüft.

   

Das Management-Applet verursachte zunächst zahlreiche Probleme (Sicherheitsverletzungen, Java-Runtime-Exceptions, etc.) innerhalb des Netscape Communicator, die im Appletviewer des JDK nicht auftraten. An dieser Stelle half auch die ansonsten recht gute Dokumentation zum VisiBroker nicht weiter. Zahlreiche Tests führten schließlich zur Lösung des Problems. Zum ersten sind die Parameter in der oben erwähnten HTML-Datei Manager.html äußerst wichtig. Zweitens darf die Umgebungsvariable CLASSPATH auf der Managementstation die VisiBroker-Klassen nicht enthalten, da der Browser sonst versucht, die ORB-Klassen lokal von der Festplatte zu laden, was wiederum zum Abbruch des Applet (security exception) führt. Drittens muß der Konfigurationsdatei des Communicators ($(HOME)/.netscape/preferences.js) folgender Eintrag hinzugefügt werden:

user_pref("security.lower_java_network_security_by_trusting_proxies", true);

Prinzipiell kann der ORB von Visigenic, den Netscape in seine Browser ab der Version 4.0 integriert hat, vom Management-Applet genutzt werden. Hierzu sind einige kleine Änderungen an der HTML-Datei nötig. Außerdem muß der Gatekeeper in einem speziellen Kompatibilitätsmodus gestartet werden (siehe [Vis97a]). In diesem Fall müssen die ORB-Klassen, die als Jar-Archiv immerhin eine Größe von über zwei Megabyte besitzen, nicht vom Web-Server über das Netz geladen werden. Das Problem hierbei ist, daß der ORB im Communicator in der ,,alten`` Version 2.5 vorliegt. Der CORBA Event-Service von Visigenic funktioniert aber erst ab Version 3.0 des ORB. Weiterhin plante Netscape sowohl den ORB als auch die Technologie des Gatekeeper in ihre Web-Server zu integrieren. Es ist zu hoffen, daß die Produkte in Zukunft besser aufeinander abgestimmt werden. Die Integrationen könnten in diesem Fall die Ausführungsgeschwindigkeit des Management-Applet erheblich verbessern.