7.2 Vorarbeiten

7.2.1 Entflechtung der Quellen

Abbildung 7.1: Oberstruktur im CVS-Repository

Zu Beginn der Implementierung wurden zunächst die Quelldateien des bisherigen MASA entflochten, da sich im gleichen Zweig des CVS-Repositories sowohl Klassen des Agentensystems, als auch Klassen spezifischer Agentengattungen befanden. Notwendig wurde dieser Schritt, um getrennte JAR-Distributionen der einzelnen Agenten nach Kap. 6.5.1 erstellen zu können.

Die sich daraus ergebende Oberstruktur im CVS-Repository ist in Abbildung 7.1 zu sehen:

system/:

Das Agentensystem mit Basis- und allgemeinen Hilfsklassen zur Agentenentwicklung

system_gui/:

Das AgentSystemApplet zur Steuerung des Agentensystems, sowie der ASManagementAgent, einem Hilfsagenten für Applets (siehe [Gerb 99]).

Webserver/:

Der Webserver Agent

Gleichzeitig wurde sowohl für das Agentensystem als auch für Agenten eine neue Produktionsumgebung entwickelt, die in Anhang A beschrieben wird. Für die Agenten Webserver und ASManagementAgent kommt diese neue Produktionsumgebung bereits zum Einsatz.

7.2.2 Portierung auf JDK 1.2 und Orbacus 3.1.2

Da für die Umsetzung des Implementierungskonzepts JDK 1.2 eine Grundvoraussetzung ist, wurden zunächst das Basissystem, sowie die Agenten Webserver und ASManagementAgent auf JDK 1.2 portiert. Dabei traten, durch die identische Sprachsyntax zum bisher verwendeten JDK 1.1.x, mit einer Ausnahme, keine größeren Probleme auf.

In JDK 1.2 ist die Methode stop() der Klasse java.lang.Thread als deprecated bezeichnet, d.h. sie sollte nicht mehr verwendet werden. Allerdings ist diese Methode essentiell für die Terminierung einer Agenteninstanz, konkret für das (zwangsweise) Anhalten eines Threads. Sun stellt momentan keine für MASA akzeptable Alternative für stop() bereit, weshalb diese Methode trotzdem weiterhin verwendet wird, bis ein entsprechender Ersatz durch eine spätere JDK-Version verfügbar ist.

Weiterhin wurde in diesem Schritt die alte CORBA-Entwicklungsumgebung Visibroker gegen Orbacus 3.1.2 ausgetauscht. Erheblich erleichtert wurde die gesamte Umstellung dabei durch die neue Produktionsumgebung.

7.2.3 Klassen für symbolische Konstanten

Während der Entflechtungsarbeiten fiel auf, daß einige Konstanten ``hart'' in die Quelltexte von Agenten bzw. des Agentensystems einkodiert waren. Um die Wartbarkeit der Quellen zu verbessern wurden deshalb neue Klassen angelegt, die ausschließlich Konstantendefinitionen^7.3 enthalten.

Die Klassen

• Klasse tools.AgentSystemType
• Klasse tools.LanguageID
• Klasse tools.SerializationID

enthalten Konstantendefinitionen des MASIF-Standards (vgl. [OMG 98-03-09]).

In der Klasse tools.GlobalConstants befinden sich MASA-spezifische Konstantendefinitionen wie z.B. der MASA-Versionsstring.

Für die CVS-Verzeichnisse system/ und system_gui/ wurden alle Quellen nach ```hartkodierten'' Konstanten durchsucht, und diese durch entsprechende symbolische Konstanten aus den beschriebenen Klassen ersetzt.

7.2.4 Hilfsmittel zur Fehlerausgabe

Abbildung 7.2: GUI des LoggerConfigAgent

Um eine Basis für einen generischen Logging-Mechanismus zu schaffen und die Fehlersuche während der Entwicklung zu erleichtern, wurde die sehr einfache Möglichkeit zu Fehlerausgabe in tools.Debug durch einen leistungsfähigeren Logging-Mechanismus ersetzt.

Dieser unterstützt nun, in Anlehnung an den syslog-Mechanismus von Unix-Systemen, verschiedene Quellen (Facilities) von Fehlerausgaben und unterschiedliche ``Dringlichkeiten'' (Levels). Weiterhin wird die automatische Ausgabe von java.lang.Trowable-Objekten unterstützt.

Die zur Verfügung stehenden Facilities sind in der Klasse tools.Debug in den Konstanten mit dem Präfix FACILITY_, die Levels in den Konstanten mit dem Präfix LEVEL_ definiert.

Zur Ausgabe von Fehler- bzw. Logmeldungen sind folgende Methoden definiert:

• logMessage( int inFacility, int inLevel, String[] inMessage)

• logMessage( int inFacility, int inLevel, String inMessage)

• logMessage( int inFacility, int inLevel, String[] inMessage, Throwable inException)

• logMessage( int inFacility, int inLevel, String inMessage, Throwable inException)

Daneben stehen, für Debug-Zwecke, die folgenden Methoden bereit:

• logEnvProps( int inFacility, int inLevel)

  Gibt die Belegung einiger Standard Java-Properties aus.

• logThreadGroup( int inFacility, int inLevel, ThreadGroup inTG)

  Gibt eine Übersicht aller Threads aus, die zur Thread Group inTG gehören.

Neben diesen Funktionen besteht mit dem neuen Logging-Mechanismus noch die Möglichkeit, die Ausgabe von Meldungen nach Facility und Level zu unterdrücken bzw. zu ermöglichen. Die Konfiguration erfolgt dabei über den LoggerConfigAgent. Am Applet des LoggerConfigAgent (Abbildung 7.2) läßt sich die Ausgabe von Facility/Level-Kombinationen einzeln steuern, sowie der Kopf, der zu jeder Meldung ausgegeben wird, konfigurieren.

7.2.5 Korrekturen an Orbacus/OrbacusSSL

An den Produkten Orbacus und OrbacusSSL waren einige Änderungen notwendig, um diese für die neue MASA-Implementierung verwenden zu können. Ursache hierfür waren Implementierungsmängel der jeweiligen Produkte, die sich erst im Laufe der Implementierung der erweiterten MASA-Version zeigten.

Die an Orbacus bzw. OrbacusSSL durchgeführten Änderungen liegen der MASA-Distribution in Form von Unix patch-Dateien bei.

7.2.5.1 Orbacus

Um den Naming Service von Orbacus über eine SSL-Verbindung ansprechen zu können, mußte die Quelldatei com/ooc/CosNaming/Server.java geringfügig modifiziert werden, damit der Naming Service selbst ein SSL-fähiges ORB-Objekt benutzt. Für den Event Service war eine entsprechende Modifikation nicht notwendig, da die zu verwendende ORB-Instanz nicht durch die Implementierung des Service selbst vorgeschrieben wird.

7.2.5.2 OrbacusSSL

An OrbacusSSL waren umfangreichere Änderungen notwendig. Da OrbacusSSL nur ein Zertifikat pro ORB-Instanz unterstützt, mußte in der MASA-Implementierung jeder Agenteninstanz, sowie dem Agentensystem selbst, eine eigene ORB-Instanz zugeteilt werden, damit diese ihre individuellen Zertifikate für die CORBA/SSL-Kommunikation benutzen können.

Dabei zeigte sich jedoch, daß das Attribut in OrbacusSSL, welches das zu verwendende Zertifikat referenziert, in der Quelldatei com/ooc/SSL/impl/SSLimpl.java als static deklariert war. Die Folge war, daß alle ORB-Instanzen das Zertifikat des zuletzt instanziierten ORB zur SSL-Kommunikation benutzen, womit OrbacusSSL in der vorliegenden Form für MASA unbrauchbar gewesen wäre. Durch Entfernen des static Modifikators und einigen weiteren Änderungen, die durch Seiteneffekte aus dem geänderten Attributmodifikator notwendig wurden, konnte dieses Manko jedoch behoben werden.

Weiterhin wurde im SSLCurrent-Objekt die Zertifikatkette des Kommunikationspartners in Form eines com.ooc.SSL.X509CertificateChain-Objekts geliefert. Dieses enthielt allerdings nur eine DN-Repräsentation der einzelnen Zertifikate und nicht die kompletten Zertifikate inklusive öffentlichem Schlüssel und X.509 Extensions. Somit wären Überprüfungen der Zertifikatkette auf ihre Integrität durch MASA ausgeschlossen gewesen. Deshalb wurde die Klasse com.ooc.SSL.IAIK.X509Certificate und die zugrundeliegende IDL-Definition um das Attribut rawIAIKCert erweitert, welches eine serialisierte Form des Java-Objekts com.IAIK.X509Certificate enthält.

Fußnoten

... Konstantendefinitionen^7.3

Es existieren zwar keine ``echten'' Konstanten in Java, eine Attributdeklaration mit public static final kann aber als äquivalent angesehen werden.