Visualisierung auf einem Grid-System mittels verteiltem Java AWT

Transkript

1 Visualisierung auf einem Grid-System mittels verteiltem Java AWT Diplomarbeit im Fach Informatik vorgelegt von Bernd Heller angefertigt am Institut für Informatik Lehrstuhl für Informatik 2 Programmiersysteme Friedrich-Alexander-Universität Erlangen Nürnberg (Prof. Dr. M. Philippsen) Betreuer: Dr. Ronald Veldema, Prof. Dr. Michael Philippsen Beginn der Arbeit: 22. November 2004 Abgabe der Arbeit: 23. Mai 2005

2

3 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der Diplomarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt. Erlangen, den 23. Mai 2005 Bernd Heller

4

5 Diplomarbeit Thema: Visualisierung auf einem Grid-System mittels verteiltem Java AWT Hintergrund: Java, Visualization, Grid/Cluster computing, C++, C Aufgabenstellung: This DA is to design and develop a grid-enabled Java Abstract Windowing Toolkit (AWT) for our research Grid-DSM Jackal. In short, our Jackal system allows a programmer to automatically distributed a multithreaded (thus already parallelized) program over a number of machines connected by some interconnect. Our goal is then to provide a Single System Image (SSI). As part of a SSI, it should provide a unified view of AWT as Java normally provides. The problem is then that, one machine might create a window and give the handle to the window to another machine (by for example storing the handle in an object where the DSM protocol has transfered the object to another machine) where the handle is normally only locally valid. This DA should then virtualize the window handle so that each machine can create AWT window handles that should then be globally valid. The second problem is then that our Jackal system targets the grid, which loosely translates to clusters connected by the internet. This means that, if a machine were to put single pixels on a display that is in terms of latency, far away, there is a performance problem. This problem could be solved in a number of ways: for example buffering the pixels locally for some period of time, compressing the pixel stream if needed, reducing bitmap resolutions if the programmer allows it (lossless and lossy compression). This DA should investigate which solutions can be automatically applied (which is different than current works which need programmar input always). Another problem is event management, for example, draw line, mouse click, mouse move and update graphics events. These events should be delivered in order and some events can be ignored if performance is critical. For example, if a mouse delivers 1000 move events to some machine far away, we could throw away a large number of these except the last. Another aspect of this DA would be to investigate mechanisms to optimize event management. Literatur: Java AWT Manuals, X protocol compression methods: gviz: Visualization and Computational Steering on the Grid, Across Grids Conference, Santiago, February : D. Kanzlmüller, P. Heinzlreiter, H. Rosmanith, J. Volkert Grid-Enabled Visualization with GVK Betreuung: Bearbeiter: Dr. Ronald Veldema, Prof. Dr. Michael Philippsen Bernd Heller

6

7 Zusammenfassung Im Rahmen dieser Diplomarbeit sollte eine verteilte Implementierung des Java Abstract Window Toolkit (AWT) für das Forschungs-Grid-DSM Jackal entworfen und entwickelt werden. Jackal erlaubt es bereits parallelisierten (also für Multithreading angepassten) Programmen automatisch auf mehreren zu einem Grid verbundenen Rechnern verteilt ausgeführt zu werden. Ziel ist es ein so genanntes Single System Image (SSI), also eine zusammenhängende Sicht aller Rechner als einen einzigen großen Rechner zur Verfügung zu stellen. Als Teil dieses SSI soll auch Java AWT behandelt werden können als liefe es auf einem einzigen Rechner. Dazu ist es erforderlich alle Grafikausgaben und erwarteten Benutzereingaben an einem Punkt des Grids zusammenzuführen der als Schnittstelle für den Benutzer dient. i

8 ii

9 Inhaltsverzeichnis 1 Einführung 1 2 Java AWT AWT und Swing AWT Swing Vergleich Die AWT Peer Architektur im Detail java.awt.toolkit java.awt.peer.* java.awt.graphics, java.awt.graphics2d AWT Event Modell Event-Hierarchie Event-Queue Vor- und Nachteile der AWT-Architektur in einem verteilten System Vorteile Nachteile Zusammenfassende Bewertung Jackals GridAWT Ansätze für eine verteilte AWT Implementierung Notwendigkeit eines Display-Servers Positionierung des Display-Servers Implementierung des Display-Servers Übersicht über die GridAWT Implementierung Verwaltung und Steuerung von UI Widgets Klassenhierarchien in AWT und Display-Server Verbindung zwischen Java und C Eine vollständige Implementierung am Beispiel eines Buttons iii

10 Inhaltsverzeichnis 3.4 Eventbehandlung und -verarbeitung Events im Display-Server Eventbehandlung im Grid Grafikoperationen Grafiken in GridAWT Typische Anwendungsfälle RPC-Implementierung mit Lizard RPC-Compiler Probleme mit Lizard Erweiterungen für die Zukunft Datenkompression Vervollständigen der AWT-Implementierung Genauigkeit der Darstellung FileDialog-Komponente Classpath-Bibliotheken iv

11 Abbildungsverzeichnis 2.1 Übersicht der AWT Architektur Klassenhierarchie von java.awt.peer.* Übersicht über AWT Event-Behandlung AWT Peer-Modelle im Vergleich Mögliche Positionierungen des Display-Server Übersicht der GridAWT Architektur Zusammenspiel der AWT-Klassenhierarchien Zusammenspiel der AWT- und GridAWT-Klassenhierarchien Beteiligte Klassen und Interfaces für Button v

12 Abbildungsverzeichnis vi

13 Listingsverzeichnis 3.1 Factory-Methode für ButtonPeer-Objekte AWT Peer-Interface ButtonPeer Java-Implementierung des Interfaces ButtonPeer in GridAWTButtonPeer Nativ implementierte Methoden von GridAWTButtonPeer Deklaration der Pure Virtual Class (Interface) Button Deklaration der Klasse GTKButton Implementierung der Klasse GTKButton RPC-Definition für ButtonPeer vii

14 Listingsverzeichnis viii

15 1 Einführung Visualisierung ist ein wichtiger Aspekt der verschiedensten wissenschaftlichen Anwendungen. Hierzu zählen gerade auch rechenintensive Applikationen wie Partikel- oder Molekülsimulation. Um den Anforderungen an hohe Rechenleistungen gerecht zu werden, gestützt von der Möglichkeit viele dieser Algorithmen parallel ausführen zu können, wird häufig zu verteilten Implementierungen in Rechner-Grids gegriffen. Diese Anwendungen können somit auf einer großen Anzahl von Rechnern, die durch ein Netzwerk (z.b. ein Intranet oder das Internet) miteinander verbunden sind, ausgeführt werden. Getreu dem Motto ein Bild sagt mehr als tausend Worte ist die Visualisierung, also die bildliche Darstellung, der Ergebnisse solcher Berechnungen ein wichtiger Aspekt der entscheidend für das Verständnis der untersuchten Vorgänge sein kann. Während das Erzeugen statischer Bilder in einer verteilten Anwendung meist noch ohne größere Probleme zu bewerkstelligen ist, bedürfen Animationen und Echtzeit-Darstellungen besonderer Maßnahmen. Aufgrund der begrenzten Übertragungsraten in Netzwerken kann es schwierig bis unmöglich sein flüssige Animationen darzustellen, oder ist nur unter Einbußen an Bildqualität zu erreichen. Echtzeit-Anwendungen hingegen leiden auch noch unter den in Netzwerken auftretenden Latenzzeiten, also der Zeit die vergeht bis eine Nachricht die auf einem Knoten abgeschickt wurde, auf einem anderen Knoten empfangen und damit verfügbar wird. Dies wirkt dem Ziel von Echtzeit-Anwendungen, kurze Reaktionszeiten zu garantieren, direkt entgegen. Leider sind kurze Reaktionszeiten auch für Benutzeroberflächen eine wichtige Eigenschaft. Das Ziel gerade von grafischen Benutzeroberflächen ist es dem Benutzer das Gefühl zu geben zu jedem Zeitpunkt das Programm kontrollieren zu können. Um diesen Eindruck herzustellen ist es unbedingt notwendig, daß jede Aktion des Benutzers nicht nur möglichst schnell den Programmablauf beeinflussen muß, sondern auch sofort von einer Rückmeldung innerhalb der Benutzeroberfläche begleitet werden sollte. Dies können so einfache Rückmeldungen sein wie einen Button eingedrückt zu zeichnen sobald ein Klick registriert wird, oder so komplexe wie das Darstellen von Dialogen. Nur durch eine schnelle Reaktion der Benutzeroberfläche kann beim Benutzer die Vorstellung erzeugt werden, er würde reale Bedienelemente vor sich haben. Es käme aufgrund unser aller Erfahrungen zu großer Verwirrung, wenn der Druck auf einen mechanischen Druckknopf in der realen Welt diesen nicht eindrücken würde, oder das Bewegen eines Hebels nicht zu einer Positionsänderung führt. Dieselben Maßstäbe müssen für grafische Benutzeroberflächen angelegt werden. Es wird im allgemeinen angenommen, daß Benutzer eine Verzögerung von ms nicht wahrnehmen oder nicht als störend empfinden. Bei 1

16 1 Einführung Internetverbindungen kann die Netzwerk-Latenzzeit allein bereits solche Werte erreichen oder deutlich überschreiten, was zeigt wie hoch das Ziel in diesem Bereich gesteckt ist. Das Ziel dieser Diplomarbeit ist es die Visualisierung in Java-Programmen zu ermöglichen, die mittels Jackal verteilt ausgeführt werden. Jackal ist ein Grid-DSM das es Programmen erlaubt verteilt auf einem Rechner-Grid zu laufen. Dazu müssen die Programme nicht speziell angepasst werden, außer daß sie natürlich in Hinblick auf eine Multithreading-Umgebung geschrieben sein sollten um maximalen Nutzen aus dem Rechnernetz zu ziehen. Abgesehen davon muß aber keine Modifikation für Jackal stattfinden, weil die Programme im allgemeinen nicht die einzelnen Rechner (also die Knoten des Grids) sehen, sondern ein so genanntes Single System Image (SSI) das den Programmen eine Sicht auf das Grid als einen einzigen großen Rechner erlaubt. Die natürliche Visualisierungsumgebung in Java ist AWT, das Abstract Window Toolkit, auf dem auch das später hinzugekommene Swing aufsetzt. AWT bietet dem Programmierer Möglichkeiten grafische Benutzeroberflächen aus den allgemein üblichen Teilen wie Menüs, Fenstern, Buttons, etc. zu erstellen. Weiterhin hat AWT eine grafische Komponente die es erlaubt mit Vektor- und Raster-Grafikoperationen auf den Bildschirm zu zeichnen, sowie Rasterbilder zu laden und darzustellen. Die Herausforderung eine Implementierung von AWT zu entwickeln die verteilt auf einem Rechnernetz funktionsfähig ist, besteht zunächst in erster Linie darin dafür zu sorgen, daß sämtliche grafischen Ausgaben nur an einem einzigen Rechner erscheinen und Benutzereingaben auch nur von dort entgegengenommen werden. Weiterhin muß Sorge getragen werden, daß Komponenten (z.b. Fenster) die auf einem Rechner des Grids erzeugt wurden, auch auf allen anderen Rechnern zugänglich sind. In einer normalen AWT Implementierung in den üblichen Java Virtual Machines wird das Java-Objekt das ein Fenster repräsentiert mit einem Fenster des nativen Window Systems des Betriebssystems (z.b. X-Windows) assoziiert sobald es auf dem Bildschirm erscheint. Eine solche feste Zuordnung zu einer nur lokal existierenden Ressource wäre in einem verteilten System natürlich fatal und unweigerlich zum scheitern verurteilt. In der vorliegenden AWT Implementierung, dem GridAWT in Jackal, wurden diese Probleme dadurch gelöst, daß ein einzelner Rechner als Display-Server fungiert und sämtliche grafischen Operationen ausführt, sowie Eingaben von Benutzern entgegennimmt und an das Grid weiterleitet. Dieser Display-Server ist mit dem Grid verbunden, aber kein echter Teil des Single System Images. Das Grid benutzt ihn gewissermaßen nur als Schnittstelle zum Benutzer. 2

17 2 Java AWT AWT ist die Abkürzung für Abstract Window Toolkit. Dahinter verbirgt sich ein Konglomerat aus nicht wenigen Java-Klassen die es zusammengenommen dem Programmierer ermöglichen in Java auf recht einfache Weise grafische Benutzeroberflächen in ihre Programme zu integrieren. Außerdem hält das AWT auch Klassen bereit um mit Rasterund Vektor-Grafikoperationen Bilder zu erzeugen und auf dem Bildschirm darzustellen. 2.1 AWT und Swing AWT war bereits Teil von JDK 1.0, wurde aber bis hin zum aktuellen JDK 1.5 immer wieder erweitert. Es gibt im Großen und Ganzen zwei Versionen von AWT: 1.0 und 1.1. Der Unterschied ist dabei hauptsächlich ein deutlich verbessertes Event-Modell in der Version 1.1. Inzwischen wird die direkte Arbeit mit AWT von Sun wohl eher als nicht mehr zeitgemäß angesehen, so sind z.b. die Tutorials die zum Erlernen von AWT, und der Erzeugung von Benutzeroberflächen mittels AWT dienen, nur noch in archivierter Form zum Download verfügbar, können also nicht mehr direkt online eingesehen werden. Der Grund dafür heißt Swing. Swing ist ein neueres Grafik-Toolkit das ebenfalls Teil von Standard-Java ist. Swing ist nicht Teil dieser Diplomarbeit und wurde auch nicht speziell berücksichtigt. Es sei aber darauf hingewiesen, daß Swing auf AWT aufbauend implementiert ist, also grundsätzlich zusammen mit GridAWT, also der hier vorliegenden verteilten AWT-Implementierung, funktionieren sollte AWT AWT basiert auf dem nativen Window System des Betriebssystems auf dem die Java Virtual Machine läuft, d.h. dem Teil des lokalen Betriebssystems, das Programmierschnittstellen zur Grafikausgabe zu Verfügung stellt. Jede der Grundkomponenten die AWT für Benutzeroberflächen anbietet (z.b. Fenster, Buttons, Checkboxes,... ) müssen eine native Entsprechung haben. Diese Gegenstücke werden als Peers bezeichnet und machen die eigentliche Arbeit, d.h. die bereits im Window System des Betriebssystems vorhandenen Routinen für Darstellung und Eventbehandlung solcher Komponenten übernehmen diese beiden Hauptaufgaben. Die Java-Objekte in der Virtual Machine und die Peers auf 3

18 2 Java AWT Native Window System Components Java AWT Components Java AWT Peer Native Implementation Java AWT Peer Implementation Java AWT Peer Interfaces Native Machine Java Virtual Machine Abbildung 2.1: Übersicht der AWT Architektur der Betriebssystemseite müssen also zwingend über nativen Code miteinander verbunden sein, damit AWT die Peers zum zeichnen veranlassen und im Gegenzug von ihnen Events entgegennehmen kann Swing Swing im Gegensatz dazu geht das Problem völlig anders an: Wo es bei AWT für jede Grundkomponente der Benutzeroberfläche einen nativen Peer gibt, also einen Window- Peer, einen Button-Peer, etc. beschränkt sich Swing auf die minimalste Schnittstelle zwischen Java und dem Window Systems des unterliegenden Betriebssystems. Bei Swing sind alle Widgets der Benutzeroberfläche ausschließlich in Java geschrieben. Um sie auf den Bildschirm zu zeichnen und den Benutzer damit agieren zu lassen, benötigt Swing nur zwei grundlegende Mechanismen: Es muß Zugang zum Bildschirm (bzw. Ausschnitten davon, also Fenstern) haben, um die Komponenten zeichnen zu können. Und es muß über die elementaren Events wie Tastatureingaben (Key Events) und Mausbewegungen bzw -klicks (Mouse Events) informiert werden, um daraus higher-level Events zu generieren. Wie bereits erwähnt werden diese Grundfunktionen von Swing erreicht indem es auf AWT zurückgreift und nicht durch eine weitere spezielle Schnittstelle zwischen Java Virtual Machine und nativem Window System Vergleich AWT und Swing sind offensichtlich konzeptionell sehr unterschiedliche Systeme. Sun spricht bei AWT-Komponenten auch von Heavyweight, und bei Swing-Komponenten von Lightweight, wobei diese Nomenklatur nur teilweise zutreffend ist. AWT-Komponenten sind zwar dahingehend Schwergewichte, daß sie immer eine native Ressour- 4

19 2.2 Die AWT Peer Architektur im Detail ce des Betriebssystems als Gegenstück benötigen. Allerdings hat dies auch den Vorteil, daß die Behandlung der Komponenten durch das (optimierte) native Window System wahrscheinlich effizienter ist als die entsprechenden Implementierungen von Swing- Komponenten in der Java Virtual Machine. Es ist zu vermuten, daß diese so genannte Heavyweight -Implementierung genau aus diesem Grund gewollt war. Denn als AWT und Java eingeführt wurden, stand noch nicht die heute übliche durchschnittliche Performance von Desktop-Rechnern zur Verfügung, und die ersten Virtual Machines mussten sich noch gegen das Argument wehren, daß Java um so vieles langsamer als ein compiliertes C-Programm ist. Der für den Benutzer wohl auffälligste Unterschied zwischen AWT und Swing besteht im Design der Benutzeroberfläche. AWT ist durch seine Abhängigkeit zum Window System des Rechners auf dem es läuft natürlich zwangsweise an dessen Look & Feel gebunden. D.h. es kann nicht beeinflussen wie die einzelnen Komponenten dargestellt werden. Dies hat aber auch den nicht unwesentlichen Vorteil, daß ein AWT-Programm nicht optisch unangenehm hervorsticht, sondern sich in das auf dem Rechner vorherrschende Benutzeroberflächen-Design einfügt. Umgekehrt hat natürlich Swing den Vorteil eines Look & Feel der über alle Plattformen hinweg in jeder Java-Umgebung gleich aussieht, also den Vorsatz der Plattformunabhängigkeit auf das Design der Benutzeroberfläche ausdehnt. Hinzu kommt, daß Java mehr als nur eine Look & Feel Umgebung für Swing anbietet, sondern verschieden aussehende Themes, die auch ohne Neustart des Programms gewechselt werden können. Um den Vorteil von AWT, sich dem Look & Feel des Gastrechners anzupassen, auch in Swing zu übernehmen, gibt es z.b. auf Windows eine entsprechendes Theme die Swing-Applikationen den typischen Windows-Look verleiht, und bei Apple s Virtual Machine eine Aqua-Theme, die den typischen Mac-Look herstellt. 2.2 Die AWT Peer Architektur im Detail Um beurteilen zu können was nötig ist um eine verteilte Implementierung von AWT zu realisieren, soll hier zunächst im Detail erklärt werden wie der plattformabhängige Teil der AWT Architektur aufgebaut und strukturiert ist. Innerhalb der Java AWT API handelt es sich hierbei hauptsächlich um die Interfaces die in java.awt.peer.* definiert sind sowie das Interface java.awt.graphics bzw. java.awt.graphics2d. Um alles zu verbinden wird außerdem eine Unterklasse von java.awt.toolkit benötigt java.awt.toolkit In jedem AWT Programm gibt es normalerweise genau eine Singleton-Instanz eines Toolkits, auf die bei Bedarf mit der statischen Methode Toolkit.getDefaultToolkit() zugegriffen werden kann. 5

20 2 Java AWT ButtonPeer CanvasPeer CheckboxPeer ChoicePeer PanelPeer ComponentPeer ContainerPeer ScrollPanePeer LabelPeer WindowPeer DialogPeer FileDialogPeer LightweightPeer FramePeer ListPeer ScrollbarPeer TextComponentPeer TextAreaPeer FontPeer TextFieldPeer MenuComponentPeer MenuBarPeer MenuItemPeer MenuPeer PopupMenuPeer CheckboxMenuItemPeer Abbildung 2.2: Klassenhierarchie von java.awt.peer.* Die abstrakte Klasse java.awt.toolkit definiert alle Methoden die von jeder AWT- Implementierung in einer Unterklasse plattform- bzw. implementierungsspezifisch zur Verfügung gestellt werden müssen. Hierzu gehören z.b. Methoden, um Instanzen der zu der AWT-Implementierung gehörenden Peer-Klassen zu erzeugen, auf die gleich noch näher eingegangen werden soll. Das Toolkit fungiert hier also als Factory für die AWT Peer-Objekte. Weiterhin stellt das Toolkit Hilfsfunktionen bereit die unter anderem Auskunft über die grafische Umgebung geben. Dazu gehören z.b. Abfragen der Bildschirmgröße und -auflösung java.awt.peer.* Den Großteil einer plattformspezifischen AWT Implementierung machen die Implementierungen der Peer-Interfaces aus, die in java.awt.peer.* definiert sind. Wie in Abbildung 2.2 zu sehen ist, handelt es sich dabei um eine nicht unerhebliche Anzahl von Interfaces. Die Vielfalt kommt daher, daß AWT jede spezielle Komponente der Benutzeroberfläche (im Folgenden auch Widget genannt) durch ein plattformabhängiges Gegenstück dem so genannten Peer auf dem Bildschirm darstellt. D.h. jeder Widget-Typ, der dem AWT-Programmierer zur Verfügung steht hat eine definier- 6

21 2.2 Die AWT Peer Architektur im Detail te API-Schnittstelle die genau auf seine Funktion zugeschnitten ist. Demzufolge muß es auch für jeden Widget-Typ ein eigenes Interface geben das diese APIs genau definiert. In der Praxis besteht die Implementierung eines einzigen Widgets normalerweise aus vier Teilen: Peer-Interface: Ein Interface aus java.awt.peer.* das die APIs des Widgets definiert. Dieses Interface ist Teil von Java AWT und dient als Ausgangspunkt der Implementierung. Java Peer-Implementierung: Eine Klasse die das spezielle Interface des Widgets implementiert. Dies ist eine Java-Klasse, die aber praktisch nie ohne native Teile auskommt, also Methoden die als native deklariert sind und mittels JNI in C/C++ implementiert wurden. Native Peer-Implementierung: C bzw. C++ Funktionen, die mittels Java Native Interface (JNI) die nativen Teile der Peer-Klasse implementieren. Dies ist nötig weil die Peer-Implementierung mit dem nativen Window System des Rechners kommunizieren muß um die Peers darzustellen, und ein entsprechendes Interface im allgemeinen nicht als Java API zur Verfügung steht. Toolkit Factory Method: java.awt.toolkit definiert für jedes der Peer-Interfaces eine zugehörige Factory-Methode (z.b. createbutton() für java.awt.peer. ButtonPeer). In der Toolkit-Implementierung müssen diese Factory-Methoden ein Objekt der jeweiligen Peer-Implementierung instanziieren. Der gesamte plattformunabhängige Sourcecode von AWT in Java benutzt ausschließlich Referenzen auf die Peer-Interfaces um eine strikte Trennung von Design und Implementierung zu garantieren. Erzeugt werden die Peer-Objekte von ihrer entsprechenden Klasse in java.awt.*, indem dort die jeweilige Toolkit.create... () Factory-Methode aufgerufen wird. Nur so ist es überhaupt erst möglich, daß AWT mit einer spezifischen Peer-Implementierung zusammenarbeiten kann ohne sie genau kennen zu müssen java.awt.graphics, java.awt.graphics2d Wie bereits erwähnt bietet AWT neben Komponenten um eine grafische Benutzeroberfläche zu erzeugen, auch Möglichkeiten um mit Vektor- und Rasterbildern zu arbeiten, sowie neue User Interface Widgets zu schreiben, die mittels der Grafikkommandos auf den Bildschirm gezeichnet werden können. Diese Funktionen sind in den beiden abstrakten Grafik-Klassen java.awt.graphics und java.awt.graphics2d definiert. Anfänglich existierte nur die recht einfache Klasse java.awt.graphics als Teil von AWT. Später wurde dann java.awt.graphics2d als abstrakte Unterklasse von java. awt.graphics hinzugefügt, das deutlich umfangreichere Funktionen bietet. Unter anderem gibt es Unterstützung für Transformationen des Koordinatensystems, Pfade und 7

22 2 Java AWT Stroke/Fill Methoden. Es kommt damit den Möglichkeiten des PostScript bzw. PDF Grafikmodells sehr nahe. Als Teil einer AWT-Implementierung muß wenigstens eine der beiden Graphics- Klassen implementiert werden. Auch diese Klasse ist meist sehr plattformspezifisch, weil die Grafikkommandos auf entsprechende Funktionen des nativen Window Systems abgebildet werden müssen. 2.3 AWT Event Modell Das AWT Event Modell hat sich von AWT 1.0 zu AWT 1.1 deutlich geändert. Die Kompatibilität zu Programmen die noch in Hinblick auf das 1.0-Modell geschrieben sind, wird im allgemeinen innerhalb der Java AWT Klassen hergestellt. Hier soll deshalb nur noch die aktuelle Variante betrachtet werden, da die Peers sich bei der Event-Erzeugung nicht speziell auf das alte Modell einstellen müssen Event-Hierarchie Unter Events versteht man in Zusammenhang mit AWT praktisch alle Ereignisse die in der Benutzeroberfläche registriert werden. Dazu gehören einfache Ereignisse wie Mausbewegungen, genauso wie komplexere Ereignisse die das Auswählen eines Menüpunktes repräsentieren. Java-typisch sind alle AWT Events als gewöhnliche Objekte repräsentiert. Dabei sind alle spezielleren Event-Klassen von java.awt.awtevent abgeleitet, und in dem Package java.awt.event.* zusammengefasst. Gemein haben alle AWT Events eine so genannte Event ID, die den Typ des Ereignisses eindeutig identifiziert. Diese Event ID ist eine Integer-Konstante, deren Bedeutung auch über die Grenzen der AWT-Event-Klassen hinweg eindeutig festgelegt ist, d.h. die Bedeutung kann ganz ohne Zuhilfenahme des instanceof Operators o.ä. festgestellt werden. Weiterhin hat jedes AWT Event eine Quelle, also einen Ursprung des Ereignisses. Da diese Quellen sehr vielfältig und nahezu beliebig sein können, wird eine Referenz auf ein allgemeines java.lang.object gespeichert. So können die verschiedensten Komponenten, wie z.b. java.awt.button und java.awt.menuitem, gleichermaßen als Event- Quellen dienen. Dies ist wichtig weil diese beiden Klassen, genau wie ihre Peers in Abbildung 2.2, nicht von einer gemeinsamen Klasse abgeleitet wurden. Im Folgenden soll eine Übersicht über die wichtigsten Event-Klassen gegeben werden. Wenn dabei davon gesprochen wird, daß ein bestimmtes AWT Widget ein Event erzeugt, ist das so zu verstehen, daß eigentlich der entsprechende Peer ein Ereignis registriert und daraus das passende AWT Event generiert. Semantisch gehören die AWT Events allerdings zu den AWT Widgets, und die unterliegenden Peers sind nur eine Spezialität der Implementierung. 8

23 2.3 AWT Event Modell ActionEvent ActionEvents werden von all den Button-Widgets (Button und Checkbox) erzeugt, denen eine auszuführende Aktion zugeordnet werden kann. Werden sie geklickt, wird ein ActionEvent verschickt das einen String enthält, der die zugehörige Aktion spezifiziert. Diese Events müssen von den Peer-Objekten erzeugt werden, da sie eine direkte Reaktion auf eine Benutzereingabe sind. ContainerEvent ContainerEvents dienen als Information für den Fall, daß Widgets zu einer Container- Komponente hinzugefügt oder von ihr entfernt wurden. Diese Events können ohne Beihilfe der Peers erzeugt werden, da keine Informationen von den Peers dazu benötigt werden. FocusEvent FocusEvents werden immer dann erzeugt wenn der Fokus von einem Widget der Benutzeroberfläche zu einem anderen wechselt. Als Fokus wird hier verstanden, daß Eingaben (z.b. von der Tastatur) sich immer auf das eine Widget auswirken das gerade den Fokus hat. In modernen Benutzeroberflächen wird das Widget das den Fokus hat üblicherweise durch einen leuchtenden Ring (den sog. Fokusring) gekennzeichnet der um das Widget gezeichnet wird. Ein Fokuswechsel wird meist durch die Tab-Taste oder einen Mausklick auf ein Widget herbeigeführt. Diese Events können am einfachsten von der Peer-Ebene erzeugt werden, da das native Window System meist eingebaute Möglichkeiten besitzt um den Fokus zu verfolgen und die Widgets entsprechend zu zeichnen. KeyEvent KeyEvents gehören zu den InputEvents und werden für jedes Tastatur-Ereignis erzeugt. Dazu gehören Ereignisse für das Drücken und das Loslassen einer Taste. Außerdem wird ein spezielles Ereignis für jede Taste die gedrückt und dann losgelassen wurde, also für jedes getippte Zeichen, geschickt. Die Peers müssen diese Ereignisse erzeugen. MouseEvent Wie KeyEvents sind MouseEvents recht grundlegende Events die von den Peers erzeugt werden müssen. Als MouseEvents werden dabei alle Formen von Mauseingaben verstanden, also Mausbewegungen, einfache und mehrfache Mausklicks, sowie Drag- Bewegungen, also Mausbewegungen bei gedrückter Maustaste. 9

24 2 Java AWT PaintEvent PaintEvents unterscheiden sich von den anderen hier aufgeführten Ereignissen darin, daß sie sowohl von den Peers, als auch von der Java-AWT-Seite erzeugt werden. PaintEvents kommunizieren die Notwendigkeit einen Teil einer Komponente neu zu zeichnen. Dies kommt z.b. vor wenn sich eine Komponente geändert hat (z.b. ein Button dessen Beschriftung je nach Zustand wechselt), oder ein Teil des Bildschirminhalts zerstört ist und nun neu gezeichnet werden muss (z.b. wenn ein Fenster vergrößert wird). Die nativen Peer Widgets müssen solche Events schicken wenn ein Ereignis im nativen Window System das Neuzeichnen von AWT-Komponenten erfordert. Standard-Widgets könnten zwar unter Umgehung des Java-Teils von AWT direkt von den Peers gezeichnet werden, aber AWT erlaubt auch manchen Komponenten ihre eigenen Darstellungsroutinen in Java zu definieren. In dem Fall muß sich das Zeichnen, ausgehend vom Java-Code, in die Peers hinunter fortsetzen. Gleichzeitig gibt es viele Situationen in denen die Java-Teile von AWT, oder das Java- Programm selbst das Auffrischen des Bildschirms oder Teilen davon erfordert. Beispielsweise eine Änderung in der Hierarchie einer Container-Komponente oder der Bildwechsel in einer Animation erfordern ein sofortiges Neuzeichnen der geänderten Bildschirmbereiche, und erreichen dies intern indem ein PaintEvent geschickt wird. Letztendlich führen diese Events dann dazu, daß die entsprechenden Peers sich neu zeichnen. AdjustmentEvent Das AdjustmentEvent ist ein sehr spezielles Ereignis. Es wird von allen verstellbaren Komponenten geschickt, d.h. von den Komponenten die in irgendeiner Form zur Auswahl eines Wertes aus einem Wertebereich dienen. Der bekannteste Vertreter dürfte java.awt.scrollbar sein. ItemEvent Diese Events werden für jedes Element geschickt das selektiert oder deselektiert wurde. Dazu gehören die einzelnen Einträge in Auswahllisten (java.awt.list, java.awt. Choice), sowie Checkboxen (java.awt.checkbox, java.awt.checkboxmenuitem). TextEvent TextEvents werden von allen Text-Komponenten (java.awt.textfield und java.awt. TextArea) geschickt wenn sich der Inhalt geändert hat. Im Gegensatz zu KeyEvents sind dies higher-level Events, die nicht nur einzelne Tastenanschläge, sondern logisch vollständige Änderungen beschreiben, die z.b. auftreten wenn das editieren einer Text- Komponente beendet wird. 10

25 2.4 Vor- und Nachteile der AWT-Architektur in einem verteilten System Event-Queue Bisher wurde zwar der Aufbau der AWT-Events, sowie ihre verschiedenen Ausprägungen beschrieben, allerdings noch nicht erklärt wie Events geschickt und verarbeitet werden. Die zentrale Komponente die dafür zuständig ist, ist die Ereigniswarteschlange oder Event Queue, die als java.awt.eventqueue implementiert ist. Wie alle anderen plattformspezifischen Teile von AWT, wird auch auf die EventQueue nur indirekt über die Toolkit-Methode Toolkit.getSystemEventQueue() zugegriffen. Es kann also eine speziell auf die Peers zugeschnittene Unterklasse von java.awt.eventqueue implementiert und benutzt werden. Im Prinzip ist die Aufgabe und Funktionsweise der Event-Queue sehr einfach: alle Events werden mit der Methode EventQueue.postEvent() zur Warteschlange hinzugefügt und mit EventQueue.getNextEvent() aus ihr entnommen. Dabei arbeitet die Queue nach dem First-In-First-Out (FIFO) Prinzip, d.h. Events die zuerst geposted werden, werden auch zuerst ausgelesen und verarbeitet. Die Implementierung auf die hier nicht detailliert eingegangen werden soll hält allerdings einige Falltüren wie Thread- Synchronisierung bereit. Eingefügt werden Events in die Queue zum einen von den Java- bzw. JNI-Teilen der AWT Peer-Implementierungen. Auf diese Weise wird AWT über Ereignisse informiert die im nativen Window System registriert wurden. Zum anderen werden Events in praktisch allen Teilen von java.awt.* erzeugt und von dort in die EventQueue eingefügt. Das Einfügen kann dabei auch von ganz verschiedenen Threads erfolgen ohne zu einem Deadlock zu führen. Ausgelesen werden die Events aber nur von einem einzigen Thread, dem Event Dispatcher. Dieser Thread entnimmt in einer Endlosschleife Events aus der Event-Queue und leitet sie an die richtigen AWT-Komponenten zur Verarbeitung weiter. Um Deadlocks zu verhindern während z.b. modale Dialoge dargestellt werden, gibt es die Möglichkeit mehrere EventQueues als Stack zu verbinden, wobei jede der Queues einen eigenen EventDispatcherThread erhält. Glücklicherweise muß sich damit aber meist nicht einmal der Entwickler von AWT-Peers beschäftigen, da dies in der Java AWT Implementierung erledigt und nicht speziell behandelt werden muß. 2.4 Vor- und Nachteile der AWT-Architektur in einem verteilten System Da nun ein grundsätzlicher Überblick über AWT gegeben wurde, soll hier noch eine Bewertung dieser Architektur in Hinblick auf eine verteilte Implementierung in einem Grid-System erfolgen. 11

26 2 Java AWT AWT Benutzer-AWT-Programm java.awt.eventqueue Speichert Events in First-In- First-Out Ordnung java.awt.awteventlistener wartet und reagiert auf Events java.awt.awteventdispatchthread entnimmt Events aus der Queue, verteilt sie an alle Interessenten java.awt.awteventlistener java.awt.component erzeugt High-Level Events kann auf Events reagieren java.awt.peer.componentpeer erezugt Events kann auf Events reagieren wartet und reagiert auf Events java.awt.awteventlistener wartet und reagiert auf Events Abbildung 2.3: Übersicht über AWT Event-Behandlung Vorteile Zunächst zu den positiven Aspekten der AWT-Architektur: Die Trennung von Komponenten in Java-Objekte und native Peer-Objekte ist geradezu perfekt für eine verteilte Implementierung. Da das Zeichnen der Benutzeroberfläche und Empfangen von Ereignissen in einem verteilten System auf einen einzigen Rechner beschränkt werden muß, kommt die saubere Trennung zwischen Java-Welt und externer Welt einer verteilten Implementierung mittels RPCs sehr entgegen. Es ist nicht nötig den eigentlich Java AWT Sourcecode zu modifizieren, stattdessen reicht es eine vollständig neue Peer- Implementierung zu entwickeln. Dabei ist es ohne besondere Probleme möglich nicht mit einem lokalen Window System zu agieren, sondern mit einer RPC-Schicht zunächst alle Funktionen per Netzwerk an einen dedizierten Displayserver weiterzuleiten und dort die Anbindung an das lokale Grafiksystem herzustellen. Man könnte beinahe den Eindruck gewinnen, daß AWT in Hinblick auf ein solches System entworfen wurde. Vermutlich ist aber auch hier nur wieder der Ursprung von AWT zu erkennen: Die Implementierung eines Frameworks für Benutzeroberflächen allein in Java war damals aus Performance-Gründen noch nicht sinnvoll realisierbar, und die nötige Brücke zwischen der Java Virtual Machine und dem nativen Window System kann als durchaus ähnlich zu dem hier nötigen RPC-Layer angesehen werden Nachteile Der auffälligste Nachteil von AWT ist die Unmenge einzelner Peer-Klassen und entsprechender nativen Gegenstücke die für eine vollständige Implementierung geschrieben werden müssen. AWT ist hier teilweise unübersichtlich, und der zu investierende Auf- 12

27 2.4 Vor- und Nachteile der AWT-Architektur in einem verteilten System Lokale AWT Peer-Implementierung Verteilte AWT Peer-Implementierung Native Implementierung der Anbindung an das lokale native Window System Native Implementierung der Anbindun an das lokale native Window System als Teil des RPC-Servers Verbunden durch lokale Funktionsaufrufe, Parameterübergabe per Register, Stack, etc. Implementierung der AWT Peer-Interfaces durch Aufruf von nativen JNI-Methoden (z.b. gnu.awt.peer.*) Verbunden durch RPCs, Parameterübergabe über Netzwerk Implementierung der AWT Peer-Interfaces durch Benutzung von RPCs (z.b. grid.awt.peer.*) AWT AWT Peer-Interfaces definiert in java.awt.peer.* (z.b. java.awt.peer.component) AWT AWT Peer-Interfaces definiert in java.awt.peer.* (z.b. java.awt.peer.component) AWT-Komponenten Implementierungen in java.awt.* (z.b. java.awt.component) AWT-Komponenten Implementierungen in java.awt.* (z.b. java.awt.component) (a) Rein Lokale AWT Peer- Implementierung (b) Verteilte AWT Peer- Implementierung Abbildung 2.4: AWT Peer-Modelle im Vergleich wand nicht gerade gering. Wenn man zum Vergleich Swing heranzieht, das nur auf einem kleinen Bruchteil von AWT aufbaut, wird schnell klar wie viel einfacher sich eine solch minimale Schnittstelle zum Window System implementieren lässt. Allerdings gereicht auch dieser offensichtliche Nachteil AWT in diesem speziellen Fall wieder zum Vorteil: Denn wie bereits besprochen ist gerade diese detailliertere API die implementiert werden muß, in einem verteilten System von Vorteil. Die Anzahl und Menge der Daten die bei jeder Veränderung von UI-Komponenten per RPC transportiert werden muß, ist durch diese Feingliederung deutlich geringer. Der Preis der dafür gezahlt werden muß ist allerdings derselbe wie bei nicht verteilten AWT-Implementierungen: Es müssen alle Peer-Klassen geschrieben werden. Und dafür werden wiederum sehr viele verschiedene RPCs benötigt, was zu einem recht beträchtlichen Aufwand führt, der schnell unübersichtlich werden kann Zusammenfassende Bewertung Zusammenfassend kann gesagt werden, daß eine verteilte Implementierung durch die AWT-Architektur eher vereinfacht als erschwert wird. Die grundlegende Peer-Schnittstelle, auf die aufgebaut werden kann ist bereits vorhanden, und ermöglicht eine saubere Implementierung bei gleichzeitigem Verzicht auf Hacks im eigentlichen Java AWT Code. 13

28 2 Java AWT 14

29 3 Jackals GridAWT Nachdem gerade ein Überblick über die Architektur von AWT und die grundsätzlichen Anforderungen an eine verteilte Implementierung gegeben wurde, soll in diesem Kapitel die genauere Struktur der vorliegenden Implementierung GridAWT erläutert werden. 3.1 Ansätze für eine verteilte AWT Implementierung Es wurde bisher nur darauf eingegangen, daß es für eine verteilte Implementierung von AWT zwingend ist, lokale Ressourcen wie Fenster zu einem Teil des Single System Images zu machen. Nur so ist es auch entfernten Gridknoten möglich auf diese Ressourcen zuzugreifen, die ihnen ja nicht lokal zur Verfügung stehen. Es gibt verschiedene Wege und Modelle dieses Ziel zu erreichen, von denen nun einige vorgestellt werden sollen, die während der Konzeption von GridAWT erwogen wurden Notwendigkeit eines Display-Servers Der Benutzer der die von AWT erzeugte Benutzeroberfläche bedienen soll, muß alle erzeugten Fenster und grafischen Ausgaben auf einem einzelnen dedizierten Rechner sehen, da es absurd wäre ihn von Rechner zu Rechner laufen zu lassen um ein Programm zu bedienen. Außerdem muß er wissen an welchem Rechner er Eingaben machen kann, die dann an AWT zurückgeführt und ausgewertet werden. D.h. jedes sinnvolle Konzept einer verteilten AWT-Implementierung muß einen einzigen Rechner auserwählen zu dem alle grafischen Ausgaben kanalisiert werden, und von dem als einziger Quelle Benutzereingaben an AWT geleitet werden. Dieser Rechner wird im folgenden als Display-Server bezeichnet. Es sind verschiedene Szenarien denkbar wie dieser Display-Server implementiert und in das Gesamtkonzept eingebunden wird Positionierung des Display-Servers Zunächst gibt es prinzipiell zwei Möglichkeiten, wie der Display-Server in Beziehung zu den Grid-Knoten stehen kann: Der Display-Server kann ein ganz normaler Knoten des Grids sein, der zusätzlich zu seinen eigentlichen Aufgaben als Display-Server fungiert (3.1(a)) 15

30 3 Jackals GridAWT Grid Grid Gridknoten 1 Gridknoten 1 Gridknoten 2 AWT-Programm Gridknoten 2 AWT-Programm AWT-Programm AWT-Programm Gridknoten 3 Netzwerk Gridknoten 0 AWT-Programm Display-Server Gridknoten 3 Netzwerk Gridknoten 0 AWT-Programm Events AWT-Programm AWT-Programm RPCs Externer Rechner Display-Server Gridknoten 4 AWT-Programm Gridknoten n AWT-Programm Gridknoten 4 AWT-Programm Gridknoten n AWT-Programm (a) Grid mit Display-Server als Teil eines Knotens (b) Grid mit externem Display-Server Abbildung 3.1: Mögliche Positionierungen des Display-Server Ein dedizierter Display-Server der zwar mit dem Grid verbunden ist, aber kein eigentlicher Teil des Grids ist, also keine Rechenaufgaben des Grids übernimmt (3.1(b)) In GridAWT wurde die zweite Variante gewählt, also ein dedizierter Display-Server der außerhalb des Grids steht. Der Hauptgrund der zu dieser Entscheidung führte war die Vorgabe, daß die Gridknoten als headless zu betrachten sind, und im allgemeinen weder über die Möglichkeit zur grafischen Ausgabe noch über installierte Grafik- Bibliotheken verfügen. Beides ist unverzichtbar für den Display-Server. Allerdings sprechen noch weitere Argumente für diese Separation von Grid und Display-Server. So liegt der eigentliche Vorteil eines Grid-integrierten Display-Servers nur darin, daß man keinen weiteren separaten Rechner benötigt. Dies ist aber nur auf den ersten Blick ein Vorteil: sollte es tatsächlich so sein, daß ein oder mehrere Gridknoten grafikfähig sind, und der Display-Server auf einem dieser Grid-Rechner laufen soll, so kann der dedizierte Display-Server als eigener Prozess auf einem davon gestartet werden. Somit ist der eigenständige Display-Server flexibler einsetzbar, weil er je nach Bedarf sowohl auf einem Gridknoten, als auch auf einem externen Rechner betrieben werden kann. Ein Nachteil eines separaten Display-Servers ist die zusätzliche Netzwerk-Verbindung die zwischen dem Server und den Gridknoten hergestellt werden muß. Dabei muß darauf geachtet werden, daß der Display-Server potentiell von allen Gridknoten angesprochen werden können muß, also eine Verbindung zu jedem Gridknoten nötig wird. Allerdings wird dieser Nachteil bei Jackal/GridAWT praktisch völlig durch die Existenz einer Kommunikationsbibliothek aufgehoben. Sie ist als Basis der Kommunikation innerhalb 16

31 3.1 Ansätze für eine verteilte AWT Implementierung des Grids konzipiert, und kann auch zur Kommunikation zwischen Display-Server und Grid eingesetzt werden. D.h. der Display-Server ist zwar formal auf Netzwerk-Ebene ein vollständiger Teil des Grids, wird aber auf höheren Ebenen nicht als Gridknoten angesehen oder verwendet Implementierung des Display-Servers Es ist zwar jetzt klar welche Möglichkeiten es gibt den Display-Server relativ zum Grid zu positionieren und damit zu verbinden, aber noch nicht wie die Implementierung aussehen kann. Deshalb sollen nun die verschiedenen Wege aufgezeigt werden die dazu existieren. Zunächst soll noch einmal in Erinnerung gebracht werden, welche Aufgaben der Display-Server erledigen muß: Anbindung der entfernten Java AWT Peers an UI-Widgets des lokal laufenden nativen Window Systems. Sammeln und Versenden von Events die im Benutzerinterface auftreten und vom, im Grid laufenden, AWT-Programm verarbeitet werden müssen. Es muß also für jeden AWT Peer der im Grid erzeugt wurde eine native Entsprechung im Display-Server geben. Dabei müssen der Peer und sein Gegenstück miteinander eindeutig assoziiert werden können, damit die Ereignisse die im Display-Server registriert werden, erscheinen können als kämen sie von der richtigen Quelle, also dem zugehörigen AWT Objekt. Implementierung mit UI Frameworks Um diese Aufgaben zu erfüllen ist es sinnvoll ein Framework für grafische Benutzeroberflächen (GUI) einzusetzen, um den ohnehin schon beträchtlichen Aufwand zu minimieren. In einer UNIX/Linux-Umgebung reichen die Kandidaten von X11/Motif hin zu GTK+ und Qt, wobei letzteres auch native Implementierungen für Windows und Mac OS anbietet die aber nicht frei verfügbar sind. Diese Frameworks bieten fertige Implementierungen für die üblichsten UI-Widgets, unter anderem auch jene die AWT anbietet. Die eigentliche Herausforderung besteht also darin, die API die von AWT in den Peer-Interfaces definiert ist mittels eines solchen Frameworks zu implementieren. Im Idealfall käme dies einem reinen Mapping einer API auf eine andere gleich, aber wie so oft ist der Idealfall in der Praxis nicht erreichbar. Es sei aber schon vorweggenommen, daß zumindest GTK+, welches in GridAWT Verwendung fand, einen Großteil der Funktionen bereitstellt die von AWT definiert sind, und damit die Implementierung soweit möglich vereinfacht. 17

32 3 Jackals GridAWT Implementierung in Java und AWT Während der Entwurfsphase von GridAWT stand noch eine völlig andere Idee zur Implementierung im Raum: Es wäre theoretisch möglich den Display-Server in Java zu implementieren. Wie auch bisher dargestellt, würden die Methoden der AWT Peers als RPCs implementiert, die dann im Display-Server ausgeführt werden. Die Implementierung würde sich dann aber dahingehend unterscheiden, daß statt eines fremden UI Frameworks, AWT selbst im Display-Server bemüht wird. Der Vorteil ist offensichtlich: Man würde ohne besonderen Aufwand einen Display-Server erhalten, der nahezu identische Ergebnisse auf den Bildschirm bringt wie die AWT-Implementierung der Java Virtual Machine auf der der Display-Server läuft. Eine zu Sun-AWT konforme Ausgabe, die zudem noch plattformübergreifend lauffähig ist, wäre also mit einer solchen Implementierung möglich, was einen gewissen Anreiz darstellt. Das Problem das aber leider besteht, ist daß man die Peer-Implementierung nicht kennt oder beeinflussen kann. Peers sind nicht darauf vorbereitet eigenständig zu arbeiten, d.h. ein Peer ist nur in Kombination mit dem zugehörigen AWT-Objekt (also z.b. java.awt.button) funktionsfähig. Man müsste deswegen für jeden Peer der im Display-Server erzeugt werden muß, zusätzlich (bzw. stattdessen) ein AWT-Objekt erzeugen. Das ist zugleich auch der Kern des Problems, weil es wohl nur mit erheblichem Aufwand oder gar nicht möglich ist alle nötigen Informationen für ein vollständig identisches AWT-Objekt aus dem deutlich reduzierten Peer-Interface zu gewinnen. Die Frage die sofort folgen muß ist ob es dann nicht möglich wäre die Kommunikation zwischen Display-Server und Grid nicht auf der niedrigen Ebene der Peer-Interfaces, sondern auf der höheren Ebene der AWT-Objekte, also java.awt.*, zu realisieren. Es wäre wohl machbar so ein Protokoll zu etablieren, allerdings ist dazu zwingend ein direkter Eingriff in die java.awt.* Klassen erforderlich. Zum einen ist das nicht gerade ein einfaches Unterfangen und beinhaltet sehr viele und umfangreiche Modifikationen. Zum anderen ist die Netzwerk-Effizienz eines solchen Ansatzes wegen des erhöhten Kommunikationsbedarfs auf dieser Ebene von AWT zumindest fraglich. 3.2 Übersicht über die GridAWT Implementierung Es wurden gerade einige mögliche Strategien gezeigt wie sich ein verteiltes AWT implementieren lässt, welche Bedingungen zwingend erfüllt werden müssen und bei welchen eine Auswahl möglich ist. Im Folgenden soll nun zunächst eine Übersicht über die Architektur der hier vorliegenden Implementierung GridAWT gegeben werden, die später von einer genaueren Beschreibung der einzelnen Komponenten des Systems gefolgt wird. Für GridAWT wurde entschieden den Display-Server als eigenständigen Prozess zu konzipieren, der zwar mit dem Grid verbunden, aber kein vollwertiger Teil davon ist. Wie bereits im vorigen Kapitel erläutert wurde, ist dieser Ansatz der flexibelste und 18

33 3.2 Übersicht über die GridAWT Implementierung vereinigt damit die meisten Vorteile auf sich. Darüber hinaus war eine unumstößliche Prämisse die Annahme, daß keiner der Grid-Knoten über Grafikfähigkeiten oder auch nur Grafikbibliotheken verfügt. Ein essentieller Design-Grundsatz musste also sein, den Display-Server außerhalb des Grids betreiben zu können. Implementiert wurde der Display-Server in C++ unter Zuhilfenahme von GTK+ als UI Framework. GTK+ wurde deshalb gewählt, weil Jackal die Java-Klassenbibliotheken des Classpath-Projekts verwendet. Teil dieser Bibliotheken ist auch eine AWT-Implementierung, deren nativer Teil auf GTK+ basiert. Somit existierte eine Beispiel-Implementierung mittels eines verfügbaren Frameworks die, wenn auch nicht zur Kopie diente, doch als Vorlage bei der Implementierung des Display-Servers nützlich war. Die Wahl des objektorientierten C++ gegenüber C ist mit den speziellen Anforderungen an die Implementierung des Display-Servers zu erklären. Sie besteht darin eine Spiegelhierarchie der Hierarchie der Java AWT Peer-Klassen herzustellen, die dann per RPC mit den Peer-Objekte auf der Java-Seite verbunden werden kann. Ein objektorientierter Ansatz bietet hier starke Vorteile wie später noch ausführlicher gezeigt werden wird. Die Verbindung zwischen Grid und Display-Server wird mittels der Kommunikationsbibliothek Lizard hergestellt. Sie wird später eine grundlegende Komponente von Jackal sein, was es möglich macht den Display-Server dann noch besser in das Gesamtkonzept Jackal zu integrieren. Zum Zeitpunkt des Schreibens war leider keine in vollem Umfang funktionsfähige Lizard-Implementierung verfügbar, was zu erheblichen Abstrichen sowohl bei Funktions- als auch Performance-Tests führte. Die Peer-Implementierungen in Java sind eher unspektakulär. Wo möglich wurde versucht existierenden Code, oder zumindest Ansätze dafür, aus der AWT-Implementierung des Classpath-Projekts weiterzuverwenden. In den meisten Fällen beschränkt sich der Code der GridAWT Peer-Implementierungen allerdings darauf, RPCs zum Display- Server auszuführen und vorher bzw. nachher die Parameter bzw. Rückgabewerte entsprechend an die Anforderungen des jeweils anderen anzupassen oder zu konvertieren. In Abbildung 3.2 ist zu sehen aus welchen Komponenten GridAWT aufgebaut ist, in welcher Beziehung es zu den Gridknoten steht, und wie die Funktionen innerhalb des Systems verteilt sind. Nachdem bisher nur eine eher abstrakte Übersicht über die Anforderungen an eine verteilte AWT-Implementierung im Allgemeinen, sowie über die grobe Architektur von GridAWT im Speziellen gegeben wurde, soll es nun in den folgenden Kapiteln um tiefere Einblicke in die konkreten Details der GridAWT-Implementierung gehen. Dazu werden 19