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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.