Sprachen

ACIT - SS97, WS97/98

Thema: 
ACIT – Interaktive Animation von Konzepten und Verfahren der Computergrafik im InterneT
Zeitraum: 
SS97, WS97/98
Umfang: 
8 SWS pro Semester
Veranstalter: 

Robert Garmann, Informatik VII, Universität Dortmund
Robert Mencl, Informatik VII, Universität Dortmund

Thematik: 

Das klassische Ausbildungs-Szenario wird in jüngerer Zeit immer häufiger durch verteilt stattfindende und über Rechnernetze verbreitete Online-Veranstaltungen ergänzt. Ein weiterer Trend sind Multimedia-Kurse, die selbständige Weiterbildung am Computer ermöglichen. Solche Kurse sind sehr aufwendig herzustellen und insbesondere die Programmierung der dort eingesetzten Applets ist zeitraubend. Der Einsatz des Multimedia-Materials in einer Online-Veranstaltung ist daher unter dem Kosten-Nutzen-Gesichtspunkt sinnvoll. In diesem Beitrag wird der Prototyp ACIT vorgestellt, mit dem die gemeinsame Benutzung von Java-Applets in einer über das World Wide Web verbreiteten Online-Veranstaltung ermöglicht wird. Eine mögliche Realisierung der Anwenderschnittstelle sowie die technischen Aspekte der Systemarchitektur und des die Wiederverwendbarkeit gewährleistenden Programmdesigns werden erläutert.
Recently the classic education scenario often is supplemented by online events that are distributed across computer networks. A further trend are multimedia courses that allow self-learning at the computer. Such courses are expensive to produce. Especially the programming of the applets used in these courses is very expensive. Using this multimedia material in an online education event therefore makes sense under cost-profit aspects. In this paper we present the prototype system ACIT which allows joint usage of java applets in an online event that is distributed across the world wide web. A possible realization of the user interface as well as technical issues regarding the system architecture and the reuse permitting program design are discussed.

Motivation: Traditionell geschieht Ausbildung in Form von Vorträgen, Seminaren oder Übungen, wobei Lehrende und Lernende zeitgleich an einem gemeinsamen Ort versammelt sind (Abbildung 1a). Diese Orts- und Zeitabhängigkeit ist insofern zu begrüßen, daß sie intensive Kommunikation zwischen Lehrenden und Lernenden ermöglicht. Die Kommunikation ist meist audiovisueller Art, kann jedoch auch direkte Interaktion oder gemeinsame oder abwechselnde Interaktion mit einem Werkzeug, z. B. einem Computerprogramm, umfassen. Gerade letztere Form der interaktiven, "handlungsorientierten" Ausbildung ermöglicht den Lernenden meist ein tieferes Verständnis des Gelernten.

Abbildung 1:: (a) Traditionelles Szenario. Online-Szenario.

Abbildung 1:  (a) Traditionelles Szenario. (b) Online-Szenario. (c) Offline-Szenario.

In jüngerer Zeit werden jedoch Wege gesucht, die traditionelle Form des Unterrichts durch örtlich verteilte oder sogar zeitlich verteilte Veranstaltungen zu ersetzen. Der Vorteil von Orts- und Zeitunabhängigkeit liegt auf der Hand. Die Reisetätigkeit der Teilnehmer verringert sich. Individuelle Tagesabläufe müssen nicht mehr an einen festen Unterrichtstermin angepaßt werden. Der erste Punkt ist für die Reduktion der Kosten z. B. der innerbetrieblichen Weiterbildung wichtig. Der zweite Punkt ist insbesondere dann interessant, wenn die Teilnehmer aus unterschiedlichen Zeitzonen (z. B. USA - Europa - Japan) stammen.
Eine Möglichkeit, ortsunabhängige Ausbildung zu realisieren, ist die Live-Übertragung von Bild und Ton einer an einem festen Ort zu einem festen Zeitpunkt stattfindenden Veranstaltung über Weitverkehrsnetze wie z. B. ISDN oder das Internet. Die Teilnehmer sind räumlich verstreut und wohnen der Veranstaltung virtuell bei, indem sie die Daten der Veranstaltung online - also zeitgleich - empfangen (Abbildung 1b). Die Möglichkeit der Interaktion in audiovisueller Form zwischen Zuhörern und Vortragenden ist meist erforderlich und technisch durch Nutzung derselben Netze - im Internet z. B. durch die Mbone-Tools [14] - realisiert. In der Regel steht für Live-Übertragungen ein mit Kameras, Mikrofonen, Videobeamern und Übertragungstechnik gut ausgestatteter Vortragsraum zur Verfügung, der sozusagen das zentrale Element der virtuellen Veranstaltung darstellt [9]. Problematisch an diesem Online-Szenario und nicht einfach zu realisieren ist die oben erwähnte positiv einzustufende gemeinsame Verwendung von Werkzeugen. Das gemeinsame Zeichnen auf einem Blatt Papier kann durch Tools wie ein kooperativ im Netz zu benutzendes whiteboard [14] ermöglicht werden. Die gemeinsame Nutzung von anderen Werkzeugen wie etwa eigenen Programmen ist jedoch nicht ohne weiteres möglich.
Um den Lernenden sogar eine zeitunabhängige Ausbildung zu ermöglichen, bietet sich natürlich zunächst an, die Live-Veranstaltung mitzuschneiden. Der Mitschnitt (Film) wird auf Anforderung über Netze oder über traditionelle Transportwege (Post) zum Lernenden geschickt. So kann jeder Teilnehmer sowohl ortsunabhängig als auch zeitunabhängig (offline) den Ausbildungsstoff erarbeiten. Außerdem kann durch Verwendung eines elektronischen whiteboards statt der herkömmlichen Tafel relativ einfach zusätzliches Lehrmaterial direkt während der Live-Veranstaltung hergestellt werden [8]. Selbstverständlich ist in diesem Offline-Szenario kein Raum mehr für direkte Interaktion zwischen Lernenden und Lehrenden. Evtl. kann nachrichtenbasierte Kommunikation (e-mail) diese - allerdings mehr schlecht als recht - ersetzen. Insbesondere handlungsorientierte Ausbildung ist in der Form von Filmvorführungen nicht realisierbar.
Um dieses Manko abzumildern, bietet sich die Bereitstellung von zusätzlichem multimedial aufbereitetem Lehrmaterial an (Bild 3). Nicht von ungefähr werden heutzutage Multimedia-Sprachkurse, -Kochkurse, -Reiseführer, usw. in großen Mengen erfolgreich verkauft. Diese Kurse bieten den Vorteil, daß der Lernende sein Wissen abfragen lassen kann, und daß sich das Kurstempo seinem Können anpassen kann. Die Orts- und Zeitunabhängigkeit bleibt gegeben, und dennoch kann der Lernende mit dem Werkzeug Computer interaktiv lernen.
Auch im universitären Bereich gibt es Beispiele [7], wie multimediale Ausbildung sinnvoll umgesetzt werden kann. Der Bereich der Computergrafik, der uns in diesem Beitrag besonders interessieren soll, wurde etwa in [15] auf multimediale Weise aufbereitet. Die Bereitstellung dieses Materials im World Wide Web gewährleistet rasche Verfügbarkeit und einfache Beschaffbarkeit durch den Lernenden. Viele kleine Java-Applets (kleine über das Internet beziehbare Programme) ermöglichen dem Lernenden, das Gelernte sofort an einem Beispiel interaktiv auszuprobieren. Exemplarisch sei hier etwa der Themenbereich der geometrischen Modellierung mit Freiformflächen genannt [10]. Die mathematischen Hintergründe sind auf den ersten Blick kompliziert. Sie werden aber schnell anschaulich, wenn man ein kleines Programm einsetzt, das dem Lernenden anbietet, Parameter wie Kontrollpunkte oder Polynomgrade der Freiformfläche zu verändern. Das Programm reagiert darauf jeweils mit einer angepaßten Darstellung der resultierenden Freiformfläche.
Natürlich kann die Offline-Ausbildung die Online-Ausbildung nicht vollständig ersetzen. Die - ggf. virtuelle - Anwesenheit eines Lehrenden ist häufig erwünscht, so daß für zeitabhängige Online-Veranstaltungen nach wie vor Raum bleibt. Es stellt sich die Frage, ob das ansprechende, für einen Offline-Kurs multimedial aufbereitete Material, dessen Erstellung in der Regel außerordentlich aufwendig ist, nicht auch für eine Online-Veranstaltung zu verwenden ist. Im obigen Beispiel könnte einerseits der Lehrende selbst anhand eines Java-Applets den Lehrstoff anschaulich demonstrieren, andererseits könnten Lernende eingreifen und mithilfe des Werkzeugs "Applet" Fragen stellen und aufklären. Dies ist in einer traditionellen, an einem gemeinsamen, festen Ort stattfindenden Veranstaltung problemlos möglich. Bei einem über Netze verteilten Vortrag müssen die Applets jedoch mehrbenutzerfähig sein und zudem synchron und zentralgesteuert im Netz verteilt werden können.
Dieser Beitrag beschreibt die Realisierung des Systems ACIT, welches sich genau dieser Aspekte annimmt. ACIT - ein Akronym für "Animation von Computergrafik im Internet" - ist ein Prototyp für die verteilte, wechselseitig interaktive Verwendung von Java-Applets durch mehrere Personen im Internet. Es ist eingebettet in ein System [9] zum multimedialen verteilten Lehren und Konferieren. Im folgenden Abschnitt werden die Anforderungen an ACIT beschrieben. Zentraler Bestandteil des Systems sind Applets, deren Funktion in Abschnitt 3 erläutert wird. Die Anwendersicht wird exemplarisch anhand von Bildschirmmasken erläutert. Anhand eines Beispiel-Applets aus der Computergrafik wird in den Abschnitten 4 und 5 die Verwendung in einem verteilten Szenario dargestellt. Daran schließen sich die aus technischer Sicht interessanten Aspekte wie die Client-Server-Architektur und die Synchronisation von Applets (Abschnitt 6) sowie das objekt-orientierte Programmdesign (Abschnitt 7) an.
Anforderungen an das System ACIT : ACIT wurde als Baustein eines Systems für verteilte multimediale Lehre und Konferenzen konzipiert, welches die Übertragung von Veranstaltungen aus einem Multimedia-Hörsaal zu externen Teilnehmern über Rechnernetze ermöglicht. Ein wesentlicher Aspekt dabei ist die Möglichkeit für externe Zuhörer und Dozenten, mit den lokal Anwesenden zu kommunizieren und zu interagieren. Als Software-Basis werden hierzu Java Applets, die von einem zentralen Webserver geladen werden, und die MBone-Tools [13,14] zur effizienten Verteilung der Audio- und Video-Datenströme benutzt.
Als erstes Einsatzgebiet wurden exemplarisch Themen aus dem Bereich der Computergrafik realisiert. Wegen der offenen Konzeption ist ACIT jedoch grundsätzlich auch in anderen Gebieten einsetzbar.
Da das System viele verschiedene Nutzer bedienen muß, ist die Plattformunabhängigkeit eine wesentliche Anforderung. ACIT wurde in der Programmiersprache Java [3] implementiert. Java ist als Sprache des Internets hochgradig plattformunabhängig. Auf nahezu jeder Plattform gibt es - meist sogar vorinstallierte - Software zum Ausführen von Java-Applets, so daß der Nutzer sich über seinen Internet-Browser [4] hinaus um keine technischen Angelegenheiten kümmern muß.
Die Interaktion zwischen Teilnehmern einer virtuellen Veranstaltung war zentraler Gesichtspunkt bei der Entwicklung von ACIT. Dies unterscheidet ACIT von "normaler" Multimedia-Software. Benutzer können ein Applet kooperativ im Stile eines gemeinsam genutzten Whiteboards bedienen. Dazu werden Interaktionen (Actions) über das Netz verschickt und von einem Server synchronisiert.
Typischerweise wird Ausbildungsmaterial von Jahr zu Jahr überarbeitet. Veraltetes Material fällt weg, neues kommt hinzu. Da auch die neuen Ausbildungsthemen jedesmal multimedial u. a. in Form von Applets aufbereitet werden müssen, mußte das System ACIT einfach erweiterbar sein. So wurden Kommunikationsmechanismen zwischen Server und Client in einer tieferen Softwareschicht programmiert. Anwendungsprogrammierer benutzen eine komfortable Schnittstelle mit wiederverwendbaren Ein-/Ausgabekomponenten. Die Kommunikation mehrerer im Netz verteilter Applet-Instanzen untereinander ist bereits in diesen Komponenten implementiert und steht somit direkt zur Verfügung.
Applets: Applets sind kleine in Java geschriebene über das Internet beziehbare Programme. Die grafische Oberfläche eines Applets wird in der Regel in einem Internet-Browser [4] dargestellt. Ein Benutzer kann Eingaben vornehmen, welche das Applet entweder selbständig oder durch Kontaktaufnahme mit dem Server, von dem es stammt, verarbeitet. Die Kommunikation mit dem Server ist z. B. notwendig, wenn auf einen zentralen Datenbestand zugegriffen werden muß, oder wenn aufwendige Berechnungen nur auf einem leistungsstarken Server durchgeführt werden können.
Bei den üblicherweise in der Ausbildung eingesetzten Applets ist in der Regel keine Kommunikation mit dem Server notwendig. Die Applets stellen kleine überschaubare Einheiten dar, die selbständig auf einem Client laufen. Sollen jedoch wie in ACIT mehrere Applets synchronisiert werden, muß ein Kontakt zum Server hergestellt werden.

a b

Abbildung 2:  (a) Beispiel für ein ACIT-Applet. Dieses zeigt einen Algorithmus zur adaptiven Flächenapproximation. Oben sind der Parameterbereich der Fläche und das Ergebnis zu sehen. Im unteren Bereich kann der Benutzer sich schrittweise durch den Algorithmus arbeiten. (b) Das Network-Applet ermöglicht die Auswahl von Dokumenten und Veranstaltungen (Sessions). Mit der Wechsel-Schaltfläche start/finish transmission lassen sich die Applets aller Veranstaltungsteilnehmer synchronisieren. Mit talk bzw. cast kann an andere Teilnehmer eine Nachricht gesendet werden.

ACIT-Applets sind oberflächlich ganz normale Applets (siehe Abbildung 2a), die auf Benutzereingaben direkt reagieren, und die so die geforderte Interaktivität beim Lernen gewährleisten. Zusätzlich werden bei jeder benutzergesteuerten Aktion Informationen an einen Server gesendet, der diese auswertet und ggf. anderen Applets zukommen läßt, die irgendwo im Internet auf einem anderen Client laufen. Es existieren mehrere Kopien eines Applets im Internet. Eines davon kann die Steuerung aller anderen übernehmen. So kann z. B. das Applet eines Lernenden durch das Applet des Lehrenden gesteuert werden. Aktionen des Lehrenden wirken sich auf das grafische Aussehen des Applets beim Lernenden exakt so aus, als hätte der Lernende selbst diese Aktionen veranlaßt. Auf diese Weise kann dem Lernenden in einem über das Netz verbreiteten Online-Vortrag ein Sachverhalt mithilfe des Werkzeugs "Applet" beigebracht werden.
Natürlich muß bei einem realen Einsatz solch synchronisierter Applets irgendeine ordnende Instanz existieren, die Zugriffsrechte überwacht, und die dafür sorgt, daß über das Netz verschickte Aktionen auch bei den richtigen Adressaten ankommen. Es ist z. B. denkbar, daß ein Lehrender aus didaktischen Gründen zwei gleiche Applets nebeneinander betreiben will, um an Ihnen durch verschiedene Eingabeparameter die unterschiedlichen Auswirkungen deutlich zu machen. Auch die Lernenden beobachten jeweils zwei Applets. Die Aktionen des Lehrenden müssen nun eindeutig jeweils einem der beiden Applets des Lernenden zugespielt werden. Auf jedem dem System ACIT angeschlossenen Client läuft daher ein weiteres Applet - das Network-Applet -, welches diese Ordnungsfunktionen übernimmt. Es bietet darüber hinaus die Möglichkeit, verschiedene Online-Veranstaltungen aufzulisten und mit Teilnehmern Kontakt aufzunehmen (siehe Abbildung 2b).
Fallstudie: Applet-Einsatz im Netz Wir betrachten exemplarisch einen online gehaltenen Vortrag über adaptive Flächenapproximation. Ein Kamerabild des Vortragenden - nennen wir ihn V. - sowie der Vortragston werden durch Mbone-Tools [13,14] ins Internet eingespeist. V. hat eine Webseite angewählt, die ihn nach einer Authentifizierung zum ACIT-System bringt. In dem nun zur Verfügung stehenden Network-Applet Fenster wählt er eine Veranstaltung (Session) und betritt somit quasi den virtuellen Vortragsraum.
Ein anderer Benutzer - nennen wir ihn B. - möchte dem Vortrag beiwohnen. B. wählt die gleiche Webseite wie V., meldet sich an, und wählt die entsprechende Session. Das Network-Applet zeigt B. alle anwesenden Personen an, unter anderem auch den Vortragenden V.
Beide Teilnehmer V. und B. haben Kopien des Network-Applets von einem Webserver bezogen. Beim Start nimmt das Network-Applet Kontakt zu einem Serverprogramm auf, führt die Authentifizierung durch und lädt eine Liste verfügbarer Sessions. Beide Teilnehmer sind dem Serverprogramm nun bekannt. Aktionen, wie das Betreten oder Verlassen einer Session werden vom Serverprogramm registriert und allen angeschlossenen Network-Applets mitgeteilt.
V. beginnt den Vortrag. Während seines Vortrages bedient er sich des in Bild 4 gezeigten Beispiel-Applets, indem er das entsprechende Dokument in der Oberfläche seines Network-Applets anklickt. Das Beispiel-Applet wird geladen und angezeigt. Um nun bei allen Zuhörern ebenfalls das Laden dieses Applets zu verursachen, drückt V. auf den Knopf start transmission. Ab nun sind alle Aktionen von V., die er am Beispiel-Applet vornimmt, öffentlich, das heißt sie werden an alle Teilnehmer weitergeleitet.
Sobald V. start transmission gedrückt hat, meldet das Network-Applet von V. die Adresse des aktuell bei V. angezeigten Dokumentes an das Serverprogramm (in diesem Fall also die Information, daß das Beispiel-Applet angezeigt wird). Der Server gibt diese Information an alle Session-Teilnehmer also auch an B. weiter. Das Network-Applet von B. reagiert durch Laden des Beispiel-Applets.
V. bedient nun unter gesprochenen Erläuterungen einige Schalter des Beispiel-Applets. Das Beispiel-Applet von V. reagiert sofort durch ein verändertes Aussehen. Die Aktionen werden jedoch zusätzlich an das Network-Applet von V. weitergeleitet. Von dort gehen die Aktionen analog der Dokumentenadresse den Weg über den Server an die Network-Applets der übrigen Teilnehmer. Das Network-Applet von B. entscheidet, daß die eingegangene Aktion zu dem bereits geladenen Beispiel-Applet gehört und leitet sie entsprechend weiter. Für die Zuordnung erhalten alle Applets eine eindeutige Nummer. Beim Beispiel-Applet angekommen wird die Aktion interpretiert und das Aussehen des Beispiel-Applets ändert sich entsprechend. Im Ergebnis sehen jetzt die Beispiel-Applets von V. und B. exakt gleich aus.
Wir nehmen an, daß B. in das Geschehen eingreifen möchte. Er schreibt eine Frage in die dafür vorgesehene Zeile im Network-Applet und schickt diese per talk an den Vortragenden V. Der bekommt eine entsprechende Meldung und entscheidet sich, B. die Verfügungsgewalt über das Beispiel-Applet zu überlassen, und drückt dazu finish transmission. B. drückt start transmission und benutzt das Applet, um seine Frage zu erläutern. Jetzt sehen nicht nur V., sondern alle angeschlossenen Teilnehmer, was B. mit dem Beispiel-Applet anstellt. Ebenso kann B. mithilfe der Mbone-Tools gesprochene Worte an alle Teilnehmer übermitteln. Schließlich gibt B. die Kontrolle wieder ab, und der Vortragende fährt fort.
Fallstudie: Verwendung im Offline-Betrieb Wie in der Einleitung bereits erwähnt, ist es sinnvoll, einmal aufwendig programmierte Applets sowohl im Online- als auch im Offline-Szenario zu verwenden. In ACIT wird dazu dieselbe Benutzerschnittstelle wie im Online-Betrieb eingesetzt.
Der Benutzer B. möchte sich über adaptive Flächenapproximation im Selbst-Studium informieren. Er wählt die oben bereits erwähnte Webseite und erhält das Network-Applet Fenster. Dort wählt B. das entsprechende Dokument und gelangt zum Beispielapplet. Das Beispielapplet ist in eine Seite eingebettet, die theoretische Hintergrundinformationen zum Applet liefert. B. studiert diese und verwendet dann das Beispielapplet zur praktischen Vertiefung des Gelernten.
Architektur: Die Architektur des Systems ACIT im Online-Betrieb ist in Abbildung 3 dargestellt. Auf einem Server läuft ein Webserver, der die Clients mit HTML-Dokumenten versorgt. Auf den Clients läuft je ein Internet-Browser, der diese Dokumente anfordert und anzeigt. Die Dokumente enthalten Verweise auf Applets, so daß diese automatisch mitgeladen und angezeigt werden.

Abbildung 3:: ACIT-Systemarchitektur.Abbildung 3:: ACIT-Systemarchitektur.

Das erste Dokument, das zum Betreten des Systems ACIT angewählt wird, enthält zwei HTML-Frames [11,12], wobei in einem der beiden das Network-Applet läuft und der andere zunächst leer ist. Nach der Anmeldung kann der Benutzer mithilfe des Network-Applets im anderen Frame anwenderspezifische Dokumente inklusive mehrerer Applets laden.
Das Network-Applet kommuniziert mit einem auf dem Server laufenden Session-Manager. Dieses in Java geschriebene Programm verwaltet die Benutzer und mehrere aktuell stattfindende Veranstaltungen (Sessions). Der Kontakt zwischen Network-Applet und Session-Manager wird hergestellt, indem im Session-Manager für jeden Client auf dessen Initiative hin ein Kommunikationsobjekt (wir nennen es Drudge) erzeugt wird. Das entfernte Kommunikationsobjekt wird mithilfe eines Object-Request-Brokers erzeugt, einem Serverprogramm, das im folgenden auch die Kommunikation mit dem Drudge ermöglicht. Dabei geschieht die Kommunikation völlig transparent, indem auf dem Client einfach Methoden einer lokalen Schattenklasse aufgerufen werden, die dann intern diese Aufrufe an das entsprechende Objekt auf dem Server weiterleitet. In ACIT wird HORB [2] als Object-Request-Broker verwendet. Gegenwärtig wird das System jedoch auf den Java-RMI-Standard [5,6] umgestellt.
Die Server-zentrierte Architektur wurde gewählt, da Sicherheitsrestriktionen bei der Ausführung von Applets eine direkte Kommunikation zwischen Client-Applets verhindern. Wenn jedoch die Anzahl der angemeldeten Clients sehr groß wird, könnte der Server zum Flaschenhals für die Kommunikation werden. Um dies so gut wie möglich zu vermeiden, wurde ein Protokoll verwendet, das dem Client abfordert, selbst für die rechtzeitige Entgegennahme von Informationen vom Server zu sorgen. Der Server stellt zu verbreitende Daten jedem Client in einer eigenen Warteschlange zur Verfügung. Jeder Client muß regelmäßig dort wartende Informationspakete abholen. Tut er dies nicht, nimmt der Server eine unterbrochene Verbindung an, und eliminiert den Client aus dem System. So können Online-Veranstaltungen auch dann ungestört fortgesetzt werden, wenn der eine oder andere Teilnehmer technische Probleme hat. Die serverseitige Verwendung von Threads, wie sie in Java existieren, gewährleistet, daß der Server in einem solchen Fall nicht blockiert.
Objektorientiertes Design: Um ein wiederverwendbares System zu schaffen, wurde ein objektorientierter Softwareentwurf verfolgt. Abbildung 4 zeigt einige zentrale Klassen. Eine Übersicht über alle Klassen des Systems ist in [1] zu finden.

Abbildung 3::  	Die Softwarestruktur des Systems ACIT. Jedes weiße Kästchen beschreibt eine Klasse, wobei der Klassenname jeweils oben steht und Methoden der Klasse darunter aufgelistet sind. Verbindungen (Assoziationen) zwischen den Klassen sind durch weiße Linien darAbbildung 3:: Die Softwarestruktur des Systems ACIT. Jedes weiße Kästchen beschreibt eine Klasse, wobei der Klassenname jeweils oben steht und Methoden der Klasse darunter aufgelistet sind. Verbindungen (Assoziationen) zwischen den Klassen sind durch weiße Linien dargestellt.

Die Kommunikation zwischen Client und Server wird von der bereits erwähnten Klasse Drudge initiiert. Der Client sendet Daten - Actions oder anderweitige Nachrichten - an den Server, indem vom NetworkApplet aus eine Methode send... der Klasse Network aufgerufen wird, die ihrerseits eine Methode recv... der Klasse Drudge aufruft.
Auf dem Server verwaltet eine Instanz der Klasse SessionManager alle laufenden Veranstaltungen (Sessions). Jeder Session sind einige Benutzer mit ihren Drudges zugeordnet. Zusätzlich ist jedem Drudge paarweise eine Mailbox zugeordnet. In diese werden serverseitig mit put Nachrichten oder Aktionen gelegt. Die Methode run der Klasse Network implementiert den Rumpf eines Threads, der die in der Mailbox abgelegten Pakete regelmäßig durch Aufruf von get abholt und dann dem NetworkApplet zukommen läßt.
Im rechten Teil von Bild 7 sind die clientseitig verwendeten Klassen dargestellt. Alle Klassen der Anwenderschicht sind abstrakt, d. h. zur Implementierung eines realen Applets müssen jeweils konkrete abgeleitete Klassen implementiert werden. Ein AcitVisualizer ist ein grafisches Ein-/Ausgabeobjekt. Z. B. zeigt Bild 4 Visualisierer für Textfenster, für Schaltflächen sowie für rechteckige Ausgabebereiche für Grafiken. Je Applet gibt es also mehrere Visualisierer-Instanzen unterschiedlichen Typs. Alle diese Visualisierer sind mit einer AcitLogic-Instanz verbunden. Sobald der Benutzer eines Applets einen Knopf drückt oder sonstige Interaktionen vornimmt, wird eine Instanz AcitAction erzeugt und der Methode AcitLogic.notify als Parameter übergeben. Die "Logik" dieser Klasse besteht nun darin, daß sie "weiß", wie sich bestimmte Aktionen auswirken. Nehmen wir an, es gäbe sechs Visualisierer u, v, w, x, y und z. Jedem Visualisierer ist genau ein AcitProducer vorgeschaltet, der den Visualisierer steuert (über die Methode produce). Die AcitLogic könnte nun z. B. eine Aktion, die vom Visualisierer x stammt, an die Produzenten der Visualisierer x, u, v und z vermitteln, jedoch nicht an die Visualisierer w und y. Inwiefern die Aktionen eines Visualisierers andere Visualisierer beeinflussen können, ist vom Programmierer eines Applets zu definieren. So kann er z. B. auch entscheiden, daß etwa Aktionen des Visualisierers u keine weiteren Konsequenzen für andere Darstellungselemente haben, und demnach werden solche Aktionen von der AcitLogic nur wieder an u zurückvermittelt.
Eine weitere Aufgabe der AcitLogic ist, zu entschieden, ob die Aktion an den Server geschickt werden soll (wurde start transmission gedrückt?), und ggf. die Methode NetworkApplet.notifyClients zu informieren. Diese wiederum schickt die Aktion per Network.send... an den Server, der wiederum Kopien der Aktion in die Mailboxen aller Clients legt. Die Clients holen die Aktion wie oben beschrieben ab und geben sie vom NetworkApplet aus an AcitLogic.notify. Dort werden die Aktionen genauso wie lokal erzeugte behandelt.
AcitApplet stellt die Initialisierungsroutine eines Beispiel-Applets, wie es in Bild 4 dargestellt ist. In dieser Klasse werden alle benötigten Visualisierer und Produzenten instanziiert und "logisch" mit der AcitLogic verknüpft. Danach greift AcitApplet nicht mehr in das Geschehen ein, sondern übergibt die Kontrolle den Visualisierern.
Eine Sonderrolle spielt das Basiswissen eines Applets (AcitBasicKnowledge). Dieses ist gewissermaßen ein Produzent, der auf Aktionen reagiert, der jedoch keinen speziellen Visualisierer steuert. Je Applet gibt es genau ein Basiswissen, in dem - wie der Name schon sagt - das zentrale Wissen, seien es Daten oder Funktionen, gespeichert ist. Alle Produzenten haben Zugriff auf dieses Wissen, um korrekt auf eine Aktion reagieren zu können. Für ein Freiformflächenapplet könnten dort etwa Kontrollpunkte gespeichert sein und eine Funktion zur Berechnung der Fläche zur Verfügung stehen. Die Rolle des Basiswissens könnte selbstverständlich ein spezieller Produzent mit übernehmen. Jedoch wurde das Instrument eines zentralen Wissens bei der Implementierung verschiedener Applets als äußerst nützlich empfunden.
Im gegenwärtigen Stadium ist das ACIT-System als erweiterungsfähiger Prototyp einzustufen. Diese Fähigkeit ist im wesentlichen auf das Vorhandensein einer Bibliothek von Visualisierern zurückzuführen. Um neue Applets zu implementieren, können in der Regel vorhandene Visualisierer wiederverwendet werden, was den Entwicklungsaufwand reduziert.

Anforderungen:

Beschreibung der Anforderungen (gnuzipped postscript)

Erschienen in:

"it+ti Informationstechnik und Technische Informatik", Heft 3/99, Oldenbourg Verlag, München, Juni 1999

Dank:

In die Entwicklung des Prototyps ACIT waren die folgenden Informatik-Studenten und -Studentinnen der Universität Dortmund im Rahmen einer Projektgruppe zu einem entscheidenden Anteil involviert: Michael Alburg, Jörg Ayasse, Markus Bajohr, Matthias Brunschede, Benjamin de la Porte, Andre Dierker, Peter Grannas, Claas Harlinghausen, Martin Keienburg, Thomas Leineweber, Markus Siepermann, Christian Wolder, Sandra Zobel. Den Mitgliedern sei hiermit für ihr Engagement und die erfolgreiche Arbeit gedankt. An Herbert Kloseck geht ein Dank für die Aufbereitung der Bilder in diesem Beitrag.

Literatur:

[1] Alburg, M., Ayasse, J., Bajohr, M., Brunschede, M., de la Porte, B., Dierker, A., Grannas, P., Harlinghausen, C., Keienburg, M., Leineweber, T., Siepermann, M., Wolder, C., und Zobel, S.: Projektgruppe 296: ACIT. Animation von Verfahren und Konzepten der Computergrafik im Internet, Endbericht. Fachbereich Informatik, Universität Dortmund, 1998.
[2] Satoshi, H.: HORB. Distributed Execution of Java Programs, WWAC97 1st International Conference on Worldwide Computing and Its Applications, 1997. Online: http://ring.etl.go.jp/openlab/horb.
[3] Arnold, K. and Gosling, J.: The Java Programming Language. Addison-Wesley, 1996.
[4] Internet-Browser. http://www.browsers.com.
[5] Java Remote Method Invocation (RMI). http://www.javasoft.com/products/jdk/1.1/docs/guide/rmi
[6] Campione, M. and Walrath, K.: The Java Tutorial: Object-Oriented Programming for the Internet. Addison-Wesley, 1998.br/> [7] Fernuniversität Hagen. http://vu.fernuni-hagen.de
[8] Ottmann, T. und Bacher, C.: Authoring on the Fly. Journal of Universal Computer Science 1 (1995) 10.
[9] Deponte, J., Müller, H., Pietrek, G. Schlosser, S. and Stoltefuß, B.: Design and Implementation of a System for Multimedial Distributed Teaching and Scientific Conferences. Proceedings of VSMM'97, September 10-12, 1997 in Geneva, Switzerland. IEEE Computer Society Press, Los Alamitos, California, 1997.
[10] Abramowski, S. und Müller, H.: Geometrisches Modellieren. B. I. Wissenschaftsverlag, Mannheim, Reihe Informatik, 1991.
[11] Born, G.: HTML 2.0/3.2. Reference Guide. Addison-Wesley, Bonn, 1997.
[12] World Wide Web Consortium: http://www.w3.org/MarkUp
[13] Eriksson, H.: Mbone; The Multicast Backbone. Communications of the ACM 37 (1994) 8, S. 54-60.
[14] Mbone tools. http://www-nrg.ee.lbl.gov
[15] Universität Tübingen. Computer-Graphik spielend lernen. http://www-gris.uni-tuebingen.de/gris/grdev/java/doc/ html/Overview.html
Manuskripteingang: 20. Oktober 1998.

Endbericht:

endbericht-acit.ps.gz(FTP-Download 809k)
endbericht-acit.ps.gz(HTTP-Download 809k)

zur Person:

Dipl.-Inform. Robert Garmann studierte Informatik an der Universität Dortmund und ist seit 1995 wissenschaftlicher Mitarbeiter am Lehrstuhl für Graphische Systeme an der Universität Dortmund. Seine Forschungsinteressen liegen im Bereich der realitätsnahen Bildsynthese und der parallelen Datenverarbeitung. Adresse: Universität Dortmund, Informatik VII (Graphische Systeme), Otto-Hahn-Str. 16, D-44221 Dortmund E-Mail: garmann@ls7.informatik.uni-dortmund.de
Dipl.-Inform. Jens Deponte studierte Informatik an der Universität Dortmund und ist seit 1996 wissenschaftlicher Mitarbeiter am Informatik-Lehrstuhl für Graphische Systeme an der Universität Dortmund. Sein Forschungsschwerpunkt liegt im Bereich der verteilten multimedialen Systeme, insbesondere für die verteilte multimediale Lehre. Adresse: Universität Dortmund, Informatik VII (Graphische Systeme), Otto-Hahn-Str. 16, D-44221 Dortmund E-Mail: deponte@ls7.informatik.uni-dortmund.de
Dipl.-Inform. Robert Mencl studierte Informatik an der Universität Karlsruhe. Seit Ende 1994 ist er wissenschaftlicher Mitarbeiter am Lehrstuhl für Graphische Systeme an der Universität Dortmund. Seine momentanen Forschungsgebiete sind die Algorithmische Geometrie und die Rekonstruktion von Flächen aus dreidimensionalen Abtastdaten. Adresse: Universität Dortmund, Informatik VII (Graphische Systeme), Otto-Hahn-Str. 16, D-44221 Dortmund E-Mail: mencl@ls7.informatik.uni-dortmund.de

Anhang:

gzipptes Archiv (569 K) mit HTML-Text und allen Bildern zum herunterladen.