DreamTeam Logo

Die DreamTeam-Umgebung

DreamTeam ist eine CSCW-Umgebung für synchrone Gruppenarbeit. Sie soll vorerst als Forschungs- und Testplattform dienen, ein späterer Einsatz in einer "realen" Umgebung (z.B. zur Unterstützung eines Softwarepraktikums) soll aber vorbereitet werden. Gesichtspunkte wie die Verwendung von PCs über Modems werden bei der Realisierung beachtet.

Bei der Konzeption von DreamTeam sollen folgende Merkmale erfüllt werden:

Der erste Punkt sollte für Software immer zutreffen, die von einer Benutzergruppe ohne besondere Vorkenntnisse verwendet wird. Die Plattformunabhängigkeit resultiert aus der Tatsache, daß die typische Benutzergruppe über PCs mit unterschiedlichen Betriebssystemen verfügt. Zusätzlich zu PCs soll das System aber auch auf UNIX-Workstations lauffähig sein, da es auch universitätsintern eingesetzt wird. Ein Wiederaufsetzen im Fehlerfall sollte ohne besondere Verfahrensweisen möglich sein, da dies in der zu erwartenden Einsatzumgebung häufiger der Fall sein kann.
Die Verwendung mehrere Dialogsprachen ist teilweise schon ein Standardmerkmal von Softwaresystemen. Oft muß sich der Benutzer aber vor oder während der Installation eines Pakets für eine Landessprache entscheiden. In DreamTeam kann diese Entscheidung zur Laufzeit getroffen und beliebig revidiert werden.
Die Wahl für eine dezentrale Architektur wird später ausführlich begründet.

Folgende Funktionsbereiche werden von der DreamTeam-Umgebung abgedeckt:

Entwickler von verteilten Anwendungen werden durch eine Funktionsbibliothek und eine Laufzeitumgebung unterstützt.

Architektur

Die DreamTeam-Umgebung ist dezentral aufgebaut, d.h. es gibt keine Server-Anwendung. Folgende Gründe waren dafür ausschlaggebend:

Bei der Entscheidung für eine dezentrale Architektur wurde ein komplexeres Laufzeitsystem in Kauf genommen.

Laufzeitsystem

Eine der Grunddienste eines CSCW-Systems ist die Verwaltung der verschiedenen Profile. DreamTeam verwaltet folgende:

Benutzerprofil:
Das Benutzerprofil beinhaltet alle Daten, die den Benutzer in einer Sitzung ausweisen, also Name, Adresse, Emailadresse und sein Bild. Ein Benutzer kann sein Profil beliebig ändern. Anhand von Zeitstempeln wird bei einer Sitzung festgestellt, ob sich ein Profil geändert hat und ggf. aktualisiert. Mit Hilfe von Übersichtsfunktionen können alle Teilnehmer die Profile der anderen Benutzer einsehen.

Rechnerprofil:
Im Rechnerprofil sind rechnerspezifische Daten festgehalten. Darunter fällt der Rechnertyp, das Betriebssystem und die Netzwerkadresse, wenn diese fest eingestellt ist. Als weiteres kann die Anbindungsart (Anbindung lokal oder über Einwählpunkt) angegeben werden. Das Rechnerprofil wird vom System automatisch generiert. Einige Einträge können vom Benutzer editiert werden.

Sitzungsprofil:
Im Sitzungsprofil ist festgehalten, welche Anwendungen in einer Sitzung verwendet werden sollen und ob es Beschränkungen für Benutzer geben soll. Beispielsweise kann es sinnvoll sein, nur eine maximale Anzahl von Benutzern zu einer Sitzung zuzulassen oder den Moderator bei einem Zutrittswunsch vorher zu fragen. Das Sitzungsprofil kann von dem Benutzer geändert werden, der eine Sitzung erzeugt hat. Andere Teilnehmer können das Sitzungsprofil nur einsehen.

Beim Start der DreamTeam-Anwendung werden vorliegende Profile von dem lokalen Dateisystem eingelesen. Danach wird eine Laufzeitumgebung mit folgenden Tasks gestartet:

Logmanager:
Der Logmanager verwaltet Meldungen über Ereignisse, die im System anfallen. Er gibt sie an den Dialog weiter und schreibt sie, wenn vom Benutzer gewünscht, in eine Datei. Letzteres dient zur Auswertung von Fehlersituationen während der Entwicklungsphase oder der nachträglichen Analyse von Sitzungen. Über die Benutzungsoberfläche sind Systemmeldungen in Form von Übersichtslisten abrufbar. Besondere Ereignisse (z.B. Fehler) führen zu Nachrichtenfenstern, die der Benutzer quittieren muß.

Verbindungsmanager:
Hier werden die Verbindungen verwaltet, die von den verteilten Anwendungen verwendet werden. Jede verteilte Anwendung ist mit der entsprechenden Anwendung aller Gruppenteilnehmer verbunden. Der Auf- und Abbau dieser Verbindungen wird vom Verbindungsmanager automatisch vorgenommen.

Sitzungsmanager:
Der Sitzungsmanager verwaltet die Sitzungen des lokalen Systems. Dazu gehört z.B. der Abgleich mit anderen Rechnern. Der Sitzungsmanager führt auch die Sitzungsstarts durch und aktiviert damit die verteilten Anwendungen.

Transfermanager:
Neben spontanen Ereignissen, die in Echtzeit eine Beantwortung erfordern, gibt es Anforderungen, deren Ausführungen längere Zeit in Anspruch nehmen dürfen. Dazu gehören Dateiübertragungen zwischen Rechnern. Der Transfermanager bietet Dienstleistungen zur Dateiübertragung an. Beispielsweise wird das Bild eines Benutzers, der einer Sitzung neu beitritt, über diesen Kanal versendet. Der Transfermanager kann auch von verteilten Anwendungen genutzt werden.

Sitzungsverwaltung

Ein wichtiger Grunddienst eines CSCW-Systems ist die Sitzungsverwaltung. Da DreamTeam keine zentrale Instanz besitzt, muß die Sitzungsverwaltung dezentral ablaufen. Für eine bestimmte Sitzung existiert ein ausgezeichneter Teilnehmer, der Urheber der Sitzung. Der Urheber ist derjenige Teilnehmer, der die Sitzung generiert hat, der also das Sitzungsprofil erstellt hat. Der Urheber stellt für alle Sitzungsteilnehmer eine Anlaufstelle für den Sitzungsbeitritt und -austritt dar. Erst wenn der Urheber eine Sitzung gestartet hat, können andere Teilnehmer der Sitzung beitreten. Tritt der Urheber aus der Sitzung aus, so können die anderen Teilnehmer zwar noch weiterarbeiten, es können aber keine weiteren Teilnehmer beitreten. Abbildung 1 zeigt die Übergänge eines Sitzungszyklus. Hierbei sind die einzelnen Zustände jeweils unterteilt in den Zustand des Urhebers und den Zustand eines beliebigen anderen Teilnehmers.


Abbildung 1: Lebenszyklus einer Sitzung

Die Zustände wartend und gestoppt geben an, daß diese Sitzung zur Zeit inaktiv ist. Gestoppte Sitzungen sind mindestens einmal gelaufen, während wartende Sitzungen seit der Generierung durch den Urheber noch nie aktiv waren.

Die Zustände gestartet und läuft zeichnen eine aktive Sitzung aus. Gestartet ist eine Sitzung, wenn die verteilten Anwendungen auf den lokalen Rechnern geöffnet sind. Eine Sitzung mit dem Status läuft gibt an, daß eine Sitzung schon vom Urheber gestartet ist, ein potentieller Teilnehmer ihr aber noch nicht beigetreten ist.

Verteilungskonzept

Es gibt viele Möglichkeiten der Informationsverteilung in einem Gruppensystem. Eine häufig benutzte Form ist Multicast-RPC. Dabei führt ein spezieller Aufruf eines lokalen Systems dazu, daß auf allen Systemen eine Prozedur aufgerufen wird. Hierzu werden die Parameter in geeigneter Form versendet und dem Aufruf mitgegeben. Mit dieser Methode können verschiedene Aufgabenbereiche abgedeckt werden.

DreamTeam verwendet eine spezielle Form von Multicast-RPC. Ein bestimmter Aufruf mit einer vordefinierten Parameterliste führt zu einem verteilten Aufruf auf allen Teilnehmersystemen. Die feste Parameterzahl könnte im ersten Ansatz als Einschränkung gesehen werden. Die DreamTeam-Umgebung ist jedoch objektorientiert aufgebaut und an einer Parameterposition können beliebige Objekte stehen. Hiermit ist es möglich, auch komplexe Strukturen, als Objekt verpackt, an alle Teilnehmer zu versenden. Als einzige Einschränkung muß für das Objekt gelten, daß es serialisierbar ist. Serialisierbare Objekte haben die Fähigkeit, ihre Datenstrukturen über einen Datenkanal zu versenden und am Zielort wieder aufzubauen.

Mit dem Konzept serialisierbarer Objekte wird auch das Problem der Späteinsteiger gelöst. Späteinsteiger sind Sitzungsteilnehmer, die erst der Sitzung beitreten, nachdem schon Aktionen von anderen Teilnehmern ausgeführt wurden. Sie finden also einen nichtinitialen Sitzungszustand vor, der erst übertragen werden muß. Die Objekte, die eine Sitzung repräsentieren, sind in DreamTeam serialisierbare Objekte, so daß sie komplett an die Späteinsteiger übertragen werden können. Nachdem diese die Datenstrukturen komplett geladen und aufgebaut haben, verfügen sie über den aktuellen Sitzungszustand und können von nun an über die Ereignisverteilung schritthaltend den internen Sitzungszustand fortschreiben.

Kommunikationskanäle

DreamTeam verfügt über eine ganzen Satz von Kommunikationskanälen, die nach Bedarf aufgebaut werden. Die Aufteilung in verschiedene Kanalarten ist begründet in unterschiedlichen Nutzungsprofilen für unterschiedliche Aufgaben. Folgende Kommunikationskanäle stehen zur Verfügung:

Verbindungskanäle:
Über diese Kanäle werden die Aktivitäten der verteilten Anwendungen während der Sitzungen übertragen. Es handelt sich um schnelle Verbindungen, da Ereignisse der Anwendungen in Echtzeit ohne nennenswerte Verzögerungen verteilt werden müssen. Sonst wären Irritationen der Benutzer die Folge. Als Übertragungsmedium wurden permanent geöffnete Socketverbindung gewählt. Das schnellere, jedoch unsichere Medium der Datagramme wurde bewußt vermieden, da dann Konsistenzprobleme zu behandeln wären. Sendeaufrufe werden blockierend ausgeführt. Es findet lediglich eine Pufferung statt, um Sender und Empfänger zumindest minimal zu entkoppeln. Der Verwaltungsaufwand für Threads, die eine nicht blockierende Sendeoperation bereitstellen, wurde dadurch eingespart. Zusätzlich bekommt der Sender sofort eine Erfolgskontrolle über seinen Sendebefehl. Die Verbindungskanäle werden beim Start einer Sitzung bzw. beim Beitritt eines Benutzers aufgebaut und bleiben für die Dauer der Teilnahme bestehen. Hiermit wird die Zeit für Auf- und Abbau gespart.

Sitzungskanäle:
Über diese Kanäle werden Abgleichoperationen der teilnehmenden Rechner durchgeführt, also

Vom Wesen her sind diese Operationen weniger zeitkritisch als die Verbindungsereignisse. Sie werden daher von Tasks niederer Priorität behandelt. Der Sendevorgang wird im Hintergrund durchgeführt, ist also nicht blockierend. Es wird ein Thread generiert, der die Sendung durchführt. Die Nachricht über Erfolg oder Mißerfolg der Sendung übergibt der Thread dem System über eine definierte Schnittstelle.

Sitzungskanäle werden nicht permanent gehalten, sondern nur bei Bedarf aufgebaut und nach Beendigung einer Transaktion wieder terminiert.

Transferkanäle:
Sie stellen die langsamste Verbindungsart bereit. Übertragungen (i.d.R. Dateitransfers) können minutenlang dauern und sollten das System wenig belasten. Deshalb bekommen die behandelnden Prozesse die niedrigste Priorität zugeordnet. Analog zu Sitzungsverbindungen findet ein Sendevorgang nicht blockierend statt. Auch hier wird die Verbindung nur bei Bedarf aufgebaut.

Eine Übersicht über die Kanäle ist im folgenden Bild wiedergegeben.


Abbildung 2: Kommunikationskanäle



In der weiteren Entwicklung könnte sich die Notwendigkeit ergeben, einen noch schnelleren Kanal einzuführen. Sollen z.B. Audio- und Videofunktionen in die Umgebung integriert werden, sind völlig neue Anforderungen zu erfüllen. Hierzu reichen die oben beschriebenen Kanalarten nicht aus.

Struktur der DreamTeam-Klassenbibliothek

Die DreamTeam-Umgebung wurde mit Hilfe einer hierarchischen Klassenbibliothek realisiert. Sie umfaßt folgende Ebenen:


Abbildung 3: Ebenen der Klassenbibliothek

Die Realisierung wurde vollständig in Java (JDK1.02) [Sun] vorgenommen. Ein Basispaket (jr-Package) realisiert grundlegende Funktionen, die in der Java-Bibliothek z.Zt. fehlen. Das Basispaket beinhaltet noch keine CSCW-spezifischen Klassen und könnte somit auch für andere Zwecke eingesetzt werden.

Die Serviceschicht (jr.cscw-Package) ist dagegen auf eine CSCW-Umgebung ausgerichtet. Hier befinden sich die Datenstrukturen der oben beschriebenen Profile, die Programmcodes der Tasks sowie der Dialoge zur Konfiguration und Bedienung des Systems.

Neben der allgemeinen Serviceschicht wurde eine applikationsspezifische Serviceschicht (jr.cscw.runtime-Package) realisiert, die auf die allgemeinen Belange der verteilten Anwendungen zugeschnitten ist. Die oberste Schicht wird letztendlich durch das Hauptprogramm der DreamTeam-Applikation und die jeweiligen verteilten Anwendungen dargestellt.

Zur Zeit umfaßt die gesamte Klassenbibliothek 175 Klassen mit über 2000 Methoden. Sie ist komplett in Eigenentwicklung entstanden und wird ständig erweitert.

Benutzungsoberfläche

Plattformunabhängigkeit

Da die Umgebung plattformunabhängig ausgeführt ist, mußte bei der Realisierung der Oberfläche der kleinste gemeinsame Nenner der Dialogelemente aller Plattformen verwendet werden. Im wesentlichen wurden die bekannten Elemente wie Menüs, Listboxen, Eingabefelder, Checkboxen und Knöpfe verwendet. Ein wesentliches Element, von dem in dieser Umgebung verstärkt Gebrauch gemacht wird, fehlt jedoch als Standardelement: das Ikonen-Feld. Es wird in Systemen wie OS/2 oder Windows95 vielfach benutzt, ist jedoch nicht standardisiert. Deshalb wurde ein Ikonen-Feld-Element mit den Standard-Ausdrucksmitteln der graphischen Oberflächen nachimplementiert.

Bei der Realisierung der Umgebung wurde die Plattformunabhängigkeit dadurch gewährleistet, daß auf drei Plattformen gleichzeitig getestet wurde. Diese waren Solaris, Windows95 und OS/2. Prinzipiell dürften zwar keine Unterschiede zwischen den Plattformen auftreten, es hat sich jedoch gezeigt, daß manche Details unterschiedlich wiedergegeben werden. Unvermeidlich können Unterschiede sein, wenn auf einem System z.B. bestimmte Schriftarten nicht vorhanden sind oder graphische Ausprägungen von Dialogelementen in einem bestimmten Format vorliegen müssen. Solche Unterschiede können zu Formatierungsfehlern in Dialogfenstern führen, wenn die Implementierung zu stark auf eine einzige Plattform ausgerichtet ist.

Andere Unterschiede liegen in den speziellen Eigenschaften der Betriebssysteme begründet. So werden beispielsweise Pfad- und Dateinamen unterschiedlich gebildet. Einige Systeme verwalten verschiedene Laufwerke im Dateisystem, andere hängen alle Verzeichnisse unter ein einziges Stammverzeichnis. Solche Unterschiede müssen von der Laufzeitumgebung flexibel abgefangen werden.

Durch das parallele Entwickeln auf drei Plattformen ist gewährleistet, daß Probleme durch plattformspezifische Besonderheiten früh erkannt werden.

Dialogsprache

Die Dialogsprache soll vom Benutzer gewählt werden können. Hiermit können alle systemgenerierten Meldungen in der gewünschten Landessprache ausgegeben werden. Zusätzlich werden alle Dialogelemente mit Texten, also Menüs, Knöpfe, Labels etc., landesspezifisch ausgelegt. Zur Zeit sind die Sprachen Englisch und Deutsch implementiert. Prinzipiell können beliebige Sprachen hinzugefügt werden, wenn sie durch Unicode-Zeichen darstellbar sind.

Der Unicode-Zeichensatz [Uni] gewährleistet eine plattformübergreifende Darstellung länderspezifischer Sonderzeichen. Zur Zeit existiert eine Unterstützung der lateinischen Schriftzeichen mit den europäischen Sonderzeichen (deutsche Umlaute, französische Akzents etc.). Dies entspricht dem Zeichensatz nach ISO-8859-1. Eine Ausweitung auch auf nichtlateinische Zeichen (z.B. chinesische) ist jedoch für die Zukunft geplant.

Beschreibung der wichtigsten Fenster


Abbildung 4: Die wichtigsten Fenster der DreamTeam-Anwendung

Nachdem alle Tasks der Anwendung erfolgreich gestartet sind, gelangt man in das Hauptfenster der Anwendung (Abbildung 4 links). Dieses Fenster ist während der Laufzeit der Anwendung immer offen.

Folgende Funktionen können hier ausgeführt werden:

Die Konfigurationsarbeiten werden in der Regel nur beim initialen Einrichten des Systems durchgeführt. Die Funktion Sitzungen ist die wichtigste Funktion für die laufende Arbeit.

Nach dem Anwählen wird das Sitzungsfenster (Abbildung 4 Mitte) geöffnet. In dem Sitzungsfenster sind alle Sitzungen als Ikonen dargestellt, die dem System bekannt sind. Wird ein fremdes System im Rahmen eines Rendezvous' kontaktiert, so werden die lokal vorliegenden Sitzungslisten ausgetauscht, so daß nachher jedes System die Sitzungsprofile des anderen kennt. Im Sitzungsfenster können wahlweise alle Ikonen oder nur die Ikonen der lokal definierten Sitzungen angezeigt werden.

Der Benutzer kann Sitzungsprofile erstellen, ändern oder löschen. Sitzungen können immer nur vom Urheber modifiziert werden, Sitzungen anderer Rechner werden nur angezeigt. Der Urheber einer Sitzung kann diese starten und öffnet damit die verteilten Anwendungen. Benutzer anderer Rechner können nun der gestarteten Sitzung beitreten. Nach dem Start oder Beitritt öffnet sich neben den Anwendungsfenstern ein weiteres Fenster, das alle zur Zeit teilnehmenden Benutzer anzeigt (Abbildung 4 rechts).

Verläßt ein Benutzer die Sitzung, so wird auch seine Ikone gelöscht. Liegt dem lokalen System ein Bild des Benutzers vor, so wird als Ikone dieses Bild benutzt. Liegt kein Bild vor, so wird versucht, von dem System des Benutzers ein Bild zu laden. Schlägt das fehl, so wird eine Standard-Ikone verwendet.

Built-In-Dienste

Zusätzlich zu dem oben beschriebenen Grundumfang an Diensten wurden weitere Funktionen in die Plattform integriert. Diese Dienste können von Anwendungsentwicklern genutzt werden. Einige Dienste wurden in die DreamTeam-Fenster integriert und können damit von jedem Teilnehmer genutzt werden, ohne daß sie in verteilte Anwendungen integriert sein müssen.

Nachrichtendienst:
Ein einfacher Nachrichtendienst ist in das Teilnehmerfenster integriert. Selektiert man eine oder mehrere Teilnehmerikonen, kann an die entsprechenden Teilnehmer eine Textnachricht versendet werden. Diese Funktion ist unabhängig von einer Chat-Anwendung, die eventuell in der Sitzung gestartet wurde, verfügbar. Erhält ein Teilnehmer eine Nachricht, so öffnet sich automatisch ein entsprechendes Fenster. In diesem kann direkt eine Antwort eingegeben werden, die der ursprünglichen Sender erhält.

Dateiübertragungen:
Eine weitere Funktion des Teilnehmerfensters ist die Möglichkeit, Dateien zu versenden. Ein Teilnehmer selektiert einen anderen Benutzer und wählt die Funktion zur Dateiübertragung aus. Danach öffnet sich eine Dialogbox, mit der die zu versendende Datei ausgewählt werden kann. Nach der Bestätigung wird der andere Teilnehmer über eine Dateiübertragung informiert. Er kann nun entweder diese Übertragung verweigern oder ein Verzeichnis auswählen, in das die Datei geschrieben werden soll. Es ist einem fernen Teilnehmer somit nicht möglich, lesend auf ein lokales Dateisystem zuzugreifen. Die Übertragung erfolgt grundsätzlich nur in der oben beschriebenen Richtung.

Verteilte Mauszeiger:
Die Möglichkeit, seinen eigenen Mauszeiger für andere Benutzer sichtbar zu machen bzw. andere Mauszeiger in den lokalen Fenster darzustellen, ist in die Umgebung integriert. Der Anwendungsentwickler muß lediglich bei der Realisierung eines Fensters eine bestimmte Fensterklasse benutzen, die diese Eigenschaften zur Verfügung stellt. Über spezielle Aufrufe kann gesteuert werden, ob und in welcher Form die Verteilung erfolgen soll. Die Übertragung der Mauspositionen und der Mausereignisse erfolgt mit einem eigenen Protokoll über den Verbindungskanal.