Reintegration von Client- und Server- Seite der Booster- Entwicklungsumgebung

Transkript

1 Reintegration von Client- und Server- Seite der Booster- Entwicklungsumgebung Projektarbeit von Jorg Rech September AG System Software Fachbereich Informatik Universität Kaiserslautern Ausgegeben von : Prof Dr. rer. nat, Jurgen Nehmer Betreut von: Dip/.-lnform. Lothar Baum

2

3 Zusammenfassung Diese Ausarbeitung beschäftigt sich mit der Vervollständigung und Erweiterung von Booster, eines graphischen Systems zur Unterstützung und Managemen t global verteilter So ffwareprodukte. Durch die Wiedereinführung des Kommunikationssystems Boosterlnfluencer sowie einer neu entstandenen Zustandskontrolle ist es nun möglich, kooperativ an einem Soffwareprojekt zu arbeiten, ohne dabei beim Zugriff auf Resourcen zu konkurieren. In dieser Ausarbeitung werden die Änderungen an dem bisherigen System aufgezeigt und der neue Aufbau von Booster beschrieben.

4 lnhaltsverzeichnis Inhaltsverzeichnis Vorwort 5 Kapitel 1 : Einleitung 7 Grundlagen,.,,. ~.. o ~ ~ ~ ~ o. ~ ~ ~ ~ ~ ~ ~,,.,.. 7. ~... ~ Der Aufbau des Booster-Systems., ,,,,,..,,.,,,.,,,,..,,,,,,,,9 Kapitel 2: Die Änderungen am BoosterGUl 10 Änderungen an den lassen ~llgemeine Änderungen am ~ooster~~l., Neuerungen im BoosterGUl,,,,,,,,.,,,...,,,.,,,,,,,.,,.,,,,.,,,,, 14 Kapitel 3: Die Änderungen am BoosterServer 15 Änderungen an den lassen ,.,.,,...,.,,.,.,,.,..,,,,.,.. 15 Neuerungen im BoosterServer,.,,,..,,.,,,.,.,,,,,.,,,,,,,,,.,,.,,. 16 Ka~itel4: Der Boosterlnfluencer 17 Der Aufbau des Boosterlnfluencers,,,.,..,,,,,.,,,,,,,..,,,,,,,,,.,, 17 Das Vorgehen des Boosterlnfluencers,..,,,,,,,,,,,.,,,,,,,,,.,,,.., 17 Kapitel 5: Zusammenfassung und Ausblick 19 Allgemeine Probleme des Booster-Systems,,,,,,,,,.,,,,,,.,.,,,,.,,, 1 9 Ideen für den Ausbau des Booster-Systems,...,..,,,,,,,.,,,.,,..,,,,20 Seite 111

5 Inhaltsverzeichnis Anhang A: Die Schlüsselwörter des BoosterServers 22 Die Kommandos des BoosterServers.. U,,,,,,,,,,.,,,,.,,.,,,,,22 Die bisher undokumentierten Kommandos,,,..,,,,,,,,,...,,,,,,.27 Die Signale zur Zustandsänderung,,, ,..,,,..,..,...,..,,,,,,29 Anhang B: lnstallationshinweise und FAQ 3 1 Installation eines BoosterGUl,,,.,,,,,,,,.,., ,.,.,,,..,,,...,34 Installation eines BoosterServer,,,,,.,.,,,,,,,,,,,,,,, ,,,,,..35 Installation des Boosterlnfluencer,,.,,,,., ,.,,,.,,,,,,,,, Anhang C: Terminologie und Abkürzungen 38 Literaturverzeichnis 42 Literatur uber Booster.,...,,.,.,,,.,.,,,,,,,,,..,,,,,,,,,,,, Literatur uber Java,,,,,.,.,......,....,,,,,,,,,.,,,,,,,..,...,,.,43 Tabellenverzeichnis 44 Abbildungsverzeichnis 45 lndexverzeichnis Seite /V

6 Vorwort Vorwort Durch die Entwicklung immer größerer und komplexerer Software Systeme sind die Anforderungen an einzelne Entwickler und Entwicklerteams immer mehr gestiegen. Nicht zuletzt wegen des Mangels an ausgereiften und umfassenden Werkzeugen zur Entwicklung von Software geriet die Software Branche immer weiter in eine Zustand, der nur mittels neuer Werkzeuge, Methoden und Techniken des Software Engineerings zu bewältigen ist. Aus dieser Problematik entstand die Idee eines Global Software Highway, der den Zugriff auf weltweit verteilte Softwarekomponenten und Klassenbibliotheken erlauben soll. Dieser Global Software Highway würde es ermöglichen, viele weltweit verteilte Entwickler an einem großen Softwareprojekt parallel arbeiten zu lassen, um so nicht nur Wissen und Ressourcen auszutauschen, sondern auch um ihre Arbeit effizienter koordinieren zu können. Nach der ersten Implementierung eines Prototyps dieses Global SoWare Highway Namens WebMake [5] entstand die verteile Software Entwicklungsumgebung Booster [4], die aus einer graphischen Benutzeroberfläche, sowie einem Server bestand. Eine wichtige Anforderung war dabei natürlich die Möglichkeit, die benötigten Ressourcen wie Quelltexte, Dokumentationen und Klassenbibliotheken global zu verteilen und diese über eine weltweit vorhandene Infrastruktur, in diesem Falle das Internet, zugänglich zu machen. Diese rudimentäre Software Entwicklungsumgebung (SEU), die als ClientIServer Applikation geplant und entwickelt wurde, ermöglicht es, große Softwaresysteme in kleinen Partitionen auf mehrere BoosterSewer im Internet zu verteilen und parallel bearbeiten zu lassen. Der Prototyp Webmake wurde bereits 1994 von der AG Systemsoftware an der Universität Kaiserslautern geplant und mittels der Programmiersprache C++ implementiert. Die Komponenten zur Verwaltung und Kommunikation dieses Systems wurden dabei ursprünglich als CGI Kommandos entwickelt, die die Befehle der Benutzer über die schon installierten Webserver direkt ausgeführen konnten. Um Booster schließlich unabhängiger von der verwendeten Rechnerplattform und Entwicklungsumgebung zu machen wurde Ende 1995 eine Konvertierung des C++ Codes nach Java beschlossen und im Juli 1996 durch Christof Baumgärtner vollendet [3]. Java wurde C++ deshalb vorgezogen, weil es neben der Objektorientierung und der Sicherheitskontrolle sehr leicht mit parallelen Threads umgehen kann und auf vielen Rechnerplattformen durch Entwicklungsumgebungen und Compiler unterstützt werden sollte. Die von Michael Junker erweiterte graphische Oberfläche BoosterGUI [2] und die von Andreas Goldschmidt reimplementierte Ressourcenverwaltung namens BoosterSewers [I] sind dann in den Jahren 1996 und 1997 er- Seite 5

7 Vorwort stellt worden. Aufgabe dieser Projektarbeit war es, diesen neuen BoosterGUI an den erweiterten Booster- Sewer anzupassen, so daß dieser alle zur Verfügung gestellten Kommandos unterstützt und sich der neuen Kommandoschnittstellen bedient. Außerdem sollte der sogen. Influencer" von Booster in Java reimplementiert werden, um wieder die Kommunikation mehrerer BoosterGUIs und BoosterServer zu ermöglichen. Diese Kommunikation wurde noch um die Zustandskontrolle der Knotendateien, d.h. der Ressourcen, erweitert, die nun dafür sorgt, daß Knoten nicht mehr an mehreren BoosterGUIs zur Bearbeitung vergeben werden können. Das erste Kapitel beschreibt die Grundlagen und Funktionen von Booster und geht etwas näher auf die Kommunikation der einzelnen Komponenten von Booster ein. Anschließend wird in Kapitel 2 erklärt, welche Änderungen am BoosterGUI vorgenommen wurden, um die Zusammenarbeit mit dem BoosterSewer wieder zu gewährleisten. Kapitel 3 beschäftigt sich dann mit den Änderungen im BoosterSewer, sowie einigen seiner Neuerungen wie das Zustandsmanagement der Knotendateien. Danach wird in Kapitel 4 der Aufbau und die Funktionsweise des neue BoosterInfluencer beschrieben. Im letzten Kapitel werden momentan existierenden Probleme von Booster behandelt, sowie Anregungen für den weiteren Ausbau von Booster gegeben. Die Anhänge beschäftigen sich mit den Kommandobefehlen des BoosterSenlers, einigen Installationshinweisen für die Komponenten von Booster, sowie mit der in der Ausarbeitung verwendeten Terminologie bzw. den benutzten Abkürzungen. - Seite 6

8 Einleitung Kapitel 1 Einleitung Booster ist eine verteilte Software Entwicklungsumgebung, durch die die Arbeit mehrerer geographisch getrennter Entwickler, Analytiker und Designer ermöglicht und gefördert wird. Da das Booster-System auf einigen grundlegenden Konzepten und Modellen der Informatik beruht, sollen diese hier noch einmal kurz vorgestellt werden. Außerdem wird ein Überblick über den strukturellen Aufbau des Booster-Systems vermittelt, wodurch das Zusammenspiel der einzelnen Komponenten von Booster verdeutlicht werden soll. 1.1 Grundlagen Vernetzte Rechnersysteme ersetzen zunehmend die bislang eingesetzen zentralen Großrechnersysteme, da mit ihnen oft die gleiche Rechenleistung mit weniger Resourcen erzielt werden kann. Besonders die auf sie zugeschnittenen verteilen Anwendungen können diese Rechenleistung effizient Ausnutzen und ermöglichen es den Anwendern, je nach Ausdehnung des Rechnernetzes, an beliebigen Orten zu arbeiten, sowie ihr Wissen und ihre Produkte zu teilen. Obwohl das ClientIServer Modell nicht von verteilten Systemen abhängig ist, da es mittels mehrerer Threads auf einem einzelnen Rechner implementierbar ist, kann es diese Zentralisierung ausnutzen, um auf einigen wenigen Rechnern mittels Serverprozessen die Ressourcen und Werkzeuge eines Systems den Benutzern (Klienten) bzw. den entsprechenden Clientprozessen anzubieten. Die Clientprozesse stellen dabei die Schnittstelle zwischen den Benutzern und den eigentlichen Werkzeugen, z.b. Compiler, in den Servern dar, sie bieten aber teilweise auch kleinere Hilfsmittel an, um die Resourcen zu bearbeiten. Der Serverprozess hat dagegen nur die Aufgabe die Aufträge der Clientprozesse anzunehemen, und sie mit Hilfe seiner Werkzeuge, meist in einem eigenen Prozeß (sog. Childprozesse/Kindprozesse), abzuarbeiten. Er kann aber, falls sich der Auftrag mit einem bereits laufendem überschneidet, diesen Auftrag ignorieren oder die Herausgabe von Ressourcen verweigern. Diese Prozesse werden im Booster-System durch das BoosterGUI (Clientprozeß) und den BoosterServer (Serverprozeß) übernommen. Der BoosterInfluencer wirkt dabei als Manager, der die Klienten registriert und als,,kornrnunikationsleitung" zwischen BoosterServer und BoosterGUI fungiert. Um Ressourcen im Booster-System darzustellen, werden sogenannte Knoten (Nodes) und Kanten (Edges) benutzt. Ein Knoten stellt dabei entweder eine atomare Informationseinheit Seite 7

9 Einleitung ( Des cr ip t i on Nodes ) wie einen Quelltext dar, oder verweist auf mehrere andere Knoten ( S truc tural Nodes ). Die bündelnden Knoten können entweder eine besondere Sicht auf andere Knoten darstellen (Vi ew Node ) oder zusammengehörende Knoten verbinden ( C lus ter Node). So bündelt z.b. ein PROGRAMCLUSTERNODE die Knoten der von ihm benötigten Objekte und Bibliotheken, die der Compiler zum Erzeugen des Programmes benötigt, und verweist auf das ausführbare Programm, die Dokumentationsdatei, sowie auf die Datei mit den Ausgaben des Compilers (d.h. den Fehlermeldungen). Die im Booster-System verwendete Struktur dieser Knoten ist in Abbildung 1 "Klassenhierarchie der Knoten in Booster'' mittels der Klassendiagramme von Booch [7] genauer dargestellt. 'Abbildung 1 : Klassenhierarchie der Knoten in Booster Die hellgrau dargestellten Klassen bzw. Knoten wurden im Booster-System bereits eingearbeitet und stehen dem Benutzer zur Verfügung. Klassen mit einem weißen Hintergrund sind momentan noch nicht implementiert. Die dunkelgrauen Klassen existieren entweder nur im BoosterServer oder nur im BoosterGUI. So finden die Klassen MakeableC lus t ernode, ObjectNode, ExecutableNode, LibraryNode, ErrorNode und Workspace- ViewNode nur im BoosterServer Verwendung. Die Klassen ExternDescript ionnode, TextDescript ionnode, ToolNode und ToolClus ternode werden dagegen nur im BoosterGUI verwendet. Ein weiterer wichtiger Grund für die Mächtigkeit und Portabilität von Booster ist die verwendete Java-Technology. Java ist eigentlich nur eine objekt-orientierte Programmiersprache, die Anfang der 90er Jahre von Sun Microsystems mit dem Ziel entwickelt wurde, kleine Elektrogeräte mit unterschiedlicher Hardware zu programmieren. Daraus entwickelte sich eine der heutzutage wichtigsten Programmiersprachen im Internet, die es durch Ihren Aufbau, insbesondere durch den verwendeten Bytecode, erlaubt, ein Java-Programm auf einem beliebigen Rechner auszuführen, auf dem eine entsprechende Virtual Machine existiert. Die momentan erstellte Version von Booster basiert auf Java 1.1, wobei aber noch einige alte Funktionen von Java 1.0 benutzt werden. Diese sogennanten Deprecated Functions sollen in zukünftigen Java Versionen nicht mehr existieren, können aber in Java 1.1 nur sehr kompliziert nachgebaut werden und wurden deshalb momentan noch so beibehalten, wie sie sind. Seite 8

10 Einleitung 1.2 Der Aufbau des Booster-Systems Booster besteht aus drei Komponenten: der graphischen Oberfläche genannt BoosterGUI, die die Bedienung durch den Entwickler ermöglicht, dem BoosterServer, der den Zugang zu den Resourcen und Compilern bietet, sowie dem BoosterInfluencer, der für die Vermittlung der Zustandssignale zwischen den beiden vorherigen Komponenten zuständig ist. Der BoosterInfluencer und das BoosterGUI wurden als eigenständige Programme implementiert, der BoosterServer basiert auf einem Java-WebServer nahmens Jigsaw. Abbildung 2 "Der Aufbau des Booster Systems'' zeigt den Datenfluß zwischen zwei BoosterGUIs, zwei BoosterServern und einem BoosterInfluencer. Die beiden BoosterGUI haben sich dabei beim BoosterInfluencer angemeldet (1) und erhalten über diesen Kanal bei Zustandsänderungen Mitteilungen (5) von den BoosterServern. Wird vom BoosterGUI ein Befehl an einen BoosterServer gesendet (2), so wird dieser durch den Jigsaw-Webserver empfangen und an den Requesthandler des BoosterServer übermittelt. Dazu wird beim Starten des BoosterServers der RequestHandler des Jigsaw durch den Requesthandler des WebMakeLinks (WML) und des CompileServerLinks (CSL) ersetzt. Dieser sendet dann entweder die angeforderten Daten bzw. eine Fehlermeldung an den Auftraggeber (der entsprechende Booster- GUI) (3a), oder übergibt den Auftrag an einen vorher festgelegten CompileServer (2b oder 2c). Ändert sich dabei der Zustand eines Knotens, d.h. die Möglichkeiten zur Bearbeitung ändern sich, so wird ein Signal (4) über den BoosterInfluencer an alle angemeldeten BoosterGUI's (5) übermittelt, die daraufhin überprüfen, ob sie diesen Knoten anzeigen und dementsprechend den internen Zustand sowie die Darstellung dieses Knotens ändern müssen. Die genaue Vorgehensweise des BoosterServer wird in der Ausarbeitung von Andreas Goldschmidt [I] näher beschrieben, die des BoosterGUI in der Ausarbeitung von Michael Junker [2]. Abbi'ldung 2: Der Aufbau des Booster Systems Seite 9

11 Die Änderungen am BoosferGUl Kapitel 2 Die Änderungen am BoosterGUl BoosterGUI ist eine graphische Oberfläche, die es dem Benutzer erlaubt, die Funktionalität des Booster-Systems zu nutzen. Sie dient der Darstellung von Knoten und Abhängigkeiten in einem Softwaresystem, sowie der Ansteuerung der BoosterServer und der Bearbeitung der meisten DESCRIPTION NODES. Im Laufe dieser Projektarbeit mußten hauptsächlich an den Sourcen des BoosterGUI Änderungen vorgenommen werden, da der neue BoosterServer mehrere neue, sowie modifizierte Kommandos anbietet, die bisher nur unzureichend unterstützt wurden. Unter anderem wurden im BoosterGUI mehrere Methoden geändert, neu hinzugefügt oder beseitigt, und die Vererbung der Methoden etwas geändert. Eine weitere kleine Modifikation besteht in den verbesserten und übersichtlicheren Ausgabetexten und Fehlermeldungen, die zuvor zu ausführlich und unübersichtlich dargestellt wurden. In diesem Kapitel werden nun neben den Änderungen an den einzelnen Packages auch die Neuerungen des BoosterGUI näher beschrieben. 2.1 Änderungen an den Klassen Die Knotenklassen des BoosterGUI wurden fast alle modifiziert, um die neuen Kommandos des BoosterServer eingehen zu können. Die neue Übergabeprozedur verlangt nun, daß das BoosterGUI ein Kommando an den BoosterServer schickt, ein Handshake austauscht, und möglicherweise Daten überträgt. Zu den strukturellen Änderungen innerhalb der Klassen zählt das Verlegen einiger Methoden aus der Unterklasse in die jeweilige Oberklasse. Diese Umstrukturierungen wurden haupsächlich durch einzelne Änderungen und Vereinigungen einiger Kommandos im BoosterServer ermöglicht und haben den Vorteil, daß Änderungen einiger Methoden im BoosterGUI nur noch in einer einzigen Klasse vorgenommen werden müssen. Desweiteren sind durch diese Umverteilung einige Menüeinträge in die entsprechenden Oberklassen verlegt worden. Seife 70

12 Die Änderungen am BoosterGUl Änderungen in der Klasse ClusterNode ClusterNode ist eine Unterklasse von StrukturalNode und wird zum Bündeln mehrerer atomarer Knoten verwendet (s.a. Abbildung 1 "Klassenhierarchie der Knoten in Booster" ). Sie vereinigt einige elementare Methoden und Konstanten (z.b. Kommandonamen), die in Ihren Unterklassen benötigt werden. Folgende Änderungen wurden an dieser Klasse durchgeführt: Die Konstantendefinitionen der Zustandssignale (siehe 2.3 und 3.2.1) wurden in die Klasse ClusterNode integriert, um sie an einem zentralen Ort verwalten zu können. Die Methode INITIATEMAKE dient dazu, dem BoosterServer ein Kommando zum Übersetzen eines Knoten zu schicken. Sie ist von den Klassen ProgramClusterN~de, SubsystemClusterNode und SourceClusterNode in die Oberklasse ClusterNode verlegt worden, da der BoosterServer fiir das Übersetzen von Knoten nur noch das Kommando MakeClus ter unterstützt. Die Methode VIEWERRORS wird zum Anfordern der Ausgabe des Übersetzers1 Compilers verwendet. Sie ist von den Klassen ProgramClusterNode, Subsys temclus ternode sowie SourceClus ternode in die Oberklasse Clus ternode verlegt worden, da der BoosterServer nun das Kommando GetErrorFiie anbietet. Die Methode EDITOPTIONSON dient dazu, dem BoosterServer ein Kommando zum Ändern der Optionen des Übersetzers zu schicken. Sie ist von den Klassen ProgramClus ternode sowie SourceClus ternode in die Oberklasse ClusterNode verlegt worden, da der BoosterServer nun die Kommandos SetOpt ions und GetOpt ions anbietet. Vorher wurde diese Methode nicht in Subsys temc lus t ernode benötigt, kann nun aber dazu benutzt werden, dem hier verwendeten Linker (unter UNIX,,ld") weitere Optionen mitzugeben. Die Methode INITIATEDEPENDENCYCHECK wird zum Testen der Abhängigkeiten des Knotens verwendet. Sie ist von den Klassen Subsys temclus ter- Node sowie SourceClus ternode in die Oberklasse Clus ternode verlegt worden, da in den Unterklassen das gleiche Kommando CheckDependencies verwendet wurde. Leider wird dieses Kommando im Booster- Server für PROGRAMCLUSTERNODES sowie SUBSYSTEMCLUSTERNODES noch nicht unterstüzt. Außerdem sind die Menüeinträge der entsprechenden Methoden ebenfalls in die Oberklasse eingefügt worden Änderungen in der Klasse Node Node ist eine Oberklasse aller verwendeter Knotenklassen und wird zum Beschreiben und Erzeugen der atomaren Knotenstrukturen verwendet (s.a. Abbildung 1 "Klassenhierarchie der Knoten in Booster'' ). Sie vereinigt die elementaren Methoden und Konstanten, die in allen Knoten benötigt werden. Folgende Änderungen wurden an dieser Klasse durchgeführt: 1. Die Konstantendefinitionen der Kommandos des BoosterServers wurden von den einzelnen Unterklassen in die Klasse Node verlegt, um sie an einem zen- Seite 7 7

13 Die Änderungen am BoosterGUl tralen Ort verwalten zu können. 2. Es wurde eine neuen Schnittstelle für die Methode DISPLAY implementiert, die nun dafür sorgt, daß die Methode UPDATEICONMODE zum Erneuern des dargestellten Icons aufgerufen wird. Sie wird von der Klasse URLManagement verwendet, um bei Zustandsänderungen eines Knoten das Icon neu zu zeichnen. 3. Es wurde die Methode GETICONMODE implementiert, um zum den Zustandswerte eines spezifischen Icons und somit des Knotens zu ermitteln. 4. Die Methode SENDCOMMANDTOSERVER wurde implementiert, die dafür sorgt, daß dem BoosterServer das angegebene Kommando zugeschickt und dessen Quitierung angenommen wird. Das zurückgegebene URLIOS tream Objekt kann nun dazu verwendet werden, angeforderte Daten zu lesen. Die ebenfalls neue Methode GETNODEFROMSERVER ist eine Spezialisierung der vorherigen mit dem fest vorgegebenen Kommando GET-NODE. 5. Die Methode CALL~NFLUENCER wurde aus der Klasse Node entfernt, da die Weitergabe des Zustandes eines Knotens vom verwaltenden BoosterServer übernommen wird Änderungen in der Klasse URLIOStream Die Klasse URLIOStream wurde aus Performancegründen so umgebaut, daß sie nicht mehr wie bisher mit den zwei Threadklassen für die Ein- und Ausgabe der Daten arbeitet (UR- LIThread und URLOThread in der Ausarbeitung von Christof Baumgärtner [3] auf Seite 34 bis 37), sondern die Daten nur noch direkt übermittelt. In Abbildung 3 "UIOStream Vorher, Nachher'' werden die beiden Vorgehensweisen verdeutlicht um bei späteren Implementierungen von Booster, die auf schnelleren Systemen arbeiten, die Umstellung auf das ältere und möglicherweise sicherere Modell zu erleichtern. Warum das alte Modell mit zwei eigenen Threads implementiert wurde konnte nicht mehr nachvollzogen werden. Socket Socket I URLIOStream Methoden URLIOStream Methoden Seite 72

14 Die Änderunaen am BoosterGUl Abbildung 3: UIOStream Vorher, Nachher Änderungen in verschiedenen einzelnen Klassen In der Klasse Ca1 1backHandler wurde die Methode RECONNECTTOINFLUENCER eingefügt, die dafür zuständig ist, daß das BoosterGUI beim Abbruch der Verbindung zum Booster- Influencer alle 5 Sekunden versucht, die Verbindung neu aufzubauen. Vorher wurde nach einem mißglückten Anmeldeversuch beim BoosterInfluencer oder dem erfolglosen Laden der Konfigurationsdatei vom BoosterServer der Startvorgang des BoosterGUIs abgebrochen. Ein weiterer Vorteil dieser automatischen Wiederverbindung ist, daß zur Laufzeit des BoosterGUI der BoosterInfluencer unterbrochen werden kann, ohne daß das BoosterGUI neu gestarten werden müßte. In der Klasse Conf igurationmanager wird deshalb beim Anfordern der Konfiguationsdatei auf die Verbindung zum BoosterServer gewartet, bis dieser gestartet wurde und die Datei liefert. Der zu verwendende Editor und andere Konfigurationseinstellungen, die bislang mittels des Schlüsselworts EDITOR. SOLARIS aus der Konfigurationsdatei gelesen wurden, sind jetzt auf beliebige Plattformen angepaßt. Dies wird durch die Verwendung der Umgebungsvariable OS. NAME erreicht, mit welcher die plattformspezifischen Definitionen in der Konfigurationsdatei ausgelesen werden. 2.2 Allgemeine Änderungen am BoosterGUl Im BoosterGUI wurden auch einige Änderungen vorgenommen, die nicht auf eine Klasse beschränkt sind. Unter anderem wurde der Quelltext und die Ausgaben des Zustandes sowie die der Fehlermeldungen durch eine einheitlichere Formatierung optisch aufgebessert. Zu den wichtigeren Änderungen zählen folgende Punkte: Da von nun an der BoosterServer über die Zustände seiner Knotendateien bescheid wissen sollte, sind fast alle URLIS tream Objekte zu URLIOS tream Objekten umgewandelt worden. Die Klasse URLIStream schickte bisher Anfragen direkt an den Jigsaw Server und umging somit den BoosterServer, der neben der Zustandskontolle auch noch bei jedem neuen Auftrag eine Quittung in Form eines,,okcc oder,,error NR. zurücksendet. Diese Quittungen werden nun erkannt und im Falle eines Fehlers inklusive der Fehlermeldung ausgegeben. Bei Auftägen oder Anfragen an den BoosterServer werden jetzt nur noch die Kommandos des BoosterServer verwendet. So wurden in der Klasse S ourc ec lus t ernode die Methoden TOUCHSOURCE und TOUCHHEADER von einer umständlichen BoosterGUI-basierenden Datumserneuemng auf die Benutzung des Kommandos TouchSource bzw. TouchHeader umgestellt. Ausserdem ist die Methode ViewError auf GetErrorFile und CLO- NENODEON auf das Kommando CreateNode umgestellt worden. Um auf die erweiterte Zustandssignale eingehen zu können, wurde die Methoden CALLBACK in den Klassen SubSys t emc lus t ernode, Program- ClusterNode und SourceClusterNode an die neuen Gegebenheiten angepaßt. Um die immer wiederkehrenden Kodefragmente zum Ansprechen des BoosterServers zu zentralisieren, wurden die Methoden GETNODEFROMSERVER und Seite 73

15 Die Änderungen am BoosferGUl SENDCOMMANDTOSERVER in die Klasse Node eingefügt. Diese Methoden werden überall dort verwendet, wo das BoosterGUI einen Auftrag an einen Boosterserver schicken muß. 5. Da in einigen Klassen eine Kante zu der Ausgabedatei fehlte, wurde diese eingerichtet und die Methoden PARSEINPUTLINE in den Klassen SubSys tem- ClusterNode, ProgramClusterNode und SourceClusterNode, an die modifizierten Knotenstruktur angepasst. 2.3 Neuerungen im BoosterGUl Durch die Einführung der Zustandskontrolle im BoosterServer haben sich auch einige Neuerungen im BoosterGUI ergeben. So werden die Zustände der Knoten in mehreren Farben je nach Priorität dargestellt, wobei z.b. das Editieren des Sourcecodes die höchste Priorität hat. Diese Zustände werden im BoosterServer, der den Knoten verwaltet, gespeichert und durch die Aktionen des BoosterGUI gesetzt bzw. gelöscht. Der Weg dieser Signale im BoosterGUI führt zuerst durch den Ca1 IbackHander, der das Signal vom BoosterInfluencer erhält und ermittelt, ob es in seiner Knotenliste enthalten ist. Ist dies der Fall, so wird die spezifische CALLBACK Methode des Knotens aufgerufen, die den Zustand aus dem Signal ließt und die Darstellung des Knotens mittels der Methode UPDATE~CON- MODE ändert. Ist ein neues Signal vom BoosterServer an einen BoosterGUI gemeldet worden, so werden alle Menüeinträge, die davon betroffen sind, gesperrt, bis der Zustand wieder zurückgesetzt wird. Sperrt z.b. ein EDIT-SOURCE Signal den Menüeintrag zum Editieren des Quelltextes, wird der Menüeintrag zum Editieren der Headerdatei nicht verändert. Wurde hingegen ein COMPILING Signal gesendet, so sind nicht nur der Menüeintrag für Compiling, sondern auch alle Menüeinträge zum Editieren gesperrt. Dies bedeutet, da momentan das Editieren einer Datei nur von einem BoosterGUI möglich ist und die anderen BoosterGUIs nicht mehr auf den Menüeintrag und somit die Datei zugreifen können. Seife 74

16 Die Änderungen am BoosterServer Kapitel 3 Die Änderungen am BoosterServer Ein BoosterServer ist für die Verwaltung der Knoten sowie für Compileaufträge auf seinem" Rechnersystem zuständig. Die eigentlichen Webserverfunktionen werden von dem Java- Server Jigsaw übernommen und durch die Methoden WebMakeLink und Compi 1 eserve - rlink erweitert. Ein Auftrag an WebMake wird nun zuerst durch den WebMakeLink empfangen und nach einem kleinen Handshake mit dem Klienten an WebMake weitergeleitet. Analog dazu werden Nachrichten an den Compi leserver erst vom Compi leserver- Link entgegengenommen, quittiert und erst dann zum CompileServer weitergereicht. Die Packages WebMake und CompileServer stellen dabei die eigentlichen Funktionen des BoosterServers zur Verfügung, Der CompileServer ist für die Übersetzung und Generierung der Programme, Objekte und Bibliotheken zuständig, WebMake hingegen für alle anderen verwaltungstechnischen Aufgaben. An den Quelltexten des BoosterServer wurden nur geringfügige Änderungen vorgenommen, da die meiste Arbeit im BoosterGUI vorgenommen werden konnte. Die bedeutendste Erweiterung war die Einführung der Klasse ModeManagment, die nur für die Zustandskontrolle in den beiden Packages WebMake und CompileServer zuständig ist. In diesem Kapitel werden sowohl die Änderungen an den einzelnen Packages als auch die Neuerungen des Booster- Server näher beschrieben. I I I 3.1 Änderungen an den Klassen Der BoosterServer wurde abgesehen von einigen wenigen Modifikationen nicht weiter verändert. Die einzigen Veränderungen bestehen in einer neuen Klasse zur Verwaltung der Zustände der Knoten, sowie in der Benutzung der SETMODE-Methode der Klasse ModeManagement in den Klassen des Compi leservers und WebMake Package (unter anderm die Klassen MakeObj ect, MakeLibrary, MakeExecutable im CompileServer und MakeableClusterNode, ProgramClusterNode, SubSystemClusterNode und SourceClus ternode im WebMake). Außerdem wurde fehleranfälliger Code, wie z.b. in der Klasse Dependency (steht in der MakeOb j ec t Klasse), der bei alten Environment-Dateien zum Abbruch führte, beseitigt oder sicherer programmiert. Seite 75

17 Die Änderungen am BoosterServer 3.2 Neuerungen im BoosterServer Durch die Umstellungen im BoosterGUI und die Einführung der Zustandskontrolle mußten im BoosterServer einige Neuerungen eingeführt werden. Zunächst betrifft dies die die Implementierung eines neuen Kommandos für den BoosterServer namens GET-NODE. Ferner die Implementierung einer neuen Klasse namens ModeManagement, die die Verwaltung der Knoten übernimmt. Das Kommando GETNODE dient zum Anfordern einer beliebigen Datei des BoosterSer- Vers. Dieses Kommando wurde benötigt, da einige Dateien des BoosterServers vorher über den Jigsaw Server geladen wurden und somit der BoosterServer nicht über deren Verwendung informiert wurde. Ein bereits bestehendes Kommando ReturnFile konnte nicht benutzt werden, da einige Dateien des BoosterServers, z.b. die Konfigurationsdatei, keine Knoten darstellen und somit nicht über dieses Kommando angesprochen werden können Die ~ustandsverwaltun~ im BoosterServer Eine weitaus wichtigere Neuerung im BoosterServer betrifft die Verwaltung der Knotenzustände in einer Hashtable, welche in der Klasse ModeManagement zusammen mit anderen Methoden definiert ist. Dabei wird jedem angeforderten Knoten ein Zustandwert (Mode) zugeordnet, der die einzelnen Zustände bitweise speichert. Wird z.b. von einem Knoten die Sourcesowie Headerdatei gleichzeitig bearbeitet, werden auf den bisherigen Zustandswert des Knotens jeweils der Wert 16 und 32 addiert, wodurch die Bits 5 und 6 gesetzt werden. Bei der Erzeugung eines neuen Knotens werden die einzelnen Subknoten (meist ein SourceNode oder HeaderNode) zuerst nicht angelegt. Wird nun von einem beliebigen BoosterGUI ein solcher Subknoten erzeugt, d.h. dem BoosterServer der Befehl übermittelt, schickt dieser über den BoosterInfluencer an alle BoosterGUIs ein Signal. Daraufhin wird der entsprechende Knoten in allen BoosterGUIs aktualisiert und der Eintrag für den Subknoten erzeugt. Seife 76

18 - Der Boosterlnfluencer Kapitel 4 Der Boosterlnfluencer Der BoosterInfluencer ist für die Kommunikation zwischen den BoosterServern und BoosterGUIs zuständig. Die aktiven BoosterGUIs registrieren sich bei ihm, um Zustandsänderungen zu erhalten, die er ihnen mittels eines Broadcast von den BoosterServern weiterleitet. In diesem Kapitel wird neben dem Aufbau auch die Funktionsweise des BoosterInfluencers näher beschrieben. 4.1 Der Aufbau des Boosterlnfluencers Der alte auf C++ basierende BoosterInfluencer, der als CGI-Skript implementiert wurde, hatte durch diesen Aufbau einige Probleme. Unter anderem konnte sich nur ein BoosterGUI gleichzeitig am BoosterInfluencer anmelden und mit ihm kommunizieren. Nahm ein neuer BoosterGUI die Verbindung zum BoosterInfluencer auf, so beendete dieser die letzte Verbindung und kommunizierte nur noch mit dem neuen BoosterGUI. Dadurch konnte keine Kommunikation zwischen den BoosterGUI's stattfinden und Informationen wie Zustandsänderungen nicht an die BoosterGUI's weitergeleitet wurden. Angesichts dieser Problematik wurde ein neuer BoosterInfluencer in Java geschrieben, der neben der Plattformunabhängigkeit auch die Kommunikation beliebig vieler BoosterGUI unterstützt. Dieser neue BoosterInfluencer basiert auf der Serverimplementierung, die in dem Buch,,Java in a Nutshell" vorgestellt wurde [8]. Er erzeugt für jede neue Verbindung zum Booster- Influencer einen eigenen Thread, der die entsprechende Mitteilung weiterverarbeitet. Der eigentliche Server liegt in der Klasse inf luencer, in der für jede neue Verbindung ein eigener Thread erzeugt und ein Objekt der Connec tion Klasse instanziiert wird. 4.2 Das Vorgehen des Boosterlnfluencers Der BoosterInfluencer unterstützt momentan zur Bewältigung seiner Aufgabe zwei Befehle, deren Benutzung in Abbildung 4 "Graphische Darstellung der Influencerkommunikation" verdeutlicht wird. Seite 77

19 Der Boosterlnfluencer 1 Abbildung 4: Gra'phische Darstellung der Influencerkommunikation Der erste Befehl namens GET wird benötigt, um ein BoosterGUI beim BoosterInfluencer anzumelden. Diese Verbindung wird vom BoosterGUI zur Startzeit durch einen eigenständigen Thread des CallbackHandler aufgebaut und erzeugt im BoosterInfluencer einen eigenen permanenten Thread, der als konstanter offener Nachrichtenkanal verwendet wird. Durch den GET Befehl wird im BoosterInfluencer dieser Thread erzeugt und die Adresse des BoosterGUI (Ein Print S t ream Objekt) zusammen mit einem Identifikator (integer Objekt) in einer Hashtabelle gespeichert. Wird das entsprechende BoosterGUI beendet, so stirbt auch die Verbindung zum BoosterInfluencer, der daraufhin diesen Thread beendet und die Adresse des Rückkanals aus der Hashtabelle löscht. In Tabelle 1 "Befehlssemantik des BoosterInfluencer" wird der Datenaustausch bei einer Anmeldung näher beschrieben. Der andere Befehl des BoosterInfluencer nennt sich SET-MODE und dient dazu, Informationen an alle angemeldeten BoosterGUI zu senden (Broadcast). Dazu wird ein temporärer Thread aufgebaut, der diesen Auftrag bearbeitet, den BoosterGUIs eine Nachricht sendet und danach terminiert. Ändert sich z.b. ein Zustands einer Knotendatei, so sendet der BoosterServer ein Zustandssignal an den BoosterInfluencer, der daraufhin alle Adressen aus seiner Hashtabelle ausliest und jedem BoosterGUI dieses Zustandssignal zuschickt. Tabelle 1 "Befehlssemantik des BoosterInfluencer" zeigt den Aufbau des Datenaustauschs bei einer Zustandsänderung im BoosterInfluencer. Die Zusatzinformation TYPEID steht dabei für den eigentlichen Zustand, die URL für den veränderten Knoten und MESSAGE für eine Nachricht, die im BoosterGUI angezeigt wird. Für zukünftige Erweiterungen, z.b. einer erhöhten Sicherheit, sind die Zusatzinformationen MAINSEQID und SECSEQID eingebettet: beide werden aber momentan nicht benutzt. Ta belle 1 : Befehlssemanti k des Boosterlnfluencer Ursache Das BoosterGUI meldet sich beim Booster- Influencer an und schickt: GET HTTP/1.0 Der BoosterServer hat einen Zustandswert geändert und informiert den BoosterInfluencer mittels: SETMODE typeid ur1 mainseqid secseqid message Wirkung Der BoosterInfluencer speichert den Antwortkanal und quitiert mit: HTTP/ OK Der BoosterInfluencer erhält den neuen Zustandswert und informiert die angemeldeten BoosterGUIs mittels des gleichen Befehls. SETMODE typeid... Seite 78

20 Kapitel 5 Zusammenfassung und Ausblick Diese Projektarbeit beschäftigt sich mit der Wiederherstellung und Erweiterung der verteilten Entwicklungsumgebung Booster. Die in unterschiedlichen Arbeiten entstandenen Komponenten BoosterGUI" und,,boosterserver" wurden wieder zusammengeführt und um den BoosterInfluencer ergänzt. Dadurch wurde die Zusammenarbeit der Komponenten, sowie der Mehrbenutzerbetrieb durch die Einführung einer Zustandskontrolle wieder ermöglicht. 5.1 Allgemeine Probleme des Booster-Systems Obwohl Booster schon sehr stabil läuft, gibt es immer noch Probleme bei einigen Funktionen, die es zu lösen gilt. Einige der wichtigen Probleme werden in der nachfolgenden Aufzählung näher beschrieben: 1. Es werden noch einige sogen. Deprecated Functions in den Klassen benutzt, die in zukünftigen Java-Versionen möglicherweise nicht mehr existieren. Diese sollten durch geeignete Methoden ersetzt oder umschrieben werden. 2. Die Divergenz in den Klassenhierarchien zwischen dem BoosterServer und dem BoosterGUI (z.b. MakeableClusterNode) sollte beseitigt werden, indem eine einheitliche Klassenstruktur entworfen und implementiert wird. 3. Momentan ist es noch nicht vorgesehen, daß der BoosterServer Anfragen der BoosterGUI blockiert, falls 2.B. jemand gerade ein Dokument editiert und ein anderer die gleiche Anfrage stellt. 4. Der interne Editor TEdit hat manchmal Probleme mit dem Speichern (Segmentation violation) von Dateien und sollte durch eine neue Version ersetzt werden. 5. Der BoosterServer legt manchmal in einer Environmentdatei eine HEADER-NEEDED Kante auf sich selbst an oder kann alte Environmentdateien nicht verwenden. Dies könnte beseitigt werden, indem der BoosterServer seine Environmentdateien beim Öffnen überprüft und gegebenfalls neu erstellt. 6. Die Verteilung der Icons im BoosterGUI ist noch nicht ganz ausgereift. Wer- Seite 79