Document [original]

Fakult¨

at f¨

ur Elektrotechnik, Informatik und Mathematik

Institut f¨

ur Informatik

Mobilit¨

at in der kooperativen Wissensarbeit

Entwicklung einer Musterarchitektur f¨

mobil-verteilte Wissensr¨

aume

Dissertation

Schriftliche Arbeit zur Erlangung

des akademischen Grades

Doktor der Naturwissenschaften

Bernd Eßmann

Paderborn

M¨

arz 2006

Mobilit¨

at in der kooperativen Wissensarbeit

Inhaltsverzeichnis

1 Einleitung 1

2 Szenarien 11

2.1 Pr¨

asenzkooperation............................ 14

2.1.1 Lerngruppe............................ 15

2.1.2 Spontane Kooperation . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern . . . . . . . . . . . 34

2.2.1 R¨

aumlich getrennte Kooperation . . . . . . . . . . . . . . . . 36

2.2.2 Distant Learning . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.3 Herausforderungen mobil-verteilter Kooperation . . . . . . . . . . . . 50

3 Anforderungen 53

3.1 Phasen mobil-spontaner Kooperation . . . . . . . . . . . . . . . . . . 55

3.2 Medienfunktionen und Mobilit¨

at .................... 57

3.3 Neue Qualit¨

aten mobiler Kollaboration . . . . . . . . . . . . . . . . . 60

3.3.1 Vernetzung und Sichtbarkeit . . . . . . . . . . . . . . . . . . 61

3.3.2 Kontextualisierung . . . . . . . . . . . . . . . . . . . . . . . . 63

3.3.3 Konsistenz und Reversibilit¨

at.................. 66

3.4 Neue Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.1 Kommunikation ......................... 75

3.4.2 Koordination ........................... 80

3.4.3 Kooperation ........................... 83

3.5 Zusammenfassung ............................ 85

4 L¨

osungsans¨

atze f¨

ur eine technische Umsetzung 87

4.1 Knotenaufbau – Microkernel . . . . . . . . . . . . . . . . . . . . . . . 88

4.2 Vernetzung und Sichtbarkeit . . . . . . . . . . . . . . . . . . . . . . . 90

4.2.1 Protokolle zur Vernetzung mobiler Knoten . . . . . . . . . . . 92

4.2.2 Vernetzung verteilter Dienste . . . . . . . . . . . . . . . . . . 98

4.2.3 Netzwerktopologie . . . . . . . . . . . . . . . . . . . . . . . . 99

4.3 Persistenz................................. 100

4.3.1 Verteilte Persistenzsysteme . . . . . . . . . . . . . . . . . . . 101

4.3.2 Verteilte Persistenz als gemeinsamer Speicher . . . . . . . . . 116

4.3.3 Konsistenz in verteilten Persistenzsystemen . . . . . . . . . . 118

4.4 Ereigniskontrolle ............................. 120

iii

iv Inhaltsverzeichnis

5 Musterarchitektur mobil-verteilter Wissensr¨

aume 129

5.1 Replikationsstrategien f¨

ur die mobil-spontane Kooperation . . . . . . 130

5.2 Gruppen-Tuple Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.3 Einbettung externer Dienste . . . . . . . . . . . . . . . . . . . . . . . 143

5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume........... 145

6 Schluss und Ausblick 155

Literatur 177

Stichwortverzeichnis 179

Mobilit¨

at in der kooperativen Wissensarbeit

Abbildungsverzeichnis

2.1 Der Prozess einer mobil-spontanen Kooperation . . . . . . . . . . . . 13

3.1 Anforderungen mobilit¨

atsunterst¨

utzender Kooperationsumgebungen 55

3.2 Der Kollaborationsprozess als Regelkreis . . . . . . . . . . . . . . . . 56

3.3 Schl¨

usselfaktoren mobil-verteilter Wissensr¨

aume ........... 61

3.4 Verkn¨

upfung von realem Raum und virtuellem Wissensraum . . . . 65

3.5 Kollaboration – Kommunikation, Koordinierung und Kooperation . 75

4.1 In die Schaffung mobil-verteilter Wissensr¨

aume involvierte Forschungs-

bereiche .................................. 88

4.2 Mobil-verteilter Wissensraum: Handlungs- und Umsetzungsebene . . 89

4.3 Auf DHTs basierende Overlay-Netzwerk-Protokolle und deren An-

wendungen ................................ 105

4.4 Abbildung eines physikalischen Netzwerkes in einen logischen Adress-

raum.................................... 106

4.5 Verwaltungstabellen und Routinginformationen eines Pastry-Knotens 108

4.6 Auswirkung der Lokalit¨

at auf das Routing in DHTs . . . . . . . . . 109

4.7 Initialisierung der Verwaltungstabellen beim Anmelden eines neuen

Knotens in ein Pastry-Netzwerk . . . . . . . . . . . . . . . . . . . . . 110

4.8 Pastrys Selbstorganisation im Fall einer Netzwerksegmentierung . . . 110

4.9 Das Replikationsverfahren von PAST . . . . . . . . . . . . . . . . . . 113

4.10 Trade-off verteilter Persistenzkonzepte . . . . . . . . . . . . . . . . . 115

4.11 Abonnieren eines bereits ver¨

offentlichten Themas in Scribe . . . . . . 123

4.12 Abbestellen eines abonnierten Themas in Scribe . . . . . . . . . . . . 124

4.13 Gegen¨

uberstellung von Single-Multicast und Multiple-Unicast . . . . 125

5.1 Offline-Verf¨

ugbarkeit in einer verteilten Persistenzschicht . . . . . . . 130

5.2 Schematische ¨

Ubersicht des Versionierungsmechanismus . . . . . . . 132

5.3 Der Hypercube als Distributionstopologie . . . . . . . . . . . . . . . 135

5.4 Distributionstopologie basierend auf einem Sparse Graphen . . . . . 137

5.5 Replikation des Gruppen-Tuple Space zwischen Independent Nodes . 141

5.6 Virtuelle Wissenr¨

aume zweier Kooperationsgruppen mit den zugeord-

neten Gruppen-Tuple Spaces . . . . . . . . . . . . . . . . . . . . . . 142

5.7 Exemplarische Architektur einer mobil-spontanen Kooperationsum-

gebung................................... 147

vi Abbildungsverzeichnis

Mobilit¨

at in der kooperativen Wissensarbeit

1 Einleitung

Mobilit¨

at bestimmt in der heutigen Welt wesentliche Faktoren im Leben der Men-

schen. Mobile Ger¨

ate und Infrastrukturen sind zu einem festen Bestandteil des All-

tagslebens geworden. Der naheliegende Wunsch, die neuen technischen M¨

oglichkei-

ten f¨

ur eine kooperative Wissensstrukturierung in mobilen Alltagssituationen zu

nutzen, bleibt dennoch bis heute unerf¨

ullt. Bei der Suche nach den Gr¨

unden f¨

das Fehlen einer durchg¨

angigen Unterst¨

utzung mobiler Kooperationsprozesse hilft

eine Betrachtung der Entwicklungsstr¨

ange kooperativer Wissensstrukturierung und

mobilen Arbeitens.

Ausgehend von einer zun¨

achst isolierten Dokumentenverarbeitung und sp¨

ateren

Workflow-Systemen haben sich in der heutigen Arbeitswelt Groupware- und Com-

puter Supported Cooperative Work (CSCW)-Systeme etabliert, die ein kooperatives

Bearbeiten von Dokumenten erlauben. Aus einer technischen Perspektive spiegelt

sich diese Entwicklung in fest vernetzten Kommunikations- und Kooperationsstruk-

turen wider. In diesen Strukturen nehmen dedizierte Server eine zentrale Rolle f¨

die Koordination der Kooperationsprozesse und die persitente Speicherung der ge-

meinsam genutzten Dokumente ein.

Parallel zu diesen zentralisierten Strukturen begleiten mobile Computer ihre Besit-

zer in allen Lebenslagen und f¨

uhren so zu neuen Formen der Mobilit¨

at in computer-

gest¨

utzten Arbeitsprozessen. Der Arbeitsplatz wird nicht l¨

anger von dem Standort

des Computers bestimmt, sondern kann an jedem Aufenthaltsort des Benutzers sein.

Die Integration funkbasierter Netzwerkschnittstellen in mobile Computer erh¨

oht zu-

dem die Unabh¨

angigkeit der Benutzer von Netzwerk- und Telefonanschl¨

ussen und

erm¨

oglicht – zumindest theoretisch – einen flexiblen Zugang zu etablierten Netz-

werkstrukturen und eine direkte Vernetzung mobiler Ger¨

ate untereinander.

Die M¨

oglichkeiten der spontanen Vernetzung der Mobilger¨

ate ¨

uber mobile Ad-

Hoc-Netzwerke enth¨

alt ein hohes Potential f¨

ur eine direkte und unabh¨

angige com-

putergest¨

utzte Interaktion der mobilen Benutzer. Dennoch bleiben die Nutzer in

ihrer Mobilit¨

at oft isoliert und arbeiten auf einem pers¨

onlichen Dokumentenfundus.

Diese Isolation wird oft lediglich tempor¨

ar durch einen sporadischen Austausch von

Dokumenten unterbrochen. Es fehlt die langfristige Integration einer kooperativen

Dokumentenbearbeitung. Daher findet auch eine computergest¨

utzte Kooperation im

mobilen Umfeld kaum statt.

Lediglich in Reichweite von Zugangspunkten zu klassischen Netzwerkinfrastruk-

turen verbinden sich die Benutzer mit zentralen Kooperationsdiensten und nut-

zen diese wie bei einem station¨

aren Rechner. Trotz der M¨

oglichkeit einer Ad-Hoc-

Vernetzung ist eine spontane Kooperation zwischen Benutzern in einer mobilen Um-

gebung ohne feste Kooperationsinfrastrukturen ¨

außerst selten. Das Brachliegen die-

2 1 Einleitung

ser nahe liegenden Verwendung mobiler Computer f¨

ur spontane Kooperationssitzun-

gen wirft Fragen nach den Gr¨

unden auf.

Die Realisierung einer mobilit¨

atsfreundlichen Kooperationsumgebung ist aber oh-

ne ein Wissen um die Nutzungsszenarien und die strukturellen Grenzen einer techni-

schen Realisierung nicht m¨

oglich. Diese Arbeit untersucht daher anhand des Wech-

selspiels zwischen den Nutzungsszenarien die Probleme, die sich aus einer Zusam-

menf¨

uhrung der Techniken aus dem Feld der mobilen Vernetzung und des CSCW

ergeben. Mangels einer durchgehenden Persistenz in mobilen Netzwerken ist da-

bei unklar wie eine l¨

angerfristige Kooperationen in einem mobilen Umfeld zustande

kommen soll.

Um diese fehlende Konvergenz beider Entwicklungen zu beschreiben werden im

Rahmen dieser Arbeit Nutzungsszenarien entwickelt, die eine Verkn¨

upfung von mo-

bilen und spontanen Netzwerken mit kooperationsunterst¨

utzenden Infrastrukturen

betrachten. Derzeit bekannte Szenarien bewegen sich zumeist isoliert in einer der

beschriebenen Welten. Klassische CSCW-Szenarien beschr¨

anken sich h¨

aufig auf die

Zusammenarbeit in etablierten Infrastrukturen, w¨

ahrend sich Szenarien der mo-

bilen Vernetzung auf die Aspekte mobilit¨

atsfreundlicher Netzwerke konzentrieren.

Nutzungsszenarien f¨

ur eine Verkn¨

upfung von computergest¨

utzter Kooperation und

spontaner Vernetzung sind hingegen bis heute relativ unerforscht.

Ein wesentliches Ziel der entwickelten Nutzungsszenarien ist die Ermittlung der

spezifischen funktionalen Elemente, die essentiell f¨

ur eine Unterst¨

utzung mobiler

Kooperationsprozesse sind. Diese funktionalen Anforderungen h¨

angen von den tech-

nischen Elementen der angestrebten Kooperationsumgebung ab. Da sich die techni-

schen Elemente ihrerseits an den funktionalen Anforderungen orientieren, bedingen

sich beide Ebenen der Anforderungsbestimmung gegenseitig. Im Rahmen dieser Ar-

beit werden zur Unterscheidung dieser Anforderungsebenen die Begriffe Handlungs-

ebene f¨

ur die funktionalen Anforderungen und Umsetzungsebene f¨

ur die technischen

Anforderungen gepr¨

agt.

Die hier entwickelten Nutzungsszenarien helfen zun¨

achst die Anforderungen auf

der Handlungsebene zu ermittelten. Ein wichtiges Resultat ist der freie und spontane

Charakter der Kooperation infolge der Unabh¨

angigkeit von festen Infrastrukturen.

Die sporadischen und spontanen Verbindungen zu den Kooperationspartnern ¨

ahneln

dabei stark einer nat¨

urlichen Zusammenarbeit in Situationen des t¨

aglichen Lebens.

In diesen treffen sich Personen bewusst oder auch zuf¨

allig und beginnen eine koope-

rative Handlung aus dem momentanen Kontext heraus.

Die Spontanit¨

at der kooperativen Handlung und die hohe Bedeutung des aktuellen

Kontextes der Kooperationspartner werden in dieser Arbeit als eine der wesentlichen

Herausforderungen an die technischen wie funktionalen Komponenten der zuk¨

unf-

tigen mobilen Kooperationsumgebung identifiziert. Insbesondere die funktionalen

Elemente der Kooperationsunterst¨

utzung m¨

ussen dem freien und flexiblen Charak-

ter der Zusammenarbeit gerecht werden. Daher setzt der hier entworfene Ansatz auf

das langj¨

ahrig erprobte Konzept der virtuellen Wissensr¨

aume1mit den zugeh¨

origen

1Vgl. [Hampel, 2001]

Mobilit¨

at in der kooperativen Wissensarbeit

prim¨

aren Medienfunktionen als eine Verk¨

orperung freier dokumentenzentrierter Ko-

operation. Die virtuellen Wissensr¨

aume bieten die wesentlichen Mechanismen f¨

ur ein

freies Arbeiten und stellen ¨

uber persistente Objekte auch eine l¨

angerfristige Grup-

penarbeit sicher. Diese Nachhaltigkeit k¨

onnen die h¨

aufig verfolgten kommunikativen

L¨

osungsans¨

atze nicht leisten. Daher wird in dieser Arbeit der Ansatz einer ¨

Uberf¨

uh-

rung des Konzeptes der virtuellen Wissensr¨

aume in eine mobile Netzwerkumgebung

verfolgt und unter dem Begriff der mobil-verteilten Wissensr¨

aume zusammengefasst.

Im Feld derzeit verf¨

ugbarer L¨

osungsans¨

atze aus Forschung und Industrie zeigen

sich zwei unterschiedliche Herangehensweisen an die Vernetzung mobiler Compu-

ter: Erstere erweitert existierende feste Netzwerkinfrastrukturen mit fl¨

achendecken-

den Zugangsm¨

oglichkeiten f¨

ur Mobilger¨

ate; Zweitere schafft neue Protokolle f¨

ur eine

spontane Vernetzung mobiler Computer in selbstorganisierenden Netzwerken. Zu-

k¨

unftig d¨

urfte sich eine heterogene Netzwerkinfrastruktur aus von Dienstanbietern

bereitgestellten festen Infrastrukturen und untereinander spontan vernetzten Mobil-

ger¨

aten ergeben. ¨

Uberg¨

ange zwischen diesen Strukturen besitzen eine hohe Dynamik

und machen eine Vorhersage ¨

uber deren Verf¨

ugbarkeit schwierig. Die ¨

Uberf¨

uhrung

der virtuellen Wissensr¨

aume in die Welt der mobilen Vernetzung f¨

uhrt zu bisher

nicht betrachteten Problemstellungen, die im Rahmen dieser Arbeit herausgearbei-

tet werden.

Betrachtet man die Ad-Hoc-Vernetzung der beteiligten Ger¨

ate als Basis einer

mobil-spontanen Kooperation, l¨

asst diese, im Gegensatz zu den herk¨

ommlichen An-

s¨

atzen des CSCW, keine Server-zentrierten Architekturen mehr zu. Die Speicherung

der Inhalte und die Verwaltung der Kooperationsumgebung kann nicht l¨

anger ein

dedizierter Server ¨

ubernehmen, da von dessen Verf¨

ugbarkeit die Funktionsf¨

ahigkeit

der gesamten Kooperationsumgebung abh¨

angt. Als alternative Architektur verfolgt

diese Arbeit eine verteilte Verwaltung und Speicherung der Kooperationsinhalte auf

den beteiligten Knoten. Diese Vorgehensweise erm¨

oglicht eine Gew¨

ahr der Verf¨

ug-

barkeit der Kooperationsumgebung auch in mobilen Nutzungsszenarien. Bei Ausfall

eines Knotens k¨

onnen dessen Aufgaben automatisch auf die verbliebenen Knoten

transferiert werden. Jedoch gestalten sich innerhalb dynamischer Netzwerkstruktu-

ren die persistente Speicherung von Kooperationsobjekten und der nahtlose Zugriff

auf diese durch alle Kooperationspartner ¨

außerst schwierig.

Eine wesentliche Problemstellungen ist daher die persistente Speicherung von Ko-

operationsobjekten, die gerade in dokumentenzentrierten Kooperationskonzepten,

wie dem der virtuellen Wissensr¨

aume, von zentraler Bedeutung ist. Daher orientie-

ren sich die in dieser Arbeit entwickelten Ans¨

atze an einer Bereitstellung persistenter

virtueller Wissensr¨

aume in mobil-spontanen Kooperationsszenarien. Die Frage einer

verteilten und persistenten Speicherung des gemeinsamen Wissensraums beinhaltet

auch die Vermeidung von Medienbr¨

uchen2infolge von Verbindungsabbr¨

uchen zur

eigenen Kooperationsgruppe und deren Ressourcen. Daher stellt diese Arbeit die

Forderung auf, Kooperationsobjekte auch dann erreichen zu k¨

onnen, wenn gerade

2Vgl. [Keil-Slawik und Selke, 1998]

Mobilit¨

at in der kooperativen Wissensarbeit

4 1 Einleitung

keine Verbindung zu den Kooperationspartnern und Kooperationsinfrastrukturen

besteht. Diese Forderung wird im Folgenden als Offline-Verf¨

ugbarkeit definiert.

Um die Verf¨

ugbarkeit der f¨

ur die Kooperation ben¨

otigten Dokumente auch bei Ab-

wesenheit einiger Knoten des Netzwerkes garantieren zu k¨

onnen, wird im Rahmen

des entwickelten L¨

osungsansatzes im Wesentlichen die Strategie einer Distribution

und Replikation der Kooperationsobjekte verfolgt. W¨

ahrend die Distribution Objek-

te auf mehreren Knoten verteilt speichert und dadurch verhindert, dass der gesamte

Datenraum von lokalen Ausf¨

allen betroffen ist, speichert die Replikation Objekte

redundant auf mehrere Knoten und erh¨

oht so deren generelle Verf¨

ugbarkeit. Die

Persistenz und die Verf¨

ugbarkeit der Kooperationsobjekte h¨

angen somit stark von

den Distributions- und Replikationsstrategien der verteilten Kooperationsumgebung

ab. Sie bestimmen auch die Eignung der Kooperationsumgebung f¨

ur einen Einsatz

im mobilen Nutzungsumfeld.

Derzeitige Ans¨

atze f¨

ur eine Persistenz in verteilten Systemen, wie z. B. die Distri-

buted Hashtables (DHT), verteilen und replizieren Datenobjekte scheinbar zuf¨

allig

auf die Knoten des Netzwerkes. Eine n¨

ahere Betrachtung im Rahmen dieser Ar-

beit ergibt, dass sie daher eine gesteuerte Verf¨

ugbarkeit von Objekten auf einzelnen

Knoten nicht ohne weiteres gew¨

ahrleisten k¨

onnen. Insbesondere fehlt oftmals die

M¨

oglichkeit, Objekte zwischen den replizierenden Knoten zuverl¨

assig abzugleichen,

wenn beteiligte Knoten zeitweise nicht im Netzwerk verf¨

ugbar sind.

Ziel dieser Arbeit ist eine Musterarchitektur, die geeignete Komponenten der For-

schungsfelder der computergest¨

utzten Kooperation und der spontanen Vernetzung

verkn¨

upft und um fehlende Elemente erg¨

anzt, um so eine Unterst¨

utzung der ent-

wickelten Nutzungsszenarien zu erm¨

oglichen. Dies geschieht sowohl ausgehend von

existierenden CSCW-Strukturen als auch von verf¨

ugbaren Techniken spontaner Ver-

netzung. Der Einsatz verf¨

ugbarer und erprobter Technologien erm¨

oglicht schon in

fr¨

uhen Phasen des Entwurfs eine alltagspraktische L¨

osung zu erlangen. Daher werden

klassische Konzepte der Gruppenarbeit mit neuen M¨

oglichkeiten der mobilen Ad-

Hoc-Netzwerke so zusammengebracht, dass eine durchg¨

angige Nutzung ¨

uber diesen

Bereich entsteht und Medienbr¨

uche verringert werden, die einer langfristigen Nut-

zung im Wege stehen.

Dazu m¨

ussen im Rahmen dieser Arbeit Probleme der verteilten Speicherung und

Verwaltung der Kooperationsumgebung gel¨

ost werden. Diese Fragestellungen werden

ausgehend von den entwickelten Nutzungsszenarien angegangen und bestimmen so

den Aufbau der Arbeit. Zuerst werden daher die angesprochenen Nutzungsszenarien

erarbeitet, ohne die eine Eingrenzung der funktionellen und technischen Anforde-

rungen nicht m¨

oglich ist. Um die L¨

ucke zwischen CSCW-Systemen und mobilen

Netzwerken zu schließen, werden anhand der dort ermittelten Anforderungen die

ben¨

otigten Komponenten f¨

ur eine Musterarchitektur mobil-verteilter Wissensr¨

au-

me identifiziert. Diese Komponenten werden in einem n¨

achsten Schritt durch eigens

entwickelte Strategien erg¨

anzt. Erst diese Strategien erlauben eine Verkn¨

upfung der

Komponenten zu der gesuchten Musterarchitektur. Zu diesem Zweck wird im Rah-

men der vorliegenden Arbeit eine an die Gegebenheiten der mobil-verteilten Koope-

Mobilit¨

at in der kooperativen Wissensarbeit

ration angepasste mobilit¨

atsfreundliche Distributions- und Replikationsstrategie f¨

eine verteilten Persistenz entworfen.

Mangels vergleichbarer Infrastrukturen werden nach der Einleitung in Kapitel 2

Nutzungsszenarien der mobilen Kooperation in verteilten Softwareumgebungen ent-

worfen und f¨

ur eine Bestimmung der zentralen Anforderung an mobil-verteilte Ko-

operationssysteme genutzt. Die dort entworfenen Szenarien orientieren sich sowohl

an der scheinbar ”nat¨

urlichen“ computergest¨

utzten Zusammenarbeit in mobilen Le-

benssituationen, als auch an der r¨

aumlich getrennten Kooperation in klassischen

CSCW-Systemen. Die Szenarien erlauben dabei eine Beschreibung von Kooperati-

onskonstellationen, die auf technischer Ebene zurzeit noch nicht definierbar sind.

Diese sind Mischungen aus Pr¨

asenzszenarien und Szenarien r¨

aumlich getrennter Ko-

operation. Besonders f¨

ur solche Mischszenarien existieren bis dato keine ad¨

aquaten

Vorschl¨

age f¨

ur deren Gestaltung. Ihnen wird in dieser Arbeit daher ein besonderer

Stellenwert einger¨

aumt.

Grundlage der Nutzungsszenarien ist stets eine Kooperation auf Basis eines ge-

meinsamen Fundus von Dokumenten. Die in den Nutzungsszenarien f¨

ur eine compu-

tergest¨

utzten Kooperation verwendeten Werkzeuge entstammen heutigen CSCW-

Systemen und werden in einen mobilen Kontext transferiert. Da die Arbeitswelt

im Sinne klassischer Workflows st¨

arker formalisiert ist und die Lernwelt einen eher

konstruktivistischen Ansatz mit offener Zusammenarbeit darstellt, entstammen die

entwickelten Nutzungsszenarien zu je einer H¨

alfte der Welt des Lernens und des Ar-

beitens. Innerhalb der entwickelten Szenarien wird von der st¨

andigen Verf¨

ugbarkeit

der gemeinsam genutzten Dokumente f¨

ur alle Teilnehmer ausgegangen, auch wenn

diese nicht ¨

uber ein Netzwerk in Verbindung stehen.

Bei der Betrachtung der Szenarien stellt sich heraus, dass diese sich ¨

uber den ge-

samten Kooperationsprozess in drei Phasen gliedern, die jeweils sehr unterschiedliche

Aktivit¨

aten enthalten. Die erste Phase ist die der Gr¨

undung, in der die Teilnehmer die

Kooperation bewusst oder unbewusst beginnen. In der Phase der Kooperation erfolgt

die eigentliche Zusammenarbeit basierend auf den gemeinsam genutzten Dokumen-

ten. Die letzte Phase ist die der Aufl¨

osung. Sie wird in klassischen CSCW-Szenarien

kaum betrachtet. Ihr kommt im mobilen Nutzungsumfeld jedoch eine besondere Be-

deutung zu.

Die Phase der Aufl¨

osung entspringt der im Rahmen dieser Arbeit vorgenomme-

nen Betrachtung der Dynamik in spontanen Kooperationsprozessen. Aufgrund der

Mobilit¨

at der Teilnehmer darf eine starke Fluktuation innerhalb der Gruppenstruk-

tur angenommen werden. Jedes Verlassen der Kooperation kommt f¨

ur Benutzer

im mobilen Umfeld einer Aufl¨

osung derselben gleich, da ein Wiederkehren in die

Kooperation mit der gleichen Teilnehmerkonstellation aufgrund der Mobilit¨

at aller

Teilnehmer nicht vorausgesagt werden kann. Oftmals wird die Kooperation in einer

anderen Nutzungskonstellation weitergef¨

uhrt, so dass die Aufl¨

osung auch als eine

Art ¨

Ubergang begriffen werden kann. Analog dazu wird das Wiedereintreten in die

Kooperation als Gr¨

undung mit einer anderen Teilnehmerkonstellation betrachtet.

Trotz der Mobilit¨

at der Nutzer tragen die entwickelten Szenarien dem Umstand

Rechnung, dass auch eine mobile Kooperation an bestimmte Orte gebunden sein

Mobilit¨

at in der kooperativen Wissensarbeit

6 1 Einleitung

kann oder aus einem bestimmten Ortskontext heraus entsteht. Dies macht den Nut-

zungskontext zu einem wichtigen Aspekt dieser Szenarien. Mit steigender Mobilit¨

gewinnt dieser an Bedeutung. Die Nutzbarmachung des Nutzungskontextes ist daher

eine wesentliche Fragestellung f¨

ur die im Rahmen dieser Arbeit entworfene Muster-

architektur einer mobilit¨

atsunterst¨

utzenden Kooperationsumgebung.

Weiterhin werden die Szenarien in zwei Gruppen unterteilt. Die erste Gruppe

bilden die Szenarien der Pr¨

asenzkooperation, die der ”nat¨

urlichen“ Kooperation bei

einem pers¨

onlichen Treffen der Teilnehmer entspricht. Die zweite Gruppe bildet die

Kooperation mit r¨

aumlich verteilten Teilnehmern und orientiert sich eher an klassi-

schen CSCW-Szenarien mit ¨

ortlich getrennten Kooperationspartnern, ¨

ubertr¨

agt die-

se aber auf eine mobil-verteilte Kooperationsumgebung. Die Szenarien beider Grup-

pen werden grunds¨

atzlich auch hinsichtlich der M¨

oglichkeit des nahtlosen ¨

Ubergangs

zwischen Pr¨

asenzkooperation und r¨

aumlich getrennter Kooperation betrachtet. Sie

tragen zudem der Option Rechnung, existierende CSCW-Systeme in die Kooperati-

on integrieren zu wollen.

Die entworfenen Szenarien sind die Grundlage f¨

ur die Beschreibung der techni-

schen Rahmenbedingungen der Umsetzungsebene. Die in Kapitel 3 untersuchten

Anforderungen an die Musterarchitektur mobil-verteilter Wissensr¨

aume resultieren

direkt aus den Handlungsmustern der einzelnen Szenarien. In dem aufgestellten An-

forderungskatalog an die zuk¨

unftige mobil-verteilte Kooperationsumgebung identifi-

ziert diese Arbeit als wesentliche Problembereiche die ”

Vernetzung und Sichtbarkeit“

der Kooperationspartner, die ”Kontextualisierung“ der Kooperationsumgebung und

die ”Konsistenz“ der verteilt und redundant gespeicherten Kooperationsobjekte.

Die Anforderungen im Bereich ”

Vernetzung und Sichtbarkeit“ der Kooperations-

partner werden als direkte Folge der Mobilit¨

at der Benutzer in den Szenarien iden-

tifiziert. Sie lassen sich zumeist der Phase der Gr¨

undung zuordnen. Erster Schritt

der Kooperation ist stets die Etablierung einer Kommunikation zwischen den Ko-

operationspartnern. Mangels eines zentralen Verzeichnisses verf¨

ugbarer Dienste und

Benutzer m¨

ussen die Informationen in der verteilten Umgebung gesammelt und auf-

bereitet werden. Erst anhand dieser Informationen kann eine Kooperationsgruppe

etabliert werden.

Speziell im Umfeld großer Kooperationsstrukturen und verschiedenster angebote-

ner Dienste sind Mechanismen der Kontextualisierung der Kooperationsumgebung

notwendig, um eine Auswahl potentieller Kooperationspartner und -dienste treffen

zu k¨

onnen. Diese Forderung verlangt insbesondere eine Unterst¨

utzung der Benutzer

durch eine Bereitstellung von Kontextinformationen. Diese betreffen sowohl potenti-

elle Kooperationspartner als auch verf¨

ugbare Dienste im aktuellen Kooperationsum-

feld. Daher k¨

onnen Kontextinformationen in jeder Phase der Kooperation genutzt

werden, um die Benutzer im Kooperationsprozess zu unterst¨

utzen.

Die ebenfalls ermittelte Anforderung der Konsistenz der Kooperationsobjekte ent-

stammt der in der Mobilit¨

at der Nutzer begr¨

undeten Forderung nach einer Vertei-

lung und Replikation der gemeinsamen Kooperationsobjekte auf die mobilen Ger¨

ate

aller beteiligter Kooperationspartner, um eine st¨

andigen Verf¨

ugbarkeit der gemein-

sam genutzten Dokumente zu gew¨

ahrleisten (Offline-Verf¨

ugbarkeit). Bei einer Zu-

Mobilit¨

at in der kooperativen Wissensarbeit

sammenarbeit mittels derart stark replizierten Datenr¨

aumen m¨

ussen alle Repliken

stets synchronisiert werden. Im Falle eines Konflikts m¨

ussen zudem die abweichen-

den ¨

Anderungen beliebig r¨

uckg¨

angig gemacht oder ver¨

andert werden k¨

onnen. Diese

Anforderungen werden in dieser Arbeit unter den Bergriffen ”Synchronizit¨

at“ und

”Reversibilit¨

at“ zusammengefasst.

Neben den Anforderungen, die aus der neuen Qualit¨

at der mobilen Nutzung ver-

teilter Kooperationsumgebungen entstehen, werden des Weiteren auch die Funk-

tionen herk¨

ommlicher zentralisierter Kooperationssysteme speziell im mobilen Nut-

zungskontext betrachtet. Dabei offenbart sich ein Anpassungsbedarf herk¨

ommlicher

Funktionen der Kooperationsunterst¨

utzung f¨

ur deren Nutzung in mobil-verteilten

Systemen. Diese Funktionen entstammen den Basisdiensten der Bereiche Kommuni-

kation,Koordination und Kooperation, welche die Basis der Kooperation in mobilen

Nutzungsszenarien darstellen. Aufgrund ihres neuartigen mobil-spontanen Charak-

ters wird diese Form der Kooperation im Rahmen dieser Arbeit Kollaboration ge-

tauft.

Die in Kapitel 3 ermittelten Anforderungen an eine Basisarchitektur f¨

ur die Bereit-

stellung virtueller Wissensr¨

aume in einem mobil-verteilten Nutzungsumfeld werden

in Kapitel 4 auf bereits existierender L¨

osungsans¨

atze aus den Forschungsfeldern der

mobilit¨

atsunterst¨

utzenden Netzwerktechnologien, der verteilten Kommunikations-

wie Persistenzsysteme und der Kooperationssysteme untersucht.

Es zeigt sich, dass die ben¨

otigten Protokolle zur Vernetzung und Kommunikation

in mobilen und weitr¨

aumig verteilten Systemen vorhanden, aber noch nicht in all-

t¨

agliche Arbeitsumgebungen integriert sind. Mittels einer Kombination von existie-

renden und spontan etablierten Netzwerken l¨

asst sich eine weitr¨

aumige und flexible

Kommunikationsstruktur aufbauen. F¨

ur die noch fehlende automatische Vernetzung

verteilt bereitgestellter Dienste in derartigen Netzwerken existieren ebenfalls L¨

osun-

gen, die bereits in heutigen Netzwerkstrukturen zum Einsatz kommen.

Anders verh¨

alt es sich bei Systemen zur Realisierung verteilter Persistenz. Zwar

findet sich eine große Anzahl von L¨

osungsans¨

atzen, insbesondere im Bereich der ver-

teilten Hash-Tabellen (DHT), sie erweisen sich aber als zun¨

achst wenig geeignet f¨

mobile Kooperationsszenarien. Durch ihre Konzentration auf die Aufrechterhaltung

des Gesamtsystems bei Knotenausf¨

allen erlauben sie keine Offline-Verf¨

ugbarkeit des

unverbundenen Knotens. Wie die im Rahmen dieser Arbeit entwickelten Nutzungs-

szenarien zeigen, spielt diese jedoch in mobilen Kooperationsszenarien eine wichtige

Rolle, da eine Aufrechterhaltung der Grundfunktionalit¨

at der Kooperationsumge-

bung und somit eine lokale Replikation der Kooperationsobjekte auf dem unver-

bundenen Knoten ben¨

otigt wird. Dennoch liefern die DHTs dank eines von ihnen

aufgespannten so genannten Overlay-Netzwerks interessante Ans¨

atze f¨

ur die Adres-

sierung von Knoten in verteilten Systemen. Daher wird in der vorliegenden Arbeit

der Ansatz der DHTs weiter verfolgt. Die beschriebenen Beschr¨

ankungen bez¨

uglich

der Gew¨

ahrleistung einer Offline-Verf¨

ugbarkeit werden dazu mit Hilfe der in Kapi-

tel 5 entworfenen Distributions- und Replikationsstrategie umgangen.

Weiterhin wird in dieser Arbeit mit den bew¨

ahrten Tuple Spaces ein Konzept auf-

gegriffen, das einen einfachen und r¨

aumlich wie zeitlich entkoppelten Zugriff auf die

Mobilit¨

at in der kooperativen Wissensarbeit

8 1 Einleitung

Kooperationsobjekte erlaubt. Bereits existierende L¨

osung f¨

ur spontan vernetzte Tu-

ple Spaces fehlt aber ein Konzept zur Gew¨

ahrleistung einer persistenten Speicherung

gemeinsam genutzer Kooperationsobjekte unter Wahrung der Offline-Verf¨

ugbarkeit.

Diese L¨

ucke wird mit dem in Kapitel 5 entworfenen Konzept derGruppen-Tuple

Spaces geschlossen.

In Kapitel 4 werden die wesentlichen Komponenten f¨

ur eine Musterarchitektur

mobil-verteilter Wissensr¨

aume identifiziert. Im darauf folgenden Kapitel 5 wird die

Integration der gew¨

ahlten L¨

osungsans¨

atze betrachtet. Insbesondere werden die er-

mittelten Defizite der betrachteten L¨

osungsans¨

atze hinsichtlich einer Unterst¨

utzung

mobil-verteilter Kooperation systematisch behoben. Dazu werden sie mit eigens auf

die Bed¨

urfnisse einer mobil-verteilten Kooperation zugeschnittenen konzeptionellen

und technischen Bausteine zu der gesuchten Musterarchitektur erg¨

anzt.

Als Grundlage f¨

ur die technische Realisierung einer verteilten Persistenz dienen die

innovativen Konzepte der DHTs. Die vorliegende Arbeit entwirft zus¨

atzlich, basie-

rend auf den Anforderungen der betrachteten Szenarien, eine gezielte Distributions-

und Replikationsstrategie inklusive einer Versionierung der verteilten Objekte. Die

Versionierung dient dabei der ¨

Uberwachung der Konsistenz des verteilten Daten-

raumes und unterst¨

utzt die kooperative Behebung von Konsistenzkonflikten. Even-

tuelle Konfliktsituationen, die nicht von der Kooperationsumgebung automatisch

behoben werden k¨

onnen, werden mit einem an verteilte Dateisysteme angelehnten

Mechanismus gel¨

ost. Er erlaubt den Benutzern, von einander abweichende Versionen

kooperativ zusammenzuf¨

uhren.

Mit dieser Distributions- und Replikationsstrategie ist es m¨

oglich, Objekte gezielt

an bestimmte Knoten des Kooperationsnetzwerkes zu senden und zwischen diesen

zu replizieren. Was fehlt, ist eine logische Struktur, die hilft, die Replikation der

Objekte zu steuern, und ein Mechanismus, um zwischen zeitweise unverbundenen

Knoten zu kommunizieren. Zu diesem Zweck wird im Rahmen dieser Arbeit das

Konzept der Gruppen-Tuple Spaces entworfen, das eine B¨

undelung replizierender

Knoten in ”Gruppen“ erlaubt. Die Knoten einer Gruppe teilen sich einen gemeinsa-

men und leicht zugreifbaren replizierten Speicher. Gleichzeitig wird eine zeitliche und

r¨

aumlich entkoppelte Kommunikation zwischen den Knoten erreicht, da die Kommu-

nikation in dem Tuple Space ¨

uber eine zeitweise Ablage von Nachrichtenobjekten im

gemeinsamen Tuple Space realisiert wird. Die Nachrichtenobjekte werden automa-

tisch an den Empf¨

anger ausgeliefert, wenn dieser sich das n¨

achste Mal mit dem

Tuple Space verbindet. Dieser Kommunikationsmechanismus wird des Weiteren f¨

die Ereigniskontrolle und Koordination der verteilten Umgebung genutzt.

Auf diese Abstraktionschicht setzen die mobil-verteilten Wissensr¨

aume auf. Je-

der Kooperationsgruppe wird mit ihrem zugeh¨

origen Arbeitsbereich ein Gruppen-

Tuple Space zugeordnet. In diesem werden sowohl die Kooperationsobjekte als auch

die f¨

ur die Benutzer normalerweise nicht sichtbaren Verwaltungsobjekte abgelegt.

Durch diese persistente Speicherung der gesamten Kooperationssitzung finden die

Gruppenteilnehmer ihren Kooperationsbereich beim Betreten stets so vor, wie sie

ihn zum Ende der letzten Kooperationssitzung verlassen haben. Dabei kann die Ko-

operation in der vom virtuellen Wissensraum gewohnten Weise mittels Anwendung

Mobilit¨

at in der kooperativen Wissensarbeit

der prim¨

aren Medienfunktionen auf die Kooperationsobjekte erfolgen. Mit dieser

neuartigen Verkn¨

upfung verteilter und stark replizierter Speicherkonzepte mit vir-

tuellen Wissensr¨

aumen etabliert diese Arbeit ein Konzept f¨

ur eine durchg¨

angige

Verf¨

ugbarkeit der gemeinsamen Kooperationsdaten.

Die hier entworfene Musterarchitektur gliedert sich somit in vier Schichten. Die

Vernetzungsschicht erlaubt eine generelle Kommunikation zwischen den Knoten des

Kooperationsnetzwerkes und ein Auffinden potentieller Kooperationspartner. Die

Schicht zur Objektverwaltung und -speicherung setzt auf diese Kommunikations-

schicht auf und bildet den technischen Kern der Basisarchitektur. Sie enth¨

alt neben

der Adressierung der Knoten Mechanismen f¨

ur die gezielten Replikation der Ko-

operationsobjekte und deren Versionierung. Die Schicht der Gruppen-Tuple Spaces

abstrahiert diese technische Sicht in ein schl¨

ussiges Modell zur B¨

undelung von re-

plizierenden Knoten. Sie bietet diesen außerdem Mechanismen f¨

ur eine zeitlich und

r¨

aumlich entkoppelte Kommunikation. Als oberste Schicht erm¨

oglichen die mobil-

verteilten Wissensr¨

aume den Einsatz bew¨

ahrter Kooperationskonzepte auch in mo-

bil-spontanen Nutzungsszenarien.

War eingangs dieser Arbeit die Realisierung einer mobilit¨

atsfreundlichen Koope-

rationsumgebung in Bezug auf die funktionalen und technischen Anforderungen un-

klar, so helfen die entwickelten Nutzungsszenarien und aufgezeigten L¨

osungsans¨

atze

die wesentlichen technischen Problemstellungen zu identifizieren. Ausgehend von den

im Rahmen der vorliegenden Arbeit entwickelten Nutzungsszenarien erlaubt diese

Musterarchitektur mobil-verteilter Wissensr¨

aume die Umsetzung einer mobilen Ko-

operationsumgebung. Diese erm¨

oglicht mobilen Benutzern eine freie Kooperation

ohne Nutzungshemmnisse durch ¨

außere Gegebenheiten. Dabei ist jederzeit eine Ein-

bettung externer Dienste in die Kooperationsumgebung sowie ein nahtloser ¨

Uber-

gang zwischen Pr¨

asenzkooperation und r¨

aumlich getrennter Kooperation m¨

oglich.

Trotz des komplexen Umfeldes einer mobil-spontanen Kooperation wird der Be-

nutzer durch Nutzung verf¨

ugbarer Kontextinformationen und einer automatischen

Konfiguration der Kooperationsumgebung auch im heterogenen Umfeld nicht mit

technischen Fragestellungen belastet.

Die Arbeit schließt mit einer kurzen Zusammenfassung der einzelnen Kapitel und

gibt einem Ausblick auf zuk¨

unftige Forschungsfragen.

Mobilit¨

at in der kooperativen Wissensarbeit

10 1 Einleitung

Mobilit¨

at in der kooperativen Wissensarbeit

2 Spontane Wissensorganisation im

mobilen Nutzungsumfeld –

Szenarien

Die Unterst¨

utzung der Kooperation in einem mobilen Nutzungsumfeld ist an viele

Rahmenbedingungen gebunden. Diese bestehen zum einen aus der technischen Syste-

mumgebung und zum anderen aus den m¨

oglichen Nutzungsszenarien. Die technische

Systemumgebung ist dabei durch portable Hardwarearchitekturen, wie z. B. Note-

book, PDA oder Mobiltelefon, und die m¨

ogliche mobile Netzwerkanbindung, wie

z. B. WLAN, Bluetooth, GRPS, UMTS, etc., gepr¨

agt. Die Nutzungsszenarien sind

im Gegensatz zu den technischen Rahmenbedingungen nur schwer zu identifizieren

und zu benennen. Um eine Grundlage zur Ermittlung der Anforderungen an eine

Basisinfrastruktur f¨

ur die spontane und auch geplante Kooperation in einem mobilen

Nutzungsumfeld zu schaffen, werden in diesem Kapitel wesentliche Szenarien einer

mobilen Kooperation beschrieben.

In allen hier beschriebenen Szenarien werden die Benutzer durch ihnen pers¨

on-

lich zugeordnete mobile Ger¨

ate in ihrer Mobilit¨

at begleitet. Die Szenarien ordnen

sich somit in dem unter dem Begriff des ”Normadic Computing“ [Kleinrock, 1995]

bekannten Paradigma hochmobiler Benutzer in einem st¨

andig wechselnden techni-

schen Umfeld ein. Im Gegensatz zu der von Mark Weiser gepr¨

agten Sichtweise des

”Ubiquitous Computing“ [Weiser, 1991] besteht das Ziel also nicht darin, die Ko-

operationsumgebung in Alltagsgegenst¨

anden einzubetten, sondern in einer Nutzung

der vorhandenen pers¨

onlichen mobilen Computer f¨

ur die Kooperation mit anderen

Menschen. Dennoch laufen die folgenden Szenarien nicht quer zu einem durch Com-

puter angereicherten Lebensumfeld, sondern beziehen in der Umgebung verf¨

ugbare

Dienste mit ein, ohne von diesen abh¨

angig zu werden. Die Benutzer sollen Zeitpunkt

und Ort der Kooperation frei und abh¨

angig vom aktuellen Umfeld w¨

ahlen k¨

onnen

und dabei ihre bevorzugten und auf sie konfigurierten Ger¨

ate benutzen k¨

onnen.

Die Realisierung einer derart gestalteten mobilit¨

atsfreundlichen Kooperationsum-

gebung ist ohne ein Wissen um die Nutzungsszenarien und die strukturellen Gren-

zen einer technischen Realisierung nicht m¨

oglich. Klassische CSCW-Szenarien be-

schr¨

anken sich jedoch h¨

aufig auf die Zusammenarbeit in etablierten Infrastrukturen,

w¨

ahrend sich Szenarien der mobilen Vernetzung auf die Aspekte mobilit¨

atsfreund-

licher Netzwerke konzentrieren. Um die fehlende Konvergenz kooperativer Wissens-

strukturierung und spontaner Vernetzung zu beschreiben, werden in diesem Kapitel

Nutzungsszenarien entwickelt, die eine Verkn¨

upfung von mobilen und spontanen

Netzwerken mit kooperationsunterst¨

utzenden Infrastrukturen betrachten. Anhand

12 2 Szenarien

des Wechselspiels zwischen diesen Nutzungsszenarien werden die Probleme unter-

sucht, die sich aus einer Zusammenf¨

uhrung der Techniken aus dem Feld der mobilen

Vernetzung und des CSCW ergeben.

F¨

ur eine grobe Einordnung der ben¨

otigten Kooperationsunterst¨

utzung lassen sich

die m¨

oglichen Kooperationsformen in unterschiedliche Kategorien unterteilen. Hier

hat sich die Unterteilung in Pr¨

asenzkooperation und entfernte Kooperation, sowie

synchroner und asynchroner Kooperation etabliert. W¨

ahrend Pr¨

asenzkooperation

und entfernte Kooperation etwas ¨

uber die r¨

aumliche Relation der Kooperations-

partner aussagt, beschreiben die Kategorien der synchronen und asynchronen Ko-

operation, ob die Kooperation zum gleichen Zeitpunkt (synchron) oder zu versetzten

Zeitpunkten (asynchron) stattfindet.

Ein Online-Chat ist demnach ein synchroner Kooperationsdienst w¨

ahrend E-Mail

zumeist asynchron genutzt wird. Des Weiteren ist ein Smartboard ein Hilfsmittel f¨

die Pr¨

asenzkooperation, bei der alle Teilnehmer anwesend sind, und E-Mail wieder-

um ein Dienst zur entfernten Kooperation, bei der die Teilnehmer meist r¨

aumlich

von einander getrennt sind.

Wie man an dem Beispiel des E-Mail-Dienstes sieht, ist die Zuordnung eines Diens-

tes zu einer bestimmten Kooperationskategorie nicht immer eindeutig m¨

oglich. Den-

noch l¨

asst sich mit Hilfe dieser Kategorien leicht erkennen, ob ein Dienst f¨

ur das

geplante Kooperationsszenario geeignet ist. Durch eine Einordnung der in diesem

Kapitel beschriebenen Szenarien in eine oder mehrere Kategorien lassen sich daher

bereits erste R¨

uckschl¨

usse auf die ben¨

otigten Kooperationsdienste ziehen.

Der hier verfolgte Ansatz ¨

ahnelt den in [Booch et al., 1998] beschriebenen Useca-

ses1. Die Grundidee der Verwendung von Usecases ist, die Entwickler eines Softwa-

reprojektes davor zu bewahren, w¨

ahrend der technischen Realisierung die ben¨

otigte

Funktionalit¨

at aus den Augen zu verlieren und sich stattdessen durch technische

Aspekte leiten zu lassen. Eine ¨

ahnliche Funktion ¨

ubernehmen die Szenarien in die-

sem Kapitel. Eine Formalisierung dieser Szenarien geht dabei jedoch nur so weit, wie

es eine Pr¨

azisierung der einzelnen Handlungen der Kooperationspartner erfordert,

um die allgemeine Verst¨

andlichkeit der Szenarien nicht zu gef¨

ahrden.

Die Szenarien dieser Arbeit fußen auf dem Konzept der virtuellen Wissensr¨

aume

[Hampel, 2001], die bereits in der serverzentrierten Architektur des open-sTeam-

Sytems2implementiert sind. Ein Ziel der vorliegenden Arbeit ist es, dieses flexible

Konzept der dokumentenzentrierten Kooperation in mobile Nutzungsszenarien zu

uberf¨

uhren und eine entsprechende technische Dienste-Infrastruktur zu entwerfen.

Daher werden in den folgenden Szenarien insbesondere die mobile Kooperation in

virtuellen Wissensr¨

aumen betrachtet und bez¨

uglich einer technischen Unterst¨

utzung

der Zusammenarbeit durch eine m¨

ogliche Kooperationsinfrastruktur analysiert.

Dieses Kapitel gliedert sich in zwei Szenariengruppen entsprechend der r¨

aumlichen

Beziehung der Kooperationspartner zueinander. Die erste Szenariengruppe ”Pr¨

1Die Usecases werden in der Beschreibungssprache Unified Modeling Language (UML) weiter for-

malisiert und verfeinert.

2Im Folgenden wird open-sTeam der besseren Lesbarkeit wegen sTeam genannt.

Mobilit¨

at in der kooperativen Wissensarbeit

Gründung Kooperation Auflösung

Wiederaufnahme

der Kooperation

Änderung der

Gruppenstruktur

Abbildung 2.1: Der Prozess einer mobil-spontanen Kooperation gliedert sich in

drei Phasen: Die Gr¨

undung steht am Anfang und besteht aus der Gruppengr¨

un-

dung und der Erstellung des gemeinsamen Arbeitsbereiches. Die eigentliche Ko-

operation findet in der gleichnamigen Phase statt. Das Aufl¨

osen der Kooperation

erfolgt aus Sicht der einzelnen Teilnehmer immer am Ende ihrer Beteiligung an

der Kooperationssitzung. Sie k¨

onnen dieser aber jederzeit in einer anderen Nut-

zungskonstellation wieder beitreten.

senzkooperation“ betrachtet haupts¨

achlich Kooperationsformen bei der alle Teilneh-

mer r¨

aumlich zugegen sind. Wohingegen die zweite Szenariengruppe ”Kooperation

mit r¨

aumlich verteilten Teilnehmern“ haupts¨

achlich Kooperationsformen mit r¨

aum-

lich entfernten Kooperationspartnern betrachtet. In beiden Gruppen wird dabei auch

auf Mischszenarien beider Kooperationsformen Bezug genommen.

Jede der zwei Gruppen enth¨

alt wiederum zwei Hauptszenarien. Bei der Gruppe

”Pr¨

asenzkooperation“ sind dies die Hauptszenarien ”Lerngruppe“ und ”Spontane

Kooperation“. Die Gruppe ”Kooperation mit r¨

aumlich verteilten Teilnehmern“ ent-

h¨

alt die Hauptszenarien ”R¨

aumlich getrennte Kooperation“ und ”Distant Learning“.

Die Hauptszenarien sind in drei Kooperationsphasen unterteilt, die den Ablauf

eines Kooperationsszenarios in Gr¨

undung,Kooperation und Aufl¨

osung gliedern. Die

Phase der Gr¨

undung enth¨

alt die Prozesse, in denen die Teilnehmer eine Koopera-

tion bewusst oder unbewusst beginnen. Die Phase der Kooperation betrachtet die

eigentliche Zusammenarbeit zwischen den Teilnehmern. Die Phase der Aufl¨

osung ist

besonders im kooperativen Nutzungskontext wichtig, da sie die Archivierung der

Kooperationsergebnisse einschließt und in mobilen Szenarien oft einen ¨

Ubergang

zu einer neuen Nutzungskonstellation in der Kooperationsumgebung darstellt. Die

Aufl¨

osung geht somit oft direkt in die Gr¨

undung einer Kooperation mit anderer

Konstellation ¨

uber. So entsteht eine Art Regelkreis, in dem die Kooperationskonfi-

guration st¨

andig dem Nutzungskontext angepasst wird (Abbildung 2.1).

Die insgesamt vier Hauptszenarien enthalten jeweils mehrere detaillierte Fallbe-

schreibungen, die eine Identifizierung der ben¨

otigten Unterst¨

utzungsfunktionen er-

lauben. Beispiele dieser detaillierten Fallbeschreibungen sind die Szenarien ”Gr¨

un-

dung einer Gruppe aus dem Ortskontext der Teilnehmer“ (Szenario 1.1),”Koope-

ratives Arbeiten in einem gemeinsamen Gruppenbereich“ (Szenario 1.6) und ”¨

Uber-

f¨

uhren einer zentral verwalteten Kooperationsgruppe in eine mobil-verteilte Koopera-

tionsumgebung“ (Szenario 3.1). Es empfiehlt sich im Folgenden f¨

ur einen ¨

Uberblick

Mobilit¨

at in der kooperativen Wissensarbeit

14 2.1 Pr¨

asenzkooperation

uber das Hauptszenario auf den Fließtext und f¨

ur einen tieferen Einblick in die

Einzelszenarien auf die grauen Boxen mit mit den detaillierten Fallbeschreibungen

zur¨

uckzugreifen.

2.1 Pr¨

asenzkooperation

In die Gruppe der Szenarien der Pr¨

asenzkooperationen oder auch Face-to-Face Ko-

operationen, ordnen sich alle Kooperationssituationen ein, in denen die Kooperati-

onspartner direkt und ohne r¨

aumliche Trennung miteinander interagieren. Aufgrund

dieser Umst¨

ande haben die Benutzergruppen daher eine begrenzte Gr¨

oße und ver-

st¨

andigen sich zumeist ohne technische Hilfsmittel ¨

uber direkte Sprache und Gestik.

Bei der Kommunikation sind alle Kooperationspartner gleichberechtigt und erfolgt

an alle Partner zugleich. Es handelt sich demnach um eine ungerichtete Kommu-

nikation zwischen allen Teilnehmern. In einigen F¨

allen mag jedoch ein Moderator

die Kooperation steuern, um den Kooperationsprozess zu koordinieren. Dies macht

dann Sinn, wenn die Kooperationspartner sich ansonsten durch ihre Handlungen

behindern w¨

urden, weil sie gemeinsam auf einige wenige Kooperationsressourcen

zugreifen.

Die Kooperationsressourcen bilden hier oftmals technische Hilfsmittel wie Wis-

sensquellen in Form von Literatur und Notizen, die w¨

ahrend der Kooperationssitzung

mit Beschriftungen, Bleistiftskizzen oder Tafelbildern erg¨

anzt werden. Durch das ver-

st¨

arkte Aufkommen von mobilen Computern und digitalen Medien werden viele der

Hilfsmittel und Ressourcen inzwischen durch ihre digitalen Pendants erg¨

anzt oder

ersetzt. Es kommt zu einer Vermischung von herk¨

ommlichen und computerisierten

Hilfsmitteln.

In einem solchen Kooperationsumfeld gilt es, diese technischen Hilfsmittel naht-

los und ohne Medienbr¨

uche einzubinden. Dies bedeutet, die nat¨

urliche Kooperation

durch die technischen Hilfsmittel zu erg¨

anzen und die herk¨

ommlichen Kooperati-

onsmaterialien m¨

oglichst einfach in die computergest¨

utzte Kooperation zu integrie-

ren. Dieses Unterfangen ist aufgrund der vielen nicht digitalisierten Materialien wie

Schmierzettel, B¨

ucher, Mitschriften, etc. schwierig. Der Trend zeigt jedoch, dass die

digitalen Hilfsmittel zunehmend eine wichtige Stellung im Alltagsleben der Benutzer

einnehmen3. Zus¨

atzlich kann ein verst¨

arkter Einsatz dieser digitalen Hilfsmittel hel-

fen, die unvermeidlichen Medienbr¨

uche durch einen Wechsel zwischen analoger und

digitaler Welt zu reduzieren.

Um Medienbr¨

uche, die durch den Wechsel zwischen analogen zu digitalen Hilfs-

mitteln entstehen, zu vermeiden, wird in den Szenarien – falls verf¨

ugbar – direkt die

digitale Variante gew¨

ahlt. Dabei wird davon ausgegangen, dass die digitale L¨

osung

zumindest gleichwertig zu ihrem analogen Vorbild ist. Eventuelle Nachteile der aktu-

ellen digitalen Umsetzungen analoger Hilfsmittel werden der Einfachheit halber bei

dieser Betrachtung ignoriert und beide Varianten als zumindest gleichwertig ange-

3Als Beispiele seien hier eBooks und Digital Ink als Ersatz f¨

ur Literatur in Papierform, TabletPC

als Ersatz f¨

ur Notizzettel und Smart Whiteboards als Ersatz f¨

ur Tafeln genannt.

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.1 Lerngruppe 15

nommen. Es scheint eine realistische Annahme zu sein, dass die digitalen Hilfsmittel

sich mehr und mehr den Analogen angleichen und zus¨

atzlich einen funktionalen

Mehrwert bieten werden. Die Nutzung der neuen digitalen Hilfsmittel entwickelt

besonders in Verbindung mit mobilit¨

atsfreundlichen Kommunikationsschnittstellen

und -infrastrukturen spannende M¨

oglichkeiten f¨

ur eine nahtlose Kooperation im mo-

bilen Umfeld.

2.1.1 Lerngruppe

Das erste Szenario der Pr¨

asenzkooperation mobiler Benutzer bildet eine studentische

Lerngruppe. Lerngruppen haben ¨

ublicherweise wenige Mitglieder, die sich nach losen

Verabredungen an einem geeigneten Ort treffen. Die Gruppenst¨

arke variiertert von

Treffen zu Treffen durch die Abwesenheit einiger Teilnehmer oder das Hinzukommen

von G¨

asten. Ziel einer solchen Lerngruppe ist das gemeinsame Aufarbeiten eines

bestimmten Wissensgebietes bzw. eines vorgegebenen Lernstoffes. In den meisten

F¨

allen schließt sich an die Lernphase eine zu absolvierende Pr¨

ufung an einem festen

Termin an. Alle Kooperierenden arbeiten daher auf ein gemeinsames Ziel hin, welches

jedoch nicht nur durch die gemeinsam geschaffenen Artefakte, sondern auch durch

das individuell erlangte Wissen gepr¨

agt ist.

Gr¨

undung, Anbahnungsphase Der organisatorische Rahmen einer Lerngruppe

ist durch eine lose und gleichberechtigte Kooperation aller Teilnehmer gepr¨

agt. Die

Gr¨

undung der Gruppe erfolgt durch Absprache w¨

ahrend eines spontanen Treffens

im Vorlesungsumfeld oder auch geplant durch einen Aushang.

Die schnelle Identifizierung potentieller Kooperationspartner ist also eine erste

wichtige Komponente der Kooperationsumgebung. Potentielle Kooperationspartner

k¨

onnen z. B. Benutzer in r¨

aumlicher N¨

ahe oder mit ¨

ahnlichem Interessenprofil sein.

Die Initiatoren lassen den potentiellen Partnern eine Kooperationsanfrage zukom-

men. Wird die Anfrage positiv beantwortet, f¨

ugen sie die Teilnehmer der Lerngruppe

hinzu – unter Umst¨

anden ist aber auch eine Bewerberliste sinnvoll, welche die In-

itiatoren nutzen k¨

onnen um die passenden Kandidaten auszuw¨

ahlen.

Szenario 1.1: Gr¨

undung einer Gruppe aus dem Ortskontext der Teil-

nehmer

•Gr¨

undung einer Gruppe mittels Auswahl anwesender Kooperationspartner

Die Benutzerin T1einer mobilen Kooperationsumgebung m¨

ochte anhand von poten-

tiellen Teilnehmern (T1,· · · , Tn) eine Lerngruppe mit zun¨

achst h¨

ochstens 6 Mitglie-

dern gr¨

unden, um f¨

ur eine Pr¨

ufung zu lernen. Mit zwei der gew¨

unschten Teilnehmer

(T2, T3) hat sie sich am Rande einer Vorlesung getroffen. Um die Gruppe anhand

der anwesenden Teilnehmer zu gr¨

unden, l¨

asst sie sich alle Benutzer der Koopera-

tionsumgebung in ihrer N¨

ahe anzeigen. Dies sind die Benutzer T2,T3und Tx. Da

auch nicht gew¨

unschte Benutzer als m¨

ogliche Gruppenmitglieder in der Umgebung

Mobilit¨

at in der kooperativen Wissensarbeit

16 2.1 Pr¨

asenzkooperation

vorhanden sind, w¨

ahlt sie die Benutzer, die zur Gruppe geh¨

oren sollen (T2und

T3), aus der Menge der Anwesenden aus. Aus dieser Selektion heraus gr¨

undet sie

eine neue Gruppe Ginnerhalb der Kooperationsumgebung. Die nicht anwesenden

aber bekannten Benutzer (T4,T5und T6) lassen sich vorl¨

aufig hinzuf¨

ugen und be-

kommen so eine Einladung nach deren Best¨

atigung sie automatisch Mitglieder der

Gruppe Gwerden.

Neben der Gruppengr¨

undung mit Anwesenden bei einem spontanen Treffen, kann

eine solche Gr¨

undung auch durch eine Art Aushang oder Laufzettel angek¨

undigt wer-

den. In diesem Fall wird eine Nachricht an alle potentiellen Teilnehmer gesandt. Um

auch Teilnehmer zu erreichen, die derzeit nicht im System verf¨

ugbar sind, wird die

Anfrage epidemisch – also bei Kontakt von Benutzer zu Benutzer – weitergegeben.

Diese Anfrage tr¨

agt ein G¨

ultigkeitsdatum, welches festlegt, wie lange der Aushang

weitergereicht werden soll. L¨

auft dieses Datum ab, verf¨

allt die Anfrage und wird

nicht mehr an weitere Benutzer weitergereicht.

Interessierte Benutzer, die an der Lerngruppe teilnehmen wollen, schicken eine

Antwort auf die Anfrage in Richtung der initiierenden Benutzer. Diese k¨

onnen noch

entscheiden, wer endg¨

ultig in die Lerngruppe aufgenommen wird. Sie sind somit

Verwalter der Lerngruppe. Die Verwaltungsrechte k¨

onnen sp¨

ater an andere Teilneh-

mer weitergegeben werden, um die Lerngruppe zu erweitern oder G¨

aste einladen zu

k¨

onnen.

Soll die Lerngruppe nicht ¨

offentlich ausgehangen werden oder wird die Lerngruppe

durch ein pers¨

onliches Treffen initiiert, kann der Prozess der Ank¨

undigung f¨

ur einen

begrenzten Benutzerkreis verwendet werden. Dazu k¨

onnen die gr¨

undenden Teilneh-

mer eine Auswahl der Zielgruppe durch Benennen der gew¨

unschten Teilnehmer oder

gew¨

unschter Attribute potentieller Teilnehmer vornehmen. M¨

ogliche Attribute w¨

ren hier z. B. Teilnehmer der Vorlesung ,Architekturen des CSCW’ oder – im Fall

des pers¨

onlichen Treffens – alle anwesenden Personen.

Szenario 1.2: Gruppengr¨

undung mittels Aushang und Eingrenzung des

Nutzerkreises

•Gr¨

unden einer Gruppe mit unbekanntem Benutzerkreis

•Definieren gew¨

unschter Benutzerprofile f¨

ur die Gruppengr¨

undung

Der Benutzer T1einer mobilen Kooperationsumgebung m¨

ochte eine Lerngruppe

gr¨

unden, ohne alle der m¨

oglichen Teilnehmer bereits zu kennen. Er macht des-

halb eine systemweite Ank¨

undigung, die alle in Frage kommenden Benutzer er-

reichen soll. Da es sich um eine Lerngruppe zur Vorlesung ”Architekturen des

CSCW (ACSCW)“ handelt, beschließt er, nur Benutzer zu adressieren, die an

dieser Vorlesung teilnehmen. Außerdem sollen alle Teilnehmer in der selben Stadt

(hier: Paderborn) wohnen, um Pr¨

asenztreffen leichter organisieren zu k¨

onnen. Dazu

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.1 Lerngruppe 17

gibt er beide Kriterien als Filter ¨

uber die Attribute Gruppe=ACSCW und Adres-

se.Stadt=Paderborn ein. Nur Benutzer, die diesen Kriterien entsprechen, bekom-

men die Ank¨

undigung angezeigt.

Um eine Verbreitung an einen m¨

oglichst großen Benutzerkreis zu gew¨

ahrleisten,

wird der Aushang innerhalb der computergest¨

utzten Kooperationsumgebung an

alle Benutzer weitergereicht sobald diese kontaktiert werden. Die Benutzer reichen

den virtuellen Aushang wiederum an andere Benutzer weiter, die sie treffen, auch

wenn sie selbst nicht zum gew¨

unschten Personenkreis geh¨

oren. Nach einer zuvor

definierten Zeit wird die Ank¨

undigung wieder entfernt und von allen Ger¨

aten ge-

l¨

oscht.

Benutzer, die an der Lerngruppe teilnehmen wollen, beantworten die Ank¨

undi-

gung positiv. Der Initiator bekommt diese Benutzer daraufhin in einer Liste po-

tentieller Teilnehmer angezeigt, aus der er die endg¨

ultige Gruppe zusammenstellen

kann. Als Hilfsmittel f¨

ur die Entscheidung ¨

uber m¨

ogliche Mitglieder nutzt er Chat-

Mechanismen und Benutzerprofile.

Der Aushang von T1erreicht die Benutzerin T2als sich ihr mobiles Ger¨

uber ein Funknetzwerk mit dem Ger¨

at von Benutzer T1verbindet. Allerdings

wird Benutzerin T2der ¨

ubergebene Aushang nicht angezeigt. Das Attribut Adres-

se.Stadt=Paderborn trifft bei ihr zwar zu, aber sie besucht nicht die Vorlesung

”Architekturen des CSCW (ACSCW)“ und ist somit auch nicht Mitglied in der ge-

forderten Gruppe ACSCW. Benutzerin T2lebt mit Benutzerin T3, deren Profil den

gew¨

unschten Vorgaben entspricht, in einer Wohngemeinschaft. Als T2in der ge-

meinsamen Wohnung eintrifft, wird die Ank¨

undigung automatisch an die ebenfalls

anwesende T3¨

ubermittelt und dieser aufgrund der ¨

Ubereinstimmung des Profils

angezeigt.

Teilnehmerin T3entschließt sich, der Lerngruppe beizutreten und schickt eine

positive Antwort an den Initiatior T1. Die Antwort wird ebenfalls epidemisch ¨

uber-

tragen. Daher erh¨

alt T2eine Kopie der Antwort, ohne diese je zu Gesicht zu bekom-

men. Diesmal kommt T3w¨

ahrend der besagten Vorlesung noch vor T2in Reichweite

von T1und beantwortet die Anfrage somit direkt. Das Antwortobjekt von T2ver-

f¨

allt entweder nach einer gewissen Lebenszeit, wird beim n¨

achsten Kontakt mit T3

zur¨

uckgezogen oder erreicht T1und wird dann von dem Ger¨

at von T2entfernt.

Nach der Gr¨

undung der Lerngruppe muss die Kooperationsumgebung die Benutzer

zu einer Gruppe innerhalb des Systems zusammenschließen und einen gemeinsamen

Arbeitsbereich zur Verf¨

ugung stellen. Gleichzeitig sind die Berechtigungen der Teil-

nehmer einer gleichberechtigten Kooperation entsprechend zu setzen. Dies bedeutet

im Detail, dass der Gruppenbereich und alle enthaltenen Dokumente, bis auf eini-

ge gezielte Ausnahmen, f¨

ur alle Teilnehmer voll zugreifbar sind. Zun¨

achst sind also

alle Dokumente im Besitz aller Gruppenmitglieder. Bei Bedarf werden die Ausnah-

men nachtr¨

aglich festgelegt und mit entsprechenden Berechtigungen versehen. Die

Verwaltung der Gruppe selbst kann entweder durch die Gr¨

undungsmitglieder, die

designierten Gruppenadministratoren oder alle Gruppenmitglieder erfolgen. In einer

Mobilit¨

at in der kooperativen Wissensarbeit

18 2.1 Pr¨

asenzkooperation

gleichberechtigten Kooperation erscheint in der Regel eine Verwaltung seitens aller

Gruppenmitglieder sinnvoll.

Szenario 1.3: Gemeinsamer Arbeits- und Lernbereich f¨

ur Dokumente

und aktive Objekte

•Gr¨

unden einer Gruppe mit einem gemeinsamen Bereich

•Berechtigungen im Gruppenbereich

•Entfernter Zugriff auf gemeinsam genutzte Objekte

Begleitend zur Vorlesung ”Architekturen des CSCW (ACSCW)“ hat sich eine Lern-

gruppe mit vier Mitgliedern zusammengeschlossen. Die Gruppe nutzt einen gemein-

samen Arbeitsbereich f¨

ur alle gemeinsam genutzten Objekte. Im Sinne einer offenen

und gleichberechtigten Kooperation haben alle Teilnehmer die gleichen Zugriffs-

rechte auf die in dem Bereich enthaltenen Objekte. Wenn Benutzer neue Objekte

in dem Gruppenbereich ablegen, haben alle Angeh¨

origen der Gruppe das Recht,

das Objekt gem¨

aß seiner Relevanz zu bewerten, anzuordnen, zu kommentieren, zu

bearbeiten oder sogar zu l¨

oschen, wenn sie es f¨

ur irrelevant halten.

Die Abstimmung der Handlungen geschieht in der Regel mittels direkter Kommu-

nikation zwischen den anwesenden Teilnehmern. Kommunikation mit abwesenden

Teilnehmern wird ¨

uber ein Nachrichtensystem koordiniert. Die Kommunikation be-

z¨

uglich eines Objektes wird an das Objekt selbst gekoppelt und so ein intuitiver

Bezug f¨

ur die Kommunikation hergestellt. Damit abwesende Teilnehmer nicht st¨

an-

dig den Gruppenbereich aufsuchen m¨

ussen, um den Fortschritt zu verfolgen, kann

die Kommunikation oder auch ein ¨

Anderungsprotokoll als pers¨

onliche Nachricht

zugestellt werden.

Die Lerngruppe Gbesitzt vier Teilnehmer (G={T1,· · · , T4}). Diese befinden

sich derzeit in einer Kooperationssituation und wollen gemeinsam das Dokument

d1bearbeiten. Dieses Dokument liegt in einem der Gruppe zugeordneten Bereich

der Kooperationsumgebung. Nur die Gruppenmitglieder haben auf diesen Bereich

Zugriff. Innerhalb dieses Bereichs d¨

urfen alle Gruppenmitglieder alle Objekte und

Dokumente ¨

andern, l¨

oschen und neu anlegen. In dem leeren Bereich legt T1das

Dokument d1an, das von nun an alle Gruppenmitglieder lesen und ¨

andern (schrei-

ben) k¨

onnen. Des Weiteren legt T1ein Dokument d2an, in dem er eigene Notizen

ablegen will. T1m¨

ochte diese Notizen auch dem Rest der Gruppe zug¨

anglich ma-

chen, aber den anderen Gruppenmitgliedern nicht erlauben, den Inhalt zu ¨

andern.

Daher legt er das Dokument im gemeinsamen Gruppenbereich ab, entzieht aber

allen Gruppenmitgliedern die Schreibberechtigung.

F¨

ur eine Kooperation mittels dieser Dokumente treffen sich T1,T2und T3in

einem Raum und setzen sich um einen Tisch. Sie verf¨

ugen alle ¨

uber mobile Ger¨

ate,

die miteinander vernetzt sind. Teilnehmer T4befindet sich an einem anderen Ort

und greift ¨

uber eine Netzwerkverbindung auf dieselbe Kooperationsumgebung wie

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.1 Lerngruppe 19

die Gruppenmitglieder vor Ort zu. W¨

ahrend T1,T2und T3eine Gliederung f¨

ur das

Dokument d1erstellen, wird T4¨

uber jede ¨

Anderungen im Dokument informiert.

Nachdem eine grobe Gliederung steht, f¨

ugt er einen neuen Gliederungspunkt in d1

ein, was wiederum den anderen Gruppenmitgliedern sofort angezeigt wird.

Kooperationsphase Nach der Gr¨

undung der Gruppe verabredet die Gruppe sich

f¨

ur Pr¨

asenztreffen. Die Treffen k¨

onnen dabei f¨

ur einen bestimmten wiederkehrenden

Termin verabredet oder von Mal zu Mal neu bestimmt werden. Nicht anwesende

Teilnehmer m¨

ussen ¨

uber diese Termine informiert und bei Bedarf in die Termin-

findung eingebunden werden. Neben Benachrichtigungsmechanismen erlauben Ab-

stimmungsfunktionen und Gruppenkalender eine Unterst¨

utzung der Prozesse in der

Terminfindung.

Szenario 1.4: Terminkoordination f¨

ur die Pr¨

asenzsitzungen in Klein-

gruppen

•Unterst¨

utzung des Terminfindungsprozesses

Eine Gruppe von gleichberechtigten Benutzern m¨

ochte einen einmaligen Termin

oder sogar wiederkehrende Termine f¨

ur regelm¨

aßige Treffen bestimmen. Hierzu ist

es wichtig, dass m¨

oglichst alle Teilnehmer zu diesem Termin verf¨

ugbar sind. ¨

Ubli-

cherweise wird eine erste Terminfindung bei dem ersten Treffen zusammen mit der

Gruppengr¨

undung erfolgen. Generell gibt es zwei m¨

ogliche Vorgehensweisen:

a) Iterative Abstimmung: Die Initiatoren der Lerngruppe machen einige Ter-

minvorschl¨

age, ¨

uber die in der Gruppe abgestimmt wird. Der Termin mit der

meisten Zustimmung wird gew¨

ahlt. Sollte ein Teilnehmer an diesem Termin

nicht k¨

onnen, muss die Wahl eventuell mit neuen Vorschl¨

agen wiederholt wer-

den. Dieses Verfahren bietet sich an, wenn alle Teilnehmer ¨

ahnliche Termine

haben (z. B. einheitlicher Stundenplan von Teilnehmern in der gleichen Stu-

dienphase), ansonsten kann das Verfahren aus b) schneller zum Erfolg f¨

uhren.

b) Termin¨

uberdeckung: Jeder der Teilnehmer nennt die eigenen, bereits exis-

tierenden wiederkehrenden Termine (Stundenplan). Der neue Termin wird in

der Zeit geplant an dem keine ¨

Uberdeckungen der existierenden Termine auf-

treten. Gibt es eine solche ¨

Ubereinstimmung nicht, werden die existierenden

Termine priorisiert oder bereits existierende Termine verschoben. Dies ist in

der Regel ein interaktiver Prozess, bei dem die Teilnehmer die Wichtigkeit

ihrer Termine argumentieren. Im Gegensatz zum Verfahren in a) muss jeder

Teilnehmer alle seine Termine offen legen und Rechenschaft ¨

uber diese f¨

uhren.

Eine Pr¨

asenzsitzung beschleunigt die Terminfindung aufgrund deren stark interak-

tiven Charakters. Aber auch eine r¨

aumlich entfernte und zeitlich versetzte Form

Mobilit¨

at in der kooperativen Wissensarbeit

20 2.1 Pr¨

asenzkooperation

der Terminbestimmung ist m¨

oglich. Das Ergebnis der Terminabstimmung f¨

ur re-

gelm¨

aßige Termine muss aber im Gegensatz zu einmaligen Terminen den Konsens

aller Teilnehmer finden.

Im Folgenden plant eine Gruppe von gleichberechtigten Benutzern einen einzel-

nen Termin f¨

ur ein Pr¨

asenztreffen. Dies kann z. B. der erste Termin einer interak-

tiven Terminbestimmung f¨

ur regelm¨

aßige Treffen sein oder ein außerordentliches

Treffen f¨

ur eine zus¨

atzliche Lernsitzung. Dieser einmalige Termin bedarf keiner

strikten Verf¨

ugbarkeit aller Teilnehmer, Ziel ist aber dennoch ein m¨

oglichst hoher

Konsens. Eine Bestimmung von regelm¨

aßigen Terminen erfolgt analog.

In einer iterativen Abstimmung wird nach der Nennung m¨

oglicher Termine durch

T1mehrheitlich einer der Termine gew¨

ahlt. Die Mehrheit der Stimmen f¨

allt auf

einen Termin, an dem zwei Mitglieder nicht verf¨

ugbar sind. Deshalb beschließt

die Gruppe die Abstimmung unter Ausschluss dieses Termins zu wiederholen. Die

Teilnehmerin T2ist bei der Terminfindung nicht pers¨

onlich zugegen und soll sp¨

ater

von dem mehrheitlichen Ergebnis in Kenntnis gesetzt werden. Weil die Abstimmung

aber f¨

ur einen wichtigen Termin erfolgt, an dem sie unbedingt teilnehmen m¨

ochte,

ubertr¨

agt sie ihr Stimmrecht auf das anwesende Mitglied T3.T3weiß aber bei dem

gew¨

ahlten Termin nicht ob T2diesen wahrnehmen kann und T2wird kurzfristig

uber technische Hilfsmittel wie Telefon oder Chat hinzugezogen. Stimmt T2zu, ist

der Termin gefunden.

Die Teilnehmer T1,T2,T3und T4wollen nach abgeschlossener Gr¨

undung der

Gruppe Gmittels des Verfahrens der Termin¨

uberdeckung einen Termin f¨

ur das

n¨

achste Treffen verabreden. T1,T2und T3treffen sich zuf¨

allig in der Kantine. T4

ist nicht anwesend. Sie ermitteln mit Hilfe eines Gruppenkalenders in ihrer Koope-

rationsumgebung einen m¨

oglichen Termin. Dazu legen sie Ihre pers¨

onliche Kalender

ubereinander und w¨

ahlen einen bei allen Teilnehmern freien Termin. Der pers¨

on-

liche Kalender von T4kann nicht ber¨

ucksichtigt werden, da dieser nicht vorliegt

und zudem die Berechtigung zur Einsicht des pers¨

onlichen Kalenders von T4fehlt.

Daher verzichten die drei Anwesenden zun¨

achst auf eine Einbeziehung und bestim-

men einen Termin auf die Gefahr hin, mit dem pers¨

onlichen Kalender von T4zu

kollidieren. Der Termin wird in den Gruppenkalender eingetragen und somit auch

T4bekannt gegeben. Da dieser Termin in dem pers¨

onlichen Kalender von T4be-

reits belegt ist, tritt er direkt ¨

uber die Kooperationsumgebung mit den anderen drei

Teilnehmern in Kontakt. Unter zus¨

atzlicher Einbeziehung des Terminkalenders von

T4wird daraufhin ein endg¨

ultiger Termin bestimmt.

W¨

ahrend der Pr¨

asenzsitzungen arbeiten die Lernpartner mit einem gemeinsamen

Fundus von Dokumenten. Dieser wird gr¨

oßtenteils kooperativ erweitert und kom-

mentiert, soll aber auch individuellen Bed¨

urfnissen angepasst werden. Es m¨

ussen

daher sowohl individuelles als auch kooperatives Arbeiten innerhalb derselben Ar-

beitsumgebung unterst¨

utzt werden, um diese nicht st¨

andig wechseln zu m¨

ussen. Da-

mit bei einer wachsenden Anzahl von Dokumenten die ¨

Ubersicht nicht verloren geht,

ist es wichtig, dass der Kooperationsbereich strukturiert werden kann – ¨

ahnlich zu

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.1 Lerngruppe 21

den in [Hampel, 2001] beschriebenen Szenarien. Da nicht alle Teilnehmer bei jeder

Pr¨

asenzsitzung anwesend sein k¨

onnen, m¨

ussen dar¨

uber hinaus ¨

Anderungen in dem

gemeinsamen Kooperationsbereich seit der letzten Teilnahme f¨

ur die abwesenden

Benutzer kenntlich gemacht werden.

Szenario 1.5: Individuelles und kooperatives Arbeiten an Dokumenten

•Zusammenspiel von Gruppenbereich und pers¨

onlichem Bereich

•Verkn¨

upfung von Dokumentversionen

Die Lerngruppe beschliesst, den Lernstoff anhand des vorhandenen Vorlesungs-

skriptes aufzuarbeiten. Sie gehen zu diesem Zweck sequentiell durch den Stoff der

Vorlesung und somit durch die Kapitel des Skripts. W¨

ahrend ihrer Lernsitzungen

versehen sie gemeinsam das Skript mit ihren Kommentaren oder f¨

ugen Zusatzmate-

rialien hinzu. Dabei werden zum Teil auch ¨

Anderungen eines anderen Teilnehmers

nochmals bearbeitet, kommentiert oder entfernt, weil sie z. B. falsch oder ungenau

sind.

Neben dem gemeinsam bearbeiteten Dokument besitzen alle Teilnehmer eine

eigene Kopie des Skripts, in das pers¨

onliche und f¨

ur die Kooperation irrelevante

Kommentare einf¨

ugt werden. Auf diese privaten Daten darf kein anderer Teilneh-

mer zugreifen oder sie ¨

andern. Optional k¨

onnen die Teilnehmer eine Kopie ihrer

pers¨

onlichen Version wieder in die kooperative Fassung einfließen lassen oder um-

gekehrt, kooperative Anteile in die pers¨

onliche Version ¨

ubernehmen.

Die Benutzer T1,T2und T3sind Mitglieder der Gruppe G. Sie bearbeiten in ihrem

gemeinsamen Gruppenbereich eine elektronische Version des Vorlesungsskripts zur

Vorlesung ”Architekturen des CSCW (ACSCW)“. Das Skript wird als Dokument

d1analog zu Szenario 1.3 im gemeinsamen Gruppenbereich abgelegt. Zus¨

atzlich

speichert jeder Teilnehmer eine Kopie d0

1des Skript in seinen pers¨

onlichen Arbeits-

bereich. Teilnehmerin T1macht in ihrer pers¨

onlichen Version einige Anmerkungen

zu einem Abschnitt im Skript. Sie beschließt, dass diese Anmerkungen n¨

utzlich

f¨

ur ihre Kooperationspartner sein k¨

onnen und markiert diese f¨

ur eine ¨

Ubernahme

in das gemeinsame Dokument d1. Daraufhin sind diese f¨

ur alle Gruppenmitglieder

sichtbar. Teilnehmer T2entdeckt einen Fehler in den Anmerkungen von T1und

korrigiert diesen. Die ¨

Anderung wird in dem gemeinsamen Dokument wiederum

sofort f¨

ur alle sichtbar. In der pers¨

onlichen Version von T1bleibt die fehlerhafte

Anmerkung zun¨

achst bestehen, wird aber bez¨

uglich der neu existierenden Version

markiert. T1erkennt ihren Fehler und ¨

ubernimmt die ¨

Anderung in ihr pers¨

onliches

Skript – somit sind beide Versionen der Anmerkungen wieder synchron.

Obwohl der Ablauf des kooperativen Lernens in der Lerngruppe bedingt durch den

Lernstoff, pers¨

onliche Vorlieben der Lernenden und die bewusst angewendeten Lern-

strategien variiert, wird im Rahmen der hier beschriebenen Szenarien folgender Ab-

lauf als typisch angenommen:

Mobilit¨

at in der kooperativen Wissensarbeit

22 2.1 Pr¨

asenzkooperation

1. Sammeln von Materialien: Zu Beginn werden alle m¨

oglichen Quellen f¨

das Erlernen des gew¨

unschten Stoffes zusammengetragen. Dies geschieht in der

Regel nicht arbeitsteilig. Die Teilnehmer suchen getrennt nach allen Materia-

lien, die sie f¨

ur sich relevant halten.

2. Sichten der Materialien: Die gesammelten Materialien werden gemeinsam

von den Lernpartnern gesichtet und sortiert. Dabei werden die irrelevanten

Materialien beiseite gelegt und zentrale Quellen in den Mittelpunkt des ge-

meinsamen Interesses gestellt.

3. Aufarbeiten des Lernstoffes: Die zentralen Quellen werden gemeinsam

durchgearbeitet, aus anderen Quellen erg¨

anzt sowie mit Kommentaren ver-

sehen.

4. Verdichten des Wissens: Das Verdichten des Wissens meint den Prozess,

relevantes Wissen f¨

ur das Erreichen des Lernziels zu ermitteln und aufzuar-

beiten. Dazu strukturieren es die Lernenden h¨

aufig in eine Form die ihrem

mentalen Modell entspricht. Dies kann z. B. mittels semantischer Karten erfol-

gen, die sich z. B. durch eine r¨

aumliche Anordnung im virtuellen Wissensraum

verwirklichen lassen [Hampel und Eßmann, 2004]. Es sind aber nat¨

urlich auch

andere Strukturierungsmittel m¨

oglich. Diese Struktur der Dokumente kann als

ein Artefakt oder Ergebnis des Kooperationsprozesses betrachtet werden, das

durch ein sukzessives neues Durchlaufen des beschriebenen Prozesses st¨

andig

verfeinert wird.

Szenario 1.6: Kooperatives Arbeiten in einem gemeinsamen Gruppenbe-

reich

•Zentral gespeicherter Gruppenbereich

•Gruppenvernetzung bei einem Treffen

•Verhindern von zeitgleichen ¨

Anderungen

•Behandeln von Versionskonflikten

•Mitf¨

uhren einer pers¨

onlichen Kopie

Nach der Gr¨

undung einer Lerngruppe Gmit den Teilnehmern und Teilnehmerinnen

T1,· · · , T6innerhalb des Kooperationssystem (siehe Szenario 1.1 und Szenario 1.2)

treffen sich deren Mitglieder erstmalig zu einem vereinbarten Termin (vgl. Szenario

1.4), um den aufzuarbeitenden Lernstoff zu sichten.

Teilnehmerin T1legt dazu zun¨

achst die vom Lehrstuhl als PDF-Dokumente ver-

offentlichten Foliens¨

atze (d1), ¨

Ubungszettel (d2,d3) und das Vorlesungsskript (d4)

in ihrem Gruppenbereich innerhalb der Kooperationsumgebung ab. Hinzu kommen

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.1 Lerngruppe 23

noch auf Vorschlag des Teilnehmers T2, ein Skript von einer verwandten Veranstal-

tung in die Sammlung aufzunehmen (d5). Auch einige andere Dokumente aus den

Best¨

anden der einzelnen Teilnehmer finden Einzug in den gemeinsamen Gruppen-

bereich. So entsteht eine weit gefasste Sammlung von Materialien, die mit dem

Thema der Vorlesung verwandt sind.

Die Treffen finden stets an einem verabredeten Ort in Anwesenheit aller Teil-

nehmer statt. Daher werden die gemeinsamen Dokumente in dem Gruppenbereich

der Kooperationsumgebung auf dem Notebook von T1gespeichert. Dazu schafft

dieser Teilnehmer einen f¨

ur alle Teilnehmer zugreifbaren Bereich. Das Notebook

wird zu jeder Sitzung mitgebracht. Zu Beginn der Lernsitzung verbinden sich alle

Teilnehmer ¨

uber ein bereitgestelltes Netzwerk mit dem Notebook und greifen von

nun an ¨

uber ihren pers¨

onlichen Rechner auf den zentralen Dienst zu. Teilnehmer T2

verbindet zun¨

achst seinen Rechner mit dem Netzwerk und ¨

uber dieses mit der Ko-

operationsumgebung auf dem Notebook von T1. Die Kooperationsumgebung stellt

einen Gruppenbereich f¨

ur die Gruppe Gzur Verf¨

ugung. Mit diesem Gruppenbereich

verbindet sich T2und kann somit auf die Dokumente der Lerngruppe zugreifen. Er

offnet den ¨

Ubungszettel d3und erarbeitet eine L¨

osung f¨

ur die Aufgabenstellung.

Gleichzeitig hat T1dasselbe Dokument d3ge¨

offnet und ebenfalls eine Teill¨

osung

skizziert. T2speichert nun seine L¨

osung in die Datei d3ab. Wenig sp¨

ater speichert

T1ihre Skizze ebenfalls in das gemeinsame Dokument d3und ¨

uberschreibt somit die

L¨

osung von T2, die daraufhin verloren ist. Gl¨

ucklicherweise hat T2noch eine lokale

Kopie des Dokuments d3mit seiner L¨

osung. Er ¨

uberschreibt wiederum (diesmal ge-

wollt) die Teill¨

osung von T1im gemeinsamen Gruppenbereich. T1und T2nehmen

noch einige Korrekturen an der L¨

osung vor und beenden die Lernsitzung.

Am Ende der Sitzung m¨

ussen die Teilnehmer ¨

ahnlich wie in Szenario 1.5 die per-

s¨

onlichen Versionen der gemeinsam genutzten Dokumente mit den kooperativen

Anderungen in Einklang bringen, um diese jenseits der Kooperationssitzungen ver-

f¨

ugbar zu haben – auf die kooperativen Versionen haben sie zwischen den Treffen

keinen Zugriff. Alternativ k¨

onnte ein zentraler Server verwendet werden, der die

Dokumente bereit stellt und von gewissen Orten aus erreicht werden kann.

T2m¨

ochte die L¨

osung gerne mit nach Hause nehmen und fertigt eine lokale Kopie

an. Bis zur n¨

achsten Sitzung nehmen sowohl T1als auch T2wiederum ¨

Anderungen

an der L¨

osung von d3vor. Teilnehmerin T1¨

andert das Dokument d1direkt im Grup-

penbereich auf ihrem Notebook. T2¨

andert seine lokale Kopie d0

3, da er außerhalb der

Kooperationssitzungen keinen Zugriff auf den gemeinsamen Gruppenbereich hat.

Infolge dieser asynchronen ¨

Anderungen existieren wieder zwei Versionen des Doku-

ments d3, die beim n¨

achsten Treffen zusammengef¨

uhrt werden m¨

ussen. Die Koope-

rationsumgebung erkennt die abweichenden Versionen des Dokuments d3, indem

sie sich den letzten Stand eines erfolgreichen Abgleichs merkt und bei ¨

Anderungen

in beiden Versionen (Original d3und Kopie d0

3) die Benutzer auf ein m¨

ogliches

Problem aufmerksam macht. Von dem Kooperationssystem gewarnt, vergleicht T2

zun¨

achst den Inhalt seiner lokalen Kopie d0

3mit dem gemeinsamen Dokument d3.

Er stellt fest, dass sich die gemeinsame Version ge¨

andert hat und muss nun sei-

Mobilit¨

at in der kooperativen Wissensarbeit

24 2.1 Pr¨

asenzkooperation

ne ¨

Anderungen in das gemeinsame Dokument einpflegen. Da er das Dokument in

einem Editor auf seinem Notebook ¨

andert, muss er es wiederum mit der entfern-

ten gemeinsamen Version in dem gemeinsamen Bereich vergleichen. Sind seit dem

Offnen des Dokuments keine ¨

Anderungen erfolgt, darf er die konsolidierte Version

zur¨

uck in das gemeinsame Gruppenareal schreiben.

Eine Besonderheit von Lerngruppen ist, dass aufgrund des losen Kooperationsver-

bundes die Gruppenstruktur recht dynamisch sein kann. Eventuell scheiden Grup-

penmitglieder aus, da sie das Lernziel (z. B. das Bestehen einer Pr¨

ufung) verworfen

haben oder neue Teilnehmer stoßen zur Gruppe hinzu. In beiden F¨

allen m¨

ussen die

Berechtigungen auf die Kooperationsobjekte entsprechend gesetzt werden. Im Falle

eines Ausscheidens sind die in der Abschlussphase beschriebenen Schritte f¨

ur den

ausscheidenden Teilnehmer zu vollziehen.

Weiterhin f¨

uhren m¨

ogliche G¨

aste zu einer kurzfristigen Ver¨

anderung der Struk-

tur einer Lerngruppe. Sie nehmen meist einmalig an der Lerngruppe teil, um zu-

sammen mit den Mitgliedern zu lernen oder auch um als Spezialist Wissen an die

Gruppe weiterzugeben. F¨

ur einmalige G¨

aste erscheinen die in dem Abschnitt Gr¨

un-

dung, Anbahnungsphase beschriebenen Mechanismen zur Aufnahme von Mitgliedern

uberdimensioniert, da G¨

aste nicht voll in die Gruppe integriert werden m¨

ussen und

eventuell auch nicht gleichberechtigt zu den Gruppenmitgliedern sind – hier werden

flexible Alternativmechanismen ben¨

otigt.

Szenario 1.7: Hinzukommen und Ausscheiden von Gruppenmitgliedern

•Ausscheiden und Nachr¨

ucken von Gruppenmitgliedern

Aus der Lerngruppe Gmit den Teilnehmern T1,T2und T3scheidet das Mitglied

T3aus, da es an der Pr¨

ufung nicht teilnehmen kann. Dennoch w¨

urde T3gerne f¨

die n¨

achste Pr¨

ufungsphase auf die Lernergebnisse zur¨

uckgreifen. Da T3nicht l¨

anger

Mitglied in der Gruppe Gist, wird T3in Zukunft von den Kommunikationsprozes-

sen ausgeschlossen und darf auch nicht mehr auf den gemeinsamen Gruppenbereich

zugreifen, Materialien in diesem ¨

andern oder diese kommentieren. Die Teilnehmer

T1und T2gew¨

ahren T3jedoch explizit weiterhin Leserechte auf den gemeinsamen

Bereich.

Teilnehmer T3m¨

ochte aber lieber eine Momentaufnahme des Lernfortschritts

zum Zeitpunkt des Ausscheidens haben. Er fertigt dazu eine Kopie des Gruppen-

bereichs im pers¨

onlichen Bereich an.

Die m¨

oglichen Lernpartner T4und T5, die in der Gr¨

undungsphase (siehe Szenario

1.1 und Szenario 1.2) ebenfalls Interesse an einer Teilnahme an der Lerngruppe G

zeigten, wurden in eine Warteliste eingef¨

ugt, aus der nun ein neues Gruppenmitglied

nachr¨

ucken kann. T1und T2entscheiden sich f¨

ur die Kandidatin T4.T4kann nun

ihrerseits Materialien in den gemeinsamen Bereich einbringen und wie zuvor T3als

gleichberechtigtes Mitglied am Kooperationsprozess teilnehmen.

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.1 Lerngruppe 25

Szenario 1.8: Treffen mit Gastteilnehmer

•Gleichberechtigter Gastbenutzer mit vollem Zugriffsrecht auf den Gruppen-

bereich

Die Lerngruppe Gmit den Teilnehmern T1,T2und T3trifft sich zu einem gemein-

sam ausgehandelten Termin (siehe Szenario 1.4). Zu ihnen gesellt sich noch T4als

Gastteilnehmer hinzu. T4hat bereits im Vorjahr erfolgreich eine Pr¨

ufung ¨

uber den

Lernstoff abgelegt und will der Gruppe beim Lernen helfen. Dazu bekommt T4ein-

malig Zugriffsrechte auf den gemeinsamen Arbeitsbereich der Lerngruppe. Somit

ist T4gleichberechtigt zu den anderen Teilnehmern. – Es w¨

are alternativ auch nur

ein lesender Zugriff auf den Gruppenbereich m¨

oglich. – T4kann somit Materiali-

en aus seinem pers¨

onlichen Bestand zu dem Gruppenfundus hinzuf¨

ugen oder die

Materialien der Gruppe ¨

andern. Nach Beendigung der Lernsitzung werden diese

Rechte automatisch wieder entfernt.

Aufl¨

osung, Abschlussphase Lerngruppen existieren meist nur ¨

uber einen fest-

gelegten Zeitraum. Mit dem Erreichen des Lernzieles kann die Lerngruppe oftmals

aufgel¨

ost werden. Die Lernenden haben jedoch h¨

aufig den Wunsch, die Ergebnisse

f¨

ur einen sp¨

ateren Zeitpunkt zu archivieren. Eine Weitergabe der Lernergebnisse an

andere Lerngruppen ist ebenfalls ¨

ubliche Praxis. Die Archivierung der Lernergebnis-

se kann zum einen durch ein Aufrechterhalten der Gruppe geschehen, um sp¨

ater in

den Gruppenbereich zur¨

uckkehren zu k¨

onnen, oder zum anderen durch das Speichern

einer Momentaufnahme des Gruppenbereichs in den pers¨

onlichen Arbeitsbereich der

Teilnehmer gew¨

ahrleistet werden.

Die Alternative des Aufrechterhaltens aller je existierenden Gruppen ließe die

Gruppenstruktur un¨

ubersichtlich werden, da diese kontinuierlich mit jeder neuen

Lerngruppe w¨

achst. Auf diese Art geht schnell die ¨

Ubersicht verloren. Wird der

Bereich der Gruppen auf die Ger¨

ate ihrer Teilnehmer repliziert, ergibt sich hieraus

zus¨

atzlich ein stetig wachsender Speicherplatzbedarf auf den betroffenen Ger¨

aten.

Da die Teilnehmer mobile Ger¨

ate mit begrenzter (und teurer) Speicherkapazit¨

nutzen, ist darauf zu achten, dass das Archiv platzeffizient angelegt wird. Eine wei-

tere M¨

oglichkeit besteht darin, das Archiv auf einen externen Dienst auszulagern,

um sp¨

ater wieder darauf zugreifen zu k¨

onnen. Nat¨

urlich muss der Dienst in diesem

Fall stets erreichbar sein, sonst steht das Archiv in mancher mobilen Situation nicht

zur Verf¨

ugung.

Szenario 1.9: Aufl¨

osen der Lerngruppe

•Aufl¨

osen einer Gruppe

•Archivieren von Gruppenbereich und Gruppenstruktur

Mobilit¨

at in der kooperativen Wissensarbeit

26 2.1 Pr¨

asenzkooperation

•¨

Uberf¨

uhren der mobilen Gruppe in ein zentralisiertes CSCW-System

•Reaktivierung der Gruppe f¨

ur eine Wiederaufnahme der mobilen Kooperation

Nach der Pr¨

ufung wird die Lerngruppe Gmit den Mitgliedern T1,T2und T4auf-

gel¨

ost. Dies bedeutet, dass die Organisationsstruktur der Gruppe und die gemein-

samen Kommunikationskan¨

ale nicht mehr benutzt werden sollen. Die Gruppe an

sich kann somit gel¨

oscht werden. Da T1,T2und T3aber beim Lernen Freundschaft

geschlossen haben, beschließen sie, die Gruppe f¨

ur eine nicht zweckgebundene Kom-

munikation zu zu nutzen, um weiterhin ¨

uber das Kooperationssystem miteinander

in Kontakt treten zu k¨

onnen.

Die Teilnehmer T1und T2¨

ubernehmen dar¨

uber hinaus die Daten aus dem Grup-

penbereich als Archiv in ihren pers¨

onlichen Fundus auf und speichern diese auf

ihrem pers¨

onlichen mobilen Computer. So k¨

onnen sie auch in Zukunft auf die Ler-

nergebnisse zur¨

uckgreifen. T1leitet sein Archiv an den Benutzer T4weiter, der

nicht Mitglied der Lerngruppe war, aber in Zukunft einen ¨

ahnlichen Lernstoff zu

bew¨

altigen hat.

Da ein solches Archiv wertvollen Speicherplatz auf dem mobilen Ger¨

at von Teil-

nehmerin T2belegt, speichert diese es auf einem zentralen CSCW-Server. Dort k¨

on-

nen auch T1und T2in Zukunft auf dieses Archiv zugreifen, da die Gruppenstruktur

sammt Berechtigungen auf Wunsch ebenso auf den Server ¨

ubertragen werden. F¨

den Fall einer Folgeveranstaltung ¨

ubertr¨

agt T2also gleich die gesamte Gruppen-

struktur mit auf den Server, um die Gruppe bei Bedarf zu reaktivieren. Als im

darauf folgenden Jahr eine Folgeveranstaltung angeboten wird, ¨

ubertragen T1,T2

und T3die Gruppe zur¨

uck in ihre mobile Kooperationsumgebung und k¨

onnen so die

Lerngruppe an dem Punkt fortzusetzen, an dem sie die letzte Lerngruppe beendet

hatten.

Das hier behandelte Szenario der Lerngruppe mit mobilen Ger¨

aten hat einen kla-

ren Fokus auf Lernszenarien. Dennoch l¨

asst es sich auf andere allt¨

agliche Koopera-

tionssituationen ¨

ubertragen. Besonders im Bereich der angesprochenen spontanen

Lernsitzungen kann dieses Szenario um Aspekte des nachfolgenden Szenarios der

spontanen Kooperation erg¨

anzt werden.

2.1.2 Spontane Kooperation

Eine von klassischen CSCW Umgebungen nicht unterst¨

utzte Variante der Koope-

ration in Kleingruppen ist die spontane Kooperation, der keine Planungsprozesse

vorausgehen. H¨

aufig ist diese Form der Kooperation zeitlich begrenzt und dient ei-

nem kurzfristigen Ziel. Als Beispiel dient hier die Kooperation zweier Studierender,

die sich im Bus treffen, dort ¨

uber eine ¨

Ubungsaufgabe unterhalten und daraufhin

versuchen, gemeinsam einen L¨

osungsweg zu finden. Eine solche spontane Koope-

ration kann auch in eine l¨

angerfristige Kooperation ¨

ubergehen. Entsprechend dem

Beispiel k¨

onnten die Studierenden z. B. beschließen, eine l¨

angerfristige Lerngruppe

(vgl. Abschnitt 2.1.1) zu gr¨

unden.

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.2 Spontane Kooperation 27

Rahmenbedingungen Wie das einf¨

uhrende Beispiel schon andeutet, findet eine

spontane Kooperation oft unter unkontrollierten Rahmenbedingungen statt. Vorbe-

dingung ist lediglich, dass sich mindestens zwei Kooperationswillige treffen. ¨

Uber das

technische Umfeld kann somit nichts ausgesagt werden. F¨

ur die hier vorgestellten

Szenarien wird aber vom Vorhandensein eines pers¨

onlichen mobilen Computers mit

integrierter Netzwerkschnittstelle ausgegangen. Da in einem spontanen Kooperati-

onsszenario nicht von einer vorhandenen Netzwerkinfrastruktur ausgegangen werden

kann, muss die Kooperationsumgebung ¨

uber ein Ad-Hoc-Netzwerk kommunizieren

k¨

onnen.

Szenario 2.1: Grundszenario spontaner Kooperation

•Spontanes Treffen im ¨

offentlichen Raum

•Fehlende Kooperationsinfrastruktur

Das der spontanen Kooperation zugrunde liegende Szenario besteht aus den drei

Teilnehmern und Teilnehmerinnen T1,T2und T3, die sich im ¨

offentlichen Raum oh-

ne bestehende Infrastrukturen f¨

ur eine Kooperationsunterst¨

utzung treffen. Dieses

Treffen ist zuf¨

allig und nicht geplant. Alle Beteiligten verf¨

ugen ¨

uber mobile Compu-

ter mit zueinander kompatiblen drahtlosen Netzwerkschnittstellen, die es erlauben,

ein Ad-Hoc-Netzwerk zu etablieren. Dabei entsteht ein gemeinsames Netzwerk, das

den mobilen Ger¨

aten der Teilnehmer eine Kommunikation untereinander erlaubt.

Die Kooperationsumgebung nutzt diese Kommunikationsstruktur f¨

ur die Koordi-

nation der Kooperation und den Datenaustausch.

Gr¨

undung, Anbahnungsphase Spontane Kooperation integriert sich ¨

ublicher-

weise nahtlos in den Alltag der Kooperierenden, ohne dass sie einer der Beteiligten

in voraus geplant hat. Oft wird den Teilnehmern der eigentliche Kooperationsakt

zun¨

achst nicht einmal bewusst. Aus diesem Grund kann auch die entsprechende for-

male Kooperationsgruppe nicht bewusst gegr¨

undet werden. Sie entsteht vielmehr

aus dem Kooperationskontext. Jeder der Anwesenden bei einem Treffen ist potenti-

eller Kooperationspartner und kann w¨

ahrend des Verlaufs der Kooperationssitzung

in die Kooperationsgruppe ein- oder wieder austreten.

Die Kooperationspartner treffen sich also in allt¨

aglichen Situationen und starten

den Kooperationsprozess spontan. Die Kooperation selbst erfolgt entweder aufgrund

des g¨

unstigen Moments oder weil sich w¨

ahrend des Treffens unvorhergesehen ein

gemeinsames Kooperationsziel ergibt. Da die Kooperation nicht geplant ist, stehen

nur in der Umgebung vorhandene Hilfsmittel zur Verf¨

ugung. Dies sind insbesondere

die mitgef¨

uhrten mobilen Computer, die zu diesem Zweck genutzt werden, um eine

entsprechende Kooperationsumgebung bereitzustellen.

Die Kooperationsunterst¨

utzung muss sich nahtlos in den Kooperationsprozess ein-

betten und ohne eine aufw¨

andige Konfiguration seitens der Kooperierenden bereit-

Mobilit¨

at in der kooperativen Wissensarbeit

28 2.1 Pr¨

asenzkooperation

stehen. Im Idealfall aktivieren die Teilnehmer der Kooperation ihre mobilen Ger¨

ate

und gr¨

unden in der ad hoc bereitstehenden computergest¨

utzten Kooperationsum-

gebung beil¨

aufig eine Kooperationsgruppe mit dem dazugeh¨

orenden gemeinsamen

virtuellen Wissensraum.

Szenario 2.2: Erstellen einer vertraulichen Projektskizze w¨

ahrend einer

Zugreise – Gr¨

undung

•Gruppengr¨

undung mit Anwesenden ohne bestehende Netzwerkinfrastruktur

•spontanes Erstellen einer tempor¨

aren Kooperationsgruppe

Drei Arbeitskollegen T1,T2und T3, die der gleichen Organisation angeh¨

oren, un-

ternehmen gemeinsam eine l¨

angere Zugreise. Sie sitzen zusammen in einem Abteil

und k¨

onnen sich so vis-a-vis unterhalten. W¨

ahrend des Gespr¨

achs entsteht die Idee

f¨

ur ein neues gemeinsames Projekt. Aufgrund des g¨

unstigen Zeitpunktes und der

verf¨

ugbaren gemeinsamen Zeit schl¨

agt Teilnehmer T1vor, das neue Projekt di-

rekt zu skizzieren und in die Wege zu leiten. Zu diesem Zweck soll spontan eine

gemeinsamer Projektplan erarbeitet werden.

Die beiden Kollegen stimmen zu und aktivieren ihre mitgef¨

uhrten Notebooks,

die mittels eines Ad-Hoc-Netzwerkes vernetzt werden. Anschließend starten sie die

virtuelle Kooperationsumgebung die ihnen einen gemeinsamen Arbeitsbereich und

die ben¨

otigten Unterst¨

utzungsfunktionen zur Verf¨

ugung stellt. Da die Projektskiz-

ze einen vertraulichen Status besitzt, begrenzt Teilnehmer T1die Gruppe in der

Kooperationsumgebung mittels Selektion ¨

uber die verf¨

ugbaren Benutzer auf sich

und die zwei anwesenden Kollegen T2und T3. So entsteht eine tempor¨

are Gruppe

G∗. Andere Benutzer, die ebenfalls im Zug sitzen und mit der Kooperationsumge-

bung verbunden sind, k¨

onnen nicht auf den gemeinsamen Arbeitsbereich der drei

Kollegen zugreifen.

Da Teilnehmer T2bereits eine erste Rohskizze in der Datei d1vorliegen hat, stellt

er diese in dem gemeinsamen Arbeitsbereich zur Verf¨

ugung, indem er sie per Drag

& Drop dort hinzieht. Der Arbeitsbereich wird dabei standardm¨

aßig auf allen be-

teiligten Ger¨

aten identisch dargestellt. Hinzu kommen von Teilnehmer T1noch ein

Strategiepapier (d2) der Organisationsleitung, in die das Projekt eingeordnet wer-

den muss. Alle drei Teilnehmer der Gruppe G∗haben nun gleichberechtigten Zugriff

auf die gemeinsamen Dokumente und d¨

urfen sie sowohl lesen als auch ver¨

andern.

Fortsetzung in Szenario 2.4

Szenario 2.3: Bearbeiten einer ¨

Ubungsaufgabe in einer Vorlesungspau-

se – Gr¨

undung

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.2 Spontane Kooperation 29

•Gr¨

undung einer spontanen Kooperationsgruppe in einer existierenden Netz-

werkinfrastruktur

•Nutzung des Ortsbezugs f¨

ur die Gruppengr¨

undung

Drei Studierende der Informatik T1,T2und T3befinden sich in einem Koopera-

tionsszenario ¨

ahnlich Szenario 2.1. Sie treffen sich zwischen zwei Vorlesungen in

einem Bistro der Universit¨

at. Teilnehmerin T1fragt die beiden anderen Studieren-

den T2und T3, ob diese bereits eine ihnen aufgetragene Matheaufgabe gel¨

ost haben.

Die Studierenden verneinen dieses, auch wenn Teilnehmer T2bereits eine erste Idee

f¨

ur einen L¨

osungsansatz auf einigen Zetteln notiert hat.

Die technische Ausstattung der Teilnehmer ist wie folgt: Teilnehmerin T1besitzt

einen PDA, Teilnehmer T2ein Notebook und Teilnehmer T3einen PenPC. Neben

diesen technischen Ger¨

aten existieren noch ein Fachbuch und besagte handschrift-

liche Notizen aus dem Besitz von Teilnehmer T2. In den pers¨

onlichen Best¨

anden

befinden sich bei Teilnehmerin T1eine digitale Version einer Aufgabenstellung mit

Dateinamen d1und bei Teilnehmer T2zus¨

atzlich die Anleitung zur L¨

osung ¨

ahn-

licher Aufgabenstellungen mit Dateinamen d2– Teilnehmer T3besitzt zu Beginn

des Treffens keine eigenen Unterlagen.

Sie etablieren mittels ihrer mobilen Computer eine spontan vernetzte Koope-

rationsumgebung. Dazu nutzen sie das verf¨

ugbare Funknetzwerk der Universit¨

at.

Sofort werden alle verf¨

ugbaren Kooperationspartner angezeigt. Da sie sich im Fun-

knetz der Universit¨

at befinden, kontaktiert die Kooperationsumgebung alle ande-

ren verf¨

ugbaren Kooperationsanwendungen im Netz der Universit¨

at und findet so

eine große Anzahl potentieller Kooperationspartner. Teilnehmerin T1beschr¨

ankt

die m¨

oglichen Teilnehmer auf Personen in ihrer N¨

ahe. Aus dieser ¨

ubersichtlichen

Auswahl bildet sie nun mit ihren zwei Kommilitonen eine tempor¨

are Kooperati-

onsgruppe G∗. Somit verf¨

ugen alle drei ¨

uber einen abgeschlossenen gemeinsamen

Arbeitsbereich, in den sie ihre elektronisch verf¨

ugbaren Materialien einbringen, in-

dem sie diese aus ihrem privaten Fundus dort ablegen.

Das Fachbuch und die Skizze des L¨

osungsansatzes von Teilnehmer T1liegen auf

dem gemeinsam genutzten Tisch neben den Computern.

Fortsetzung in Szenario 2.5

Kooperationsphase Sobald die Infrastruktur f¨

ur die Zusammenarbeit etabliert

ist, nutzen die Teilnehmer deren kooperationsunterst¨

utzenden Funktionen. Bei einer

Kooperation basierend auf gemeinsam genutzten Dokumenten, dienen diese Funk-

tionen dem Austauschen, kooperativen Bearbeiten und Kommentieren der gemein-

samen Dokumente. Die Dokumente kommen dabei aus dem privaten Fundus der

Kooperationspartner, wo sie oftmals bereits in digitalisierter Form vorliegen. Nach-

dem die Dokumente in dem gemeinsamen Gruppenbereich abgelegt wurden, stehen

sie allen Kooperationspartnern zur Verf¨

ugung. Wie in dem Szenario der Lerngruppe

(vgl. Abschnitt 2.1.1) sind alle Kooperationspartner gleichberechtigt bez¨

uglich der

Mobilit¨

at in der kooperativen Wissensarbeit

30 2.1 Pr¨

asenzkooperation

Nutzung der gemeinsamen Dokumente. Eine Sperrung eines Dokuments in dem ge-

meinsamen Arbeitsbereich f¨

ur den Zugriff durch die Kooperationspartner ist nur in

Ausnahmen sinnvoll.

Eine Besonderheit der spontanen Kooperation ist die h¨

aufige Beschr¨

ankung ihrer

Dauer auf eine einzige Sitzung. Es sind nur wenige gemeinsame Objekte involviert

und der Arbeitsaufwand, diese zu strukturieren, ist f¨

ur eine so kurzfristige Koope-

ration zu hoch. Daher wird seitens der Nutzer wenig Zeit f¨

ur die Strukturierung des

Wissensraums aufgebracht, und der Wissensraum muss sich gegebenenfalls automa-

tisch strukturieren. Verschachtelte Strukturen, wie Ordner, sind in diesem Zusam-

menhang z. B. weniger effizient als semantische Karten, die nebenl¨

aufig beim Able-

gen der Objekte entstehen. Sollen die Ergebnisse einer spontanen und kurzfristigen

Kooperation weiterverwendet werden, m¨

ussen diese in persistente Kooperationss-

trukturen ¨

uberf¨

uhrt werden.

Die Kooperationspartner stehen bei dieser Kooperationsform im direkten Blick-

kontakt zueinander und ben¨

otigen somit keine virtuellen Kommunikationskan¨

ale wie

synchrone oder asynchrone Nachrichten. Die Kommunikation geschieht intuitiv ¨

uber

direkte Sprache und Gesten. Dies erm¨

oglicht eine sehr nat¨

urliche Interaktion zwi-

schen den Kooperationspartnern. ¨

Ublicherweise werden in solch ein Kooperationss-

zenario auch analoge Hilfsmittel, wie Notizzettel und B¨

ucher, integriert. Mit diesen

externen Dokumenten muss die computergest¨

utzte Kooperationsumgebung harmo-

nieren. Dies bedeutet nicht, dass sie in der Lage sein muss, diese Dokumente in ihre

virtuelle Welt zu ¨

uberf¨

uhren, sondern vielmehr, dass sie parallel zu den klassischen

Hilfsmitteln die Kooperation um computergest¨

utzte Methoden erg¨

anzt, ohne die aus

der Nutzung klassischer Hilfsmittel entstehenden Medienbr¨

uche weiter zu verst¨

ar-

ken. Das bedeutet auch, die Nutzungskonzepte an die der klassischen Hilfsmittel

anzupassen. Zur Verdeutlichung sei hier als negatives Beispiel der Wechsel zwischen

dem Schreiben mit dem Stift auf den Notizzetteln und dem Schreiben mit einer

Tastatur auf einem daneben platzierten Notebook angef¨

uhrt.

Ein mehr oder weniger bewusster Wechsel von den klassischen Kooperationshilfs-

mitteln in Richtung einer CSCW-Umgebung wird nur geschehen, wenn f¨

ur die Benut-

zer ein Mehrwert entsteht und alle Kooperationsdokumente ebenfalls in der compu-

tergest¨

utzen Umgebung verf¨

ugbar sind. Nat¨

urlich sind auch Umgebungen mit einer

erweiterten Realit¨

at (Augmented Reality) denkbar, wenngleich diese in allt¨

aglichen

Situationen aufgrund der hohen technischen Anforderungen noch nicht realisierbar

erscheinen. In den behandelten Szenarien wird diese M¨

oglichkeit daher außer Acht

gelassen.

Da die Kooperation in einem gemeinsamen Gruppenbereich spontan erfolgt, bein-

halten diese Szenarien entsprechend wenig Annahmen ¨

uber die konkreten Rahmen-

bedingungen oder den Ablauf der Kooperationsprozesse. Die Kooperation erfolgt frei

und freiwillig, dementsprechend wenig restriktiv darf die Kooperationsumgebung in

ihren Unterst¨

utzungsfunktionen sein.

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.2 Spontane Kooperation 31

Szenario 2.4: Erstellen einer vertraulichen Projektskizze w¨

ahrend einer

Zugreise – Kooperationsphase

Fortsetzung von Szenario 2.2

•Bearbeiten von Dokumenten in der spontan errichteten Kooperationsumge-

bung

•Wechsel zwischen kooperativer und individueller Arbeit

Die drei Kollegen (G∗={T1, T2, T3}) sichten zun¨

achst die vorhandenen Materia-

lien (d1, d2) und diskutieren den Entwurf in d1von Teilnehmer T2. In einem ersten

Schritt ordnen sie den Entwurf in das Strategiepapier d2der Organisationsleitung

ein und Teilnehmer T3versieht die entsprechende Stelle in d2mit einer Annotation.

T2hat noch eine Anmerkung dazu und kommentiert seinerseits die Annotation.

Da die Struktur des Entwurfs d1bei der Kollegin T1und dem Kollegen T3nicht

auf Zustimmung st¨

oßt, entschließen sie sich, den Entwurf in seine einzelnen Punk-

te zu zerlegen, um einige Punkte zu erweitern und anschliessend neu zu gliedern.

Dazu zerlegen sie das Dokumente in viele kleinere Dokumente (d1,1,· · · , d1,n), die

die einzelnen Gliederungspunkte der Skizze enthalten. Sie bewerten jeder f¨

ur sich

die einzelnen Punkte und entscheiden, welche Punkte entfernt oder hinzugef¨

ugt

werden m¨

ussen. Danach strukturieren sie kooperativ die einzelnen Dokumente als

semantische Karte, in die jedes Dokument eingeordnet wird. Um eine bereits er-

folgte Strukturierung duch die anderen Kollegen nicht unbewusst zu ver¨

andern,

werden die Sichten aller Beteiligten auf die semantische Karte synchronisiert.

Am Ende der Sitzung hat sich eine Gliederung der Punkte etabliert, deren Haupt-

abschnitte parit¨

atisch an je einen Kollegen weitergegeben wird. Dieser Abschnitt

wird von jedem der drei Teilnehmer zun¨

achst individuell weiterbearbeitet.

Fortsetzung in Szenario 2.6

Szenario 2.5: Bearbeiten einer ¨

Ubungsaufgabe in einer Vorlesungspau-

se – Kooperationsphase

Fortsetzung von Szenario 2.3

•Bearbeiten und Zusammenf¨

uhren pers¨

onlicher Versionen eines Dokumentes

Die drei Studierenden (G∗={T1, T2, T3}) entscheiden sich, die Kooperation ex-

klusiv in der computergest¨

utzten Kooperationsumgebung fortzusetzen, um Medien-

br¨

uche durch die Vermischung von herk¨

ommlichen und digitalen Dokumenten zu

vermeiden. Dazu m¨

ussen sie zun¨

achst die auf den Notizzetteln niedergeschriebe-

nen L¨

osungsans¨

atze in ein digitales Dokument ¨

ubertragen. Ein einfaches Abbild

der Notizen reicht ihnen allerdings nicht aus, da sie das Dokument im Nachhin-

ein bearbeiten k¨

onnen m¨

ochten und Teile ihrer L¨

osung zur Weiterverarbeitung an

Mobilit¨

at in der kooperativen Wissensarbeit

32 2.1 Pr¨

asenzkooperation

ein Algebrasystem ¨

ubergeben wollen, das auf dem Notebook von Teilnehmerin T3

installiert ist.

Daher ¨

ubertragen sie die Notizen von Hand und mit Hilfe einer speziellen Softwa-

re auf Zeichenebene in das Zieldokument d3. Innerhalb des gemeinsamen Arbeits-

bereiches ist das Dokument f¨

ur alle drei Teilnehmer sichtbar, und sie k¨

onnen es dort

gemeinsam bearbeiten. Um ein m¨

oglichst breites Spektrum von L¨

osungswegen zu

explorieren, beschließen sie, die L¨

osung der Aufgabe zun¨

achst getrennt, jeder f¨

sich, fortzuf¨

uhren. Sie erstellen dazu pers¨

onliche Versionen d1

3, d2

3und d3

3des Do-

kumentes d3. Teilnehmerin T1bearbeitet Dokument d1

3, Teilnehmer T2Dokument

3und Teilnehmerin T3Dokument d3

Nach der individuellen Arbeitsphase f¨

uhren sie die pers¨

onlichen Versionen wie-

der zusammen zu einem Dokument. Zun¨

achst bewerten sie die Teildokumente und

verwerfen Dokument d1

3, da der enthaltene L¨

osungsweg nicht zum gew¨

unschten

Ergebnis f¨

uhrt. Der Ansatz von Dokument d2

3erscheint am vielversprechendsten

und soll um eine Teill¨

osung aus d3

3erg¨

anzt werden. Das so entstehende Dokument

ersetzt die alte L¨

osungsskizze d3.

Dieser Vorgang der individuellen L¨

osungs¨

uberarbeitung und des Zusammenf¨

uh-

rens der resultierenden L¨

osungsdokumente wird im Laufe der Sitzung iterativ wie-

derholt bis ein zufrieden stellendes L¨

osungsdokument entstanden ist – oder die

Kooperationssitzung aus einem anderen Grund endet.

Fortsetzung in Szenario 2.7

Aufl¨

osung, Abschlussphase Da die Gruppengr¨

undung in spontanen Koopera-

tionsszenarien nicht geplant erfolgt und eher eine nebenl¨

aufige Handlung ist, erfolgt

auch die Beendigung der Kooperation eher unbewusst. Der entstandene virtuelle

Wissensraum und die zugeh¨

orige Kooperationsgruppe bestehen exakt so lange wie

die Kooperationssitzung andauert. Sie werden zum Ende der Kooperationssitzung

ebenso beil¨

aufig aufgel¨

ost, wie sie entstanden sind. ¨

Ahnlich verh¨

alt es sich mit dem

gemeinsamen Datenbestand.

Aufgrund der Begrenzung der spontanen Kooperation auf eine einzige Sitzung,

existiert zu Beginn kein langfristiges Kooperationsziel. Oftmals m¨

ochten die Ko-

operierenden dennoch am Ende der Sitzung die Kooperation fortf¨

uhren. Die zu-

n¨

achst spontane und kurzfristige Kooperation kann dann in eine Kooperationsform

uberf¨

uhrt werden, die ¨

uber einen l¨

angeren Zeitraum bis zum Erreichen des Koope-

rationsziels fortgesetzt wird. Dazu kann die tempor¨

are Kooperationsgruppe in eine

langfristige mobile Kooperationsstruktur mit einer etablierten Benutzer- und Rechte-

struktur ¨

uberf¨

uhrt werden oder sogar in ein klassisches CSCW-System transportiert

werden.

Selbst wenn eine Fortsetzung der Kooperation nicht gew¨

unscht ist, liegt es h¨

au-

fig im Interesse der Teilnehmer, zumindest Teilergebnisse der Kooperation in ihren

pers¨

onlichen Bestand zu ¨

ubernehmen. Aufgrund des gleichberechtigten Charakters

spontaner Kooperation sind hierzu alle beteiligten Kooperationspartner berechtigt.

Mobilit¨

at in der kooperativen Wissensarbeit

2.1.2 Spontane Kooperation 33

Die Kooperationsergebnisse k¨

onnen dazu innerhalb der Kooperationsumgebung oder

auf einem anderen Speichermedium f¨

ur den pers¨

onlichen Gebrauch abgelegt werden.

Alternativ k¨

onnen sie auch direkt in eine andere Kooperation eingebracht werden.

Nat¨

urlich k¨

onnen die Kooperationsergebnisse auch die Grundlage f¨

ur eine sp¨

atere

noch nicht geplante spontane Kooperation mit denselben Teilnehmern dienen. Da

eine solche sp¨

ater spontane Kooperationssitzung aber nicht voraussehbar ist, scheint

es oft nicht sinnvoll, die Gruppenstruktur und den Datenbestand aufrecht zu erhal-

ten, ohne zu wissen, ob eine solche Konstellation je wieder eintritt.

Szenario 2.6: Erstellen einer vertraulichen Projektskizze w¨

ahrend einer

Zugreise – Abschlussphase

Fortsetzung von Szenario 2.4

•Beenden der Kooperationssitzung

•Archivieren der Kooperationsstruktur

Die Teilnehmerin T3der Gruppe (G∗={T1, T2, T3}) verl¨

asst den Zug einige Sta-

tionen vor den Kollegen und beendet daher die Verbindung zur Kooperationsum-

gebung. Weil die tempor¨

are Kooperationsgruppe G∗mit den verbleibenden zwei

Mitgliedern zun¨

achst fortbesteht ¨

uberf¨

uhrt sie eine Kopie der Arbeitsergebnisse

zu dem Zeitpunkt des Verlassens der Kooperationssitzung in ihren pers¨

onlichen

Arbeitsbereich, der sich auf ihrem Notebook befindet, und nimmt diese f¨

ur eine

sp¨

atere Verwendung mit.

Die Teilnehmer T1und T2setzen die Kooperation nach dem Ausscheiden der

Teilnehmerin T3fort. Nach Erreichen des Zielbahnhofs beenden sie die Kooperati-

onssitzung. Teilnehmer T2verl¨

asst ebenfalls die Kooperationssitzung und hat wie

Teilnehmerin T3zuvor die M¨

oglichkeit, eine Kopie der Arbeitsergebnisse mitzuneh-

men. Teilnehmerin T1hat nun beim Beendigen der Kooperationssitzung folgende

Optionen:

•Verwerfen der Gruppenstruktur und der Kooperationsergebnisse.

•Archivieren der Kooperationsergebnisse im pers¨

onlichen Arbeitsbereich.

•¨

Uberf¨

uhren der Kooperationsgruppe inklusive Arbeitsbereich in eine perma-

nente Kooperationsgruppe innerhalb der Kooperationsumgebung.

•¨

Ubertragen der Kooperationsgruppe inklusive Arbeitsbereich auf einen

CSCW-Server, um eine h¨

ohere Verf¨

ugbarkeit f¨

ur alle Beteiligten zu erreichen.

Um die Kooperation zu einem sp¨

ateren Zeitpunkt fortf¨

uhren zu k¨

onnen, bewahrt

Teilnehmerin T1die Gruppenstruktur und Kooperationsergebnisse, indem sie die

tempor¨

are Kooperationsgruppe und deren Arbeitsbereich in eine permanente Grup-

pe ¨

uberf¨

uhrt. Zu diesem Zweck ordnet sie als letzte Handlung der Kooperations-

sitzung die Gruppe in die bereits existierende Gruppenstruktur der Kooperations-

umgebung ein.

Mobilit¨

at in der kooperativen Wissensarbeit

34 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

Szenario 2.7: Bearbeiten einer ¨

Ubungsaufgabe in einer Vorlesungspau-

se – Abschlussphase

Fortsetzung von Szenario 2.5

•¨

Uberf¨

uhren einer spontanen Kooperationsgruppe in eine persistente Gruppe

Die tempor¨

are Gruppe von Studierenden (G∗={T1, T2, T3}) hat gemeinsam einen

L¨

osungsansatz d3f¨

ur die Aufgabe in Dokument d1erarbeitet und beendet nun die

Kooperationssitzung. Da eine gemeinsame Abgabe der L¨

osung f¨

ur ¨

Ubungsaufgaben

bei der entsprechenden Vorlesung nicht vorgesehen ist, ¨

ubernehmen die Studieren-

den die Teill¨

osungen in ihre pers¨

onlichen L¨

osungsdokumente (d1

3, d2

3, d3

3), die sp¨

ater

elektronisch oder in Papierform an den Dozenten der Veranstaltung ¨

ubermittelt

werden m¨

ussen, um sich Zusatzpunkte f¨

ur die ausstehende Klausur zu verdienen.

Die Studierenden beschließen aufgrund ihrer positiven Kooperationserfahrun-

gen aus der einmaligen spontanen Kooperationssitzung heraus, eine permanente

Lerngruppe (vgl. Szenario in Abschnitt 2.1.1) zu gr¨

unden. Zu diesem Zweck ¨

uber-

f¨

uhren sie die tempor¨

are Gruppe G∗={T1, T2, T3}in eine permanente Gruppe

G={T1, T2, T3}auf dem CSCW-Server des Instituts und ordnen diese in dessen

Gruppenstruktur ein. Der zugeh¨

orige gemeinsame Arbeitsbereich wird ebenfalls

dauerhaft auf dem CSCW-Server gespeichert und somit den Studierenden T1,T2

und T3langfristig verf¨

ugbar gemacht.

Die in diesem Abschnitt behandelten Szenarien der ”Lerngruppe“ (2.1.1) und der

”Spontane Kooperation“ (2.1.2) setzen stets die Anwesenheit der beteiligten Benut-

zer voraus. In dem n¨

achsten Abschnitt werden in Kontrast dazu r¨

aumlich verteilte

Benutzer in eine Kooperation einbezogen.

2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

Eine der Hauptaufgaben klassischer CSCW-Systeme ist die Unterst¨

utzung der Ko-

operation r¨

aumlich getrennter Personen. Diese Systeme haben die Zielsetzung, die

r¨

aumliche Trennung zu ¨

uberbr¨

ucken, indem sie geeignete Kommunikationsmechanis-

men bereitstellen, spezielle Kooperationswerkzeuge zur Verf¨

ugung stellen und einen

gemeinsamen Arbeitsbereich (engl. shared workspace) bereitstellen. Die Erforschung

und Entwicklung von Kooperationswerkzeugen und -konzepten in den letzten Jahr-

zehnten hat zu einigen ausgereiften L¨

osungen f¨

ur verschiedenste Szenarien r¨

aumlich

getrennter Kooperation gef¨

uhrt. Die meisten L¨

osungen wurden gem¨

aß dem vorherr-

schenden Client-Server-Paradigma als zentral verwaltete Kooperationsumgebungen

umgesetzt. Da viele dieser Systeme inzwischen weit ¨

uber einen prototypischen Cha-

rakter hinaus sind, werden sie in Bildungseinrichtungen und der Industrie produktiv

eingesetzt. Im privaten Umfeld sind sie hingegen selten zu finden, was an den Tatsa-

chen liegen mag, dass aufgrund der zentralisierten Architektur eine Abh¨

angigkeit von

st¨

andigen Kommunikationsverbindungen besteht, diese Systeme nur auf speziellen

Mobilit¨

at in der kooperativen Wissensarbeit

Servern laufen, die st¨

andig in Betrieb sein m¨

ussen, und außerdem durch Spezialisten

konfiguriert und gewartet werden m¨

ussen.

Die in Kapitel 2.1 angesprochenen Szenarien der Pr¨

asenzkooperation sind eine

wichtige Komponente um computergest¨

utzte Kooperationen nahtlos in den Alltag

der Menschen zu integrieren. Hier besteht seitens der klassischen CSCW-Systeme

eine L¨

ucke, die es zu schließen gilt. Wie die Szenarien der Pr¨

asenzkooperation zei-

gen, steht der Nutzung klassischer CSCW-Systeme f¨

ur derartige Szenarien zumin-

dest deren zentralisierte Architektur im Wege. Neuere Ans¨

atze versuchen daher die

Kooperationsumgebung auf alle beteiligten Computer zu verteilen.

Dieses neue Architekturprinzip im Bereich des CSCW bedingt aber zugleich we-

sentliche Ver¨

anderungen f¨

ur die Bereitstellung von Mechanismen zur Kooperations-

unterst¨

utzung. Insbesondere die technische Umsetzung wird stark von den Mecha-

nismen abweichen, die derzeit in zentralisierten CSCW-Systemen zu finden sind. An

diesen technischen M¨

oglichkeiten m¨

ussen sich auch die Konzepte der mobil-verteilten

Kooperation orientieren. Insbesondere erschließt die Ber¨

ucksichtigung der Mobilit¨

der Nutzer in einer verteilten Architektur v¨

ollig neue Perspektiven f¨

ur die Koopera-

tionsunterst¨

utzung in CSCW-Umgebungen. Diese neuen Perspektiven deuteten sich

zum Teil bereits in den Szenarien der Pr¨

asenzkooperation an. Die folgenden Sze-

narien dienen daher der Betrachtung der neuen Aspekte einer r¨

aumlich getrennten

Zusammenarbeit in mobil-verteilten Kooperationsumgebungen.

Bei einer kombinierten Unterst¨

utzung von Pr¨

asenzkooperation und r¨

aumlich ver-

teilter Kooperation ist es wichtig, die Benutzer nicht zu n¨

otigen, die Kooperati-

onsumgebung zu wechseln, weil sie von einer Form der Kooperation in die andere

ubergehen. Der optimale Architekturansatz muss daher ein m¨

oglichst breites Spek-

trum von Kooperationsszenarien unterst¨

utzen. Sollte ein Wechsel zwischen unter-

schiedlichen Kooperationsumgebungen sinnvoll oder gar unvermeidlich erscheinen,

ben¨

otigen die Kooperationsumgebungen nahtlose ¨

Uberg¨

ange, um den Benutzer nicht

mit vermeidbaren technischen H¨

urden zu konfrontieren.

In den folgenden Szenarien wird eine Kooperationskultur beschrieben, die nur

entstehen kann, wenn Kooperation immer und ¨

uberall m¨

oglich und die Nutzung

der Kooperationsumgebung unabh¨

angig des aktuellen Aufenthaltsorts der Benut-

zer ist. Diesbez¨

uglich w¨

are eine allgegenw¨

artige Netzwerkverbindung zum Internet

w¨

unschenswert. Da diese aber auch in Zukunft nicht immer und vor allem oft nicht

kosteng¨

unstig m¨

oglich ist, wird die Kooperationsumgebung robust gegen Verbin-

dungsabbr¨

uche zum Netzwerk zu gestalten sein. Dies betrifft sowohl die Unterst¨

ut-

zung von individuellem Arbeiten im gemeinsamen virtuellen Wissensraum, wie auch

die M¨

oglichkeit zur Pr¨

asenzkooperation ohne Zugang zum Internet. Sollte eine Ko-

operationsgemeinschaft durch einen Verbindungsabbruch im Netzwerk voneinander

getrennt werden, ist zudem bei wiederkehrender Netzwerkverbindung der zeitweise

getrennte Wissensraum wieder zu vereinigen.

Die Szenarien r¨

aumlich getrennter Kooperation sind eine klassische Dom¨

ane der

g¨

angigen Client-Server-basierten CSCW-Systeme. Um aber einen nahtlosen ¨

Uber-

gang zwischen den Szenarien aus Abschnitt 2.1 (Pr¨

asenzkooperation) und 2.2 (Koope-

ration mit r¨

aumlich verteilten Teilnehmern) zu erreichen, ist es wichtig, diese Szena-

Mobilit¨

at in der kooperativen Wissensarbeit

36 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

rien in der neuartigen verteilten CSCW-Umgebung ebenfalls zu unterst¨

utzen. Erg¨

an-

zend zu einer Verschmelzung von Pr¨

asenzkooperation und r¨

aumlich getrennter Ko-

operation in einer mobil-verteilten Kooperationsumgebung wird in Abschnitt 2.2.2

(Distant Learning) eine st¨

arkere Verkn¨

upfung von Client-Server-basierten und mobil-

verteilten Kooperationssystemen diskutiert. Der folgende Abschnitt betrachtet aber

zun¨

achst die Unterst¨

utzung r¨

aumlich getrennter Benutzer in einer mobil-verteilten

CSCW-Umgebung.

2.2.1 R¨

aumlich getrennte Kooperation

R¨

aumlich getrennte Kooperation teilt sich einige wesentliche Merkmale mit der Pr¨

senzkooperation aus Kapitel 2.1. Sie zeichnet sich aber dadurch aus, dass zumindest

ein Teil der Mitglieder einer Kooperationsgruppe sich nie oder nur selten gemeinsam

an einem Ort aufhalten. In dieser Tatsache liegen einige besondere Anforderungen

an die Mechanismen zur Kooperationsunterst¨

utzung begr¨

undet. W¨

ahrend bei der

Pr¨

asenzkooperation Mechanismen zur nahtlosen Einbettung der computergest¨

utzten

Kooperationsumgebung in ”nat¨

urliche“ Kooperationsszenarien im Vordergrund stan-

den, sind es bei der r¨

aumlich getrennten Kooperation Mechanismen, die es erlauben,

Teilnehmer in die Kooperation einzubinden, die w¨

ahrend der Kooperationssitzung

nicht k¨

orperlich zugegen sind.

Gr¨

undung, Anbahnungsphase In einer verteilten Kooperationsumgebung kann

die Gr¨

undung einer Kooperationsgruppe ¨

uber Mechanismen der Gruppenfindung f¨

r¨

aumlich getrennte Teilnehmer geschehen (vgl. auch Szenario 1.2) oder die Gruppe

aus einer zuvor etablierten Kooperationsform ¨

ubernommen werden. Dabei spielt es

keine Rolle ob die Kooperation zuvor in einem klassischen CSCW-System oder einem

mobil-verteilten CSCW-System stattgefunden hat.

Im Fall eines mobil-verteilten CSCW-Systems erfolgt die Gruppengr¨

undung ana-

log zu der Anbahnungsphase in Abschnitt 2.1.1 und 2.2.1. In diesem Fall k¨

onnen die

Gruppenstrukturen beibehalten werden und auch die Kooperationsbereiche m¨

ussen

nicht weiter angepasst werden. Erst in der Kooperationsphase selber werden speziell

angepasste Mechanismen f¨

ur eine ¨

ortlich getrennte Kooperation ben¨

otigt.

Soll eine Gruppe von einem klassischen serverbasierten CSCW-System auf ein

mobil-verteiltes CSCW-System ¨

uberf¨

uhrt werden, so muss die Gruppe mit allen ent-

haltenen Benutzern und zugeh¨

origen Arbeitsbereichen in das mobil-verteilte CSCW-

System ¨

ubertragen werden. Der Gruppenarbeitsraum muss gem¨

aß der Szenarien in

Abschnitt 2.1 auf die Ger¨

ate aller Teilnehmer verteilt werden und der pers¨

onliche Ar-

beitsbereich der Benutzer muss auf deren Ger¨

ate ¨

ubertragen werden. Soll der Server

auch weiterhin genutzt werden k¨

onnen, so verbleiben die Daten zun¨

achst auf diesem

gespeichert. Bez¨

uglich des pers¨

onlichen Arbeitsbereiches bedeutet dieses Vorgehen,

dass von diesem nun mindestens zwei Versionen existieren (eine auf dem Server und

eine in der mobil-verteilten Umgebung auf dem mobilen Ger¨

at des Benutzers). Bei

dem Gruppenbereich sind sogar deutlich mehr Versionen betroffen (mindestens je

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.1 R¨

aumlich getrennte Kooperation 37

eine Version auf jedem Rechner der Gruppenmitglieder und zus¨

atzlich eine Version

auf dem Server).

Szenario 3.1: ¨

Uberf¨

uhren einer zentral verwalteten Kooperationsgruppe

in eine mobil-verteilte Kooperationsumgebung

•¨

Uberf¨

uhren einer Kooperationsgruppe von einem CSCW-Server in ein mobil-

verteiltes CSCW-System

•Verteilen des gemeinsamen Arbeitsbereiches der Gruppe auf die beteiligten

Ger¨

ate

Eine einem CSCW-Server existierende Gruppe auf mit drei Teilnehmern ( G=

{T1, T2, T3}) soll f¨

ur eine Kooperation mittels mobiler Ger¨

ate in eine mobil-

verteilte Kooperationsumgebung ¨

uberf¨

uhrt werden. Die Gruppe Gbesitzt auf

dem Server einen gemeinsamen Arbeitsbereich mit diversen Dokumenten ( A=

{d1,· · · , dn}).

Da nicht alle Gruppenmitglieder w¨

ahrend der Kooperationssitzungen stets zu-

gegen sind, kann der Arbeitsbereich Anicht zentral auf einem mobilen Ger¨

at der

Gruppenteilnehmer gespeichert werden. Daher wird auf jedem beteiligten Mobil-

computer eine Kopie des gemeinsamen Arbeitsbereichs abgelegt. Ausgehend von

einem Mobilcomputer je Teilnehmer entstehen drei Kopien des Arbeitsbereiches

und der enthaltenen Dokumente ( AT1={dT1

1,· · · , dT1

n},AT2={dT2

1,· · · , dT2

n},

AT3={dT3

1,· · · , dT3

n}). Diese Kopien werden bei jedem Kontakt der Teilnehmer

untereinander abgeglichen.

Soll die Gruppe nicht aus einem anderen System oder einer anderen Kooperati-

onsform ¨

ubernommen werden, so bedarf es einer M¨

oglichkeit, diese Gruppe ohne

pers¨

onliches Treffen zu gr¨

unden. Dies geschieht analog zu dem Vorgehen in zentrali-

sierten CSCW-Systemen: Ein zuk¨

unftiges Gruppenmitglied muss zun¨

achst eine neue

Gruppe erstellen. Damit existieren eine Gruppe mit einem Mitglied (dem Benutzer,

der die Gruppe erstellt hat) und der dazugeh¨

orige Gruppenbereich. Zu dieser Gruppe

kann der gr¨

undende Benutzer (und sp¨

ater auch alle weiteren berechtigten Gruppen-

mitglieder) Einladungen an ihm bekannte Benutzer verschicken. Beantworten diese

die Einladung positiv, geh¨

oren sie von nun an zu der Gruppe. Alternativ kann die

Gruppe auch ¨

uber ein Verteilungsverfahren oder entsprechende Verzeichnisse ¨

offent-

lich bekannt gemacht werden (vgl. auch Szenario 1.2). Interessierte Benutzer k¨

onnen

dann eine Mitgliedschaft beantragen, die daraufhin von den berechtigten Gruppen-

mitgliedern entschieden wird.

Kooperationsphase Da die Teilnehmer einer r¨

aumlich getrennten Kooperations-

gruppe ¨

uber unterschiedliche Arten einer Netzwerkanbindung verf¨

ugen, kann es not-

wendig sein, die Verteilung der Kooperationsobjekte ebenfalls unterschiedlich vorzu-

nehmen. Der Abgleich verteilt gespeicherter Objekte kann je nach Verbindungsg¨

ute

Mobilit¨

at in der kooperativen Wissensarbeit

38 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

lange dauern oder die genutzen Verbindungen k¨

onnen zu instabil sein, um einen

entfernten Objektzugriff sinnvoll durchzuf¨

uhren.

Szenario 3.2: Entfernte Teilnahme an einer verteilten Kooperation ¨

uber

eine sporadische Funkverbindung

•Verteiltes Kooperieren ¨

uber unzuverl¨

assige Netzwerkverbindungen

Eine Gruppe mit drei ¨

ortlich getrennten Mitgliedern ( G={T1, T2, T3}) arbeitet

in einer gemeinsamen Arbeitsumgebung A. Teilnehmerin T1reist mit der Bahn

uber Land und nimmt ¨

uber eine GSM-Verbindung an der Kooperationssitzung

teil. Die ¨

Ubertragung des gesamten Inhalts der Arbeitsumgebung Adauert ¨

uber

die Verbindung mindestens 5 Minuten. In unregelm¨

assigen Abst¨

anden bricht die

Verbindung zu dem GSM-Netz ab. In dem Fall eines Verbindungsabbruchs ist keine

Kommunikation mit den anderen Teilnehmern mehr m¨

oglich. Bis eine neue GSM

Verbindung aufgebaut ist k¨

onnen zwischenzeitlich mehrere Minuten vergehen.

Obwohl die Verbindung bei einem bevorstehenden Abbruch schlechter wird und

dieser somit in etwa vorausgesagt werden kann, reicht die Zeit nicht, um die noch

offenen ¨

Anderungen in dem verteilten Arbeitsbereich komplett zur¨

uckzuschreiben

und die ge¨

anderte Kopie des gesamten Arbeitsbereiches AT1an alle Teilnehmer zu

verteilen. W¨

ahrend der bestehenden Verbindung werden daher stetig die Ver¨

an-

derungen ∆AT1innerhalb des gemeinsamen Arbeitsbereiches A¨

ubertragen und in

die Kopien AT2und AT3der Teilnehmer T2und T3eingepflegt. Bei einem Verbin-

dungsabbruch werden die ¨

Anderungen gesammelt und im Nachhinein an T2und T3

verteilt. Die ¨

Anderungen seitens T2und T3werden auf dem gleichen Weg bei der Ko-

pie AT1von T1eingepflegt. Ziel des st¨

andigen Abgleichs ist es alle verteilten Kopien

des gemeinsamen Arbeitsbereiches Aidentisch zu halten ( A=AT1=AT2=AT3).

Besteht eine Verbindung, sehen alle Teilnehmer mittels einer gemeinsamen syn-

chronisierten Sicht auf den Arbeitsbereich A, an welchem Teil der enthaltenen

Dokumente die anderen Teilnehmer derzeit arbeiten.

W¨

ahrend einer Verbindungsunterbrechung arbeiten nun Teilnehmerin T1und

Teilnehmer T2an demselben Dokument d∈Aohne voneinander zu wissen. Bei

dem Versuch der Umgebung, die ¨

Anderungen ∆AT

1von T1beim n¨

achsten Verbin-

dungsaufbau bei dem synchronisierten Arbeitsbereich Aeinzupflegen, w¨

urde die

Umgebung die ¨

Anderungen von T2in dem zwischen T2und T3synchronisierten

Dokument d¨

uberschreiben. Im Gegenzug w¨

urden die ¨

Anderungen von Teilneh-

mer T2die ¨

Anderung von T1in deren Kopie von d¨

uberschreiben. Die Folge w¨

ren zwei Versionen (d0und d00) des Dokumentes d, die nicht l¨

anger synchron sind

(d0=dT16=dT2=dT3=d00 ). Da nur jeweilige ¨

Anderungen seitens der Teilnehmer

ubertragen werden, w¨

urde auch kein weiterer Abgleich vorgenommen. Es bliebe

bei den asynchronen Kopien, deren Inhalt mit weiteren ¨

Anderungen noch weiter

divergieren w¨

urde.

Um dieses Dilemma zu vermeiden, ¨

uberpr¨

uft die Kooperationsumgebung vor dem

Abgleich zweier Kopien eines verteilten Objektes erst, ob diese zwischen dem letzten

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.1 R¨

aumlich getrennte Kooperation 39

Abgleich von mehr als einem Teilnehmer ge¨

andert wurden. Sollte dies der Fall sein,

werden die beteiligten Teilnehmer ( T1und T2) aufgefordert, den Konflikt vor der

endg¨

ultigen Synchronisierung zu l¨

osen. Erst dieses konsistente Objekt wird dann

an alle Beteiligten verteilt. So bleibt der gemeinsame Arbeitsbereich konsistent.

Bei einer Kooperation ¨

uber große Entfernungen hinweg ergeben sich h¨

aufig stark

asynchrone Kooperationsszenarien. Da die Teilnehmer bei asynchronen Kooperati-

onsformen die Ver¨

anderung im gemeinsamen Arbeitsbereich nicht zeitgleich mitver-

folgen k¨

onnen, m¨

ussen Informationen ¨

uber ¨

Anderungen dementsprechend aufberei-

tet werden. Dies kann z. B. durch Zusammenfassungen oder automatisch generierte

Annotationen geschehen.

Auch die Kommunikation erfolgt in diesen Kooperationsszenarien asynchron. Da-

bei wird die asynchrone Kommunikation, auch wegen ihres h¨

aufig hierarchischen und

weniger fl¨

uchtigen Charakters, der synchronen Kommunikation vorgezogen. Diskus-

sionsforen und ausgefeilte Annotationsmechanismen, die mit einzelnen Kooperati-

onsobjekten verkn¨

upft werden, helfen dar¨

uber hinaus, eine dokumentenzentrierte

Kommunikation zu etablieren, ohne jedes Mal explizit auf das betroffene Objekt

Bezug nehmen zu m¨

ussen. Die Diskussion wird ¨

ahnlich wie ein digitaler Notizzettel

an das Dokument geheftet, so dass alle Kooperationsmitglieder direkt den Zusam-

menhang zwischen Notiz und Objekt erkennen k¨

onnen.

Szenario 3.3: Zeitversetzte Kooperation in verteilten CSCW-

Anwendungen

•Zeitlich stark versetzte Kommunikation

•Asynchroner Datenaustausch ¨

uber Mittelsdienste

Zwei ¨

uber mehrere Zeitzonen hinweg entfernte Personen, T1und T2, wollen mittels

eines mobil-verteilten Kooperationssystems eine Softwarearchitektur f¨

ur eine Wa-

renverwaltung entwerfen. Anders als bei einem Client-Server-System l¨

auft das ver-

teilt arbeitende CSCW-System gleichberechtigt auf den Computern beider Teilneh-

mer. Innerhalb der Kooperationsumgebung gr¨

unden sie eine Gruppe G={T1, T2}

mit zugeh¨

origem gemeinsamen Arbeitsbereich A. Dieser wird auf den beteiligten

Computern synchronisiert gespeichert, so dass jeder Teilnehmer stets die aktuellen

der Kooperation zu Grunde liegenden Daten im Zugriff hat. Wird also von Teil-

nehmerin T1die Datei din den gemeinsamen Arbeitsbereich Aeingebracht, wird

diese zun¨

achst in der lokalen Instanz der Kooperationsumgebung gespeichert und

dann zum n¨

achstm¨

oglichen Zeitpunkt auf die entfernte Instanz der Kooperations-

umgebung von Benutzer T2¨

ubertragen.

Da beide Teilnehmer aufgrund der Zeitverschiebung nur selten zur selben Zeit

Arbeiten, besteht die Gefahr, dass die CSCW-Anwendungen ebenfalls nur selten zur

selben Zeit laufen. Dies st¨

unde dem regelm¨

aßigen Abgleich des gemeinsamen Ar-

beitsbereiches im Wege. Die Anwendung muss daher in der Lage sein, die Gegenseite

Mobilit¨

at in der kooperativen Wissensarbeit

40 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

bei Bedarf kontaktieren zu k¨

onnen. Startet Teilnehmerin T1f¨

ur eine Arbeitssitzung

die CSCW-Anwendung, so kontaktiert diese die ihr bekannte Gegenstelle von Teil-

nehmer T2und ”weckt“ diese bei Bedarf, um eventuell anstehende ¨

Anderungen zu

ubertragen. Danach kann die Anwendung auf dem Computer von Teilnehmer T2

wieder beendet werden. Sind beide Anwendungen zur gleichen Zeit aktiv, schicken

sie sich st¨

andig die ¨

Anderungen innerhalb des gemeinsamen Arbeitsbereichs.

Teilnehmer T2muss seinen Computer jedoch h¨

aufiger vom Netzwerk trennen,

da er ihn mit auf Dienstreisen nimmt. Daher versendet er die ¨

Anderungen, die er

vorgenommen hat, per asynchroner Kommunikationsdienste ( z. B. E-Mail ) an die

Anwendung von Teilnehmerin T1oder hinterlegt sie bei einer weiteren im Netzwerk

verf¨

ugbaren Anwendungsinstanz. Sobald die Anwendung auf dem Computer von

T1aktiv wird, empf¨

angt diese die Nachricht mit den ¨

Anderungen und integriert

diese in die lokale Version der gemeinsamen Arbeitsumgebung und beginnt mit der

Sitzung.

Aufl¨

osung, Abschlussphase Bei der Beendigung einer r¨

aumlich getrennten Ko-

operationsgemeinschaft sind die Vorg¨

ange ¨

ahnlich zu denen der Pr¨

asenzkooperation

(vgl. Abschnitt 2.1). Je nach Wunsch der Teilnehmer geht es darum, die Koopera-

tionsergebnisse zu archivieren und f¨

ur eine weitere Verwendung aufzuarbeiten, oder

die gesamte Kooperationsgemeinschaft in eine andere Kooperationsform zu ¨

uberf¨

uh-

ren.

Bei einer zeitlich versetzten Kooperation muss darauf geachtet werden, dass bei

Abschluss der Kooperation alle Instanzen der verteilten Kooperationsumgebung syn-

chronisiert sind. Alle Teilnehmer m¨

ussen also ¨

uber die Beendigung der Kooperation

benachrichtigt werden und ihre Daten ein letztes Mal abgleichen. Danach ist ei-

ne konsistente Ver¨

anderung des gemeinsamen Arbeitsbereiches nicht mehr m¨

oglich.

Anschließende Ver¨

anderungen resultieren in einer pers¨

onlichen Version des Arbeits-

bereiches, die von dem gemeinsamen Arbeitsbereich entkoppelt ist. Bei eine ¨

Uber-

f¨

uhrung in eine andere Kooperationsform gilt das Gleiche. Erst in einem konsistenten

Zustand darf die Kooperationsumgebung transformiert werden.

Szenario 3.4: Beenden einer verteilten und r¨

aumlich getrennten Koope-

ration

•Beenden einer zeitlich und r¨

aumlich getrennten Kooperationsgruppe

•Gr¨

unden einer neuen Kooperationsgruppe aus einer beendeten Gruppe

Eine Kooperationsgruppe mit drei Mitgliedern ( G={T1, T2, T3}) beendet eine

Kooperation mittels einer mobil-verteilten Kooperationsumgebung nach einer l¨

an-

geren Phase der Zusammenarbeit, weil das gemeinsam bearbeitete Projekt beendet

ist.

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.2 Distant Learning 41

Die Projektleiterin T1”friert“ zu diesem Zweck den gemeinsamen Arbeitsbereich

Amit den enthaltenen Dokumenten d1und d2in seinem jetzigen Zustand ein und

archiviert ihn auf ihrem lokalen Rechner, um sp¨

ater den Projektbericht erstellen

zu k¨

onnen. Das ”Einfrieren“ des Arbeitsbereiches wird T2und T3beim n¨

achsten

Kontakt zu T1¨

uber die Synchronisation des Arbeitsbereichs bekannt gegeben.

T2hatte aber zwischenzeitlich noch ¨

Anderungen in den Dokumenten d1und

d2im Arbeitsbereich vorgenommen. Die ¨

Anderungen an d1fallen zeitlich vor den

Entzug des Schreibrechts auf den gemeinsamen Arbeitsbereich und die an d2zeitlich

danach. Daher werden die ¨

Anderungen an d1bei der n¨

achsten Synchronisation mit

T1und T3noch vor dem Durchf¨

uhren der Zugriffs¨

anderungen von T1ausgef¨

uhrt. Die

Modifikationen ∆d2, die nach der Zugriffs¨

anderung liegen, werden jedoch abgelehnt,

da die entsprechenden Rechte fehlen.

Die Kooperationsumgebung bietet daher an, ein neues Dokument d0

2=d2+ ∆d2

zu erzeugen, das die Daten des alten Dokuments plus die ¨

Anderungen enth¨

alt. Da

das neue Dokument d0

2nicht innerhalb des gesperrten gemeinsamen Arbeitsberei-

ches abgelegt werden kann, hat T2die Optionen, das Dokument entweder in seinem

pers¨

onlichen Bereich abzulegen oder den Arbeitsbereich zu kopieren und auf der

Kopie weiterzuarbeiten. T2entscheidet sich f¨

ur die letztere Option und erstellt eine

Kopie A0von A. Diese enth¨

alt anstatt des alten Dokuments d2das ge¨

anderte d0

(A0={d1, d0

2}). Auf diesem Areal beschließt T2seine Kooperation mit T3in einer

neuen Kooperationsgruppe G0={T2, T3}fortzuf¨

uhren, um ein Folgeprojekt zu

initiieren und weist daher G0den Gruppenarbeitsbereich A0zu.

2.2.2 Distant Learning

Eine popul¨

are Variante der r¨

aumlich getrennten Kooperation ist das Distant Lear-

ning aus dem Bildungsbereich. Dieses erm¨

oglicht Lernenden an einem Kurs teil-

zunehmen, ohne k¨

orperlich an der Bildungseinrichtung anwesend zu sein. F¨

ur eine

Teilnahme m¨

ussen die Lernenden unter Umst¨

anden nicht einmal gleichzeitig mit der

Lernumgebung verbunden sein. Die genaue Gestaltung des Kurses h¨

angt beim Di-

stant Learning von den zugrunde liegenden didaktischen Konzepten ab. Diese sollen

im Folgenden aber keine Rolle spielen.

In einfachen Formen des Distant Learning werden lediglich Lernmaterialien und

Ubungsaufgaben ¨

uber ein E-Learning-System bereitgestellt. Oft m¨

ussen ¨

Ubungs-

aufgaben bis zu einem bestimmten Zeitpunkt gel¨

ost und zur Kontrolle des Lern-

fortschritts an den Lehrenden gesandt werden. Diese Kontrolle kann auch durch

automatisierte Mechanismen ¨

ubernommen werden. F¨

ur R¨

uckfragen zum Lernstoff

bestehen eventuell Kommunikationskan¨

ale, um die Betreuer zu kontaktieren. Oft

bieten die E-Learning-Systeme einfache Formen der Kooperationsunterst¨

utzung wie

Mailinglisten oder Foren an. Um den Zugang zu den Materialien und den Diensten

zu erleichtern, werden diese meist in einer Webseite geb¨

undelt.

Trotz bidirektionaler Kommunikationsmechanismen wie Forum und Mailingliste

ist ein solches Lernen vom Konsumieren der Lerninhalte und von einer oft einsei-

Mobilit¨

at in der kooperativen Wissensarbeit

42 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

tigen Kommunikation vom Lehrenden zum Lernenden gepr¨

agt. Eine Kooperation

zwischen den Lernenden erfolgt oft nur außerhalb des E-Learning-Systems, da sie

nicht ausreichend unterst¨

utzt wird. Aber auch in Lernumgebungen, die Kooperatio-

nen zwischen den Lernenden ausdr¨

ucklich unterst¨

utzen, werden h¨

aufig nicht in dem

m¨

oglichen Maße f¨

ur eine Kooperation genutzt.

Dies mag zum einen an einer mangelnden kulturellen Einbettung der computerge-

st¨

utzten Kooperation bei den Lernenden liegen. Darum wird diese oft beim Aufbau

der Kurse gef¨

ordert [vgl. Hampel et al., 2003; Keil-Slawik und Hampel, 2003]. Zum

anderen mag aber auch ein Grund darin bestehen, dass die computergest¨

utzten

Kooperationsumgebungen nicht ¨

uberall verf¨

ugbar und nicht in den Alltag der Ler-

nenden eingebettet sind. Diese L¨

ucke k¨

onnen mobil-verteilte Kooperationssysteme

schließen. In diesem Abschnitt soll daher der Einsatz von mobil-verteilten Koope-

rationssystemen in dem Bereich des kooperativen Distant Learning im Mix mit der

Pr¨

asenzkooperation betrachtet werden.

Gr¨

undung, Anbahnungsphase Die Kurse, die einem Distant Learning Szenario

zu Grunde liegen, werden stets von Benutzern in der Rolle des Lehrenden angeboten.

Diese treten somit als Experten und Dienstleister auf, die eine Wissensvermittlung

in Form eines aufbereiteten Kurses an eine Gruppe Lernender anbieten. Im Folgen-

den wird ein m¨

ogliches Lernszenario skizziert, ohne dabei ein didaktisches Konzept

pr¨

asentieren zu wollen.

Im Rahmen einer Lehrveranstaltung richten die Lehrenden einen gemeinsamen

Wissensraum mit den aufbereiteten Kursunterlagen ein, der in mehrere Lernein-

heiten aufgeteilt ist. Zu jeder Lerneinheit geh¨

oren vertiefende ¨

Ubungen. Um ein

vorgreifendes Lernen zu verhindern, k¨

onnen diese Lerneinheiten nach und nach in

den gemeinsamen Wissensraum eingebracht werden.

Auf die Kursmaterialien d¨

urfen die Kursteilnehmer nur lesend zugreifen, w¨

ahrend

die Betreuer auch Schreibrechte haben. F¨

ur die freie Kooperation der Kursteilneh-

mer besteht ein Bereich der keinerlei Beschr¨

ankungen unterlegen ist. Die Betreuer

besitzen neben dem gemeinsamen Wissensraum mit den Lernenden einen eigenen

gemeinsamen Bereich, in dem die Koordination der Lehre erfolgen kann.

Der Lehrbereich besitzt zudem eine Außendarstellung des Kurses in Form einer

Webseite, die auch durch Nichtmitglieder des Kurses betrachtet werden kann. Hier

sind z. B. das Kursprofil und die Zugangsbedingungen beschrieben. Außerdem kann

hier eine Anmeldung f¨

ur den Kurs erfolgen. Die Anzahl der m¨

oglichen Anmeldungen

ist oft beschr¨

ankt, so dass ab einer bestimmten Anzahl von Teilnehmern an dem Kurs

keine Anmeldungen mehr m¨

oglich sind.

Nach der Anmeldung befinden sich alle Teilnehmer des Kurses in einer gemeinsa-

men Gruppe. Bei einer großen Anzahl von Teilnehmern werden die einzelnen Teil-

nehmer eventuell zus¨

atzlich in eine weitere Struktur von Kleingruppen eingeordnet.

Diese Unterteilung kann u. a. notwendig werden, weil eine thematische Zuordnung

vorgenommen werden soll oder nur begrenzte Platzressourcen bei Pr¨

asenz¨

ubungen

vorhanden sind.

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.2 Distant Learning 43

Szenario 4.1: Kurs mit zeitweise ¨

ortlich verteilten Teilnehmern –

Gr¨

undung

•Seminar mit regelm¨

aßigen Pr¨

asenzphasen

•Gruppenstruktur mit Untergruppen und gemeinsamen wie getrennten Ar-

beitsbereichen

F¨

ur ein Pr¨

asenzseminar mit neun Teilnehmern ( T1,· · · , T9) sollen deren mobi-

le Computer genutzt werden, um eine Computer Supported Cooperative Learning

(CSCL)-Umgebung zur Verf¨

ugung zu stellen. Es sind regelm¨

aßige Pr¨

asenzphasen

vorgesehen. Der Dozent Dstellt die Lehrunterlagen in einem auf seinem mobilen

Rechner erstellten virtuellen gemeinsamen Arbeitsbereich Abereit. F¨

ur die Zu-

griffskontrolle erstellt er eine Gruppe G, die auf den gemeinsamen Arbeitsbereich

zugreifen darf. In diese Gruppe nimmt er alle beim ersten Seminartermin anwesen-

den Teilnehmer auf.

Die Gruppenmitglieder erhalten dadurch lesenden Zugriff auf die zur Verf¨

ugung

gestellten Lehrmaterialien d1,· · · , dn. Außerdem existiert ein Bereich, in dem die

Gruppenmitglieder frei kooperieren k¨

onnen, also Schreib- und Leserechte besitzen.

Der gemeinsame Arbeitsbereich des Seminars wird auf alle mobilen Ger¨

ate ver-

teilt. Geplant sind Gruppenarbeiten in Gruppen zu je drei Teilnehmern. Hierzu

erzeugt der Dozent drei Untergruppen in der Gruppe G(G=G1∪G2∪G3).

Die einzelnen Gruppen d¨

urfen nicht auf die Gruppenbereiche der jeweils anderen

Gruppen zugreifen. Zum Austausch zwischen den Gruppen soll der gemeinsame

Kooperationsbereich Ades Seminars genutzt werden. Die Gruppenarbeit erfolgt

zwischen den Pr¨

asenzphasen.

Fortsetzung in Szenario 4.3

Szenario 4.2: Zentral verwalteter Kurs mit ¨

ortlich getrennten Teilneh-

mern – Gr¨

undung

•Mobile Arbeitsbereiche in Verbindung mit einem CSCW-Server

Ein Dozent Dan einer deutschen Hochschule gibt einen Kurs f¨

ur deutsche und

chinesische Studierende des Maschinenbaus. Die Veranstaltung soll den chinesischen

Studierenden eine Kursteilnahme erm¨

oglichen, ohne dass sich diese in Deutschland

aufhalten m¨

ussen. Zu diesem Zweck stellte Dsowohl sein Vorlesungsskript d1als

auch die Pr¨

asentationsfolien d2¨

uber einen gemeinsamen Arbeitsbereich ALehre zur

Verf¨

ugung. Dieser ist nur f¨

ur Mitglieder der Gruppe Gzug¨

anglich.

Ein externer Besucher bekommt statt des gemeinsamen Arbeitsbereichs eine

Webseite mit Veranstaltungsbeschreibung und Anmeldeinformationen zu sehen.

Mobilit¨

at in der kooperativen Wissensarbeit

44 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

Der gemeinsame Arbeitsbereich wird ¨

uber ein CSCW-System der Universit¨

at bereit

gestellt. Studierende, die an dem Kurs teilnehmen m¨

ochten, melden sich ¨

uber die

Webseite an und werden daraufhin der Gruppe Ghinzugef¨

ugt. Von nun an haben

diese Studierenden Zugriff auf die Lehrmaterialien.

Um die Kooperation der Studierenden zu f¨

ordern, sind sie zus¨

atzlich Mitglieder

der Gruppe GStud und erhalten Zugriff auf den zugeh¨

origen gemeinsamen Arbeits-

bereich AStud, in dem sie sich auch außerhalb des Lehrbetriebs virtuell treffen und

austauschen k¨

onnen. Dieser Bereich bildet zusammen mit dem Bereich ALehre mit

den Lehrmaterialien den gemeinsamen Arbeitsbereich Ader Vorlesung. Dieser dient

den Studierenden als zentrale Anlaufstelle f¨

ur die Vorlesung.

Um die mobile Kooperation zu unterst¨

utzen, k¨

onnen die Lernenden den gemein-

samen Arbeitsbereich Ades Kurses auf ihrem mobilen Computer ”mitnehmen“ und

auch ohne Verbindung zum CSCW-Server der Universit¨

at nutzen, um mit anderen

Studierenden des Kurses zu kooperieren.

Fortsetzung in Szenario 4.4

Kooperationsphase Nach der Gr¨

undung eines Kurses und der Anmeldung aller

Mitglieder bleibt die Gruppenstruktur in der Regel stabil. Die Lehrenden stellen die

Materialien in Lerneinheiten geordnet nach und nach in den gemeinsamen Arbeits-

bereich. Dieser Vorgang wird in der Pr¨

asenzlehre meist von Vorlesungen begleitet,

in denen die Lehrenden durch den Lehrstoff f¨

uhren und bei Bedarf Anmerkungen

und Erg¨

anzungen anbringen. Beim reinen Distant Learning entf¨

allt die Vorlesung,

die Teilnehmer arbeiten den Stoff selbstst¨

andig auf. Erg¨

anzungen sind oft geb¨

undelt

mit dem Skript f¨

ur die Lerneinheiten. Manchmal wird auch versucht, die fehlende

Pr¨

asenzvorlesung durch eine Video- oder Audio¨

ubertragung derselben zu kompen-

sieren.

Erg¨

anzt wird jede Lerneinheit durch ¨

Ubungen, in denen die Lernenden das Ge-

lernte anwenden und vertiefen. Diese ¨

Ubungen erfolgen h¨

aufig in Kleingruppen. Den

Lernenden steht zur Bew¨

altigung der ¨

Ubungsaufgaben ein Tutor zur Seite, der die

Ubungen betreut und f¨

ur R¨

uckfragen zur Verf¨

ugung steht. In einer r¨

aumlich ge-

trennten Variante der ¨

Ubung muss es dementsprechende Kommunikations- und Ko-

ordinationsmittel geben.

Die ¨

Ubungsaufgaben lassen sich auf diverse Arten beschreiben. Die einfachste

Form ist eine informelle Beschreibung der Aufgabe in Schriftform. Diese kann ein-

fach als Dokument in dem gemeinsamen Wissensraum abgelegt werden. Die Ler-

nenden senden ihre L¨

osungen der Aufgaben an die Betreuer oder legen sie in einem

speziellen Bereich des Wissensraums ab, auf den nur die Betreuer Zugriff haben.

Soll die erfolgreiche Teilnahme an dem Kurs von diesen L¨

osungen abh¨

angen, sind

die Berechtigungen f¨

ur die L¨

osungsdokumente so zu vergeben, dass ein Abschreiben

oder nachtr¨

agliches ¨

Andern von L¨

osungen verhindert wird.

Ubungsaufgaben k¨

onnen aber auch so gestellt werden, dass die Korrektheit der

L¨

osungen durch die Lernumgebung ausgewertet werden kann (z. B. Multiple Choice

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.2 Distant Learning 45

Aufgaben). Dies entlastet die Betreuer und bietet zus¨

atzlich die M¨

oglichkeit einer

direkten R¨

uckmeldung an die Lernenden. Eine weitere M¨

oglichkeit ist, die ¨

Ubungs-

aufgaben so zu beschreiben, dass sie personalisiert werden k¨

onnen. Dann werden

sie f¨

ur jeden Lernenden individuell erstellt. Dies geschieht ¨

uber Generatoren oder

Templates. Diese verwenden entweder einen Zufallswert oder einmaliges Attribut

der Benutzer (z. B. die Identifikationsnummer), um die Aufgaben speziell f¨

ur sie

zu erstellen. Ein beispielhaftes Szenario einer automatischen Erzeugung und Bewer-

tung von personalisierten ¨

Ubungsaufgaben mit Hilfe eines Computer Algebra Systems

(CAS) beschreibt [Bleckmann et al., 2005].

Bei R¨

uckfragen zu einer Aufgabe oder zu einem Dokument beziehen sich die Ler-

nenden stets auf diese Objekte, daher wird die Kommunikation an das betreffende

Objekt gekn¨

upft. Die Kommunikation referenziert so stets implizit das betroffene

Objekt. Bei einer Kooperation mit herk¨

ommlichen Schriftdokumenten w¨

urde dazu

das betroffene Dokument in den Mittelpunkt ger¨

uckt. In einer computergest¨

utzen

Kooperationsumgebung verh¨

alt es sich ¨

ahnlich. Kommunikation kann entweder in

Form eines an ein Dokument gekn¨

upften Diskussionsstranges oder, in anderer Rich-

tung, in Form eines Verweises auf das Dokument aus der Kommunikation mit diesem

verkn¨

upft werden.

Szenario 4.3: Kurs mit zeitweise ¨

ortlich verteilten Teilnehmern – Ko-

operationsphase

Fortsetzung von Szenario 4.1

•Synchronisation von gemeinsamen Arbeitsbereichen einer Gruppe

•Synchronisation gem¨

aß der Zugangsrechte zu einem Bereich

•L¨

osung von Versionskonflikten nach Trennungsphase

Die Teilnehmer des Seminars aus Szenario 4.1 treffen sich einmal in der Woche,

um unter Anleitung des Dozenten Ddie Ergebnisse der Gruppenarbeiten zu disku-

tieren und den Gegenstand des Seminars thematisch zu vertiefen. Zwischen diesen

Pr¨

asenzsitzungen treffen sich die drei Gruppen G1,G2und G3jeweils unterein-

ander und bearbeiten die ihnen gestellten Aufgaben. Zu diesem Zweck verbinden

sie ihre mobilen Computer und arbeiten auf dem gemeinsamen Gruppenbereich

(AG1,· · · , AG2) im Arbeitsbereich Ades Seminars.

Um selbstst¨

andig zu Hause arbeiten zu k¨

onnen, befindet sich auf jedem der mobi-

len Ger¨

ate eine identische Kopie des Seminarbereiches. Haben in der Zwischenzeit

ein oder mehrere Gruppenmitglieder in dem Bereich ¨

Anderungen vorgenommen,

so muss der Gruppenbereich zu Beginn der Gruppensitzung abgeglichen werden.

Bei einander widersprechenden ¨

Anderungen seitens zweier oder mehr Mitgliedern

muss dieser Konflikt aufgel¨

ost werden.

Teilnehmer T1und T2aus Gruppe G1haben jeweils zu Hause das Dokument

d1bearbeitet. Es existieren somit die zwei Versionen dT1

1und dT2

1, die miteinan-

der im Konflikt stehen. Sie werden zu Beginn der Kooperationssitzung auf diesen

Mobilit¨

at in der kooperativen Wissensarbeit

46 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

Konflikt aufmerksam gemacht und aufgefordert, ihn zu beheben. Als Hilfsmittel

bekommen sie beide Versionen nebeneinander dargestellt. Nachdem sie den Kon-

flikt aufgel¨

ost haben, wird mit der konfliktbereinigten Datei das alte Dokument d1

im gemeinsamen Gruppenbereich AG1¨

uberschrieben.

W¨

ahrend und am Ende der Kooperationssitzung ist der gemeinsam genutzte

Bereich auf allen mobilen Computern der Gruppe identisch, da die Instanzen auf

den mobilen Computern der Teilnehmer st¨

andig synchronisiert werden.

Da das Gruppenmitglied T3bei der gemeinsamen Sitzung von Gruppe G1fehlte,

ist dessen Version des gemeinsamen Arbeitsbereiches AG1veraltet. Als Teilnehmer

T3Teilnehmer T2nach der Kooperationssitzung in der Universit¨

at trifft, kann T3

diese jedoch mittels der aktuellen Instanz von T2aktualisieren.

Die Kooperation erfolgt meist ¨

uber direkte Kommunikation zwischen den Grup-

penmitgliedern w¨

ahrend gemeinsamer Treffen. Gleichzeitig werden die Objekte im

gemeinsamen Arbeitsbereich in der virtuellen Kooperationsumgebung manipuliert.

In einem allen Seminarteilnehmern zug¨

anglichen Bereich Apublic werden die Ar-

beitsergebnisse f¨

ur das n¨

achste Seminartreffen aufbereitet und zug¨

anglich gemacht.

Jede Gruppe legt ihre Arbeitsergebnisse in diesem ¨

offentlich zug¨

anglichen Bereich

ab. Gruppe G1erstellt eine Kopie d0

2der Datei d2aus ihrem Gruppenbereich AG1

und legt diese in dem Bereich Apublic ab. Daraufhin wird die Kopie d0

2f¨

ur alle

Seminarteilnehmer zug¨

anglich und in deren lokalen Instanzen des gemeinsamen

Arbeitsbereiches synchronisiert. Dies trifft nicht f¨

ur die Originaldatei im gemeinsa-

men Arbeitsbereich AG1von Gruppe G1zu, welche nur zwischen deren Mitglieder

synchronisiert wird.

Trifft sich das gesamte Seminar, werden alle gemeinsam einsehbaren Bereiche

in Einklang gebracht. Dies geschieht wiederum analog zu dem Abgleichen zu Be-

ginn eines Gruppentreffens. Jeder mit einem anderen Benutzer gemeinsam einseh-

bare Bereich muss dabei ber¨

ucksichtigt werden. F¨

ur jeden Teilnehmer heißt dies

folgende Bereiche abzugleichen: den eigenen Gruppenbereich (AGx) mit den ande-

ren Gruppenmitgliedern (Gx); den ¨

offentlichen Gruppenbereich Apublic mit allen

Teilnehmern (T1,· · · , Tn) und dem Dozenten D; den Kooperationsbereich der Stu-

dierenden mit den anderen Teilnehmern (T1,· · · , Tn); und den Seminarbereich mit

dem Dozenten D(da nur dieser ihn ver¨

andern darf). Dies bedeutet, dass alle Berei-

che, die ein Benutzer einsehen kann, mit gleichberechtigten Benutzern abgeglichen

werden muss. W¨

ahrend des Treffens bleiben diese Bereiche wiederum im Einklang.

Fortsetzung in Szenario 4.5

Szenario 4.4: Zentral verwalteter Kurs mit ¨

ortlich getrennten Teilneh-

mern – Kooperationsphase

Fortsetzung von Szenario 4.2

•Mischung von zentralen und mobil-verteilten Kooperationssystemen

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.2 Distant Learning 47

•Workflow-Elemente in Kooperationsprozessen

•Integration externer Dienste in die Kooperationsumgebung

Da ein gemeinsames Treffen der Studierenden und des Dozenten aus Szenario 4.2

aufgrund der großen Distanz nicht m¨

oglich ist und wegen der Zeitverschiebung auch

eine zeitliche ¨

Ubereinstimmung nur schwer zu finden ist, wird die Veranstaltung

nicht wie eine Vorlesung im klassischen Sinne gef¨

uhrt. Die Studierenden erhalten

w¨

ochentlich eine neue Lerneinheit in Form eines kommentierten Vorlesungsskriptes.

Des Weiteren gibt es zu jeder Lerneinheit eine Art Videovorlesung des Dozenten,

in der er die Vorlesung vor einer laufenden Kamera h¨

alt. Auch diese Videoaufzeich-

nung wird den Lernenden zur Verf¨

ugung gestellt. Die Studierenden erarbeiten sich

anhand dieser Materialien die Lerninhalte selbstst¨

andig.

Zus¨

atzlich zu den Lerneinheiten werden stets ¨

Ubungsaufgaben ausgegeben, die in

Kleingruppen von zwei bis vier Studierenden zu bearbeiten sind. Dazu nutzen die

Gruppen die mobil-verteilte Lernumgebung. Sie bilden selbstst¨

andig eine Gruppe

Gxmit zugeh¨

origen Gruppenbereich AGx. Diese Gruppen existieren nun sowohl auf

dem CSCW-Server als auch in der mobil-verteilten Lernumgebung, da die Gruppen

zwischen ihr und dem CSCW-Server synchronisiert werden.

Um eine ¨

Ubungsaufgabe zu bearbeiten, erzeugen die Teilnehmer T1,T2und T3

aus Gruppe G1mittels eines Generatorobjektes im Arbeitsbereich der Vorlesung

eine personalisierte ¨

Ubungsaufgabe a(T1,T2,T3), die mittels der Benutzerkennungen

auf sie zugeschnitten ist. Sie verschieben die ¨

Ubungsaufgabe in ihren Arbeitsbereich

AG1ihrer Gruppe G1. In einer oder mehreren Gruppensitzung erstellen sie darauf-

hin eine L¨

osung l(T1,T2,T3)und ¨

ubermitteln diese in einen virtuellen Abgabekasten

im Arbeitsbereich Ader Vorlesung. Nach der Bewertung wird ihnen das Ergebnis

zusammen mit einer korrigierten L¨

osung in ihren Gruppenbereich zur¨

uckkopiert.

Zu Beginn der Gruppensitzung von Gruppe G1muss der gemeinsame Bereich

AG1zwischen den Gruppenmitgliedern ( G1={T1, T2, T3}) abgeglichen werden.

Bei einer Verbindung zum CSCW-Server wird dieser in den Abgleich einbezogen,

ansonsten geschieht dieser Abgleich erst bei der n¨

achsten Verbindung eines Grup-

penmitglieds mit dem Server. Der Server ist derzeit ¨

uber eine schlechte Funkverbin-

dung an die Computer der Gruppe angebunden, so dass der Abgleich nicht z¨

ugig

vollzogen werden kann. Da aber nach einer ersten ¨

Uberpr¨

ufung keine Konflikte

zwischen den Objekten auf dem Server und denen in dem verteilten gemeinsamen

Arbeitsbereich AG1der Gruppe G1zu bestehen scheint, werden die ge¨

anderten

Objekte nach und nach im Hintergrund ¨

ubertragen.

F¨

ur die Kooperation nutzen die Gruppenmitglieder das schnellere Ad-Hoc-

Netzwerk zwischen ihren Mobilcomputern. Die Kooperation wird so nicht von der

langsamen Server-Anbindung beeintr¨

achtigt. Auch als nach einiger Zeit die Verbin-

dung zum Server abbricht, hat dies keine direkte Auswirkung auf die Kooperation.

Die Gruppenmitglieder nutzen die Lehrunterlagen, die die Teilnehmerin T1bei einer

vorherigen Verbindung mit dem Server bereits abgeglichen hatte. Diese aktuellste

Mobilit¨

at in der kooperativen Wissensarbeit

48 2.2 Kooperation mit r¨

aumlich verteilten Teilnehmern

verf¨

ugbare Version besorgen sich die Mitglieder ( T2, T3) somit von T1statt di-

rekt vom Server. Jetzt verf¨

ugen auch sie ¨

uber den neuesten verf¨

ugbaren Stand der

Lehrunterlagen.

Da der Abgleich mit dem Server nicht abgeschlossen war, muss die Synchronisa-

tion bei der n¨

achsten Verbindung wieder aufgenommen werden. Bis dahin bleiben

einige Objekte im gemeinsamen Arbeitsbereich nicht benutzbar. Eine Verkn¨

upfung,

z. B. die auf ein noch nicht geladenes Dokument in den Lehrunterlagen weist, zeigt

derzeit noch ins Leere. Das Zielobjekt war auf dem Server neu in den Arbeitsbereich

eingef¨

ugt worden (Semantische Inkonsitenz).

Am Ende der Gruppensitzung ¨

ubergeben die Lernenden die L¨

osung l(T1,T2,T3)in

den Abgabekasten, der ebenfalls als lokale Kopie auf ihren mobilen Ger¨

aten liegt.

Aufgrund der fehlenden Verbindung zum CSCW-Server ist diese L¨

osung jedoch

zun¨

achst nur lokal verf¨

ugbar. Schon seit dem Einf¨

ugen der L¨

osung in den Abgabe-

kasten haben die Teilnehmer keinen Zugriff mehr auf die L¨

osung, um sie eventuell

nachtr¨

aglich zu ¨

andern (Zugriffsschutz in verteilten Systemen).

Beim n¨

achsten Kontakt eines Gruppenmitglieds zum Server wird die lokale Ko-

pie des Abgabekastens mit diesem synchronisiert und somit die L¨

osung l(T1,T2,T3)

auf den Server ¨

ubertragen. Diese kann nun von den Tutoren korrigiert werden. Eine

Aufgabe, die zu bearbeiten war, kann automatisch durch den Computer korrigiert

werden. Zu diesem Zweck liegt ein aktives Objekt im Abgaberaum, das die L¨

osung

an ein externes Expertensystem ¨

ubermittelt. Dieses betrachtet die L¨

osung, ¨

uber-

pr¨

uft und bewertet sie und ¨

ubermittelt das Ergebnis zur¨

uck an das aktive Objekt

im Abgaberaum. Das Ergebnis wird daraufhin direkt mittels Ablage eines Bewer-

tungsobjektes b(T1,T2,T3)in den Arbeitsbereich AG1an die Gruppe ¨

ubermittelt. Eine

Kopie der L¨

osung und der Bewertung verbleiben zus¨

atzlich im Bewertungsraum,

um die Bewertung im Nachhinein nachvollziehen zu k¨

onnen.

Fortsetzung in Szenario 4.6

Aufl¨

osung, Abschlussphase Am Ende eines Kurses steht oftmals eine Erfolgs-

kontrolle in Form einer Pr¨

ufung. Diese kann ¨

ahnlich wie die ¨

Ubungsaufgaben ge-

handhabt werden. Wurden die ¨

Ubungsaufgaben bewertet, k¨

onnen sie eventuell sogar

die Abschlusspr¨

ufung ersetzen. Manche qualifizierenden Einrichtungen verlangen f¨

diese Pr¨

ufungen eine pers¨

onliche Anwesenheit der Pr¨

uflinge, um das Pr¨

ufungsum-

feld besser kontrollieren und eine Manipulation der Pr¨

ufungsergebnisse verhindern

zu k¨

onnen.

Neuere Ans¨

atze betrachten die Kooperationsergebnisse der Lernenden selbst als

eine Art Erfolgskontrolle. Anhand der Artefakte der Kooperation werden das Wissen,

die Wissensstruktur und der Grad der Beteiligung seitens der Lernenden bewertet.

In dem Jour Fixe Konzept [Hampel et al., 2003; Keil-Slawik und Hampel, 2003]

wird diese Bewertung mit einem pers¨

onlichen Fachgespr¨

ach erg¨

anzt. Eventuell muss

bei einer Bewertung der Kooperationsergebnisse aus verwaltungsrechtlichen Gr¨

un-

den der gemeinsame Arbeitsbereich der Pr¨

uflinge archiviert werden, da er in das

Mobilit¨

at in der kooperativen Wissensarbeit

2.2.2 Distant Learning 49

Pr¨

ufungsergebnis einfließt und f¨

ur dessen Nachvollziehung wichtig ist. Er darf somit

nicht alleine auf den Ger¨

aten der Lernenden verbleiben, sondern muss in einem zum

Pr¨

ufungstermin ”eingefrorenen“ Zustand an einem zentralen und gesch¨

utzten Ort

archiviert werden.

Doch auch die Lernenden haben h¨

aufig das Bed¨

urfnis, die Kooperationsergebnisse

zu bewahren und f¨

ur eine sp¨

atere Nutzung im Zugriff zu haben. Anders verh¨

alt es

sich bei den organisatorischen Strukturen wie der Gruppenzugeh¨

origkeit und den

Kooperationsbereichen, die nach Ende einer Kooperation meist nicht mehr genutzt

werden. Die Lernergebnisse werden in diesem Fall in die pers¨

onlichen Bereiche der

Lernenden transferiert und die Kooperationsstrukturen anschließend gel¨

oscht. Aller-

dings bilden sich auch h¨

aufig Langzeitkooperationen, bei denen die Gruppenstruktur

langlebiger ist als die wechselnden Inhalte der Kooperation.

Szenario 4.5: Kurs mit zeitweise ¨

ortlich verteilten Teilnehmern – Auf-

l¨

osung

Fortsetzung von Szenario 4.3

•Synchronisierte Pr¨

asenzpr¨

ufung anhand der Kooperationsergebnisse

•Archivierung der Pr¨

ufungsrelevanten Kooperationsergebnisse auf einem ex-

ternen Dienst

•Archivierung von Objekten inklusive Metadaten f¨

ur sp¨

atere Verwendung

Am Ende des Seminars f¨

uhrt der Dozent Dmit jeder der drei Gruppen ( G1, G2, G3)

ein Fachgespr¨

ach, in dem insbesondere auf die ver¨

offentlichen Inhalte der Gruppe

eingegangen wird. Jeder der Teilnehmer hat in der Pr¨

ufung seinen mobilen Compu-

ter vor sich. Zu Beginn gleichen die Ger¨

ate der Teilnehmer und des Dozenten den

Arbeitsbereich des Seminars untereinander ab. Jeder der Anwesenden hat somit

die gleiche Version zur Verf¨

ugung. Da das Fachgespr¨

ach entlang der Inhalte des

Arbeitsbereichs strukturiert wird, werden Objekte, die aktuell besprochen werden,

markiert und kommentiert. Die Gesten der Zeigeger¨

ate werden auf allen Ger¨

aten

zugleich angezeigt.

Der Dozent stellt den Studierenden die Aufgabe, Bilder im Arbeitsbereich, die

wichtige Ereignisse in der Geschichte der Entstehung des Computers repr¨

asentieren,

auf einem Zeitstrahl anzuordnen. Er gibt dazu ein Ereignis an und die Pr¨

uflinge

m¨

ussen einer nach dem anderen ein Bild anordnen. Dazu verschiebt jeder auf seinem

Computer das Bild an eine passende Stelle des Zeitstrahls. Da die Instanzen des

Wissensraums w¨

ahrend der Sitzung abgeglichen bleiben, erh¨

alt jeder Teilnehmer

der Sitzung dieselbe Ansicht auf den Wissensraum. Dies erlaubt dem Dozenten,

wenn notwendig, unterst¨

utzend einzugreifen.

Am Ende der Pr¨

ufung ist f¨

ur die Studierenden der Gruppe G1das Seminar

abgeschlossen. Der ¨

offentliche Bereich wird eingefroren und auf einem Server im

Pr¨

ufungsamt archiviert. Auch der Dozent nimmt keine ¨

Anderung an den Lehrmate-

rialien mehr vor. Die Studierenden archivieren, jeder f¨

ur sich, den f¨

ur sie sichtbaren

Mobilit¨

at in der kooperativen Wissensarbeit

50 2.3 Herausforderungen mobil-verteilter Kooperation

Inhalt des Arbeitsbereichs. Dabei werden alle Metadaten der enthaltenen Objekte

derart gespeichert, dass es m¨

oglich ist, die Kooperationsobjekte in anderen Koope-

rationssituationen wieder zu verwerten.

Szenario 4.6: Zentral verwalteter Kurs mit ¨

ortlich getrennten Teilneh-

mern – Aufl¨

osung

Fortsetzung von Szenario 4.4

•Archivieren von Lehrmaterialien f¨

ur einen zuk¨

unftigen Zugriff

•Wechsel zwischen etablierten und spontanen Kooperationsszenarien

Am Ende der Veranstaltung wird der gemeinsame Arbeitsbereich Ader Vorlesung

noch bis zum Abschluss aller Pr¨

ufungen aktiv von den Tutoren betreut. Die Teil-

nehmer der Vorlesung k¨

onnen die Inhalte und Kommunikationsmechanismen nut-

zen, um f¨

ur die Pr¨

ufungen zu lernen und Kontakt zu den Tutoren aufzunehmen.

Nach Beendigung aller Pr¨

ufungen endet die aktive Betreuung seitens der Tutoren.

Doch der gemeinsame Arbeitsbereich wir so archiviert, dass alle Studierenden auch

weiterhin auf alle Inhalte inklusive ihrer eigenen Kooperationsbereiche zugreifen

k¨

onnen. Der Veranstalter garantiert zu diesem Zweck eine 10j¨

ahrige Verf¨

ugbarkeit

des Arbeitsbereiches ¨

uber den CSCW-Server.

Die studentische Gruppe G1steht kurz vor ihrer Pr¨

ufung und gr¨

undet f¨

ur ein

gemeinsames Lernen eine Lerngruppe (siehe Abschnitt 2.1.1). Sie ¨

ubertragen zu

diesem Zweck einige Objekte aus dem Arbeitsbereich Ader Vorlesung in ihren

spontan erstellten Wissensraum AG1. Nach der Pr¨

ufung l¨

oschen die Mitglieder der

Lerngruppe ihre lokale Kopie des Arbeitsbereichs der Vorlesung, da dieser auf dem

CSCW-Server verf¨

ugbar bleibt. Den verteilten Wissensraum archiviert jeder Teil-

nehmer f¨

ur sich.

Nach Ende der Veranstaltung sperren die Betreuer den Arbeitsbereich Af¨

ur einen

schreibenden Zugriff, so dass dieser nicht mehr ver¨

andert werden kann. Teilnehmer

der Veranstaltung d¨

urfen aber weiterhin auf alle Bereiche, die ihnen zug¨

anglich

waren, lesend zugreifen. Die f¨

ur die Studierenden freien Bereiche bleiben f¨

ur eine

Aufrechterhaltung von Kooperationsgemeinschaften kooperativ nutzbar.

2.3 Herausforderungen mobil-verteilter Kooperation

Betrachtet man die in diesem Kapitel vorgestellten Szenarien, zeigt sich ein brei-

tes Einsatzspektrum f¨

ur computergest¨

utze Kooperation im Alltagsleben. Bei einer

Durchtrennung der Abh¨

angigkeit von festen und unflexiblen Infrastrukturen er-

gibt sich automatisch eine neue Qualit¨

at der Nutzung von CSCW-Systemen. Dabei

scheint ein evolution¨

ares Vorgehen bei der Transformation zentralisierter Koope-

rationsumgebungen in eine mobil-verteilte Architektur angeraten, da beide Syste-

Mobilit¨

at in der kooperativen Wissensarbeit

mauspr¨

agungen, wie aus den Szenarien ersichtlich, ihre Berechtigung haben. Der

Verl¨

asslichkeit und generellen Verf¨

ugbarkeit eines zentralisierten CSCW-Dienstes

steht die mobile und spontane Nutzung einer zwischen gleichberechtigten Benutzern

verteilten CSCW-Umgebung entgegen.

Um die Vorteile beider Auspr¨

agungen der Kooperation f¨

ur die Benutzer zug¨

ang-

lich zu machen, muss es Ziel sein, eine Systemkonvergenz von zentralisierten und

mobil-verteilten CSCW-Ans¨

atzen zu erreichen. Nur so kann ein nahtlos verkn¨

upftes

Kooperationsumfeld geschaffen werden.

W¨

ahrend viele der technischen Fragestellungen auf Seite der zentralisierten CSCW-

Dienste bereits beantwortet scheinen, ergeben sich in der Unterst¨

utzung mobil-ver-

teilter Systeme v¨

ollig neue Problemstellungen aufgrund der ge¨

anderten technischen

Perspektive. In der Tat haben sich die ben¨

otigten Mechanismen f¨

ur eine Koopera-

tionsunterst¨

utzung kaum ver¨

andert – das Konzept des virtuellen Wissensraums mit

den zugeh¨

origen prim¨

aren Medienfunktionen als Beispiel ist aufgrund seiner Flexi-

bilit¨

at auch der mobil-spontanen Kooperation gewachsen – aber die Bereitstellung

dieser Mechanismen wirft in dem neuen technischen Umfeld v¨

ollig neue Fragen f¨

deren Bereitstellung auf.

Die grundlegenden Fragenstellungen scheinen in einer Unterst¨

utzung spontaner

Gruppengr¨

undungen im strukturlosen Umfeld, dem Bereitstellen einer verteilten

und dennoch hochverf¨

ugbaren persistenten Arbeitsumgebung und der Einbindung

verf¨

ugbarer externer Dienste in der Umgebung der Benutzer zu sein. Anhand der

gebotenen Szenarien werden daher in dem folgenden Kapitel die genauen Anfor-

derungen an eine derartige technische Infrastruktur zur spontanen Vernetzung von

Kooperationsgruppen in mobil-verteilten Wissensr¨

aumen bestimmt.

Mobilit¨

at in der kooperativen Wissensarbeit

52 2.3 Herausforderungen mobil-verteilter Kooperation

Mobilit¨

at in der kooperativen Wissensarbeit

3 Anforderungen f¨

ur eine technische

Unterst¨

utzung mobiler

Wissensorganisation

Architekturkonzepte heutiger Kooperationsumgebungen h¨

angen stark von bestehen-

den Netzwerkinfrastrukturen ab und verlangen in jeder Phase des Kooperationspro-

zesses nach einer Verbindung zu einem zentralen Server des CSCW-Systems. Der

Server ¨

ubernimmt hier die Rolle des Koordinators der Kooperation und sorgt au-

ßerdem f¨

ur eine zentrale Speicherung der gemeinsam genutzten Dokumente. Aus

den in Kapitel 2 aufgezeigten Szenarien wird jedoch ersichtlich, dass zentralisierte

Infrastrukturen aufgrund der technischen Rahmenbedingungen nur bedingt f¨

ur eine

computergest¨

utzte Kooperation im mobilen Nutzungsumfeld geeignet sind.

Oftmals sind zu Beginn einer mobilen Kooperation ¨

uberhaupt keine Netzwerkin-

frastrukturen verf¨

ugbar. Die Etablierung eines unabh¨

angigen Kommunikationsnetz-

werkes ist daher der erste Schritt in Richtung einer mobilen Kooperationsumgebung.

Die so neu entstandene Spontanit¨

at in der Vernetzung der Kooperationsumgebung

l¨

asst eine Abh¨

angigkeit von zentralisierten Kommunikations- und Kooperationss-

trukturen nicht l¨

anger zu. Zudem entwickelt der gesamte Kooperationsprozess auf-

grund st¨

andig wechselnder Kontexte und Nutzungskonstellationen eine hohe Dyna-

mik. Will ein Softwaresystem mobile Kooperationsszenarien unterst¨

utzen, muss es

daher deren neuen Qualit¨

aten und Anforderungen Rechnung tragen.

Mobile Formen der virtuellen Wissensorganisation stellen somit neue Herausfor-

derungen an das Forschungsfeld des CSCW. Die Dienste dedizierter CSCW-Server

werden in den neuen mobilit¨

atsfreundlichen Architekturen von verschiedenen Knoten

eines Peer-to-Peer-Netzwerks aller Teilnehmer bereitgestellt und bilden dadurch eine

verteilte Kooperationsumgebung. Kleine und große Gruppen mobiler Knoten bilden

so spontan Netzwerke, treten existierenden Kooperationsnetzwerken bei und verlas-

sen sie kurz darauf wieder. Die klassische Trennung zwischen Dienstanbieter (Server)

und Dienstnehmer (Client) wird aufgel¨

ost und durch eine Peer-to-Peer-Infrastruktur

ersetzt. Der technische Terminus Peer erh¨

alt in mobilen Kooperationsszenarien eine

zus¨

atzliche Bedeutung f¨

ur eine spezielle Form der gleichberechtigten Zusammenarbeit

durch die gegenseitige Bereitstellung von Dienstleistungen und Ressourcen.

Eng verbunden mit derartigen flexiblen Mechanismen f¨

ur das Anbieten und Nut-

zen von Diensten ist eine neue Art der Datenhaltung. In klassischen CSCW-Umge-

bungen mit einem dedizierten Server werden die Daten und Objekte in einer zentra-

len Persistenzschicht gespeichert. In mobil-verteilten und spontan verbundenen For-

men der Kooperation l¨

asst sich der Zugriff auf eine solche zentrale Persistenzschicht

54 3 Anforderungen

nicht l¨

anger durchg¨

angig realisieren. Aus diesem Grund werden Wissensobjekte und

Kooperationsdaten ¨

uber die mobilen Ger¨

ate der Benutzer verteilt gespeichert und

f¨

uhren zu einer verteilten Datenbasis ohne zentrale Verwaltungs- und Kontrollme-

chanismen.

F¨

ur die Kommunikation innerhalb der Kooperationsumgebung k¨

onnen die mo-

bilen Ger¨

ate der Benutzer Ad-hoc-Netzwerke oder bereits existierende verwaltete

Netzwerkinfrastrukturen wie das Internet nutzen. Nicht zuletzt verschwimmen die

Grenzen zwischen individueller und kooperativer Wissensorganisation in Nutzungs-

zenarien mobiler Kooperation. Die Benutzer wechseln nahtlos von der Gruppenarbeit

zur individuellen Arbeit und umgekehrt. Es entstehen neue Konstellationen des Ge-

brauchs von kooperationsst¨

utzenden Systemen, die sich stark an dem gew¨

unschten

Nutzungskontext orientieren. Kontext meint in diesem Zusammenhang die Etablie-

rung von virtuellen Kollaborationsgruppen in Abh¨

angigkeit von der sozialen Struk-

tur der Gruppe und/oder dem Aufenthaltsort der Teilnehmer.

Diese komplexen Kooperationskonstellationen f¨

uhren zu hochdynamischen Netz-

werkstrukturen, die eine verteilte und redundante Speicherung des gemeinsamen

Wissensraums ¨

uber die beteiligten Ger¨

ate unverzichtbar machen. Diese verteilte und

redundante Speicherung der gemeinsamen Kooperationsobjekte erlaubt es den Be-

nutzern mit diesen zu arbeiten, auch wenn sie zeitweise von ihren Kollaborationspart-

nern getrennt sind. Dieses Vorgehen kann aber in abweichenden Versionen redundant

gespeicherter und ¨

uberschneidend bearbeiteter Dokumente resultieren. Ein Konflikt

bei dem Versuch die Versionen des redundant gespeicherten Dokuments wieder zu-

sammenzuf¨

uhren ist hier nahezu unvermeidbar. Darum m¨

ussen derartige Konflikte

kooperativ mittels geeigneter Werkzeuge behoben werden k¨

onnen.

Die Konsistenz der Kollaborationsdaten r¨

uckt somit in den Mittelpunkt des In-

teresses f¨

ur den Entwurf von mobil-verteilten Kooperationsumgebungen. Hier sind

Nutzer nicht l¨

anger an die reine Online-Arbeit (verbunden mit einem Server oder den

Kollaborationspartnern) gebunden, sondern arbeiten online wie offline mit verschie-

denen teils replizierten Materialien. Im Unterschied zu zentral gesteuerten CSCW-

Systemen, die ebenfalls eine Offline-Arbeit und Replikationsmechanismen bieten,

fehlt in der mobil-verteilten Kooperationsumgebung zun¨

achst eine zentrale Kontrol-

linstanz, welche die L¨

osung von Versionskonflikten koordiniert. Ohne solche zentralen

Kontrollstrukturen m¨

ussen auch die bew¨

ahrten Gruppen- und Zugriffskonzepte auf

die Anforderungen einer dezentralen verteilten Verwaltung zugeschnitten werden.

Die Vielfalt der Aspekte einer Zusammenarbeit in einem mobilen Kooperations-

kontext, welche die zuk¨

unftigen Architekturen mobil-verteilter Kooperationsumge-

bungen bestimmt, macht eine genaue Anforderungsbestimmung anhand der in Ka-

pitel 2 vorgestellten mobil-verteilten Kooperationsszenarien notwendig. In diesem

Kapitel werden daher die technischen Anforderungen an eine mobil-verteilte Koope-

rationsumgebung mit Blick auf das bew¨

ahrte Konzept der virtuellen Wissensr¨

aume

(vgl. Abschnitt 3.2) beschrieben und entlang der Handlungs- wie der Umsetzungs-

perspektive der Kooperationsunterst¨

utzung eingeordnet. Dies sind zum einen, die

den neuen Qualit¨

aten der mobilen Zusammenarbeit geschuldeten Bereiche der ”

Ver-

netzung und Sichtbarkeit“,”Kontextualisierung“ und ”Konsistenz und Reversibilit¨

at“

Mobilit¨

at in der kooperativen Wissensarbeit

Anforderungen

Kontextualisierung

Kommunikation

Konsistenz

Koordination Kooperation

Kollaboration

Vernetzung

Abbildung 3.1: Die Anforderungen mobilit¨

atsunterst¨

utzender Kooperationsumge-

bungen beinhalten neben den bekannten Unterst¨

utzungsfunktionen zur Kommu-

nikation,Koordination,Kooperation und Kollaboration zus¨

atzlich die Faktoren

Vernetzung und Sichtbarkeit,Kontextualisierung und Konsistenz und Reversibili-

t¨

at .

und zum anderen, die auf klassischen Kooperationsunterst¨

utzung aufbauenden und

an mobil-verteilten Strukturen anzupassenden Bereiche der Kommunikation,Koor-

dination und Kooperation (vgl. Abbildung 3.1). Als erster Schritt werden nun die

drei typischen Phasen mobil-spontaner Kooperation skizziert.

3.1 Phasen mobil-spontaner Kooperation

Szenarien des Arbeitens in mobilen und spontanen Arbeitsgruppen k¨

onnen in drei

wesentliche Phasen aufgeteilt werden: Gr¨

undung,Kooperation und Abschluss [vgl.

Eßmann und Hampel, 2005b]. Phase I (Gr¨

undung) beinhaltet die Etablierung der

Kooperationsgruppe und das Sammeln der Dokumentenbasis. Phase II (Koopera-

tion) wird durch die Dynamik der mobilen Zusammenarbeit mit wechselnden Be-

nutzerzusammensetzungen charakterisiert (Benutzer betreten und verlassen die Kol-

laboration in einer spontanen Weise). Die abschließende Phase III (Abschluss) been-

det den Kooperationsprozess (zumindest zeitweise) und bewahrt die Kooperations-

ergebnisse f¨

ur sp¨

atere Kollaborationssitzungen. Von Phase III aus kann die Koope-

ration fortgesetzt, zu einem sp¨

ateren Zeitpunkt wieder aufgenommen werden, in eine

zentral verwaltete Infrastruktur ¨

uberf¨

uhrt werden oder als Basis f¨

ur die individuelle

Bearbeitung der Kooperationsergebnisse dienen (vgl. Abbildung 3.2).

Keine der drei Phasen ist zu ihren benachbarten Phasen abgeschlossen, der ¨

Uber-

gang zwischen ihnen erfolgt nahtlos. Jede ¨

Anderung in der Gruppenstruktur der

Kollaboration bewirkt einen Wechsel zu einer benachbarten Phase. Im Falle eines

Beitritts von Benutzern in die Kooperation ist stets die Phase I (Gr¨

undung) betrof-

fen und im Fall des Ausscheidens von Benutzern aus der Kooperation kommt stets

Mobilit¨

at in der kooperativen Wissensarbeit

56 3.1 Phasen mobil-spontaner Kooperation

P h a s e III

Archivierung und Replikation

P h a s e II

Mobile gemeinsame Wissensräume

P h a s e I

Nutzer und digitale Medien

Gründung

Kooperation

Auflösung

Abbildung 3.2: Der Kollaborationsprozess als Regelkreis. In Phase I (Gr¨

undung)

gr¨

unden Benutzer Kollaborationsgruppen, in Phase II (Kooperation) erfolgt die

eigentliche Kollaboration in virtuellen Wissensr¨

aumen und in Phase III (Aufl¨

sung) werden die Ergebnisse f¨

ur zuk¨

unftige Kooperationssitzungen archiviert.

Phase III (Aufl¨

osung) ins Spiel, um die bisherigen Kollaborationsergebnisse f¨

ur die

scheidenden Benutzer zu archivieren.

Die Szenarien aus Kapitel 2 zeigen, dass das Auffinden und Ausw¨

ahlen potentiel-

ler Partner f¨

ur die Kooperation aus den anwesenden und erreichbaren Benutzer eine

erste wichtige Aufgabe der Gr¨

undungphase einer Kooperationsgruppe ist. Durch die-

se Auswahl werden diejenigen Benutzer bestimmt, die Zugang zu dem gemeinsamen

mobilen Wissensraum haben. Die Auswahl geeigneter Kollaborationspartner kann

beispielsweise, wie in einigen der vorgestellten Szenarien, durch explizite Auswahl

aus einem vorhandenen Fundus von Benutzern erfolgen.

Alternativ k¨

onnen Benutzer auch die Mitgliedschaft bei der Gruppe beantragen

und bei deren Zustimmung in diese aufgenommen werden. Ein wichtiger Faktor,

der hilft, die Benutzer bei der Gruppengr¨

undung zu unterst¨

utzen, kann hierbei der

Kontext der potentiellen Partner sein. Als Beispiel sei hier der gemeinschaftliche

Aufenthaltsort der Gruppenmitglieder als Grundlage f¨

ur die Gruppengr¨

undung ge-

Mobilit¨

at in der kooperativen Wissensarbeit

nannt. Nat¨

urlich k¨

onnen zus¨

atzlich auch r¨

aumlich entfernte Benutzer eingebunden

werden, sofern die n¨

otigen technischen Infrastrukturen existieren.

Die Kooperationsphase der so gegr¨

undeten Kooperationen, ist durch den Aus-

tausch und das Strukturieren von Materialien innerhalb der mobilen Arbeitsbe-

reiche gekennzeichnet. Zu diesem Zweck f¨

ugen die Teilnehmer Dokumente in die

Struktur ein, um sie gemeinsam mit den Kooperationspartnern zu nutzen. In einer

mobil-spontanen Kooperation haben alle Teilnehmer zun¨

achst dieselben Zugriffs-

rechte bez¨

uglich des gemeinsamen Arbeitsbereiches. Zudem findet hier die Koopera-

tion zumeist in Pr¨

asenzsituationen statt, kann aber auch r¨

aumlich entfernte Benutzer

einschließen. Somit ist die Gruppenstruktur durch eine hohe Fluktuation der ver-

f¨

ugbaren Gruppenmitglieder gekennzeichnet – neue Mitglieder treten spontan der

Gruppe bei und vorhandene Mitglieder verlassen diese bewusst oder aufgrund ihrer

Mobilit¨

at.

In der Aufl¨

osungsphase einer spontan vernetzten Kooperationsgruppe ¨

ubertragen

die Beteiligten die Kooperationsergebnisse f¨

ur eine sp¨

atere Weiterverwendung als

pers¨

onliche Kopie auf ihre mobilen Ger¨

ate oder Archivieren sie auf einen verf¨

ugbaren

dedizierten Server. Scheiden einzelne Teilnehmer aus, speichern sie die aktuellen

Ergebnisse lokal und aktualisieren diese bei einem sp¨

ateren Wiedereintritt in die

Kooperationssitzung. Dabei kann es sein, dass unverbundene Teilnehmer auf den

Kooperationsmaterialien weiterarbeiten und der Kooperation in einer ge¨

anderten

Medienkonstellation wieder betreten.

So f¨

uhren aus einer medienperspektivischen Sicht technische ¨

Anderungen wie der

Abbruch von Netzwerkverbindungen zu ¨

Anderungen in h¨

oheren Ebenen der Koope-

rationsstruktur. W¨

ahrend auf der technischen Ebene neue Kommunikationsverbin-

dungen initiiert werden m¨

ussen, muss den nun unverbundenen Nutzern ein weiterer

Zugriff auf die Kooperationsmaterialien gew¨

ahrt werden. Diese Offline-Verf¨

ugbarkeit

der Medien in einer mobil-verteilten Kooperationsumgebung f¨

uhrt zu besonderen

Anforderungen aus Handlungs- und Umsetzungsperspektive. Der folgende Abschnitt

betrachtet daher zun¨

achst die Folgen der Mobilit¨

at f¨

ur das medienzentrierte Konzept

der virtuellen Wissensr¨

aume.

3.2 Medienfunktionen und Mobilit¨

Die Bewertung existierender und zuk¨

unftiger Architekturen im Bereich der Koope-

rationsunterst¨

utzung f¨

ur mobile Nutzungsszenarien bedarf der Identifizierung der

ben¨

otigten Basisfunktionalit¨

at. Diese bildet das Mindestmaß an Unterst¨

utzungs-

funktionen f¨

ur eine reibungslose Zusammenarbeit mittels einer computergest¨

utzten

Kooperationsumgebung. Aus der Perspektive einer medienzentrierten Kooperation

in gemeinsamen Arbeitsbereichen hat eine mangelnde Unterst¨

utzung dieser Basis-

funktionalit¨

at automatisch einen so genannten Medienbruch zur Folge. Die Benutzer

k¨

onnen bestimmte Aufgaben nicht mehr innerhalb des Kooperationssystems bew¨

alti-

gen und m¨

ussen auf externe Werkzeuge ausweichen. Medienbr¨

uche stellen somit eine

Mobilit¨

at in der kooperativen Wissensarbeit

58 3.2 Medienfunktionen und Mobilit¨

technikbedingte Unterbrechung der Arbeitsvorg¨

ange dar. Keil-Slawik und Hampel

[vgl. Hampel, 2001, S.3] beschreiben diese Medienbr¨

uche wie folgt:

”Mit diesem Konzept bezeichnen wir Situationen, in denen es erforder-

lich ist, Wissensbest¨

ande in Bezug auf ihre medialen Tr¨

agerstrukturen zu

transformieren, ohne dass damit ein Informationsgewinn auf kognitiver

oder sensumotorischer Ebene verbunden ist.”

Um Medienbr¨

uche in Hinsicht auf eine medienzentrierte Kooperation zu vermei-

den, wird im Rahmen dieser Arbeit auf das erprobte Konzept der virtuellen Wissens-

r¨

aume und Medienfunktionen [Hampel, 2001] zur¨

uckgegriffen und bez¨

uglich mobil-

spontaner Kooperationsszenarien betrachtet. Die virtuellen Wissensr¨

aume stellen

ein raumbasiertes Konzept f¨

ur die Strukturierung gemeinsam genutzter Medien- und

Dokumentenbest¨

ande dar, das mittels so genannter prim¨

arer Medienfunktionen die

Basisfunktionalit¨

at f¨

ur die gemeinsame Manipulation der Struktur des virtuellen

Wissensraumes und der enthaltenen Medien bereitstellt. Die prim¨

aren Medienfunk-

tionen k¨

onnen durch weitergehende Medienfunktionen erg¨

anzt werden, die h¨

ohere

Ebenen der Kooperationsunterst¨

utzung implementieren. Insgesamt werden drei Ebe-

nen der Medienfunktionen unterschieden:

•Prim¨

are Medienfunktionen bilden die Gruppe der Basisfunktionen, ohne die ei-

ne medienbruchfreie Zusammenarbeit auf dem Fundament einer gemeinsamen

Mediennutzung nicht m¨

oglich ist. Die prim¨

aren Medienfunktionen werden zur

weiteren Differenzierung noch einmal in individuelle und kooperative Medi-

enfunktionen unterteilt. Erstere erm¨

oglichen die individuelle Mediennutzung

im eigenen Wahrnehmungsraum. Sie bestehen aus den Funktionen Erzeugen,

L¨

oschen,Verkn¨

upfen und Arrangieren. Zweitere sind f¨

ur den kooperativen Me-

diengebrauch unabdingbar und werden aus den Funktionen ¨

Ubertragen,Zu-

greifen und Synchronisieren gebildet.

•Sekund¨

are Medienfunktionen bilden die Gruppe komplexerer Funktionen der

Mediennutzung. Sie enthalten bereits eine Annahme ¨

uber die Art der Medien-

nutzung durch die Anwender. Sie sind nicht universell einsetzbar und erschei-

nen nicht in jedem Nutzungskontext sinnvoll.

•Terti¨

are Medienfunktionen passen sich der Mediennutzung der Benutzer an

und versuchen den virtuellen Wissensraum nach deren Bed¨

urfnissen zu struk-

turieren.

W¨

ahrend die prim¨

aren Medienfunktionen eine minimale aber f¨

ur die Koopera-

tion ausreichende Basisfunktionalit¨

at zur computergest¨

utzten und medienzentrier-

ten Zusammenarbeit bieten, stellen die h¨

oheren Ebenen der Medienfunktionen eine

an bestimmte Nutzungskonzepte gebundene Funktionalit¨

at dar. Diese Arbeit fokus-

siert beim Mediengebrauch daher die technische Unterst¨

utzung der prim¨

aren Medi-

enfunktionen, um die Basis f¨

ur eine kooperative Medienstrukturierung in mobilen

Nutzungsszenarien zu schaffen.

Mobilit¨

at in der kooperativen Wissensarbeit

Die technische Unterst¨

utzung der Medienfunktionen kann, je nach Umgebung und

Tiefe der technischen Betrachtung, unterschiedlich komplex ausfallen und setzt sich

dabei oftmals aus weiteren Funktionen zusammen. Als Beispiel sei hier das Versenden

einer Datei an einen anderen Nutzer f¨

ur eine gemeinsame Bearbeitung genannt.

Diese Funktion des Versendens kann als eine Sequenz von Einzelschritten betrachtet

werden: Die Bestimmung der Adresse des Empf¨

angers, die Ermittlung eines Pfades

von der Adresse des Versenders zur Adresse des Empf¨

angers, und die ¨

Ubermittlung

der Datei zum n¨

achsten benachbarten Knoten auf diesem Pfad. Je nach Komplexit¨

des Umfeldes und Detailtiefe der Betrachtung sind einige dieser Schritte ihrerseits

Grundfunktionen oder k¨

onnen wiederum durch Sequenzen weiterer, grundlegenderer

Funktionen beschrieben werden.

Die technische Komplexit¨

at der Umgebung ¨

ubertr¨

agt sich so auch auf die me-

dienperspektivische Betrachtung der Medienfunktionen. Eine Beobachtung der pri-

m¨

aren Medienfunktionen in ihrer zeitlichen Entwicklung zeigt, dass die kooperativen

prim¨

aren Medienfunktionen im Gegensatz zu den individuellen prim¨

aren Medien-

funktionen einem stetigen Wandel unterworfen sind. Wurde anfangs keine Unter-

scheidung zwischen individuellen und kooperativen prim¨

aren Medienfunktionen ge-

troffen, betrachten die kooperativen prim¨

aren Medienfunktionen die Besonderheiten

einer vernetzten und gemeinsamen Mediennutzung. Insbesondere die kooperativen

prim¨

aren Medienfunktionen (im Folgenden einfachheitshalber kooperative Medien-

funktionen genannt) h¨

angen stark von dem technischen Umfeld ab, in dem sie im-

plementiert werden.

Die Diskussion um die Abh¨

angigkeit der kooperativen Medienfunktionen von der

Betrachtung des technischen Umfeldes kann z. B. an der Frage der Funktion Adres-

sieren als kooperative Medienfunktion festgemacht werden. Urspr¨

unglich war sie kei-

ne kooperative Medienfunktion, obwohl das Adressieren eines Medienobjektes eine

Basisfunktion jeder kooperativen Mediennutzung ist. Um ein Medienobjekt bear-

beiten zu k¨

onnen, muss es es zun¨

achst benannt (adressiert) werden k¨

onnen. Der

Aufwand f¨

ur das Adressieren eines Medienobjektes steigt mit der Komplexit¨

at der

Vernetzung der Kooperationsumgebung. Diese Komplexit¨

at k¨

onnte f¨

ur die Benutzer

bedeuten, dass sie in dem System ein Medienobjekt nicht adressieren k¨

onnen, was

zu einem Medienbruch f¨

uhrt. Folgt man dieser Logik, ist Adressieren m¨

oglicherweise

eine Medienfunktion, da es eine essentielle Grundfunktion f¨

ur einen durchg¨

angigen

Mediengebrauch ist.

Der Grund, dass die Funktion Adressieren noch nicht bei den Medienfunktionen

erscheint, mag darin liegen, dass diese Funktion in einem geschlossenen und zen-

tral verwalteten System mit einem ebenso geschlossenen und zentral verwalteten

Namensraum als selbstverst¨

andlich erscheint. Dies ¨

andert sich jedoch bei der Bereit-

stellung von Medienobjekten in offenen und verteilten Systemen. Da die Objekte auf

nahezu allen Knoten des Systems gespeichert sein k¨

onnen, entsteht hier die Frage

nach deren genauen Speicherorten f¨

ur einen Zugriff auf die Medienobjekte.

Analog zu dem Vorgehen der Ermittlung prim¨

arer Medienfunktionen f¨

ur eine me-

dienzentrierte Basisfunktionalit¨

at, werden in den folgenden Abschnitten technische

Grundfunktionen identifiziert, die ein Kooperationssystem bieten muss, um eine me-

Mobilit¨

at in der kooperativen Wissensarbeit

60 3.3 Neue Qualit¨

aten mobiler Kollaboration

dienzentrierte Kooperation in mobilen Nutzungsszenarien zu unterst¨

utzen. Dabei

werden Ankn¨

upfungspunkte an die prim¨

aren Medienfunktionen geschaffen und eine

Uberf¨

uhrung dieser von zentral verwalteten Systemen auf verteilte und offene Archi-

tekturen betrachtet. Der besondere Fokus liegt dabei auf einer spontanen Etablie-

rung von Kooperationsumgebungen in der zuvor trivial erscheinende Grundfunktio-

nen zu komplexen und zentralen Fragestellungen werden, die bei weitem nicht jedes

vorhandene System selbstverst¨

andlich bereitstellt. Grundlage f¨

ur diese Betrachtung

bilden die in Kapitel 2 entwickelten Szenarien.

Die folgenden Abschnitte sind daher wie folgt gegliedert: Der Abschnitt ”Neue

Qualit¨

aten mobiler Kollaboration“ identifiziert die ben¨

otigten Grundfunktionen f¨

die neuartige mobile Nutzung von virtuellen Wissensr¨

aumen in einer mobilit¨

atsun-

terst¨

utzenden Kooperationsumgebung. Die in diesem Abschnitt vorgestellten Anfor-

derungen ergeben sich daher aus dem neuartigen mobilen Gebrauch und weniger

aus den technischen Anforderungen im mobilen Nutzungsumfeld an sich. Diese neu-

en technischen Anforderungen an klassische Unterst¨

utzungsfunktionen des CSCW

werden im Anschluss daran im Abschnitt ”Neue Rahmenbedingungen“ vorgestellt.

3.3 Neue Qualit¨

aten mobiler Kollaboration

Aus den in Kapitel 2 entwickelten Szenarien mobiler Kooperation ergeben sich spe-

zielle Anforderungen an den Funktionsumfang und die Mechanismen der neuartigen

Kooperationsumgebung. Einige dieser Anforderungen liegen abseits der klassischen

Kooperationsszenarien und leiten sich aus dem spontanen Charakter der Zusam-

menarbeit und der Mobilit¨

at der Benutzer her.

Grunds¨

atzlich orientieren sich die Anforderungen an der Kollaboration in mobilen

Wissensr¨

aumen an den in Kapitel 2 entwickelten Nutzungsszenarien. Die neuen Qua-

lit¨

aten der Ad-Hoc-Kooperation mit Hilfe mobiler Computer werden im Folgenden

aus diesen Szenarien ermittelt und analysiert. Vorweggenommen lassen sich die in-

novativen Aspekte mobil-spontaner Kollaboration entlang der Begriffe Vernetzung,

Sichtbarkeit,Kontextualisierung,Konsistenz und Reversibilit¨

at einordnen.

Die Komplexit¨

at der semantischen Verkn¨

upfung von mobilen Wissensr¨

aumen und

der spontane Charakter der mobilen Kollaborationsszenarien zwingen die Koope-

rationsumgebung, die Strukturen des mobilen Wissensraums so weit wie m¨

oglich

automatisch zu erschließen, um die Aufmerksamkeit der Benutzer nicht von der ei-

gentlichen Zusammenarbeit abzulenken.

Besonders in der Gr¨

undungsphase spielen Vernetzung,Sichtbarkeit und Kontext

eine wichtige Rolle. Ist der mobile Wissensraum erst errichtet, muss die Koopera-

tionsumgebung zudem dessen Konsistenz sicherstellen. Da sich die Strukturen des

mobilen Wissensraums aufgrund der Mobilit¨

at seiner Nutzer schnell und dynamisch

andern k¨

onnen, ist es wichtig, die Konsistenz so lange wie m¨

oglich aufrecht zu er-

halten. Sollte dies nicht gelingen, muss die Kooperationsumgebung Mechanismen

bereitstellen, die im Falle einer Inkonsistenz in der Struktur der mobil-verteilten

Mobilit¨

at in der kooperativen Wissensarbeit

3.3.1 Vernetzung und Sichtbarkeit 61

Vernetzung Kontext Konsistenz

spontane Netzwerke

finden der Kollaborationspartner

Objektverteilung

Gruppengründung

Rollen und Zugriffsrechte

strukturieren der Materialien

Replikationsstrategie

verteilte Wissensräume

synchronisierte Sichten

dezentralisierte Verwaltung

replizierte Dokumente

exemplarische Abhängigkeiten

Abbildung 3.3: Schl¨

usselfaktoren mobil-verteilter Wissensr¨

aume: Vernetzung und

Sichtbarkeit,Kontextualisierung und Konsistenz und Reversibilit¨

at.

Wissensr¨

aume deren Konsistenz wieder herstellen helfen. Das Zusammenspiel dieser

Schl¨

usselanforderungen verdeutlicht Abbildung 3.3.

Die folgenden drei Abschnitte befassen sich folglich mit den Anforderungen der

”

Vernetzung und Sichtbarkeit“,”Kontextualisierung“ und ”Konsistenz und Reversibi-

lit¨

at“ als Schl¨

usselfaktoren einer mobilit¨

atsunterst¨

utzenden Kooperationsumgebung

auf Basis mobil-verteilter Wissensr¨

aume.

3.3.1 Vernetzung und Sichtbarkeit

Anforderungen

Kontextualisierung

Kommunikation

Konsistenz

Koordination Kooperation

Kollaboration

Vernetzung

Vernetz

ung

Vernetzung

Der Faktor, der eine Kooperation erst erm¨

oglicht, ist die Wahrnehmung potentieller

Kooperationspartner und die Kontaktaufnahme zu diesen. Der Trend zu allgegen-

w¨

artigen Netzwerkinfrastrukturen an nahezu allen ¨

offentlichen Pl¨

atzen l¨

asst den Ein-

druck entstehen, Benutzer k¨

onnten jederzeit auf eine solche Netzwerkinfrastruktur

zur¨

uckgreifen, um ¨

uber diese eine Kommunikation mit ihren Kooperationspartnern

zu etablieren. Trotz der Anstrengungen kommerzieller Dienstleister, Netzwerke all-

gegenw¨

artig zug¨

anglich zu machen, bleiben viele Benutzer von der Nutzung dieser

Infrastrukturen ausgeschlossen.

Gr¨

unde hierf¨

ur sind h¨

aufig propriet¨

are Protokolle, Zugangsbegrenzungen auf ge-

schlossene Personenkreise, geblockte Dienste oder die Verbindungskosten. Da der

Zugang zu bestehenden Netzwerkinfrastrukturen nicht ¨

uberall gew¨

ahrleistet wer-

Mobilit¨

at in der kooperativen Wissensarbeit

62 3.3 Neue Qualit¨

aten mobiler Kollaboration

den kann oder zu hohe Kosten verursachen w¨

urde, m¨

ussen mobilit¨

atsunterst¨

utzende

Kooperationsumgebungen als ersten Schritt der Kollaboration ein Kommunikati-

onsnetzwerk zwischen den mobilen Ger¨

aten der Benutzer einrichten. Als technolo-

gische Basis f¨

ur diese Kommunikationsstrukturen eignen sich insbesondere die in

Abschnitt 4.2.1 vorgestellten Ad-Hoc-Netzwerk-Protokolle, die in der Lage sind, mit

einem minimalen Konfigurationsaufwand seitens der Benutzer, ein Netzwerk zwi-

schen den mobilen Computern zu errichten.

Eine solche Ad-Hoc-Vernetzung der mobilen Kooperationspartner ist zentrale Vor-

aussetzung f¨

ur jede weitere computergest¨

utzte Kooperationshandlung. Dieser Aspekt

der Vernetzung geht ¨

uber die in Abschnitt 4.2 behandelte technische Vernetzung hin-

aus. Zwar stellen diese innovativen Netzwerkprotokolle die Basis spontaner Compu-

terkommunikation bereit, doch bleibt die Kooperationsumgebung ohne eine Wahr-

nehmung potentieller Kooperationspartner und kooperationsunterst¨

utzender Diens-

te f¨

ur den Benutzer schwer zug¨

anglich.

F¨

ur eine Kooperationsumgebung werden zahlreiche miteinander verkn¨

upfte Diens-

te ben¨

otigt, die helfen, Kollaborationspartner zu finden, mit ihnen zu kommunizieren

und mit gemeinsamen Dokumenten zu arbeiten. Diese Dienste m¨

ussen f¨

ur jeden Teil-

nehmer der Kooperationsumgebung verf¨

ugbar sein. Sowohl die Basisdienste als auch

die Zusatzdienste sollten automatisch und ohne Benutzereingriff konfiguriert werden.

Dies gilt insbesondere, wenn Dienste an Dritte im Netzwerk angeboten werden, da

hier die Motivation der lokalen Benutzer zur Konfiguration des Dienstes am nied-

rigsten ist. Generell ist die manuelle Konfiguration eines Dienstes stets ein m¨

ogliches

Nutzungshemmnis, das es zu vermeiden gilt.

Der zu Beginn der Kooperation wichtigste Dienst ist die Identifizierung poten-

tieller Kollaborationspartner. Diese Identifizierung kann durch die Auswertung des

Kontextes verf¨

ugbarer Benutzer oder ¨

uber deren Nutzerprofil erfolgen. Als Kontext

der Benutzer kann deren Aufenthaltsort sowohl in der virtuellen Welt der Wissens-

r¨

aume als auch in der realen Welt dienen oder aber deren Beziehungen zu anderen

Benutzern. Besonders in der Pr¨

asenzkooperation, die eine intuitive Form der spon-

tanen Kollaboration darstellt, ist der Aufenthaltsort der Benutzer in ihrem realen

Umfeld n¨

utzlich f¨

ur die Gruppengr¨

undung. Nutzerprofile wiederum zeigen explizit

Interessen und Kompetenzen der potentiellen Kollaborationspartner auf. Alle diese

Hilfestellungen unterst¨

utzen somit die gezielte Auswahl der Kollaborationspartner

f¨

ur die Bildung einer Gruppe innerhalb der Kooperationsumgebung.

Die Struktur der Gruppe, die von den Kollaborationspartnern formell oder in-

formell gebildet wird, definiert den Charakter der Kollaboration. Sie ist Indiz f¨

die ben¨

otigte Vernetzung der Teilnehmer. W¨

ahrend sich im nat¨

urlichen Koopera-

tionsumfeld derartige Gruppen auf rein sozialer und r¨

aumlicher Basis finden, ist

es schwierig, derartige Gruppenstrukturen in mobilen Kooperationsumgebungen ne-

benl¨

aufig zum Kooperationsprozess zu bilden. Eine formalisierte Gruppenstruktur

wie in klassischen CSCW-Systemen kann sich kaum an die Dynamik mobil-verteilter

Kooperationsszenarien anpassen. Die formale Gr¨

undung einer Gruppe ist unter die-

sen Gesichtspunkten zu umst¨

andlich und gen¨

ugt daher nicht dem Verh¨

altnis zwi-

Mobilit¨

at in der kooperativen Wissensarbeit

3.3.2 Kontextualisierung 63

schen Aufwand und Nutzen in den oft kurzfristigen Sitzungen einer mobilen Ad-

Hoc-Kooperation.

Der spontane Charakter der Kooperationssitzungen bedingt außerdem eine hohe

Dynamik in der Zusammensetzung der Kooperationsgruppen. Neu hinzukommende

Benutzer nehmen an der Kooperationssitzung teil, w¨

ahrend andere diese wieder ver-

lassen, um sich anderen T¨

atigkeiten zuzuwenden. Diese Dynamik wird im Szenario

1.7 verdeutlicht. Die dynamische Kooperation in mobil-verteilten Kooperationssze-

narien ben¨

otigt also entsprechend dynamische Gruppenstrukturen. Das Hauptaugen-

merk liegt hierbei auf der Flexibilit¨

at bez¨

uglich der Fluktuation der Mitglieder und

der beil¨

aufigen Gr¨

undung einer solcher Kooperationsgruppe anhand des Arbeitskon-

textes wie in Szenario 2.2 beschrieben.

Da aber klassische und formelle Kooperationsformen weiterhin unterst¨

utzt werden

sollen, m¨

ussen diese dynamischen Gruppenstrukturen auch gemeinsam mit langfris-

tig genutzten Gruppenstrukturen existieren k¨

onnen. Trotz ihrer Dynamik sollte eine

Gruppe gegen¨

uber fremden Benutzern abgeschlossen sein (vgl. Szenario 2.2), da die

Gruppe nicht nur die Vernetzung der Kooperationspartner definiert, sondern oft

auch die Berechtigung auf gruppeneigene Dokumente vorgibt.

Die Dynamik mobiler Kooperation muss mit den formalen Anforderungen an die

Gruppenstruktur einer CSCW-Umgebungen vereint werden. Diese kann nur erreicht

werden, indem sich die Kooperationsumgebung selbstt¨

atig vernetzt und Prozesse der

Gruppenkonstruktion und -verwaltung mit Hilfe des Kontextes der Kooperations-

teilnehmer automatisiert.

3.3.2 Kontextualisierung

Anforderungen

Kontextualisierung

Kommunikation

Konsistenz

Koordination Kooperation

Kollaboration

Vernetzung

Vernetzun

Kontextualisierung

Kontext spielt in einer mobilit¨

atsunterst¨

utzenden Kooperationsumgebung eine wich-

tige Rolle f¨

ur die Vernetzung der Benutzer. Dieser Kontext kann z. B. aus dem derzei-

tigen Aufenthaltsort oder den zurzeit benutzten Dokumenten bestehen. Die soziale

Vernetzung mittels Gruppenbildung wird dabei ebenso wie die technische Vernet-

zung von diesem Kontext bestimmt.

In klassischen CSCW-Umgebungen bilden Informationen ¨

uber den Kontext der

Benutzer, die sich nicht direkt aus dem Kooperationssystem selbst ergeben, eine

h¨

aufig vernachl¨

assigte M¨

oglichkeit, den Nutzern komfortable Hilfestellungen f¨

ur die

Mobilit¨

at in der kooperativen Wissensarbeit

64 3.3 Neue Qualit¨

aten mobiler Kollaboration

Kooperation zu geben. In einer mobilen Kooperationsumgebung jedoch wird die In-

tegration verf¨

ugbarer Kontextinformationen zu einem maßgebenden Faktor f¨

ur deren

Effizienz. Bei oft nur kurzfristigen spontanen Kooperationssitzungen steht der Auf-

wand f¨

ur eine manuelle Einrichtung der computergest¨

utzten Kooperationsumgebung

in keinem Verh¨

altnis zum Nutzen der Kooperationsumgebung. Kontext ist folglich

ein grundlegendes Werkzeug, um den Kollaborationsprozess in mobilen Nutzungs-

szenarien zu konfigurieren.

Bei einer intensiven Einbeziehung des Nutzerkontextes in die Kooperationsumge-

bung kann dieser gleich auf mehreren Ebenen f¨

ur die Strukturierung von Koope-

rationsprozessen genutzt werden. Auf Medienebene k¨

onnen Dokumente und andere

Materialien anhand ihres Nutzungskontextes strukturiert werden. So kann bereits

zu Beginn des Kollaborationsprozesses ein vorstrukturierter Wissensraum zur Ver-

f¨

ugung gestellt werden, anstatt die Nutzer mit einer unsortierten Anh¨

aufung von

Materialien zu konfrontieren.

Aus einer organisatorischen Perspektive k¨

onnen z. B. Kooperationsgruppen ge-

gr¨

undet werden, bei denen alle um einen Tisch versammelten Personen oder alle

Studierenden eines Seminars automatisch in diese aufgenommen werden. Als eine

wichtige Quelle f¨

ur den Kontext eines Benutzers – speziell in mobilen Nutzungssze-

narien – kann der Ortsbezug (engl. Location Awareness) gelten [vgl. Dourish und

Bellotti, 1992]. Pr¨

asenzkooperation ist die nat¨

urliche Form spontan-mobiler Zusam-

menarbeit, in der die N¨

ahe zu anderen Benutzern auch die Kooperationsbeziehung

zu diesen definiert. Diesen Kooperationskontext gilt es in die virtuelle Kooperati-

onsumgebung zu ¨

ubertragen.

In mobilen Nutzungsszenarien wie Szenario 1.1 wird eine Wahrnehmung und Iden-

tifizierung potentieller Kooperationspartner, die f¨

ur eine Zusammenarbeit zur Ver-

f¨

ugung stehen, ben¨

otigt. F¨

ur Pr¨

asenzkooperationen muss man potentielle Koope-

rationspartner anhand ihres ¨

ortlichen Kontextes filtern k¨

onnen (vgl. Szenario 1.1,

Szenario 2.1). Zu diesem Zweck reicht h¨

aufig das Wissen um die relative N¨

ahe der

Benutzer zu einem Bezugspunkt aus. Dieser Bezugspunkt kann ein anderer Benut-

zer in der Kooperationsumgebung oder ein kooperationsrelevanter Gegenstand sein.

Beispiele m¨

ogen hier sein, eine Gruppe mit allen potentiellen Kooperationspartnern

in zwei Metern Umkreis von sich selbst zu gr¨

unden – oder mit allen um einen Tisch

sitzenden Benutzern. Auch ohne Kenntnis der absoluten Position der Teilnehmer

und mit nur ungenauer relativer Positionsbestimmung kann bereits eine sinnvolle

Unterst¨

utzung der Kooperationsprozesse bewerkstelligt werden.

Mittels des Ortsbezugs entsteht so eine soziale Vernetzung zwischen den Teilneh-

mern der Kooperationsumgebung, in der auch Rollen und Rechte vom aktuellen

Kontext der Benutzer abh¨

angen. Der aktuelle Aufenthaltsort kann z. B. einem Be-

nutzer einen Gastzugang zu den Ressourcen der Kooperationsgruppe er¨

offnen oder

einer Person am Rednerpult automatisch die Rolle des Moderators zuweisen. Ei-

ne manuelle Festlegung der Rollen und Rechte in einem Kooperationsszenario ist

oftmals eine komplexe Aufgabe f¨

ur die Verwalter einer Kooperationsumgebung, die

durch die Nutzung von Kontextinformationen minimiert werden kann.

Mobilit¨

at in der kooperativen Wissensarbeit

3.3.2 Kontextualisierung 65

mobil-verteilter

Wissensraum

örtlicher Kontext

Abbildung 3.4: Bei der Verkn¨

upfung von realem Raum und virtuellem Wissens-

raum werden ¨

ortlichen Gegebenheiten (z. B. einem Seminarraum) virtuellen Wis-

sensr¨

aumen zugeordnet. ¨

Uber die Verbindungen zwischen den Wissensr¨

aumen

k¨

onnen so auch die realen R¨

aume miteinander verkn¨

upft werden.

Uber ihren Kontext k¨

onnen so die Gruppenmitglieder einer Kollaboration be-

stimmt und zugleich ihre Rolle in der Gruppe definiert werden. Wenn die Benutzer

ihren Kontext ver¨

andern, passen sich die Zugriffsrechte und Rollenzuweisungen au-

tomatisch an den neuen Kontext an. Somit wird durch eine ¨

Anderung des Kontextes

innerhalb der virtuellen Kooperationsumgebung entlang des realweltlichen Kontex-

tes nebenl¨

aufig eine Verkn¨

upfung von virtuellem und realem Wissensraum erreicht

[Eßmann und Hampel, 2004]. Abbildung 3.4 verdeutlicht diese Verkn¨

upfung durch

die Bildung von Gruppenkontexten in Abh¨

angigkeit des Ortsbezugs der Teilnehmer.

Aus einer technischen Betrachtungsweise kann der Kontext auch f¨

ur vom Benut-

zer unbemerkte und transparente Vorg¨

ange in der Kooperationsumgebung genutzt

werden. Die in mobilen Nutzungsszenarien ¨

ubliche verteilte Speicherung der Koope-

rationsobjekte kann durch den Kontext der beteiligten Knoten gesteuert werden.

Der Kontext der Benutzer kann z. B. bei der Entscheidung helfen, auf welchen Kno-

ten der Kooperationsumgebung die Objekte repliziert werden sollen. W¨

ahrend viele

CSCW-Systeme die genutzten Objekte bei einem Zugriff lediglich zwischenspeichern

(Caching), kann der Kontext genutzt werden, um eine gezielte Replikationsstrate-

gie zu entwickeln. Beispielsweise sind Dokumente, die einer Gruppe geh¨

oren, meist

f¨

ur alle Mitglieder von Interesse. Eine sinnvolle Replikationsstrategie k¨

onnte also

den Gruppenkontext nutzen, um die Dokumente auf die Ger¨

ate aller Gruppenmit-

glieder zu replizieren. Dadurch sind die Dokumente der Gruppe f¨

ur alle Mitglieder

Mobilit¨

at in der kooperativen Wissensarbeit

66 3.3 Neue Qualit¨

aten mobiler Kollaboration

auch im Falle einer Trennung von der Gruppe jederzeit zug¨

anglich. Eine eingehende

Betrachtung der Replikation anhand des Gruppenkontextes findet sich in Kapitel 4.

Zusammenfassend betrachtet kann der Kontext der Benutzer somit auf organi-

satorischer Ebene, Medienebene und technischer Ebene genutzt werden, um mobil-

spontane Kooperationsszenarien zu unterst¨

utzen. Konkret l¨

asst sich der Kontext in

der Kooperation selbst f¨

ur Gruppengr¨

undung, Festlegung von Rollen und Rechten

und die Strukturierung des virtuellen Wissensraums verwenden. Aus einer eher tech-

nischen Sichtweise kann die Konfiguration der Dienste der Kooperationsumgebung

und insbesondere die Replikation der genutzten Objekte ¨

uber eine Nutzung des Ko-

operationskontextes gesteuert werden. Die Kontextualisierung der Kooperationsum-

gebung ist somit eine wesentliche Anforderung f¨

ur die Unterst¨

utzung mobil-verteilter

Kooperationsszenarien.

3.3.3 Konsistenz und Reversibilit¨

Anforderungen

Kontextualisierung

Kommunikation

Konsistenz

Koordination Kooperation

Kollaboration

Vernetzung Vernetz

ung

Konsistenz

In mobil-verteilten Wissensr¨

aumen sind die Kooperationsobjekte verteilt auf mo-

bilen Computern der Benutzer gespeichert. Um die Verf¨

ugbarkeit der gemeinsam

genutzten Objekte sicherzustellen, m¨

ussen Teile des Wissensraums oder gar der ge-

samte Wissensraum zwischen den mobilen Ger¨

aten repliziert werden. Die Replikation

erlaubt den Kooperationspartnern den Zugriff auf die gemeinsam genutzten Mate-

rialien, auch wenn sie von dem Rest der Kooperationsgruppe getrennt sind. Wenn

die Replikation alle Objekte beinhaltet, die f¨

ur eine Aufgabe ben¨

otigt werden, k¨

on-

nen auch isolierte Benutzer den Kollaborationsprozess aufrechterhalten. Diese M¨

og-

lichkeit zum isolierten Arbeiten an gemeinsamen Objekten in den unverbundenen

Phasen erfordert die Unabh¨

angigkeit der mobil-verteilten Kooperationsumgebungen

von Diensten entfernter Dienstleister (Server).

In verteilten Architekturen sind zu diesem Zweck Daten sowie Dienste ¨

uber alle

Knoten des zu Grunde liegenden Netzwerkes verteilt. Essentielle Daten und Dienste

k¨

onnen dabei auch redundant auf einer Gruppe mehrerer Knoten beheimatet sein.

Dieses Vorgehen erlaubt es einem Knoten, die Dienste eines anderen Knotens zu

ubernehmen, wenn dieser ausfallen sollte. Die Verteilung der Daten und Dienste ist

oftmals eine Strategie zur Lastverteilung zwischen den einzelnen Knoten und zur

Erh¨

ohung der Ausfallsicherheit des Gesamtsystems.

Mobilit¨

at in der kooperativen Wissensarbeit

3.3.3 Konsistenz und Reversibilit¨

at 67

Der Ausfall eines einzelnen Knotens f¨

uhrt dadurch nicht mehr zum Ausfall des

gesamten Systems. Allerdings m¨

ussen replizierte Dienste und Daten miteinander

abgeglichen werden, um die Konsistenz des Systems zu wahren. Der Fokus der Ar-

chitektur vieler verteilter Systeme liegt folglich in der Aufrechterhaltung des Ge-

samtsystems und nicht in der Unterst¨

utzung mobiler und zeitweise isolierter Kno-

ten. Ein Verbindungsabbruch zu einem einzelnen Knoten wird stets nur aus der

Perspektive des Gesamtsystems betrachtet und dessen Dienste an andere Knoten im

Verbund ¨

ubertragen. Dadurch bleibt das Gesamtsystem bei Knotenausf¨

allen intakt

– der isolierte Knoten aber ist solange unbrauchbar bis er wieder Verbindung zum

Gesamtsystem aufnehmen kann [Eßmann et al., 2006].

Die neue Qualit¨

at mobil-verteilter Kooperationsumgebungen liegt in der Mobi-

lit¨

at der Benutzer und der Dynamik der technischen Umgebung. Der Verlust der

Anbindung zum Verbund der Kooperationspartner ist eine h¨

aufige Begleiterschei-

nung dieser Mobilit¨

at. In verteilten Kooperationssystemen, die nur die Funktions-

f¨

ahigkeit des Gesamtsystems gew¨

ahrleisten, sind isolierte Benutzer gezwungen, ihre

Arbeitsvorg¨

ange innerhalb des gemeinsamen Arbeitsbereichs ruhen lassen, bis sie

wieder Kontakt zu dem Verbund aufnehmen k¨

onnen. Da dies einen Bruch in der

durchgehenden Nutzung der Kooperationsumgebung darstellen w¨

urde, ist es wich-

tig, zwischen verteilten Systemen zu unterscheiden, in denen alle funktionierenden

Knoten stets mit dem Verbund in Kontakt stehen m¨

ussen und solchen, in denen

mobile Knoten auch im unverbundenen Zustand (eventuell eingeschr¨

ankt) weiter-

funktionieren k¨

onnen.

Beide Auspr¨

agungen verteilter Systeme haben unterschiedliche Anforderungen an

die Verteilung der Ressourcen, um ihre Funktion aufrechterhalten zu k¨

onnen. F¨

eine Unterscheidung dieser Systeme werden an dieser Stelle zwei Klassen verteil-

ter Systeme mit redundanten Diensten definiert: die online-redundanten verteilten

Systeme und die offline-redundanten verteilten Systeme.

W¨

ahrend die Klasse der online-redundanten verteilten Systeme ihre Priorit¨

at in

die Aufrechterhaltung der Gesamtfunktionalit¨

at legt, liegt diese bei der Klasse der

offline-redundanten verteilten Systemen in der Aufrechterhaltung der Grundfunktio-

nalit¨

at f¨

ur die einzelnen Knoten. Letztere erlaubt ihren Benutzern auch im unver-

bundenen Fall ihre Arbeit fortzusetzen.

Der wichtigste Dienst in einem Kollaborationssystem auf Basis der virtuellen Wis-

sensr¨

aume ist die Bereitstellung der von den Kooperationspartnern ben¨

otigten Ma-

terialien und Dokumente (genereller: Objekte). Alle ben¨

otigten Objekte m¨

ussen zwi-

schen den beteiligten Partnern repliziert werden, damit auf diese bei Bedarf zuge-

griffen werden kann. Bei der ¨

Anderung eines replizierten Objektes m¨

ussen zudem

alle Repliken aktualisiert werden, um dem aktuellen Stand zu entsprechen und um

den Datenbestand der Kooperationsumgebung konsistent zu halten.

Auf Grund der Mobilit¨

at der Benutzer und der daraus resultierenden hohen Wahr-

scheinlichkeit von Netzwerkunterbrechungen, bei denen auch ganze Teilnetzwerke

getrennt werden k¨

onnen, ist eine Online-Synchronisation der Repliken nicht immer

m¨

oglich. Daher wird die Konsistenz der Kollaborationsdaten ein zentraler Punkt f¨

die Designfragen eines mobil-verteilten Kollaborationssystem sein.

Mobilit¨

at in der kooperativen Wissensarbeit

68 3.3 Neue Qualit¨

aten mobiler Kollaboration

Eine gezielte Replikationsstrategie erlaubt den nahtlosen Wechsel zwischen ver-

bundenen (online) und unverbundenen (offline) Arbeiten. Dies ist gerade in mobilen

Nutzungszenarien aufgrund der Dynamik in der Vernetzung von hoher Bedeutung.

In unverbundenen Phasen des Kollaborationsprozesses fehlt den Benutzern jegliche

Wahrnehmung ¨

uber die Handlungen ihrer Kollaborationspartner. Daher kann es zu

einer parallelen Bearbeitung mehrerer Repliken desselben Dokuments kommen, ohne

dass die beteiligten Benutzer von den konkurrierenden ¨

Anderungen wissen.

Im Fall einer parallelen ¨

Anderung der Repliken desselben Objekts, ohne gegen-

seitige Wahrnehmung der ¨

Anderungen anderer, werden die replizierten Instanzen

zwangsl¨

aufig inkonsistent zueinander. Diese Gef¨

ahrdung der Konsistenz kann sowohl

auf Medienebene als auch auf semantischer Ebene liegen. Die Konsistenz auf Me-

dienebene ist z. B. gef¨

ahrdet, wenn auf redundant gespeicherten Daten zeitgleich ge-

arbeitet ohne diese st¨

andig (online) zu synchronisieren. Die semantische Konsistenz

ist in Gefahr, wenn verteilt gespeicherte Daten semantisch gekoppelt sind aber auf-

grund gleichzeitiger ¨

Anderung der verteilten Datenbest¨

ande dieser Zusammenhang

verloren geht. Beide Formen der Inkonsistenz k¨

onnen die Konsistenz des gesamten

Wissensraums gef¨

ahrden.

Die Erhaltung der Konsistenz der Kooperationsdaten bildet einen der zentra-

len Faktoren f¨

ur eine mobile Kooperationsumgebung. Bei der Arbeit in virtuellen

Wissensr¨

aumen besitzen die Beteiligten eine gemeinsame Sicht auf die Kooperati-

onsdaten. ¨

Anderungen an einzelnen Objekten in dieser Umgebung sind somit f¨

ur alle

Benutzer gleichzeitig wahrnehmbar. In Client-Server-Umgebungen werden ¨

Anderun-

gen an einem Objekt durch einen Client an den Server angewiesen, der diese ausf¨

uhrt

und im Anschluss alle anderen beteiligten Clients ¨

uber die ¨

Anderungen informiert.

Die Clients erneuern daraufhin ihre Darstellung der gemeinsamen Sicht, um den

aktuellen Stand der Kooperationsobjekte zu repr¨

asentieren. Die zentrale Position

des Servers in dieser Architektur bef¨

ahigt diesen, die Konsistenz der ¨

Anderungen an

den manipulierten Objekten zu ¨

uberpr¨

ufen und so Konflikte bei zeitgleichen ¨

Ande-

rungsanforderungen zu l¨

osen – also nur eine ¨

Anderung nach der anderen zuzulassen.

In einer in mobil-verteilten Kollaborationsszenarien vorherrschenden Peer-to-Peer-

Architektur ist ein st¨

andiger Abgleich der Datenbest¨

ande zwischen den einzelnen

Peers unvermeidlich.

Synchronizit¨

at Eine Gef¨

ahrdung der Konsistenz muss demnach durch ein Auf-

rechterhalten der Synchronizit¨

at der Datenbest¨

ande innerhalb des verteilten Kolla-

borationssystems vermieden werden. Die Synchronizit¨

at ist wesentliches Indiz f¨

die Benutzbarkeit des Kooperationssystems. Um diese zu Gew¨

ahrleisten, muss der

Abgleich verteilter Datenbest¨

ande automatisch und im Hintergrund geschehen. Die-

se nebenl¨

aufige Synchronisierung entlastet den Benutzer von derartigen Aufgaben.

Dennoch muss der Benutzer im Konfliktfall eingreifen und die Inkonsistenzen kom-

fortabel beseitigen k¨

onnen. Im Fall einer besch¨

adigten Konsistenz des Datenbestan-

des ist es daher wichtig, auf die letzte korrekte Version zugreifen zu k¨

onnen. Diesem

Aspekt wird mit der Forderung nach Reversibilit¨

at Rechnung getragen. Dazu geh¨

ort

Mobilit¨

at in der kooperativen Wissensarbeit

3.3.3 Konsistenz und Reversibilit¨

at 69

auch die M¨

oglichkeit, die ¨

Anderungen, die die Konsistenz verursacht haben, in den

konsistenten Datenbestand einzuarbeiten.

Die in Szenario 1.3 und Szenario 1.5 geforderte Synchronisierung von Objekten in

der verteilten Kooperationsumgebung entspricht einem wesentlichen Teil der Anfor-

derung der Synchronizit¨

at im Bereich mobiler Kooperationsumgebungen. Um den

Benutzer m¨

oglichst wenig zu belasten, muss die Synchronizit¨

at, wie in Szenario 3.3

ersichtlich, m¨

oglichst als Hintergrundprozess erfolgen. Der Abgleich muss dabei nicht

nur die physische Konsistenz der Kooperationsdaten ¨

uberwachen und aufzeigen (Sze-

nario 4.3), sondern auch soweit m¨

oglich die semantische Konsistenz aufrechterhalten

helfen (Szenario 4.4).

Wo nicht anders m¨

oglich, kann der Abgleich zwischen den Datenbest¨

anden auch

asynchron (z. B. per E-Mail) erfolgen, falls ein direkter und zeitnaher Abgleich nicht

m¨

oglich ist (Szenario 3.3). Wichtig ist jedoch, dass die Synchronisierung der Ko-

operationsobjekte die Gruppenstruktur unterhalb der Kooperationspartner ber¨

uck-

sichtigt (Szenario 3.3) und den Benutzern erlaubt, sowohl eine eigene, als auch eine

verteilte Kopie desselben Objektes zu verwalten (Szenario 1.6).

Die Strategie eines st¨

andigen Abgleichs der verteilten Datenbest¨

ande zur Erf¨

ullung

der Anforderung der Synchronizit¨

at ist ein probates Mittel zur Aufrechterhaltung

der Konsistenz innerhalb des Kollaborationssystems. Sie setzt allerdings voraus, dass

alle beteiligten Knoten des Verbundes st¨

andig miteinander in Kontakt stehen – ei-

ne Voraussetzung die insbesondere in mobilen Nutzungsszenarien oft nicht erf¨

ullt

werden kann. Jenseits der technisch bedingten L¨

ucken innerhalb der Netzwerkkom-

munikation verlassen Benutzer h¨

aufig f¨

ur einen l¨

angeren Zeitraum den Verbund und

Arbeiten isoliert oder in einer Teilgruppe weiter auf den Kooperationsdaten. Diese

Tatsache macht eine st¨

andige Koordinierung von konkurrierenden ¨

Anderungen un-

m¨

oglich. Ein Sperren von Objekten f¨

ur die Bearbeitung, wie es beim Pessimistic

Locking der Fall ist, ist aus mehreren Gr¨

unden in einer solchen Umgebung nicht

empfehlenswert:

•Die Zeitr¨

aume der Sperrung k¨

onnen aufgrund von Verbindungsabbr¨

uchen (bis

zu n¨

achsten Sychronisierung) sehr lange dauern und machen die gesperrten

Objekte f¨

ur alle anderen Benutzer unbrauchbar.

•Wie die ¨

Anderung selbst, muss die Sperranforderung an alle Repliken ¨

uber-

mittelt werden.

•Die Sperrung ist oft nicht vorhersagbar und erfolgt zuweilen erst wenn die

Verbindung zu den anderen Repliken bereits unterbrochen ist.

Da ein vorgreifendes Sperren der gemeinsam genutzten Objekte aus diesen Gr¨

un-

den nicht m¨

oglich ist, empfiehlt sich der Einsatz von so genannten optimistischen

Sperren (Optimistic Locking) [Kung und Robinson, 1981]. Optimistische Sperren

beruhen auf der Annahme, dass konkurrierende ¨

Anderungen an einem Objekt eher

selten vorkommen. Daher wird ein Konflikt nicht bereits im Vorfeld durch ein Sper-

ren f¨

ur den Fall einer ¨

Anderung verhindert, sondern erst dann eingegriffen, wenn ein

Mobilit¨

at in der kooperativen Wissensarbeit

70 3.3 Neue Qualit¨

aten mobiler Kollaboration

Konflikt zwischen zwei unterschiedlichen Versionen desselben Objektes entstanden

ist. Im Fall eines solchen Konflikts wird das Objekt f¨

ur weitere ¨

Anderungen gesperrt

und die beteiligten Systeme (bzw. deren Benutzer) aufgefordert, den Konflikt zu

l¨

osen.

An diesem Punkt des Kooperationsprozesses k¨

onnen aufgrund langfristig unver-

bundenen Arbeitens bereits große Teile des Inhalts eines Kooperationsobjektes von-

einander abweichen. Anders als bei Versionskontrollsystemen f¨

ur die Softwareent-

wicklung k¨

onnen diese Abweichungen bei nat¨

urlichsprachlichen Texten nicht auto-

matisch gel¨

ost werden. Die Benutzer werden daher im Falle eines Versionskonfliktes

vom Kooperationssystem bei dessen L¨

osung nicht unterst¨

utzt.

Weiterhin kann ein automatisches Zusammenf¨

uhren der Dateien zu semantischen

Konflikten f¨

uhren oder das Ergebnis unvertr¨

aglich zu weiteren ¨

Anderungen Dritter

sein, was weitere noch gr¨

oßere Versionskonflikte zur Folge h¨

atte. Daher ist es wichtig,

jeden Schritt der Bearbeitung reversibel zu machen, um sp¨

atere Konflikte besser

l¨

osen zu k¨

onnen.

Reversibilit¨

at Die Synchronizit¨

at der Kooperationsobjekte ist die zentrale Anfor-

derung f¨

ur die Konsistenz einer verteilten Kooperationsumgebung. Da eine st¨

andige

Verbindung zwischen den Kooperationspartnern nicht garantiert ist, kann ein von

der Gruppe isoliertes Arbeiten der Teilnehmer die Regel werden. Daher bedarf es

der M¨

oglichkeit bei Verletzung der Konsistenz der Kooperationsobjekte den Scha-

den r¨

uckg¨

angig machen zu k¨

onnen. Falls m¨

oglich k¨

onnen die vorgenommenen ¨

An-

derungen nach und nach in Abstimmung mit den Kooperationspartnern zu einer

konsistenten Version des Kooperationsobjektes zusammengef¨

ugt werden.

Zu diesem Zweck gilt es, die Reversibilit¨

at der Manipulationen an den Kooperati-

onsobjekten sicherzustellen. Dies betrifft zum einen die Versionierung, die beil¨

aufig

alle ¨

Anderungen an einem Objekt protokolliert, Konflikte zwischen redundant ge-

speicherten und zeitgleich bearbeiteten Objekten erkennt und erlaubt, diese ¨

Ande-

rungen bei Bedarf r¨

uckg¨

angig zu machen. Zum anderen betrifft dies aber auch die

bewusste Archivierung von Kooperationsobjekten f¨

ur sp¨

atere Kooperationssitzun-

gen.

Szenario 1.5, Szenario 1.6 und Szenario 3.2 verdeutlichen die zentrale Rolle, die

der Versionierung der Kooperationsobjekte im Fall des unverbundenen Arbeitens

mit gemeinsamen Objekten zukommt. Die Versionierung hilft hier die Konflikte bei

konkurrierender Bearbeitung eines redundant verteilten Objektes aufzudecken und

zu l¨

osen. Manchmal ist das Erstellen konkurrierender Versionen aber auch, wie in

Szenario 2.5 beschrieben, ein gewollter Prozess, der ebenfalls mittels Versionierung

unterst¨

utzt werden kann.

Die Funktionen zum kooperativen Bewerten und Zusammenf¨

uhren konkurrieren-

der Dokumentversionen sind daher ebenfalls Bestandteil der Anforderung Versio-

nierung. Wie wichtig diese Funktionen f¨

ur den verteilten kooperativen Prozess sind,

heben Szenario 2.5, Szenario 3.2 und Szenario 4.3 hervor.

Mobilit¨

at in der kooperativen Wissensarbeit

3.3.3 Konsistenz und Reversibilit¨

at 71

Reversibilt¨

at beinhaltet aber nicht nur den Einsatz einer Versionskontrolle im lau-

fenden Kooperationsprozess, um die Konsistenz der Kooperationsobjekte bei kon-

kurrierender Bearbeitung zu wahren, sondern auch Archivierung der Kooperations-

ergebnisse f¨

ur einen sp¨

ateren Zugriff auf diese. W¨

ahrend Client-Server-Systeme zu

diesem Zweck die Objekte persistent in einer Datenbank oder ¨

Ahnlichem ablegen,

ist dies in einer mobilen Kooperationsumgebung nicht unbedingt m¨

oglich, da die

Ressourcen der mobilen Rechner weit hinter denen von zentralen Servern liegen.

Da mehrere Kooperationspartner Interesse an einem solchen Archiv haben k¨

onnten,

muss es wiederum redundant gehalten werden.

Archivieren bedeutet in diesem Zusammenhang, dass ein Archiv angelegt wird,

nachdem die eigentliche Kooperation abgeschlossen ist. Daher m¨

ussen Archive nicht

synchronisiert, sondern lediglich f¨

ur jeden interessierten Teilnehmer separat gespei-

chert werden. Demnach erscheint es nicht immer sinnvoll, diese Archive in dem per-

sistenten und stark replizierten Datenspeicher der mobilen Kooperationsumgebung

zu halten. Zum einen w¨

urden dadurch unn¨

otig Ressourcen der Kooperationsumge-

bung f¨

ur die Synchronisation der Archive verbraucht. Zum anderen w¨

urden nach-

tr¨

agliche, nicht l¨

anger im Rahmen einer Kooperation get¨

atigte ¨

Anderungen weiterhin

an alle Teilnehmer weitergereicht, obwohl diese eventuell keinerlei Interesse mehr an

den ¨

Anderungen haben und lieber das urspr¨

ungliche Kooperationsergebnis f¨

ur eine

sp¨

atere Weiterverwendung nutzen wollen.

Damit das Archiv als Basis einer neuerlichen Kooperationssitzung dienen kann

muss die vollst¨

andige Konfiguration als Momentaufnahme der Kooperationsumge-

bung inklusive der Informationen ¨

uber Dokumenten- und Gruppenstruktur enthalten

(Szenario 1.7, Szenario 1.9). Dazu geh¨

oren auch die Metadaten aller Kooperations-

objekte als wichtiger Bestandteil der Kooperationsergebnisse (Szenario 4.5). Die ar-

chivierten Momentaufnahmen einer Konfiguration k¨

onnen an Dritte (Szenario 1.9)

ubermittelt oder in eine zentralisierte CSCW-Umgebung eingef¨

ugt werden, um eine

langzeitige Verf¨

ugbarkeit sicherzustellen (Szenario 1.9, Szenario 4.6). F¨

ur den Schutz

sensibler Daten besteht bei einer Weitergabe des Archivs an Dritte die Notwendig-

keit, gewisse Informationen aus einem Archiv zu entfernen (z. B. Gruppenstruktur).

Soll eine Wiederaufnahme einer Kooperation anhand eines Archivs gew¨

ahrleistet

werden, muss das Kooperationssystem in der Lage sein, den letzten Zustand der

archivierten Kooperation vollst¨

andig wieder herzustellen. Da die ¨

außeren Umst¨

ande

(verf¨

ugbare Kooperationspartner, technische Infrastruktur) sich bis zur Wiederauf-

nahme ¨

andern k¨

onnen, muss zudem bei der Zustandswiederherstellung flexibel auf

externe Fehlerquellen und ¨

Anderungen der Konfiguration reagiert werden k¨

onnen.

(Szenario 4.5).

In einem offenen Netzwerkumfeld, wie es in mobil-verteilten Kooperationsszenari-

en Anwendung findet, der Einbindung externer Dienste und fremder Kooperations-

umgebungen eine zentrale Bedeutung zu. Die daraus resultierenden Anforderungen

an die mobil-verteilte Kooperationsumgebung werden unter dem Begriff der Offenen

Architektur zusammengefasst.

Mobilit¨

at in der kooperativen Wissensarbeit

72 3.3 Neue Qualit¨

aten mobiler Kollaboration

Offene Architektur Eine offene Architektur und frei zug¨

angliche Schnittstellen

bilden die Voraussetzungen f¨

ur eine flexible Einbettung eines Softwaresystems in eine

heterogene Infrastruktur, wie man sie in mobil-verteilten Nutzungsszenarien vorfin-

det. Der Austausch mit Drittanwendungen gew¨

ahrleistet, dass die Kooperationsum-

gebung nicht isoliert von der Netzwerkumgebung betrieben wird und Medienbr¨

uche

beim Austausch von Daten mit externen Anwendungen vermieden werden. Dar¨

uber

hinaus erlaubt eine offene Architektur den Benutzern, das System an ihre Bed¨

urfnis-

se anzupassen, indem sie dieses mit eigenen Komponenten anreichern und funktional

erweitern. Dies schließt die Einbindung externer Dienste mit ein (Szenario 4.4).

Eine solche offene Architektur darf aufgrund der geforderten Flexibilit¨

at nicht

monolithisch aufgebaut sein. Sie muss modular aus austauschbaren Komponenten

bestehen, die ¨

uber wohldefinierte Schnittstellen kommunizieren. Nur so kann die

Funktionalit¨

at des Systems ver¨

andert werden, ohne tief in die Gesamtarchitektur

einzugreifen. Besonders in Hinsicht auf die Nachhaltigkeit von Kooperationssyste-

men ist die Modularit¨

at und eine offene Architektur eine unverzichtbare Eigenschaft.

Diese erlaubt es auch Dritten, die Systeme kontinuierlich an ihre Anforderungen an-

zupassen und so eine fortw¨

ahrende Nutzung zu gew¨

ahrleisten.

Diese Forderungen werden durch die Unf¨

ahigkeit monolithischer und zentralisier-

ter CSCW-Umgebungen, sich an die Mobilit¨

at der Benutzer anzupassen, noch unter-

strichen. Aufgrund einer oft monolithischen Architektur sind sie schwer an die Gege-

benheiten eines mobilen Einsatzgebietes anzupassen. Dieses Problem wird durch die

Abh¨

angigkeit von einer zentralisierten Persistenz zus¨

atzlich verst¨

arkt. Da die Eig-

nung der bestehenden CSCW-Architekturen f¨

ur mobile Szenarien somit nicht ohne

weiteres hergestellt werden kann, ist f¨

ur einen nahtlosen ¨

Ubergang zwischen mobilen

und zentralisierten CSCW-Systemen die Bereitstellung entsprechender Schnittstellen

essenziell. In Szenario 4.2 wird die Anforderung einer Kombination von zentralisier-

ter und mobiler CSCW-Topologie verdeutlicht.

M¨

ochten Benutzer einer zentral verwalteten Kooperationsumgebung ihre Koope-

rationsobjekte mitnehmen, um diese mobil weiterverarbeiten zu k¨

onnen, ist eine

Ubernahme der Kooperationsdaten von einem CSCW-Server in die mobile CSCW-

Umgebung ¨

außerst n¨

utzlich. Auf dem umgekehrten Weg bietet der Import von

Kooperationsobjekten aus einer mobilen CSCW-Umgebung in ein serverbasiertes

CSCW-System eine zentrale wie verl¨

assliche Anlaufstelle f¨

ur die Kooperationspart-

ner und garantiert eine langfristige Verf¨

ugbarkeit der Kollaborationsdaten. Auch die

zus¨

atzlichen M¨

oglichkeiten eines in eine Diensteinfrastruktur eingebundenen CSCW-

Servers machen einen nahtlosen ¨

Ubergang von verl¨

asslichen zentralisierten Architek-

turen zu flexiblen mobil-verteilten Architekturen attraktiv (Szenario 2.6, Szenario

2.7).

Die Forderung nach Offenheit in mobil-verteilten Kooperationssystemen liegt so-

mit in mehreren Faktoren:

•Der evolution¨

are ¨

Ubergang von monolithischen, zentralisierten Kooperations-

systemen zu modularen, mobil-verteilten Kooperationssystemen zur besseren

Mobilit¨

at in der kooperativen Wissensarbeit

Unterst¨

utzung der Mobilit¨

at der Benutzer ohne einen Bruch in deren Koope-

rationsumgebungen,

•die nahtlose Integration externer Dienste in die Kooperationsumgebung und

•der nahtlose Transport von Objekten zwischen den Kooperationssystemen.

Das Erf¨

ullen der Forderung nach einer Offenen Architektur erlaubt dem Kolla-

borationssystem somit eine externe Konsistenz, die dem Benutzer die nahtlose Nut-

zung externer Dienste ohne Medienbr¨

uche erm¨

oglicht. Die vorgestellten Bereiche

der Vernetzung und Sichtbarkeit, der Kontextualisierung und der Konsistenz und

Reversibilit¨

at bilden die zentralen Anforderungen f¨

ur ein mobil-verteiltes Koopera-

tionssystem.

Der folgende Abschnitt behandelt darauf aufbauend die grundlegenden techni-

schen Anforderungen an ein Kooperationssystem und betrachtet diese im Span-

nungsfeld der Mobilit¨

at. Die mobil-spontane Zusammenarbeit baut im besonderen

Maße auf Funktionen aus den klassischen Bereichen der Kommunikation, Koordina-

tion und Kooperation auf, die allerdings einer Anpassung an die Gegebenheiten der

mobilen Nutzung bed¨

urfen.

3.4 Neue Rahmenbedingungen computergest¨

utzter

Kooperationsdienste

Anforderungen

Kontextualisierung

Kommunikation

Konsistenz

Koordination Kooperation

Kollaboration

Vernetzung

Vernetz

ung

Kommunikation

Vernetz

ung

Koordination Vernetz

ung

Kooperation

Vernetz

ung

Kollaboration

Die Zusammenarbeit im mobilen Nutzungsumfeld bedarf einer ¨

ahnlichen technischen

Unterst¨

utzung der Kommunikations- und Koordinationsprozesse wie die klassische

Kooperation in zentralisierten CSCW-Architekturen. Im Spannungsfeld mobil-spon-

taner Kooperation werden jedoch angepasste und weitergehende Mechanismen be-

n¨

otigt, um eine nahtlose Nutzung der Kooperationsumgebung zu gew¨

ahrleisten.

F¨

ur eine Unterscheidung zur klassischen Kooperation in zentralisierten CSCW-

Systemen wird an dieser Stelle der Begriff der Kollaboration eingef¨

uhrt. Zwar ist der

Begriff Kollaboration im Deutschen mit einer milit¨

arischen Bedeutung belegt1, wird

aber im englischen Sprachraum synonym f¨

ur den Begriff der Kooperation verwendet.

”Kollaboration [. . . ]: aktive Unterst¨

utzung einer feindlichen Besatzungsmacht gegen die eigenen

Landsleute“, aus: DUDEN-Fremdw¨

orterbuch, Bd. 5, Mannheim 1997.

Mobilit¨

at in der kooperativen Wissensarbeit

74 3.4 Neue Rahmenbedingungen

Im Folgenden wird der Begriff der Kollaboration verwendet, um die spontanen und

dynamischen Qualit¨

aten der Zusammenarbeit in einem mobil-verteilten Nutzungs-

umfeld zu betonen und von denen klassischer Kooperationssysteme abzugrenzen. Er

wird daher mit folgender Bedeutung belegt:

Kollaboration ist die spontane oder geplante Zusammenarbeit zwischen zwei oder

mehr Personen, die aufbauend auf technischen Unterst¨

utzungsfunktionen zur Kom-

munikation, Koordination und Kooperation geschieht. Diese Interaktion findet zwi-

schen vernetzten Partnern in virtuellen und realen R¨

aumen basierend auf Koope-

rationsobjekten (Dokumenten) statt. Die Kollaboration ist dabei durch einen stark

spontanen und dynamischen Charakter gepr¨

agt.

Kollaboration wird in diesem Sinne als interaktiver Prozess betrachtet, den es

durch die Kooperationsumgebung zu unterst¨

utzen gilt. Dabei muss Kollaboration

nicht zielgerichtet sein oder einem bestimmten Zweck dienen – der spontane Cha-

rakter der Zusammenarbeit in mobilen Nutzungsszenarien kann die Zusammenarbeit

zwischen den Benutzern sogar zu einem nebenl¨

aufigen Prozess machen, der den ei-

gentlichen Zweck eines Treffens flankiert.

Dabei bilden Kommunikation,Koordination und Kooperation die Grundlage des

Kollaborationsprozesses, die durch entsprechende Werkzeuge und Protokolle gew¨

ahr-

leistet werden muss. Anders als bei dem 3K-Modell [Teufel et al., 1995] werden

Kommunikation, Koordinierung und Kooperation als ein hierarchisches Technikmo-

dell betrachtet, in dem jede Ebene die Grundlage f¨

ur die ihr jeweils ¨

ubergeordnete

bildet (siehe Abbildung 3.5). Die Kommunikation ist somit die Basis f¨

ur die Koor-

dinierungsprozesse, auf die wiederum viele Kooperationsfunktionen aufsetzen. Mit

Hilfe der Kooperationsfunktionen findet in der obersten Ebene der Kollaboration die

Unterst¨

utzung einer spontanen und dynamischen Zusammenarbeit in einer mobil-

verteilten Kooperationsumgebung statt. Jede Ebene greift dabei auf alle unterge-

ordneten Ebenen zu.

Viele der aus Kapitel 2 hervorgehenden Anforderungen an die mobil-verteilte Ko-

operationsumgebung lassen sich entlang der technischen Unterst¨

utzung von Kom-

munikation, Koordination und Kooperation anordnen. Diese gilt es somit an die neu-

en Anforderungen einer mobil-verteilten Architektur anzupassen. Darauf aufbauend

wird dem beil¨

aufigen und spontan-dynamischen Charakter der Kollaboration in der

Ebene der Kollaborationsunterst¨

utzung gezielt Rechnung getragen.

Die im Folgenden betrachteten technischen Grundfunktionalit¨

aten f¨

ur die Kol-

laboration im mobilen Nutzungsumfeld legen somit die Basis f¨

ur eine Nutzung der

mobil-verteilten Kooperationsumgebung. W¨

ahrend die in Abschnitt 3.3 vorgestellten

Anforderungen aus der neuartigen Nutzung von Kooperationsumgebungen im mo-

bilen Umfeld abgeleitet sind (Handlungsebene), handelt es sich in diesem Abschnitt

um Mechanismen, die den Benutzern zumeist verborgen bleiben, aber dennoch die

Basistechnologie f¨

ur die Nutzung einer Kooperationsumgebung in mobilen Szenari-

en bilden (Umsetzungsebene). Eine scharfe Trennung zwischen Anforderungen auf

Handlungsebene und Umsetzungsebene gelingt nicht in allen Aspekten der Anforde-

rungsbestimmung, sie bildet aber dennoch einen geeigneten Ansatz, um technikbe-

Mobilit¨

at in der kooperativen Wissensarbeit

3.4.1 Kommunikation 75

Kollaboration

Kooperation

Koordination

Kommunikation

Abbildung 3.5: Kollaboration baut auf die Ebenen der Kommunikation, Koordi-

nierung und Kooperation auf [vgl. Eßmann und Hampel, 2005a].

dingte Anforderungen von denen zu trennen, die der mobilen Nutzung von Koope-

rationssystemen geschuldet sind.

Als Beispiel wird mit der Forderung der Versionierung der Kooperationsobjekte

aus technischer Sicht eine wichtige Anforderung an das System gestellt, um Kon-

flikte zwischen redundant gespeicherten Objekten aufzudecken. Gleichzeitig stellt

sie aber aus Sicht der mobilen Nutzung einen wichtigen Mechanismus f¨

ur die ko-

operative Bearbeitung von Dokumenten ohne Wahrnehmung der Handlungen der

Kooperationspartner dar. Im Gegensatz dazu ist die Technologie zur spontanen Ver-

netzung z. B. eine rein technische Anforderung, die aufgrund ihres spontanen und

dynamischen Charakters die Anforderungen an die Kommunikation innerhalb der

Kooperationsumgebung mitpr¨

agt.

Die technischen Rahmenbedingungen eines mobilen Nutzungsumfelds stellen so-

mit gewisse Anforderungen an eine mobil-verteilte Kooperationsumgebung. Im Fol-

genden werden die beschriebenen Szenarien bez¨

uglich ihrer besonderen Bed¨

urfnisse

an diese technische Infrastruktur analysiert.

3.4.1 Kommunikation

Kommunikation bildet die Grundlage jeder Zusammenarbeit. Erst durch eine sta-

bile Kommunikationsinfrastruktur zwischen den Kooperationspartnern, bzw. deren

Ger¨

aten, ist eine Kooperationsunterst¨

utzung ¨

uberhaupt m¨

oglich. In synchronen Ko-

operationsformen muss diese Kommunikation nicht nur verl¨

asslich sondern auch hin-

reichend schnell erfolgen. Zus¨

atzlich besteht bei einer Zusammenarbeit in spontanen

Mobilit¨

at in der kooperativen Wissensarbeit

76 3.4 Neue Rahmenbedingungen

Zusammenk¨

unften h¨

aufig der Wunsch nach einem sofortigen Einstieg in die Koope-

ration, ohne zuvor die genutzten Hilfsmittel konfigurieren zu m¨

ussen. Der Konfigu-

rationsaufwand w¨

urde hier den Nutzen einer computergest¨

utzten Kooperationsum-

gebung ¨

ubersteigen und somit unter Umst¨

anden zu einem Nutzungsverzicht seitens

der mobilen Benutzer f¨

uhren. Ein Ausweichen auf alternative Hilfsmittel (z. B. Zettel

und Stift) h¨

atte bei einer sp¨

ateren R¨

uckkehr in die computergest¨

utzte Kooperations-

umgebung einen Medienbruch zur Folge, da die Kooperationsergebnisse erst wieder

in diese ¨

ubertragen werden m¨

ussten.

Die grundlegenden Techniken f¨

ur die Kommunikation in der Kooperationsumge-

bung m¨

ussen daher mobil-spontanen Kooperationsszenarien gewachsen sein und oh-

ne Eingreifen der Benutzer die mobilen Ger¨

ate ad hoc vernetzen. Diese automatische

Etablierung von Kommunikationsstrukturen schließt dabei auch eine Verkn¨

upfung

der bereitgestellten Dienste ein, die die h¨

oheren Ebenen der Kooperationsunterst¨

ut-

zung bereitstellen.

Vernetzung

Der Vernetzung kommt als Basistechnologie f¨

ur die Kommunikation zwischen den

beteiligten Computern eine zentrale Rolle bei der Etablierung einer verteilten Koope-

rationsumgebung zu. Aufbauend auf die durch das Netzwerk zur Verf¨

ugung gestellte

Infrastruktur verbinden sich die von den Ger¨

aten der Teilnehmer bereitgestellten

Dienste zu der verteilten Kooperationsumgebung. Verteilte Anwendungen nutzen

f¨

ur die Kommunikation zwischen den Diensten oftmals Protokolle in der Anwen-

dungsschicht, welche ihrerseits die tiefer gelegenen Netzwerkprotokolle als Trans-

portschicht nutzen. Wichtig ist, dass die Protokolle in jeder Schicht dem besonderen

Charakter des mobil-verteilten Nutzungsumfeldes gerecht werden.

Spontane Vernetzung F¨

ur einen h¨

urdenlosen Einstieg in die Kooperationsum-

gebung muss die zugrunde liegende Netzwerk-Infrastruktur schnell und ohne Be-

nutzereingriff etabliert werden k¨

onnen. Diese Anforderung wird unter dem Begriff

der ”Spontanen Vernetzung“ zusammengefasst. Szenario 2.1 verdeutlicht zentrale

Aspekte der spontanen Vernetzung im Rahmen einer mobil-verteilten Kooperation.

Prim¨

ar beinhalten die Anforderungen der spontanen Vernetzung die Fragestellung

nach einer transparenten Vernetzung und sofortigen Verf¨

ugbarkeit der Kooperati-

onsumgebung aus Sicht der Benutzer (Szenario 1.6, Szenario 2.1). Daher muss diese

Infrastruktur bei einem Zusammentreffen von Kooperationspartnern ad hoc und oh-

ne deren Eingreifen gebildet werden. In Umgebungen, in denen nicht auf bestehende

Netzwerkstrukturen zur¨

uckgegriffen werden kann, bedeutet dies, diese selbstst¨

andig

zu errichten und die Instanzen der verteilten Anwendung mittels der anwendungs-

spezifischen Protokollschicht zu koppeln.

Sollten bereits existierende Netzwerkinfrastrukturen verf¨

ugbar sein, hat die Ko-

operationsumgebung die M¨

oglichkeit, diese f¨

ur die Vernetzung der verteilten An-

wendung zu nutzen. Allerdings sind etablierte Netzwerkinfrastrukturen oft nur f¨

beschr¨

ankte Nutzerkreise verf¨

ugbar (z. B. Kunden eines Netzbetreibers) und schlie-

Mobilit¨

at in der kooperativen Wissensarbeit

3.4.1 Kommunikation 77

ßen somit einige potentielle Partner von der Teilnahme an der Kooperation aus. Ein

weiteres Problem der Nutzung solcher zentral administrierten Netzwerkinfrastruk-

turen f¨

ur eine flexible Zusammenarbeit ist die Reglementierung der in dem Netzwerk

nutzbaren Dienste ¨

uber das Blockieren der seitens des Betreibers nicht erw¨

unschten

Kommunikationsprotokolle.

Derartige Einschr¨

ankungen lassen auch hier autarke Netzwerkinfrastrukturen zwi-

schen den Kooperationsteilnehmern sinnvoll erscheinen. Diese k¨

onnen bei bestehen-

der M¨

oglichkeit existierende Netzwerkstrukturen wie in Szenario 2.3 einbinden, um

in diesen verortete Dienste zu nutzen. In einem solchen Szenario treten Benutzer mit

Zugang zu dem restriktiven Netz als eine Art Mittelsm¨

anner auf, um den anderen

Teilnehmern Zugang zu diesem Netz zu gew¨

ahren.

Die spontane Etablierung der Kommunikation in einer Kooperationsumgebung ist

aber nicht auf Netzwerkstruktur und die Kopplung der verteilten Anwendung be-

schr¨

ankt. Gleichzeitig m¨

ussen die ben¨

otigten Kooperationsfunktionen eingerichtet

und zur Verf¨

ugung gestellt werden (Szenario 2.1). Dies ist insbesondere in verteilten

Umgebungen mit einem Aushandeln der Verteilung der ben¨

otigten Dienste verbun-

den.

Sind alle ben¨

otigten Dienste verf¨

ugbar, kann die Zusammenarbeit ¨

uber diese tech-

nische Infrastruktur erfolgen. Da die Benutzer sich nicht in einem starren Szenario

bewegen und keine festen Strukturen existieren, m¨

ussen auch die Strukturen der

Kooperationsumgebung spontan etabliert werden (Szenario 2.3). Erst dann k¨

onnen

die Kollaborationspartner miteinander kommunizieren und eine gemeinsame Sitzung

starten.

Robustheit Da weder Netzwerkstruktur, Diensteinfrastruktur noch die Koope-

rationsstruktur in mobilen Nutzungsszenarien als stabil betrachtet werden k¨

onnen,

muss die Kooperationsumgebung flexibel und robust auf ¨

Anderungen auf allen Ebe-

nen der Kooperation reagieren k¨

onnen. Dies liegt insbesondere an der Instabilit¨

at der

zugrunde liegenden Netzwerkverbindungen. Durch Bewegung der Benutzer kommt

es h¨

aufig und meist ohne Vorwarnung zu Verbindungsabbr¨

uchen zwischen den Kolla-

borationspartnern. Zudem geht in mobilen Szenarien kooperatives und individuelles

Arbeiten nahtlos ineinander ¨

uber. Um die Kollaborationsdaten auch in unverbun-

denen Situationen verf¨

ugbar zu haben und die Kooperationsumgebung nicht in be-

stimmten Nutzungskontexten unbrauchbar zu machen, muss ein Weiterarbeiten auch

f¨

ur von der Gruppe isolierte Kooperationspartner m¨

oglich sein (Szenario 3.2).

Aus den instabilen Netzwerkstrukturen in einer mobilen Umgebung leitet sich

auch die Forderung nach einer flexiblen Wahl der ¨

Ubermittlungsmethoden f¨

ur Daten

der Kooperationsumgebung ab (Szenario 3.2). Anders als in fest strukturierten und

zentral administrierten Netzwerken ist die Verbindungsqualit¨

at selten gleich bleibend

sondern variiert in der ¨

Ubermittlungskapazit¨

at. Dies hat zur Folge, dass eventuell

nicht alle Daten ¨

uber eine Netzwerkverbindung gesandt werden k¨

onnen.

Da die Erreichbarkeit einzelner Knoten in der Netzwerkumgebung nicht garan-

tiert werden kann, d¨

urfen essenzielle Dienste nicht nur von einer zentralen Stelle

Mobilit¨

at in der kooperativen Wissensarbeit

78 3.4 Neue Rahmenbedingungen

angeboten werden. Daraus ergibt sich die Forderung nach Unabh¨

angigkeit von zen-

tralisierten Diensten (Szenario 4.4). Als eine Daumenregel kann gesagt werden, dass

mit der Bedeutung eines Dienstes f¨

ur die Funktionsf¨

ahigkeit der Kooperationsum-

gebung dessen Verteilung im Netzwerk steigen muss. Auch unter dem Aspekt der

Robustheit m¨

ussen daher Dienste, ohne welche die Kooperationsumgebung nicht

mehr betriebsf¨

ahig ist, auf jedem Knoten vorhanden und aktivierbar sein. Nur so

kann der Knoten im unverbundenen Fall autark weiter betrieben werden.

Nachrichtensystem ¨

Uber die Protokolle der Netzwerkschicht tauschen die In-

stanzen der mobil-verteilten Kooperationsumgebung Nachrichten ¨

uber lokale und

netzweite Ereignisse aus, um sich untereinander abzugleichen und so die Zusam-

menarbeit der Benutzer zu erm¨

oglichen. Auch die Benutzer senden sich gegensei-

tig Nachrichten, um miteinander zu kommunizieren. Diese Nachrichten¨

ubermittlung

muss an den dynamischen Charakter der mobil-spontanen Nutzungsszenarien ange-

passt sein. Nachrichten k¨

onnen z. B. nicht wie in einem Client-Server-System zentral

hinterlegt werden. Eine direkte ¨

Ubermittlung an den Empf¨

anger ¨

uber eine Punkt-zu-

Punkt-Verbindung ist wegen einer weitl¨

aufigen und instabilen Vernetzung oder einer

zeitversetzten Zusammenarbeit auch nicht immer m¨

oglich. Dies gilt insbesondere f¨

Systemnachrichten ¨

uber Ereignisse in der Kooperationsumgebung. Daher muss so-

wohl das allgemeine Nachrichtensystem wie auch die Ereigniskontrolle innerhalb der

mobil-verteilten Kooperationsumgebungen dezentral und asynchron realisiert wer-

den, wie aus Szenario 1.2 und Szenario 1.3 ersichtlich.

Da aufgrund der Mobilit¨

at der Benutzer und der daraus resultierenden Dynamik

der Struktur in der Kooperationsumgebung, der Kreis der Adressaten f¨

ur die Nach-

richten anders als in statischen Kooperationsumgebungen meist nicht fest vorgege-

ben und durch den Kontext der Anwender innerhalb der Kooperationsumgebung

definiert ist (vgl. Abschnitt 3.3.2), m¨

ussen die Empf¨

anger w¨

ahrend des Nachrich-

tenversandes ermittelt werden. Dies gilt insbesondere f¨

ur Nachrichten an Benutzer-

gruppen, die in ad hoc gegr¨

undeten Kollaborationssitzungen nicht durch explizite

administrative Handlungen festgelegt werden. Daher ist es wichtig, einen flexiblen

Adressatenkreis f¨

ur s¨

amtliche Nachrichten in der Kooperationsumgebung zu unter-

st¨

utzen (Szenario 1.2).

Objekte/Medien

Kommunikation in virtuellen Wissensr¨

aumen findet ¨

ublicherweise ¨

uber die enthal-

tenen Medien statt [vgl. Keil-Slawik et al., 2005]. Textdokumente sind nur eine

m¨

ogliche Auspr¨

agung der mannigfaltigen Medientypen. Eine objektorientierte Be-

trachtungsweise l¨

asst eine einheitliche Behandlung aller Elemente innerhalb der Ko-

operationsumgebung zu und erlaubt einen einheitlichen Umgang mit allen zur Zu-

sammenarbeit ben¨

otigten Daten.

Dieser Abschnitt besch¨

aftigt sich mit der Verwaltung der Objekte innerhalb der

Kooperationsumgebung. Da die Objekte Grundlage des Kollaborationsprozesses sind,

ist es wie bei allen kritischen Diensten wichtig, die Verwaltung der Objekte ¨

uber die

Mobilit¨

at in der kooperativen Wissensarbeit

3.4.1 Kommunikation 79

beteiligten Knoten zu verteilen. Bis auf einige wenige Ausnahmen wird dieser grund-

legende Dienst auf nahezu allen Knoten laufen m¨

ussen, um die Offline-Verf¨

ugbarkeit

der Kooperationsumgebung zu garantieren. Dabei gilt es, sowohl den Dienst als auch

die von ihm verwalteten Objekte nach einem Muster zu verteilen, so dass eine opti-

male Verf¨

ugbarkeit der Kooperationsobjekte unter Ber¨

ucksichtigung der Netzwerk-

und Speicherressourcen der beteiligten Knoten gew¨

ahrleistet ist.

Distribution Um eine Verteilung der Objekte in der Kooperationsumgebung zu

erm¨

oglichen, m¨

ussen Objekte zwischen den Ger¨

aten der Kooperationspartner mi-

grieren k¨

onnen (Szenario 1.2). Damit das Objekt nach der Migration auf dem Ziel-

knoten denselben Zustand aufweist, den es auf dem Ursprungsknoten hatte, m¨

ussen

alle Eigenschaften des Objekts erhalten bleiben. Im Fall einer redundanten Speiche-

rung der Objekte innerhalb der Kooperationsumgebung, kann die Replikation der

Objekte als eine Migration ohne ein L¨

oschen des Objektes vom Ursprungsknoten be-

trachtet werden. Wichtig bei einer Replikation ist zus¨

atzlich, dass die Repliken des

Objektes miteinander gekoppelt bleiben und ¨

Anderungen an dem Objekt zwischen

diesen synchronisiert werden (siehe Abschnitt 3.3.3).

F¨

ur die effiziente Verbreitung von Objekten in verteilten Kooperationsumgebun-

gen, kann eine epidemische Distributionsstrategie gew¨

ahlt werden (Szenario 1.2). Ein

solches Distributionsmuster bezieht oft auch unbeteiligte Knoten ein, die nicht zu

den eigentlichen Zielknoten geh¨

oren. Sie speichern das Objekt zwischen und liefern

es bei Gelegenheit an die eigentlichen Zielknoten aus. Erreicht ein Objekt die Emp-

f¨

anger nicht, muss es nach festen Kriterien verworfen werden k¨

onnen, da es sonst

die zwischenspeichernden Knoten langfristig belastet.

Bei einer dokumentenzentrierten Zusammenarbeit in virtuellen Wissensr¨

aumen

nutzt eine Kollaborationsgruppe stets einen festen gemeinsamen Arbeitsbereich f¨

die Strukturierung ihrer Kooperationsobjekte. Die verteilte Speicherung dieses ge-

meinsamen Arbeitsbereiches in mobil-spontanen Kooperationsszenarien f¨

uhrt schnell

zu Problemen bei der Persistenz der Kollaborationsergebnisse. Trotz der Kurzlebig-

keit der Gruppenstrukturen in spontanen Kollaborationen darf sich der gemeinsame

Arbeitsbereich mit den Kooperationsergebnissen nicht einfach aufl¨

osen sobald sich

die Gruppe aufl¨

ost. Die in einer spontanen Kollaboration entstandenen Dokumente

m¨

ussen also persistent bleiben, damit auf die Kooperationsergebnisse sp¨

ater noch

einmal zur¨

uckgegriffen werden kann (Szenario 2.7).

Da sich die spontan entstandenen Kollaborationsgruppen nicht zwangsl¨

aufig in der

selben Konstellation wieder zusammenfinden oder die an der Kollaborationssitzung

beteiligten Benutzer die Ergebnisse eventuell individuell weiterbearbeiten wollen,

m¨

ussen die betroffenen Objekte auf die pers¨

onlichen Ger¨

ate aller Beteiligten separat

gespeichert werden (Szenario 2.6).

Eine weitere M¨

oglichkeit zur Erh¨

ohung der Verf¨

ugbarkeit der verteilt bearbeite-

ten Kooperationsobjekte ist die zus¨

atzliche Speicherung auf einem zentralen CSCW-

Server. Dieser bildet eine verl¨

assliche Instanz in der verteilten Umgebung, die eine

h¨

ohere Verf¨

ugbarkeit verspricht als mobile Knoten. Allerdings darf dieses Vorge-

Mobilit¨

at in der kooperativen Wissensarbeit

80 3.4 Neue Rahmenbedingungen

hen nicht zu einer erneuten Abh¨

angigkeit von zentralen Diensten f¨

uhren. Die Daten

sind daher w¨

ahrend des Kooperationsprozesses weiterhin redundant auf den mobi-

len Ger¨

aten vorzuhalten. Die M¨

oglichkeit einer derartigen Integration von zentralen

CSCW-Servern erlaubt zudem eine nahtlose Verkn¨

upfung verteilter und zentralisier-

ter Kooperationsumgebungen (Szenario 4.2).

Konsistenz Da die Kooperationsobjekte in dem Kooperationsnetzwerk unter Um-

st¨

anden auf mehrere Knoten repliziert werden, ist ein ¨

Uberwachen konkurrierender

Zugriffe auf die Objekte unerl¨

asslich, um deren Konsistenz zu wahren (Szenario 1.6).

Aufgrund der Tatsache, dass die Instanzen der Kooperationsumgebung in mobil-

verteilten Szenarien nicht st¨

andig vernetzt sind, k¨

onnen konkurrierende Zugriffe auf

ein Objekt eventuell erst zeitlich verz¨

ogert festgestellt werden. Bei der n¨

achsten Kon-

taktaufnahme der beteiligten Knoten m¨

ussen demnach die replizierten Instanzen

eines Objektes auf einen Konflikt ¨

uberpr¨

uft werden. Diese Problematik des konkur-

rierenden Zugriffs auf schwach gekoppelten Kooperationsobjekte aufgrund der nur

sporadisch verf¨

ugbaren Vernetzung, widmet sich eingehend der Abschnitt 3.3.3.

3.4.2 Koordination

Neben der technischen Unterst¨

utzung der Kommunikation ist die der Koordinati-

on der Teilnehmer in einem mobilen Nutzungsumfeld wichtiges Kriterium f¨

ur eine

gezielte Zusammenarbeit. Zu den Koordinationsmechanismen geh¨

oren insbesondere

Werkzeuge zur Abstimmung und Organisation der Kollaboration. Diese sind insofern

im mobilen Nutzungsumfeld wichtig als das den Benutzern, die eine mobil-verteilte

Kooperationsumgebung selbst verwalten m¨

ussen, eine Hilfestellung durch Dritte oft

nicht zur Verf¨

ugung steht.

Die Nutzung der mobil-verteilten Kooperationsumgebung findet im Gegensatz zu

klassischen CSCW-Systemen zumeist am selben Ort und zur gleichen Zeit statt. Die

Unterst¨

utzung einer einfachen Methode f¨

ur die Terminbestimmung von Pr¨

asenztref-

fen, wie in Szenario 1.4 dargestellt, geh¨

ort daher zu den zentralen Anforderungen

an mobilit¨

atsunterst¨

utzende Kooperationssysteme. Eine Einbettung dieser Abstim-

mungsmechanismen in die Kooperationsumgebung erlaubt dabei einen Bezug auf

bereits existierende Nutzerstrukturen und hilft Medienbr¨

uche durch ein Verlassen

der Arbeitsumgebung zu vermeiden. Dazu m¨

ussen die Koordinationsmechanismen

entlang des konzeptionellen Designs der Kooperationsumgebung implementiert wer-

den. Beispiele sind diesbez¨

uglich Gruppenkalender f¨

ur die Koordinierung der Zusam-

menarbeit in der Gruppe wie auch Pers¨

onliche Kalender f¨

ur individuelle Planungs-

prozesse in derselben Umgebung (Szenario 1.4). Der Zugriff auf die Gruppenkalender

muss an die Rechteverwaltung gekoppelt und auch im unverbundenen Fall gew¨

ahr-

leistet sein. Wegen der sporadischen Vernetzung der Kooperationsteilnehmer m¨

ussen

die Termine zwischen den Teilnehmern als Gruppennachrichten zwischen den diesen

epidemisch verteilt werden (Szenario 1.4). Dies garantiert eine schnelle Verteilung

der Termine an alle Teilnehmer (vgl. Abschnitt 3.4.1).

Mobilit¨

at in der kooperativen Wissensarbeit

3.4.2 Koordination 81

Neben der Terminabsprache f¨

ur geplante Kooperationssitzungen muss die Ver-

waltung der Gruppenstruktur an die Besonderheiten mobil-spontaner Kollaboration

angepasst sein. Im Folgenden werden gezielt Mechanismen besprochen, die f¨

ur die

Mobilit¨

at der Nutzer von essentieller Bedeutung sind. Generelle Aspekte der Grup-

penverwaltung, wie sie auch in zentralisierten CSCW-Systemen zu finden sind, sollen

in diesen Zusammenhang dabei nicht behandelt werden.

Koordination – Rollen und Rechte

Gruppenstrukturen bilden stets die Berechtigungen der Mitglieder an die der Gruppe

geh¨

orenden Ressourcen ab. Daher ist die Gruppenstruktur eng mit den Berechtigun-

gen der Benutzer innerhalb der Kooperationsumgebung verkn¨

upft. W¨

ahrend in den

meisten F¨

allen eine gruppenbasierte Verwaltung von Berechtigungen bez¨

uglich der

Kooperationsobjekte ausreichen mag, m¨

ussen die Berechtigungsmechanismen auch

komplizierte Berechtigungsstrukturen abbilden k¨

onnen. Dies erm¨

oglicht den Benut-

zern die Gestaltung einer an ihre Bed¨

urfnisse angepassten Arbeitsumgebung. Eine

granulare Rechteverwaltung (Szenario 1.3, Szenario 4.1) ist daher unabdingbar f¨

eine flexible und universelle Nutzung der Kooperationsumgebung, die sich den Be-

d¨

urfnissen der Benutzer anpasst.

Da die Kollaboration in mobil-verteilten Kooperationsumgebungen zuweilen in

einzelne Pr¨

asenzsitzungen aufgeteilt abl¨

auft, sollten auch Berechtigungen zeitlich an

die Dauer einer Sitzung gebunden werden k¨

onnen. Als Beispiel sei hier die Gastrolle

genannt (vgl. Abschnitt 3.3.2). Die Gastrolle ist gerade in spontanen Kooperations-

szenarien eine wichtige Voraussetzung f¨

ur eine einfache Einbindung externer Koope-

rationspartner, die nicht Teil der normalen Kooperationsgruppe sind (Szenario 1.7,

Szenario 1.8). Aus diesem Grund m¨

ussen die Mechanismen f¨

ur eine einfache Handha-

bung der Gastrolle bereits in die Grundkonzeption des Rechtesystems eingebunden

sein. Eine Ber¨

ucksichtigung der Rollen der Kooperationsmitglieder (von denen ein

Kooperationsmitglied mehrere gleichzeitig haben kann – einige davon eventuell zeit-

lich begrenzt) sollte neben einem benutzer- und gruppenzentrierten Rechtesystem

m¨

oglich sein (Szenario 4.2).

Die Zugriffskontrolle stellt eine verteilte Architektur vor besondere Herausforde-

rungen. Die Basismechanismen der mobil-verteilten Kooperationsumgebung m¨

us-

sen einen Zugriffsschutz auch ohne zentrale Sicherheitsinstanz gew¨

ahrleisten k¨

onnen

(Szenario 4.4). Besonders bei einer Verteilung der Objekte ¨

uber die Ger¨

ate aller be-

teiligten Benutzer ist sicherzustellen, dass die Objekte vor dem Zugriff durch nicht

autorisierte Benutzer gesch¨

utzt sind, auch wenn sie zeitweise – z. B. in Folge einer

epidemischen Verbreitung (vgl. Abschnitt 3.4.1) – auf deren Ger¨

aten gespeichert

werden (Szenario 1.2). Weil die Benutzer die Software der Kollaborationsanwen-

dung auf ihrem eigenen Ger¨

at manipulieren k¨

onnten, muss der Zugriffsschutz an

dem Objekt selber verankert sein und darf nicht von Zugriffskontrollmechanismen

der Anwendung abh¨

angen. Dies kann nur durch eine geeignete Verschl¨

usselung der

Kooperationsobjekte geschehen.

Mobilit¨

at in der kooperativen Wissensarbeit

82 3.4 Neue Rahmenbedingungen

Objekte k¨

onnen innerhalb der Kooperationsumgebung auch Ger¨

ate von fremden

Benutzern durchlaufen, daher ist die Sichtbarkeit der Objekte f¨

ur die Benutzer ab-

h¨

angig von dem Adressatenkreis zu gestalten. Dabei ist es m¨

oglich, dass der Kreis

der Adressaten zum Zeitpunkt der Versendung des Objektes noch nicht bekannt

ist und nur anhand eines Benutzerprofils benannt werden kann. Dies trifft z. B. bei

Rundschreiben wie Einladungen zu einer Kooperationssitzung zu. Die Sichtbarkeit

von Kooperationsobjekten muss deshalb auch in Abh¨

angigkeit von Benutzerprofilen

definiert werden k¨

onnen (Szenario 1.2).

Da sich Gruppenstrukturen in mobilen Kooperationssystemen durch eine hohe

Dynamik auszeichnen, ben¨

otigen die Initiatoren einer Kooperation effiziente Werk-

zeuge f¨

ur die Gruppenverwaltung. Um ein unkontrolliertes Wachstum der Gruppen

zu verhindern und daraus resultierende un¨

ubersichtliche Gruppenstrukturen zu ver-

meiden, m¨

ussen Kooperationsgruppen in ihrer Gr¨

oße beschr¨

ankt werden k¨

onnen.

Wartelisten erm¨

oglichen hier ein Nachr¨

ucken von neuen Kooperationspartnern, wenn

ein Gruppenmitglied wie in Szenario 1.7 die Kollaboration verl¨

asst. Die Gruppenad-

ministratoren m¨

ussen die M¨

oglichkeit besitzen, diese Wartelisten zu verwalten, um

den Prozess der Aufnahme neuer Benutzer in die Gruppe beeinflussen zu k¨

onnen.

F¨

ur eine flexible Erweiterung der Kooperationsgruppe ist in mobil-spontanen

Kollaborationsszenarien die Gastbenutzer-Rolle ein unverzichtbares Hilfsmittel. Sie

erlaubt Kooperationspartnern eine tempor¨

are Teilnahme an der Kollaborationssit-

zung, ohne diese gleich als vollwertiges Mitglied der Gruppe verwalten zu m¨

ussen

(Szenario 1.7, Szenario 1.8). Die Rolle des Gastbenutzers ist f¨

ur den Zeitraum der

aktuellen Kollaborationssitzung g¨

ultig und mit Einschr¨

ankungen bez¨

uglich der Zu-

griffsrechte auf die Objekte der Gruppe verbunden. In manchen Kooperationsszena-

rien ist es sinnvoll unterschiedliche Gastrollen vergeben zu k¨

onnen, wie z. B. Berater

oder Beobachter. Dazu muss die Gastrolle durch die Gruppenadministratoren frei

konfigurierbar sein und diese Konfiguration als Voreinstellung f¨

ur eine bestimmte

Gastrolle hinterlegt werden k¨

onnen.

F¨

ur die Verwaltung von Kooperationsgruppen in einer dynamisch vernetzten Ko-

operationsumgebung ist die netzweite Bekanntgabe einer Gruppe nach deren Gr¨

un-

dung eine wichtige Funktion, um potentielle Kooperationspartner auf die Gruppe

aufmerksam zu machen (Szenario 1.2). In mobil-verteilten Kooperationsumgebun-

gen fehlt zumeist ein zentrales Verzeichnis der verf¨

ugbaren Kooperationsgruppen, in

dem Kooperationswillige nachschlagen k¨

onnten. Eintr¨

age in einem solchen zentralen

Verzeichnis sind aufgrund der Dynamik der Gruppenstrukturen oft veraltet – eine

spontan gegr¨

undete Kooperationsgruppe existiert bereits nicht mehr oder es kann

keine Netzwerkverbindung mehr zu den Gruppenmitgliedern aufgebaut werden. Alle

Teilnehmer der Kooperationsumgebung m¨

ussen daher mittels geeigneter dezentraler

Dienste fortw¨

ahrend ¨

uber die verf¨

ugbaren Kollaborationsgruppen in ihrer Umgebung

informiert werden.

Mobil-spontane Kooperationen werden oftmals aus dem Kontext eines informellen

Zusammentreffens heraus ins Leben gerufen. Erst im Anschluss werden sie bei Be-

darf in l¨

angerfristige und formelle Kooperationsformen ¨

uberf¨

uhrt. Somit ist die M¨

og-

lichkeit zur Integration spontan etablierter Gruppen in langfristige und organisierte

Mobilit¨

at in der kooperativen Wissensarbeit

3.4.3 Kooperation 83

Gruppenstrukturen unverzichtbar (Szenario 2.7). Diese nachtr¨

agliche Integration er-

laubt es den Benutzern aus der spontanen Kollaboration heraus, erst nachtr¨

aglich

eine Entscheidung ¨

uber deren Organisationsform (kurzfristig, spontan oder langfris-

tig, organisiert) zu treffen. Die im Nachhinein gew¨

ahlte Gruppenstruktur muss somit

nicht der Struktur entsprechen, welche die Gruppe zu Beginn der Kollaboration auf-

wies.

Soll die Verf¨

ugbarkeit der Ressourcen einer Gruppe erh¨

oht werden, die in der

mobil-spontanen Kooperationsumgebung gegr¨

undet wurde, ist es sinnvoll, Teile der

mobil-verteilten Gruppenstruktur mit der eines zentralisierten CSCW-Systems zu

synchronisieren (Szenario 4.4). Dieses Vorgehen erlaubt den Nutzern der zentrali-

sierten CSCW-Umgebung außerdem, ihre zentral verwalteten Kooperationsgruppen

auch im mobilen Umfeld benutzen zu k¨

onnen. Eine solche M¨

oglichkeit verhindert

zudem einen Bruch bei der Nutzung einer mobil-verteilten und einer institutionellen

zentralisierten CSCW-Umgebung (vgl. Abschnitt 3.3.3).

3.4.3 Kooperation

Um kollaborative Prozesse in allen Facetten unterst¨

utzen zu k¨

onnen, muss die mobil-

verteilte Kooperationsumgebung technische Mechanismen f¨

ur die Gestaltung der

Kooperation bereitstellen. Kooperationsmechanismen bieten eine Unterst¨

utzung der

organisierten Zusammenarbeit, die ¨

uber die reine Koordination der Gruppe hin-

ausgeht. Sie regeln die Nutzung der gemeinsamen Ressourcen und helfen bei deren

Strukturierung. Da die Benutzer in einer mobil-verteilten Kollaborationssituation oft

autonom von bestehenden Infrastrukturen agieren, muss die Kollaboration selbstor-

ganisiert ablaufen. Neben der Verwaltung der Kooperation stellen sich aber aufgrund

des spontanen und verteilten Charakters der Kooperationsumgebung zus¨

atzlich An-

forderungen an das zugrunde liegende Objektmodell. Im Folgenden werden zun¨

achst

die Anforderungen an die Zugriffsmechanismen Gruppenverwaltung,Berechtigungen

und Zugriffsschutz vorgestellt. Daran ankn¨

upfend, werden die Anforderungen an das

Objektmodell mit Personalisierung und Objektbehandlung betrachtet.

Gruppen Schon im Abschnitt Koordination (3.4.2) wurde die Gruppenverwal-

tung als Mittel zur Koordinierung der Kollaborationspartner behandelt. In diesem

Abschnitt wird dar¨

uber hinausgehend die Bedeutung der Gruppenstruktur f¨

ur die

gezielte dokumentenzentrierte Arbeit betrachtet. Grundlage der Organisation einer

Kooperation ist die Schaffung einer Gruppenstruktur, ¨

uber die potentielle Partner

in die Kooperation eingebunden oder von ihr ausgeschlossen werden k¨

onnen. Diese

Gruppenstruktur muss den Anforderungen seitens der Mobilit¨

at der Kollaborati-

onspartner gen¨

ugen und auch komplexe Kooperationsstrukturen abbilden k¨

onnen

(vgl. Szenario 4.1). Das Gruppenkonzept muss sich dabei durch alle Bereiche der

mobil-verteilten Kooperationsumgebung ziehen und wie die Kooperationsobjekte

auch auf allen beteiligten Knoten durchgehend und konsistent verf¨

ugbar sein (vgl.

Abschnitt 3.3.3).

Mobilit¨

at in der kooperativen Wissensarbeit

84 3.4 Neue Rahmenbedingungen

Die Gruppen in einer mobil-verteilten Kooperationsumgebung m¨

ussen Mechanis-

men zum Schutz ihrer Ressourcen vor dem Zugriff Dritter besitzen. Diese Anforde-

rung ist umso wichtiger, da es keine ¨

ubergeordnete Instanz gibt (z. B. ein abgeschot-

tetes Serversystem), welche die Ressourcen einer Gruppe nach außen sch¨

utzt. Diese

Abgeschlossenheit der Gruppe nach außen ist ein wichtiger Aspekt f¨

ur das Vertrauen

der Benutzer in die Kooperationsumgebung (Szenario 2.2). Die zugrunde liegenden

Zugriffsmechanismen sind dabei an die Bed¨

urfnisse der gruppenbasierten Arbeit an-

zupassen und sollten eine Kooperation der Gruppenmitglieder untereinander nicht

behindern.

Die Unterst¨

utzung der Kooperationsprozesse in der Gruppe muss auch in die

strukturelle Konzeption der Kooperationsumgebung einfließen. Den Mitgliedern ei-

ner Gruppe muss ein gemeinsamer Arbeitsbereich zur Verf¨

ugung stehen, in dem die

Gruppe ihre gemeinsamen Objekte verwalten kann (Szenario 1.3). Die Zugriffsbe-

rechtigungen f¨

ur diesen Arbeitsbereich sind an die Struktur der Gruppe zu koppeln.

Um jedem Gruppenmitglied auch parallel ein individuelles Arbeiten zu erm¨

oglichen,

ben¨

otigt jeder Benutzer zus¨

atzlich einen eigenen pers¨

onlichen Arbeitsbereich. Dieser

muss sich in derselben Kooperationsumgebung wie der Arbeitsbereich der Gruppe

befinden, um einen nahtlosen Wechsel vom individuellen zum kooperativen Arbeiten

und um einen einfachen Transfer von Objekten von dem einen Arbeitsbereich in den

anderen zu erlauben (vgl. Szenario 1.5).

Objektbehandlung ¨

Ahnlich wie beim Zugriffsschutz muss die Verwaltung der

Kooperationsobjekte auf die verteilte Objektspeicherung ausgelegt werden. Beson-

ders die hohe Wahrscheinlichkeit kollidierender Objektversionen, bei deren verteil-

ten und redundanten Speicherung, pr¨

agt den Umgang mit Objekten innerhalb der

Kooperationsumgebung. So m¨

ussen die ¨

uber die Kooperationsumgebung verteilten

Repliken eines Objektes miteinander verkn¨

upft bleiben, um konkurrierende ¨

Ande-

rungen anderer Benutzer nachvollziehen zu k¨

onnen. Aus zwei Kopien eines Objektes,

die auf unterschiedlichen Knoten des Kooperationsnetzwerkes gespeichert sind und

dort konkurrierend bearbeitet werden, d¨

urfen nicht aufgrund der unterschiedlichen

Anderungen zwei separater Objekte resultieren – es sei denn, dies ist ausdr¨

ucklicher

Wunsch der Benutzer.

Um die Konsistenz von abweichenden Objektkopien wiederherstellen zu k¨

onnen,

m¨

ussen die Benutzer von den Differenzen zwischen abweichenden Versionen sobald

wie m¨

oglich in Kenntnis gesetzt werden. Im Idealfall geschieht dies durch eine syn-

chronisierte Sicht auf die gemeinsam genutzten Objekte. In diesem Fall werden die

Kopien bei jeder ¨

Anderung untereinander abgeglichen. Die Benutzer erfahren so

zeitnah von ¨

Anderungen seitens ihrer Kooperationspartner (vgl. Abschnitt 3.3.3).

Leider ist diese starke Synchronisation der Objektkopien im Fall hoher Latenzen

bei der Netzwerkkommunikation oder bei Verbindungsabbruch nicht l¨

anger m¨

oglich.

Die technische Unterst¨

utzung der Kooperation muss daher zus¨

atzliche Mechanismen

zur Verf¨

ugung stellen, welche die Verkn¨

upfung der verteilten Objektkopien auch bei

schwacher Synchronisation gew¨

ahrleisten kann und Differenzen zwischen den Repli-

Mobilit¨

at in der kooperativen Wissensarbeit

ken zeitnah aufdecken kann (Szenario 1.5). Werden derartige Differenzen zwischen

Objektkopien aufgedeckt, ist ein kooperativer Bewertungsprozess als Kernmechanis-

mus der Synchronisation durch die Objektverwaltung zu unterst¨

utzen (Szenario 2.4,

Szenario 2.5).

Um die Flexibilit¨

at der Kooperationsumgebung f¨

ur unterschiedlichste Einsatzge-

biete zu erh¨

ohen, sollte die Ausgestaltung der Objekte noch weitere Eigenschaften

erf¨

ullen. Eine Erweiterung der Objekte um aktive Elemente erlaubt z. B. bei Be-

darf Arbeitsprozesse (engl. Workflows) abzubilden (Szenario 1.2, Szenario 4.4). Man

spricht in diesem Zusammenhang auch von aktiven Objekten.

Ahnlich wie die aktiven Objekte erh¨

ohen auch personalisierte Objekte die Flexibili-

t¨

at der Kooperationsumgebung bzgl. der m¨

oglichen Nutzungsszenarien. Bei der Per-

sionalisierung von Objekten werden Eigenschaften des Objekts an einen bestimmten

Benutzer oder eine Benutzergruppe angepasst. Dies kann aufgrund der Vorlieben der

Benutzer oder aufgrund der Realisierung einer bestimmten Form der Kooperation

geschehen (Szenario 4.4).

3.5 Zusammenfassung

Die Nutzung von Kooperationsumgebungen in mobilen Nutzungsszenarien ist ge-

kennzeichnet von dem spontanen und nebenl¨

aufigen Charakter der Kooperation.

Anders als in klassischen Kooperationsszenarien sind deren mobil-spontanen Aus-

pr¨

agungen selten geplant und in ihrer Konstellation von Sitzung zu Sitzung va-

riabel (z. B. ¨

Ortlichkeit, technisches Umfeld, personelle Zusammensetzung). Dieser

spontan-dynamische und nebenl¨

aufige Charakter ist es, der die Kooperation zu ei-

ner in den Tagesablauf integrierten Kollaboration transformiert. Diese Kollaboration

findet in unterschiedlichen Alltagskontexten statt und bedarf spezieller Hilfsmittel,

um sie in eine st¨

arker koordinierte Form zu bringen.

Betrachtet man die Anforderungen an eine mobil-verteilte Kooperationsumge-

bung, die auf eine Unterst¨

utzung derartig spontan-dynamischer Zusammenarbeit

zielt, zeigen sich neben den speziellen Anforderungen an die grundlegende Unter-

st¨

utzung von Kommunikation,Koordination und Kooperation, die Anforderungen

der Vernetzung und Sichtbarkeit, der Kontextualisierung und der Konsistenz und Re-

versibil¨

at, die den neuen Qualit¨

aten mobil-spontaner Kooperationsformen geschuldet

sind. W¨

ahrend erstere auch in klassischen Kooperationsumgebungen von zentraler

Bedeutung sind und den Verh¨

altnissen einer mobil-verteilten Umgebung angepasst

seien m¨

ussen, folgen letztere aus dem mobil-spontanen Charakter des neuartigen

Nutzungsumfeldes.

Da die Objekte der Kooperationsumgebung verteilt und unter Umst¨

anden redun-

dant auf den Knoten des Netzwerkverbundes gespeichert sind und die Knoten den

allt¨

aglichen Bewegungen der Benutzer folgen, ist die Wahrung der Konsistenz die

zentrale Herausforderung an die neuartigen mobil-verteilten Kollaborationssysteme.

Weiterhin sind Kollaborationssitzungen ohne zentrale Dienste, wie z. B. Verzeich-

nisserver ¨

uber die verf¨

ugbaren Sitzungen und Gruppen, zu etablieren. Dies stellt

Mobilit¨

at in der kooperativen Wissensarbeit

86 3.5 Zusammenfassung

Herausforderungen sowohl an die technische Vernetzung als auch an die soziale Ver-

kn¨

upfung der verf¨

ugbaren Kollaborationspartner. Stets gilt es dabei, die Komplexi-

t¨

at der Konfiguration der Kooperationsumgebung vor dem Benutzer zu ”verstecken“

und diese soweit wie m¨

oglich automatisch im Hintergrund erfolgen zu lassen. Der

Kontext der Benutzer spielt in dieser Hinsicht eine wichtige Rolle und wird in mo-

bilen Nutzungsszenarien zu einer unverzichtbaren Komponente.

Im folgenden Kapitel werden Systeme und L¨

osungen betrachtet, die wesentliche

Komponenten f¨

ur die Bew¨

altigung dieser Herausforderungen darstellen. Dabei han-

delt es sich sowohl um Basistechnologien als auch um kooperationsst¨

utzende Sys-

teme mit Blick auf mobile Teilnehmer. Am Ende des Kapitels wird basierend auf

diesen L¨

osungen ein Entwurfsmuster f¨

ur mobil-verteilte Kooperationsumgebungen

skizziert.

Mobilit¨

at in der kooperativen Wissensarbeit

4 L¨

osungsans¨

atze f¨

ur eine technische

Umsetzung

Die Schaffung mobiler Kooperationsumgebungen beinhaltet Aspekte verschiedener

Forschungsfelder der Informatik (vgl. Abbildung 4.1). Wie in [Eßmann und Hampel,

2003b] vorgestellt, sind diese im Wesentlichen in vier Bereiche zu unterteilen: Hard-

warel¨

osungen, Netzwerkprotokolle, Architekturkonzepte und Benutzerschnittstellen.

Als Grundlage f¨

ur eine Kooperation in mobilen Nutzungsszenarien bedarf es zu-

n¨

achst portabler Ger¨

ate, die Benutzer in ihren Alltagssituationen begleiten, ohne

sie in ihrer Mobilit¨

at zu behindern oder zu st¨

oren. Die immer steigende Verbreitung

von so genannten Smartphones – einer Mischung aus Mobiltelefon und PDA – zeigt,

dass inzwischen Hardwarel¨

osungen existieren, die diese Bedingungen einer hohen

Portabilit¨

at bei ausreichender Rechenleistung erf¨

ullen.

Um dem Benutzer ein intuitiven Umgang mit der Kooperationsumgebung zu bie-

ten, m¨

ussen Benutzungsschnittstellen geschaffen werden, die auf derartig kleine trag-

bare Ger¨

ate zugeschnitten sind oder gut f¨

ur diese skalieren. Wichtiger Aspekt ist

somit eine gute Anpassung der Darstellung sowie des Funktionsumfangs an die F¨

higkeiten des benutzten Ger¨

ates. Um die Eignung derartig kleiner Displays f¨

ur die

Darstellung virtueller Wissensr¨

aume zu ermitteln, wurden eigens Prototypen entwi-

ckelt, die die M¨

oglichkeiten eines dokumentenzentierten Arbeiten auf stiftbasierten

Ger¨

aten mit kleinem Display ausloten [Eßmann und Hampel, 2003a, b]. Die positi-

ven Ergebnisse aus der Nutzung der Prototypen lassen den Schluss zu, dass derartige

Kleinger¨

ate durchaus f¨

ur eine Kooperation innerhalb virtueller Wissensr¨

aume geeig-

net sind. Es zeigte sich aber, dass Problemstellungen der mobilen Kooperation aus

dem Spannungsfeld der Technologien zur Bereitstellung einer nahtlosen Verf¨

ugbar-

keit des Kooperationsdienstes verwurzelt sind.

Zun¨

achst einmal m¨

ussen mobile Ger¨

ate Netzwerkschnittstellen bieten, die eine

Vernetzung mit den Ger¨

aten der Kooperationspartner erlauben. Im Fokus der Be-

trachtung entsprechender Technologien steht die Unabh¨

angigkeit von zentral bereit-

gestellten Netzwerkinfrastrukturen, da bereits etablierte Infrastrukturen in vielen

Nutzungssituationen nicht verf¨

ugbar und zudem h¨

aufig zu kostenintensiv sind.

Diese Faktoren stellen zweifelsohne Hemmnisse f¨

ur eine durchg¨

angige Nutzung mo-

biler Kooperationsumgebungen dar. Soll eine Kooperationsumgebung vom Benutzer

angenommen werden, muss deren Benutzung kostenneutral zu alternativen Koope-

rationswerkzeugen sein, da die Kooperationspartner sonst auf diese Alternativen

ausweichen. Dieses Ausweichen kann zu Medienbr¨

uchen f¨

uhren, die eine R¨

uckkehr

in die Kooperationsumgebung bei erneuter Verf¨

ugbarkeit erschweren. Um derartige

Nutzungshemmnisse zu vermeiden, ist es wichtig, die genutzten Netzwerkprotokolle

88 4.1 Knotenaufbau – Microkernel

Kommunikationsschichten, physikalische Netzwerke

mobile Ad-Hoc-Netzwerke, Mobile IP, etc.

verteilte Objektverwaltung

Peer-to-Peer, Overlay-Netzwerke, Distributed Hashtables (DHT), etc.

Middleware, Kontrolle

Persistenz, Ereigniskontrolle, Kontext, etc.

CSCW

mobile Wissensstrukturierung, virtuelle Wissensräume, etc.

mobil-verteilte

Wissensräume

Abbildung 4.1: In die Schaffung mobil-verteilter Wissensr¨

aume involvierte For-

schungsbereiche

so zu w¨

ahlen, dass zum einen eine Unabh¨

angigkeit von existierenden Netzwerkinfra-

strukturen besteht und zum anderen deren Vorteile einer weitr¨

aumigen und zuver-

l¨

assiger Vernetzung durch ¨

Uberg¨

ange genutzt werden kann. Die Netzwerkprotokolle

bilden somit eine Schl¨

usseltechnologie f¨

ur die mobile Kooperationsumgebung und

werden in Abschnitt 4.2.1 genauer untersucht.

Wie bereits angedeutet, setzt die Kooperationsumgebung auf diese Netzwerkstruk-

turen auf. Sie muss dabei den Besonderheiten der Netzwerkinfrastruktur angepasst

sein. Dies betrifft sowohl die Toleranz gegen Verbindungsabbr¨

uche in einem sehr

dynamischen Netzwerk als auch die Nutzung bereits existierender Strukturen in

sporadisch verf¨

ugbaren klassischen Netzwerken. Es bedarf eines Entwurfsmusters

f¨

ur eine Architektur, die derartiger Rahmenbedingungen gewachsen ist und die n¨

tige Flexibilit¨

at f¨

ur das heterogene Nutzungsumfeld aufweist. Die Entwicklung eines

solchen Entwurfsmusters bildet den Kern dieses Kapitels. Ausgehend von mobili-

t¨

atsunterst¨

utzenden Protokollen werden die technischen L¨

osungsans¨

atze anhand der

in Kapitel 3 ermittelten Anforderungen bewertet.

Die drei Kernfelder Vernetzung,Kontext und Konsistenz werden in diesem Kapitel

gem¨

aß den Anforderungen der Handlungsebene in technische Rahmenbedingungen

der Umsetzungsebene betrachtet (vgl. Abbildung 4.2). In einem ersten Schritt wird

im Folgenden der Aufbau des einzelnen Knoten im mobilit¨

atsfreundlichen Koopera-

tionsnetzwerk betrachtet.

4.1 Knotenaufbau – Microkernel

Der dynamische technische Kontext, in dem sich mobil-verteilte Kooperationsan-

wendungen einbetten verlangt, ein hohes Maß an Anpassungsverm¨

ogen. Der Zwang

zur Anpassung und Weiterentwicklung entsteht sowohl aus kurzfristigen ¨

Anderungen

der Netzwerk- und Dienstekonstellationen infolge der hohen Mobilit¨

at der Koope-

Mobilit¨

at in der kooperativen Wissensarbeit

HandlungsebeneUmsetzungsebene

Location Awareness,

automatische Konfiguration

verteilte Persistenzebene,

Distribution und Replikation

Ad-Hoc-Netzwerke für mobile Knoten,

Diensteerkennung,

gleichberechtigte Knoten (Peer-to-Peer)

Lokalität in der Gruppenbildung,

kontextuelle Rechte

medienbruchfreie Zusammenarbeit im

mobil-verteilten Wissensraum

spontane Vernetzung

mobiler Kooperationspartner

Kontext

Konsistenz

Vernetzung

Kontext

Konsistenz

Vernetzung

Abbildung 4.2: Der mobil-verteilte Wissensraum aus Perspektive von Handlungs-

ebene und Umsetzungsebene

rationsknoten und der Nutzungsvorlieben der Benutzer als auch aus langfristigen

Trends im Bereich der gew¨

ahlten technischen L¨

osungsans¨

atze.

Die Architektur der Anwendung muss dieser Dynamik mit einem hohen Maß an

Flexibilit¨

at gewachsen sein. Im Fall der Mobilit¨

at der Netzwerkknoten bedeutet dies,

auf ¨

Anderungen im Netzwerkumfeld flexibel zu reagieren, verf¨

ugbare Dienste zur

Laufzeit einzubinden und fehlende Dienste bei Bedarf zu ersetzen. Bei den wechseln-

den Nutzungsvorlieben der Benutzer muss sich die Anwendung durch einen hohes

Grad an Konfigurierbarkeit an diese anpassen lassen. Des Weiteren m¨

ussen tech-

nische Neuerungen leicht in die Anwendung eingepflegt und veraltete funktionale

Bestandteile ersetzt werden k¨

onnen.

Die im Bereich der klassischen zentralisierten CSCW-Systeme eingesetzten mono-

lithischen Systemarchitekturen erschweren eine Anpassung an neue Nutzungskon-

stellationen durch starke Abh¨

angigkeiten zwischen den funktionalen Bestandteilen.

Oftmals ziehen sich die von den Systemen bereitgestellten Funktionen quer durch die

gesamte Architektur des monolithischen Systems. ¨

Anderungen an Bestandteilen des

Systems ziehen so aufgrund der Abh¨

angigkeiten oft weitere ¨

Anderungen quer durch

die Architektur des Systems nach sich. Auch Anpassungen der Konfiguration k¨

onnen

h¨

aufig erst nach einem Neustart des Systems wirksam werden, da die funktionalen

Abh¨

angigkeiten eine Ver¨

anderung der Funktionsweise einzelner Bestandteile nicht

zul¨

asst, ohne die innere Konsistenz des Systems zu gef¨

ahrden.

Um derartig miteinander verwobene Architekturen zu verhindern, zerlegt das Ent-

wurfmuster des Microkernel [Buschmann et al., 1996] ein Gesamtsystem in vonein-

Mobilit¨

at in der kooperativen Wissensarbeit

90 4.2 Vernetzung und Sichtbarkeit

ander getrennte und in sich gekapselte Funktionseinheiten, die ¨

uber wohldefinierte

Schnittstellen miteinander kommunizieren. Zentrales und einzig unverzichtbares Ele-

ment einer solchen Architektur ist der Microkernel selbst. Dabei verf¨

ugt dieser ¨

uber

eine minimale Funktionalit¨

at und zeichnet sich lediglich f¨

ur das Laden und Ent-

fernen der Module verantwortlich. Abh¨

angigkeiten zwischen Modulen erkennt der

Microkernel in der Regel automatisch und l¨

adt die entsprechenden Module bei Be-

darf nach. S¨

amtliches Verhalten des Microkernel-Systems entspringt den Funktionen

der verkn¨

upften Module.

Das Entwurfsmuster des Microkernel wurde urspr¨

unglich im Bereich der Betriebs-

systeme eingesetzt [Rashid et al., 1989], findet sich inzwischen aber auch in Rah-

menarchitekturen f¨

ur die Softwareentwicklung wieder. Prominente Vertreter sind

hier das Plugin-Konzept des Eclipse-Framework [Gamma und Beck, 2003], JBOSS

mit dem JBossMicrokernel1und Hivemind2aus dem Jarkarta Projekt der Apache

Foundation.

Microkernel werden im besonderen Maße in komplexen und verteilten Systemen

wie Cooperative Virtual Environments (CVE) eingesetzt. Beispiele sind hier JADE

[Oliveira et al., 1999], GNU/Maverik [Hubbold et al., 1999] und Bamboo [Watsen

und Zyda, 1998]. Aber auch im Bereich der Multi-Agenten-Systeme findet sich mit

MadKit [Gutknecht et al., 2001] eine microkernelbasierte Architektur.

Besonders interessant im Hinblick auf die Ziele dieser Arbeit ist der Einsatz von

microkernelbasierten Architekturen im Bereich der Peer-to-Peer-Netzwerke, Ocean-

Store [Kubiatowicz et al., 2000] und verteilten CSCW-Cluster [Bopp und Hampel,

2005].

Monolithische und zentralisierte Ans¨

atze klassischer CSCW-Umgebungen k¨

onnen

aufgrund ihres starren Designs eine Anpassung an stark skalierende mobile Koope-

rationsumfelder kaum leisten. Das modulare und flexible Konzept des Microkernel

verspricht hingegen ein passendes Entwurfsmuster f¨

ur mobil-verteilte Kooperations-

umgebungen, deren Dynamik und Flexibilit¨

at sich insbesondere an der spontanen

Vernetzung der Benutzer in mobil-verteilten Kooperationsszenarien messen lassen

muss. Einen ersten Architekturansatz in dieser Hinsicht wird in [Eßmann et al.,

2004b] vorgestellt.

4.2 Vernetzung und Sichtbarkeit

Die Anforderungen an die Netzwerktechnologien, die mobil-verteilten Kooperati-

onsumgebungen zu Grunde liegen, werden durch die neue Mobilit¨

at der Koopera-

tionspartner und der daraus resultierenden Dezentralisierung bestimmt. Die Inte-

gration von funkbasierten Netzwerkschnittstellen wie Wireless Local Area Network

(WLAN)3,Worldwide Interoperability for Microwave Access (WIMAX)4,bluetooth5,

1http://www.jboss.org/wiki/Wiki.jsp?page=JBossMicrokernel

2http://jakarta.apache.org/hivemind/

3IEEE 802.11

4IEEE 802.16

Mobilit¨

at in der kooperativen Wissensarbeit

etc. erlaubt in vielen Mobilcomputern inzwischen die kabellose Vernetzung zweier

Gegenstellen in der physikalischen Schicht. Aber erst die darauf aufsetzenden Netz-

werkprotokolle erm¨

oglichen die eigentliche Kommunikation und den Aufbau komple-

xerer Netzwerktopologien. Diese sind somit als Kommunikationsgrundlage eine der

Schl¨

usseltechnologien f¨

ur die mobil-verteilte Kooperationsumgebung und werden im

Folgenden genauer betrachtet.

Auf der technischen Ebene m¨

ussen die mobilen Ger¨

ate miteinander verbunden und

die verteilt angebotenen Dienste verkn¨

upft werden, um Nachrichten austauschen und

den Kooperationsprozess koordinieren zu k¨

onnen. Doch die in diesem Abschnitt be-

trachteten Technologien gehen ¨

uber eine rein technische Vernetzung von mobilen

Ger¨

aten hinaus. Erst eine soziale Verkn¨

upfung der Teilnehmer ¨

uber Mechanismen

der gegenseitigen Wahrnehmung innerhalb der Kooperationsumgebung erlauben ei-

ne computergest¨

utzte Zusammenarbeit. Daher werden in diesem Abschnitt auch die

Aspekte der Bereitstellung einer Wahrnehmung der potentiellen Kooperationspart-

ner betrachtet.

Protokolle zur technischen Vernetzung der Kooperationsumgebung m¨

ussen an den

Anforderungen aus Kapitel 3 gemessen werden. Aus diesen ergeben sich eine Anzahl

von Punkten als wesentliche Merkmale einer mobilt¨

atsfreundlichen Vernetzung von

Kooperationsumgebungen:

Spontan Die zentrale Anforderung, die aus der Mobilit¨

at der Benutzer des Netz-

werkes resultiert, ist die F¨

ahigkeit, Netzwerke ohne bestehende Infrastruktur

(spontan, ad hoc) zu bilden.

Robust Die Funktion des Netzwerks muss auch bei Ausfall einzelner Knoten und

bei geringer Bandbreite gew¨

ahrleistet sein.

Skalierbar Die Netzwerkinfrastruktur darf nicht durch das Hinzukommen von zu-

s¨

atzlichen Knoten in seiner Leistungsf¨

ahigkeit beeintr¨

achtigt werden.

Netz¨

ubergreifend Dienste aus etablierten Netzwerkstrukturen muss das spon-

tan etablierte Netzwerk bei Verf¨

ugbarkeit von Zugangspunkten zu bestehen-

den Netzinfrastrukturen (z. B. Internet) einbinden k¨

onnen. Bei einem direkten

Wechsel der Zugangspunkte sollte es nicht zu einer Unterbrechung der genutz-

ten Dienste kommen.

Kompatibel F¨

ur die Einbindung existierender Netzwerkanwendungen muss die

mobile Netzwerkinfrastruktur kompatibel zu den Standardprotokollen TCP/IP

und UDP/IP sein.

Automatische Konfiguration Die Konfiguration der Netzwerkinfrastruktur muss

transparent, automatisch und ohne Benutzereingriff geschehen, um m¨

oglichst

wenig Nutzungshemnisse zu generieren.

5IEEE 802.15.1

Mobilit¨

at in der kooperativen Wissensarbeit

92 4.2 Vernetzung und Sichtbarkeit

An diesen Merkmalen m¨

ussen sich die Protokolle zur Vernetzung mobil-verteilter

Kooperationsumgebungen messen lassen. Das Forschungsfeld Netzwerkprotokolle f¨

mobile Knoten hat bereits eine Vielzahl m¨

oglicher L¨

osungen hervorgebracht, die

zum Teil v¨

ollig verschiedene L¨

osungsans¨

atze verfolgen und von ebenso verschiedenen

Verst¨

andnissen von Mobilit¨

at zeugen. Der kommende Abschnitt beleuchtet diese

unterschiedlichen Ans¨

atze anhand ihrer Eignung f¨

ur mobile Kooperationsszenarien.

4.2.1 Protokolle zur Vernetzung mobiler Knoten

Im Bereich der Netzwerkprotokolle gibt es zwei von Grund auf unterschiedliche Be-

trachtungsweisen von Mobilit¨

at. Die Erste betrachtet die so genannte Macro Mobility

oder Inter Domain Mobility. In dieser Form der Mobilit¨

at wird der mobile Knoten

als ein Teil eines relativ stabilen Netzwerkes betrachtet, der ¨

uber Zugangspunkte

mit diesem verbunden ist und in seiner Mobilit¨

at zwischen den Zugangspunkten

wechselt. In diesem Bereich hat sich das Mobile IP-Protokoll zu einer Art Standard

etabliert.

Die andere Betrachtungsweise sieht alle Knoten des Netzwerkes als mobil und

lose ¨

uber wechselnde Netzwerkverbindungen verbunden. In diesem Zusammenhang

wird von Micro Mobility oder Intra Domain Mobility gesprochen. Protokolle dieser

Mobilit¨

atsklasse m¨

ussen zum einen eine dynamische Vernetzung der Knoten bieten

und zum anderen versuchen, stabile Netzwerkpfade in dem dynamischen Netzwerk

zu etablieren.

Mobile IP – Netzwerkprotokolle f¨

ur mobile Endger¨

ate

Mobilit¨

at innerhalb etablierter Netzwerke wie dem Internet meint zumeist das Wech-

seln zwischen verschiedenen Netzwerkdomains. In diesem Fall wird von Macro Mobi-

lity oder Inter Domain Mobility gesprochen. Diese haben zum Ziel, mobilen Ger¨

aten

den nahtlosen Wechsel zwischen Domains ohne Verbindungsabbr¨

uche zu erm¨

ogli-

chen. Bei L¨

osungen, die einen Neustart der Netzwerkverbindungen ben¨

otigen und

damit einen Abbruch bestehender Anwendungen in Kauf nehmen, unterst¨

utzen in

diesem Zusammenhang lediglich so genannte Portability aber keine Mobilit¨

at (engl.

Mobility) [vgl. Valko, 1999]. Eine vielversprechende L¨

osung, die eine dementspre-

chende Unterst¨

utzung der Mobilit¨

at bietet, ist die von der Internet Engineering

Task Force (IETF) entwickelte IP Protokollerweiterung Mobile IP.

Bei Mobile IP [Perkins, 1997] handelt es sich um eine Erweiterung des im Internet

gebr¨

auchlichen IP-Protokolls, die eine Einbindung mobiler Endger¨

ate in etablierte

Netzwerkinfrastrukturen bietet.

Damit ein Endger¨

at reibungslos zwischen verschiedenen Netzwerken wechseln kann,

muss stets f¨

ur die Erreichbarkeit des mobilen Knotens gesorgt werden und einen

unterbrechungsfreien Wechsel zwischen Zugangspunkten verschiedener Subnetze er-

lauben, ohne bestehende Netzwerkverbindungen unterbrechen zu m¨

ussen. In IPv4-

basierten Netzwerken wird jedem Knoten f¨

ur dessen Adressierung eine eindeutige

IP-Adresse aus dem assoziierten Subnetz zugewiesen. Wechselt der Knoten zwischen

Mobilit¨

at in der kooperativen Wissensarbeit

4.2.1 Protokolle zur Vernetzung mobiler Knoten 93

zwei Subnetzen, erh¨

alt dieser eine IP-Adresse aus dem Subnetz dem er neu beitritt.

Auf diese Art wird ein korrektes Routing der IP-Pakete gew¨

ahrleistet.

Aufgrund der neuen IP-Adresse erreichen Pakete die an die urspr¨

ungliche Adresse

gesendet wurden den Knoten nicht mehr. Daher m¨

ussen bestehende Verbindungen

zun¨

achst beendet und mit der neuen Adresse wiederaufgenommen werden. Dazu

muss der mobile Knoten aber erst den Gegenstellen seine neue Adresse mitteilen.

Somit ist ein tempor¨

arer Verbindungsabbruch unvermeidbar. Neue Verbindungen zu

dem mobilen Knoten hingegen sind aufgrund fehlender Addressinformationen kaum

m¨

oglich.

Ein nahtloser ¨

Ubergang zwischen zwei Subnetzen ist in Standard IPv4 Netzwer-

ken somit kaum m¨

oglich. Um dieses Problem bei Beachtung der Kompatibilit¨

at zum

IPv4-Protokoll umgehen zu k¨

onnen, entwarf die IETF die IPv4-kompatible Mobi-

le IP-Variante Mobile IPv4 (MIPv4) [Perkins, 2002]. Der Grundgedanke ist jedem

Endger¨

at im Netzwerk eine feste eindeutige Adresse zuzuweisen und so Verbindungs-

abbr¨

uche aufgrund von Addresswechseln zu vermeiden.

Jedes mobile Endger¨

at wird in MIPv4 einem Heimatnetz zugeordnet, in dem ein

so genannter Home Agent (HA) die Erreichbarkeit des mobilen Knotens gew¨

ahrleis-

tet. Als Gegenst¨

ucke befinden sich in fremden Subnetzen Foreign Agents (FA), an

die sich der mobile Knoten beim Betreten der Subnetze anmeldet. Der FA meldet

daraufhin dem HA die Care-of-Adresse des mobilen Knotens. Will nun ein Teilneh-

mer im Netz den mobilen Knoten kontaktieren, wendet er sich nicht direkt an diesen,

sondern sendet seine Anfrage an die feste Adresse des mobilen Knotens im Heimat-

netz. Der HA nimmt diese Anfrage stellvertretend entgegen und leitet sie an den

FA des Netzes, in dem sich der mobile Knoten befindet, weiter. Der FA ¨

ubergibt die

Anfrage seinerseits an den mobilen Knoten. Die Anfragen werden somit ¨

uber HA

und FA umgeleitet.

Die Kommunikation des mobilen Knotens zu seinen Kommunikationspartner kann

hingegen direkt erfolgen (Dreiecksrouting). Bei einem Wechsel des Subnetzes ¨

andert

sich jedesmal die care-of Adresse. Da die Kommunikationspartner aber ¨

uber die feste

Adresse des mobilen Knoten in dessen Heimatnetz mit diesem kommunizieren, wird

der Datenverkehr lediglich an die neue care-of Adresse umgeleitet. Die Verbindungen

m¨

ussen nicht zur¨

uckgesetzt werden.

Die Hauptnachteile der Mobile IP Implementierung f¨

ur IPv4 entstehen aus dem

Dreiecksrouting und der daraus entstehenden Abh¨

angigkeit von Home Agent und

Foreign Agent: Datenpakete sind aufgrund des Dreiecksroutings ¨

uber HA und FA

l¨

anger unterwegs (Verz¨

ogerung, engl.: Delay), das gesamte Routing h¨

angt von der

Funktionf¨

ahigkeit von HA und FA ab (Robustheit, engl.:Robustness) und der HA

muss die Last der Kommunikation aller im zugeordneten mobilen Knoten tragen

(Skalierbarkeit, engl.: Scalability).

Als Alternative bietet sich hier Mobile IPv6 (MIPv6) an, das anders als MIPv4

auf IPv6 basiert und von dessen Vorteilen profitiert [Johnson et al., 2004]. In IPv6

ist es m¨

oglich, die Routen zwischen zwei Knoten automatisch zu optimieren, was den

FA ¨

uberfl¨

ussig macht. Der mobile Knoten meldet seine care-of Addresse nur noch

an den HA, der Ansprechpartner f¨

ur potentielle Kommunikationspartner in der In-

Mobilit¨

at in der kooperativen Wissensarbeit

94 4.2 Vernetzung und Sichtbarkeit

italisierungsphase der Kommunikation ist. Sobald die Verbindung zwischen mobilen

Knoten und Kommunikationspartner hergestellt ist, k¨

onnen die Datenpakete dank

der automatischen Routenoptimierung direkt gesandt werden, ohne weiterhin vom

HA abh¨

angig zu sein.

Mit Hilfe des Mobile IP Protokolls ist es somit m¨

oglich, mit mobilen Ger¨

aten von

einer Domain zu einer anderen zu wechseln, ohne die ben¨

otigtde Netzwerkverbin-

dung zu verlieren. F¨

ur die Anwendung dieser Kommunikationsl¨

osung wird allerdings

stets eine st¨

andige Verbindung zum Internet ben¨

otigt und jede Organisation ben¨

tigt einen Agenten, der die Bekanntmachung ihrer mobilen Knoten ¨

ubernimmt. Diese

L¨

osung h¨

angt somit nach wie vor stark von einer bestehenden Netzwerkinfrastruktur

ab. Da diese Abh¨

angigkeit in mobilen Szenarien problematisch sein kann, verspre-

chen die so genannten Ad-Hoc-Netzwerk-Protokolle die unabh¨

angige Etablierung von

Netzwerken von Grund auf.

Ad-Hoc-Netzwerke

Protokolle, die in mobilen Nutzungsszenarien spontan eine Netzwerkinfrastruktur

etablieren, ordnet man der Protokollfamilie der Mobile Ad-Hoc-Networks (Manets)

zu. Die einzelnen Netzwerkknoten werden als Hops bezeichnet. Ist ein Hop durch

einen anderen Hop nur ¨

uber eine Route ¨

uber weitere Hops erreichbar, spricht man

von Multihop-Verbindungen. Hops in mobilen Netzwerkstrukturen sind in der Regel

beweglich und k¨

onnen nicht ¨

uber l¨

angere Zeitr¨

aume einer festen Position zugeord-

net werden. Daher bed¨

urfen Manets spezieller dynamischer Routingverfahren und

Handoff-Mechanismen. Eine Auswahl entsprechender Verfahren findet sich in [Per-

kins, 2001].

Bei der Mobilit¨

at der Hops innerhalb eines Manets spricht man von Micro Mobility

oder Intra Domain Mobility. Diese zeichnet sich durch eine sehr viel h¨

ohere Dynamik

als die zuvor behandelte Inter Domain oder Macro Mobility aus. Des Weiteren kann

nicht von der Erreichbarkeit fester Dienste ausgegangen werden, wie es z.B. bei den

Home Agents des Mobile IP-Protokolls der Fall ist.

Die einfachste Version von Routingverfahren f¨

ur mobile Netzwerke unterst¨

utzt nur

direkte Verbindungen zwischen Hops. Ein Vertreter dieser Protokolle ist bereits in

vielen Betriebssystemen integriert und wird Link-Local genannt. Im Prinzip ist Link-

Local ein Protokoll zur automatischen Vergabe von IP-Adressen, das Routing bleibt

identisch zu dem in klassischen IP-Netzen. F¨

ur die Aushandlung der IP-Adresse

w¨

ahlt jeder Hop zuf¨

allig eine Adresse aus einem f¨

ur die Link-Local-Vernetzung

freigehaltenen IP-Adressbereich 129.169.0.0/255.255.0.0 und sendet diese per

Broadcast ins Netzwerk. Wird die Adresse nicht bereits durch einen anderen Hop

zur Kommunikation benutzt, darf er diese nutzen, um ¨

uber sie zu kommunizieren.

Ist aber die gew¨

ahlte Adresse bereits durch einen anderen Hop f¨

ur die Kommunikati-

on gebunden, legt deren derzeitiger Besitzer, ebenfalls per Broadcast, Einspruch ein,

und die Prozedur beginnt von vorne. Eine bereits vergebene aber nicht an eine aktive

Kommunikation gebundene Adresse muss hingegen wieder freigegeben werden.

Mobilit¨

at in der kooperativen Wissensarbeit

4.2.1 Protokolle zur Vernetzung mobiler Knoten 95

Die Kommunikation bei diesen Verfahren ist stets auf die direkte Kommunikati-

on zwischen den Kommunikationspartnern beschr¨

ankt und durch die vielen Broad-

casts mit einem hohen Protokoll-Overhead versehen. Des Weiteren ist die Anzahl

der m¨

oglichen Teilnehmer auf 65534 beschr¨

ankt6– wenngleich bei einer Link-Local-

Vernetzung eine derartige Netzwerkgr¨

oße unwahrscheinlich erscheint. F¨

ur Face-to-

Face-Kooperationen ist diese Vernetzung trotz ihrer Einschr¨

ankungen geeignet. Eine

Multihop-Vernetzung ist in diesen Situationen aufgrund des direkten Kontakts der

Kommunikationspartner nicht notwendig. Die geforderte Kompatibilit¨

at zu klassi-

schen IP-Netzwerken ist hingegen ohne weiteres gegeben.

Link-Local unterst¨

utzt keine weitr¨

aumige Vernetzung von ¨

ortlich verteilten Kom-

munikationspartnern, da es keine indirekten Multihop-Verbindungen kennt. Im Ge-

gensatz zu den meisten aufw¨

andigeren Multi-Hop-Routing-Protokollen ist es aber

bereits f¨

ur die mobilen Nutzer verf¨

ugbar. Die Mehrzahl der aufw¨

andigeren Manet-

Protokolle sind bisher nur als Spezifikation und Algorithmen f¨

ur Netzwerksimulato-

ren wie z. B. dem Network Simulator 2 (ns2)7verf¨

ugbar. Die Integration der unter-

schiedlichen L¨

osungen in die Protokollschichten der Betriebssysteme ist ein langwie-

riger Prozess und die Protokolle an sich sind oftmals inkompatibel zueinander.

Im Wesentlichen unterscheiden sich die Protokolle zur Realisierung eines Manet

in der Art und Weise der Verwaltung der Routingpfade f¨

ur das Netzwerk. Die eine

Gruppe der Protokolle berechnet die Routingpfade zu den Kommunikationspart-

nern stets im voraus (proaktiv), so dass bei Kontaktaufnahmen zu einem entfernten

Knoten der Versendepfad f¨

ur die Nachricht bereits bekannt ist. Die andere Gruppe

berechnet den Pfad zu entfernten Knoten erst, wenn die Kommunikation initiiert

wird (reaktiv). Durch die reaktive Ermittlung des Routingpfades vom Sender zum

Empf¨

anger wird der Verbindungsaufbau im Vergleich zum proaktiven Verfahren ver-

z¨

ogert, aber die st¨

andige Kommunikation zur Aktualisierung der Routinginforma-

tionen vermieden.

Zu der proaktiven Protokollfamilie geh¨

oren beispielsweise das Destination-Se-

quence Distance-Vector (DSDV) Protokoll [Perkins und Bhagwat, 1994, 2000] und

das Optimized Link State Routing (OLSR) Protokoll [OLSR, 2003], das unter ande-

rem im Freifunk Projekt8f¨

ur die Etablierung eines stadt¨

ubergreifenden WLAN in

Berlin Verwendung findet.

Zu den reaktiven Protokollen geh¨

oren das Dynamic Source Routing (DSR) Proto-

koll [Johnson, 1994], das Temporally-Ordered Routing Algorithm (TORA) Protokoll

[Park und Corson, 1997, 2001] und das Ad hoc On Demand Distance Vector (AODV)

Protokoll [Perkins und Royer, 1999; Perkins et al., 2003].

Aufgrund der unterschiedlichen Charakteristika der Routingmechanismen schei-

nen die proaktiven Netzwerke mit ihren vorberechneten Routingtabellen intuitiv

besser f¨

ur autonome aber relativ statische Netzwerke geeignet, wohingegen die re-

6Die ersten und die letzten 256 Adressen sind von der Internet Assigned Numbers Authority (IA-

NA) f¨

ur zuk¨

unftige Anwendungen reserviert.

7http://www.isi.edu/nsnam/ns

8http://freifunk.net/

Mobilit¨

at in der kooperativen Wissensarbeit

96 4.2 Vernetzung und Sichtbarkeit

aktiven Protokolle eher in dynamischen Konstellationen mit mobilen Knoten inter-

essant erscheinen.

Vergleiche von Netzwerkprotokollen finden aufgrund fehlender Implementierun-

gen f¨

ur Betriebssysteme und dem Wunsch nach kontrollierten Rahmenbedingungen

zumeist nur im Simulator und unter theoretischen Annahmen statt [Broch et al.,

1998; Dyer und Boppana, 2001; Campell et al., 2002]. Hier werden die Protokolle

h¨

aufig unter extremen Bedingungen in Worst-Case-Szenarien betrachtet oder nur

spezielle Aspekte der Protokolle aufgegriffen, die eine generelle Aussage ¨

uber deren

Alltagstauglichkeit erschweren.

Um eine st¨

arkere Betrachtung der Alltagstauglichkeit der Manet Protokolle zu er-

lauben, wurde an der Uppsala University das standardisierte Ad hoc Protocol Eva-

luation (APE) Testumfeld entworfen [Lundgren et al., 2002], das die verf¨

ugbaren

Protokollimplementierungen mittels realer Hard- und Softwareumgebungen erpro-

ben hilft. Bei Betrachtung der g¨

angigen Manet-Protokolle zeigte sich jedoch nur eine

bedingte Eignung f¨

ur hochmobile und skalierende Netzwerkumgebungen [Tschudin

et al., 2005].

Nichtsdestotrotz scheint z. B. das AODV-Protokoll f¨

ur Szenarien mobiler Vernet-

zung grunds¨

atzlich gut geeignet und es existieren einige nutzbare Implementierun-

gen. Mit KERNEL-AODV NIST9und AODV-UU 10 sind zwei freie Implementie-

rungen f¨

ur das Linux Betriebssystem verf¨

ugbar. Und dar¨

uber hinaus existiert mit

AODV for Microsoft Windows11 auch eine Protokollerweiterung f¨

ur WindowsXP.

Nach der Etablierung eines funktionsf¨

ahigen Manets fehlt zum Betrieb von In-

ternet-Anwendungen noch die IP-Schicht, die das Adressieren der Rechner erlaubt.

Hier existiert, wie bei Mobile IP, die grunds¨

atzliche M¨

oglichkeit, entweder IPv4 oder

IPv6 zu benutzen. IPv6 hat den klaren Vorteil, aufgrund des 128-bit Adressraumes

und der Einbeziehung der Hardwareadresse des Netzwerkdevices, mit hoher Wahr-

scheinlichkeit eine eindeutige Adresse zuzuweisen, ohne Adresskonflikte im Netzwerk

zu erzeugen. Leider sind viele Netzwerkanwendungen noch nicht in IPv6 Netzwerken

lauff¨

ahig.

IPv4 hat mit 16 Bit einen sehr viel kleineren Adressraum, der Adresskonflikte sehr

viel wahrscheinlicher macht. Ausserdem muss jedes Ger¨

at bei einer automatischen

Konfiguration eine eigene Adresse raten und dann ¨

uber ein Protokoll auf Konflik-

te ¨

uberpr¨

ufen. Das Link-Local Protokoll l¨

asst sich in Multihop-Netzwerken nicht

verwenden, da es Konflikte nur mit direkten Nachbarn ¨

uberpr¨

ufen kann. ¨

Ahnlich

dem Link-Local-Protokoll verf¨

ahrt das Duplicate Adress Detection Protokoll [Perkins

et al., 2001; Jeong et al., 2005]. Anstatt von ARP-Requests verwendet es allerdings

modifizierte ICMP-Pakete und ist daher in der Lage, eine gr¨

ossere Netzwerkumge-

bung auf Konflikte zu ¨

uberpr¨

ufen. Das Prophet Adress Allocation-Protokoll [Zhou

et al., 2003] verwendet ein stochastisches Verfahren, um Adresskonflikte vorhersagen

und somit vermeiden zu k¨

onnen.

9http://w3.antd.nist.gov/wctg/aodv_kernel/

10http://www.docs.uu.se/~henrikl/aodv/

11http://moment.cs.ucsb.edu/AODV/aodv-windows.html

Mobilit¨

at in der kooperativen Wissensarbeit

4.2.1 Protokolle zur Vernetzung mobiler Knoten 97

Mit den hier vorgestellten L¨

osungen l¨

asst sich eine spontane Vernetzung realisie-

ren, die zur Etablierung der mobil-verteilten Kooperationsumgebung dienen kann.

Bei einer Einbindung entfernter Teilnehmer w¨

are jedoch eine Einbindung von even-

tuell vorhandenen Zug¨

angen zu weitr¨

aumigen Netzwerkstrukturen wie dem Internet

w¨

unschenswert.

Mischarchitekturen

Mischarchitekturen kombinieren inter- und intra-domain Vernetzung. Urspr¨

ungliches

Ziel dieses Ansatzes ist die Verminderung der bei Mobile IP entstehenden Netzlast

durch die Pakete zur Aktualisierung der Care-of-Adresse des mobilen Clients zum

Home Agent. F¨

ur die Inter Domain Mobility oder auch Macro Mobility setzt man

dabei auf IETF’s Mobile IP Protokoll und erweitert es f¨

ur Intra Domain Mobility

(Micro Mobility) um eigene Handoff- und Routingstrategien. So werden bei Positi-

onswechseln innerhalb einer Domain keine Pakete an den HA versandt. Vergleiche

einiger Verfahren finden sich in [Reinbold und Bonaventure, 2001] (Hierarchical Mo-

bile IP, Proactive Handoff, Fast Handoff, TeleMIP, Cellular IP, HAWAII und EMA)

und [Campell et al., 2002] (Ethernet Switch, Cellular IP, Hawaii, Hierarchical Mobile

IP). Im Folgenden seien die wichtigsten Verfahren kurz vorgestellt.

Das Hierarchical Mobile IP ist eine Erweiterung des Mobile IP Protokolls um hier-

archische Registrierung an Agents [Gustafsson et al., 2000]. So k¨

onnen unterhalb der

Agents eigene Netzwerkstrukturen entstehen, die vom Home Agent selbst verwaltet

werden. Auch die Handoff-Aware Wireless Access Internet Infrastructure (HAWAII)

[Ramjee et al., 1999] nutzt Mobile IP f¨

ur Inter Domain Mobility und gew¨

ahrleistet

die Intra Domain Mobility ¨

uber einen Foreign Domain Root Router, der die lokalen

Netzwerkpfade verwaltet. Diese Pfade werden periodisch erneuert und anhand For-

warding Schemes ermittelt. CellularIP [Valko, 1999] ist ein ¨

anliches Verfahren, das

stets optimale Pfade zum Gateway ermittelt.

Neben der Entlastung der Kommunikation zur Pflege des Mobile IP Netzwer-

kes kann die Kombination von Manets und Mobile IP helfen, die Reichweite der

Ad-Hoc-Netzwerke zu erh¨

ohen. Die erste wirkliche Mischform zwischen Mobile IP

und selbstorganisierten Ad-Hoc-Netzwerken realisiert das Verfahren in [Tseng et al.,

2003]. Dieser Ansatz nutzt f¨

ur Macro Mobility Mobile IPv4 und realisiert Micro

Mobility ¨

uber das Ad-Hoc-Netzwerk-Protokoll DSDV. Damit ist das lokale Netz-

werk komplett selbstverwaltet und dennoch ¨

uber den Foreign Agent an das Internet

angebunden. Die Knoten sind somit stets ¨

uber ihren Home Agent erreichbar.

Derartige Mischarchitekturen f¨

ur die spontane Vernetzung von mobilen Knoten

mit einer optionalen Erreichbarkeit aus dem Internet erlauben es, autonome Netz-

werke zwischen den mobilen Knoten zu etablieren und bei Verf¨

ugbarkeit zus¨

atzlich

Dienste aus dem Internet sowie entfernte Kooperationspartner einzubinden. Die Dy-

namik und Skalierung derartiger L¨

osungen macht die zentralisierten Architekturen

klassischer CSCW-Systeme ungeeignet f¨

ur einen Einsatz in vielen der m¨

oglichen

Vernetzungskonstellationen.

Mobilit¨

at in der kooperativen Wissensarbeit

98 4.2 Vernetzung und Sichtbarkeit

4.2.2 Vernetzung verteilter Dienste

In mobilen Netzwerkumgebungen sind die Benutzer mit einer st¨

andig wechselnden

Diensteinfrastruktur konfrontiert. Einige der verf¨

ugbaren Dienste laufen dabei even-

tuell auf entlegenen Knoten im Internet und andere direkt in der unmittelbaren

Umgebung des Benutzers. Ohne eine Wahrnehmung der verf¨

ugbaren Dienste k¨

onnen

aber weder die einen noch die anderen genutzt werden. Es bedarf daher passender

Service Discovery-Verfahren, um die verf¨

ugbaren Dienste allen Benutzern zug¨

anglich

zu machen.

Ahnlich wie mit der Sichtbarkeit der Dienste in mobil-spontanen Netzwerken ver-

h¨

alt es sich mit der Wahrnehmung potentieller Kooperationspartner, die in der Netz-

werkumgebung verf¨

ugbar sind. Aus einer technischen Sichtweise k¨

onnen sie wie ein

Dienst betrachtet werden, dessen Verf¨

ugbarkeit durch die lokale Instanz der mobil-

verteilten Kooperationsumgebung auf den pers¨

onlichen Ger¨

aten gew¨

ahrleistet und

bekanntgegeben wird.

Als Besonderheit gegen¨

uber virtualisierten Diensten im Netz besteht bei den

Kooperationspartnern eventuell ein Interesse an Informationen ¨

uber deren aktu-

ellen Aufenthaltsort, um einen r¨

aumlichen Bezug zu sich herzustellen (vgl. Ab-

schnitt 3.3.2). Dieser Bezug kann entweder aus bereitgestellten Informationen von

Location Awareness-Diensten [vgl. Hightower und Borriello, 2001] oder ¨

uber die In-

formationen aus der Netzwerkumgebung gewonnen werden. Letzteres w¨

are z. B. ¨

uber

eine Auswertung der G¨

ute der Funkverbindung oder der Anzahl der Wegpunkte auf

dem Routingpfad m¨

oglich.

Da in mobil-spontanen Kooperationsszenarien zentrale Verzeichnisse ¨

uber verf¨

ug-

bare Dienste – wie jeder andere Dienst auch – nicht direkt sichtbar sind und zudem

als unzuverl¨

assig gelten m¨

ussen, muss jeder Dienst sich selber im Netz bekannt ma-

chen.

In der lokalen Netzwerkumgebung kann die Service Discovery per IETF Zeroconf

Workinggroup spezifizierte Multicast DNS (mDNS) [Guttman, 2001; Huck et al.,

2002; Stirling und Al-Ali, 2003] bewerkstelligt werden. Ein mDNS konformer Dienst

k¨

undigt sich dazu mittels einer Multicast-Nachricht bei allen anderen Knoten inner-

halb desselben Subnetzes an und teilt in dieser Nachricht mit, wie er zu erreichen ist.

Mit diesen Informationen k¨

onnen sich dann die Clients mit dem Dienst verbinden.

Sollen Dienste jedoch in weitr¨

aumig verteilten Systemen bekannt gemacht wer-

den, bedarf es einer Infrastruktur, die Dienstank¨

undigungen an interessierte Clients

weiterreichen. Zwar kennt mDNS so genannte Proxies, die die Dienstank¨

undigungen

in ein anderes Subnetz weiterleiten k¨

onnen, diese eignen sich aber lediglich daf¨

Subnetze zu b¨

undeln, nicht aber um autonom weitr¨

aumige Diensteinfrastrukturen

zu etablieren [vgl. Eßmann et al., 2004a].

Derartig weitr¨

aumige Infrastrukturen mit gleichberechtigten Dienstanbietern wie

Dienstnehmern hat sich das JXTA Framework12 zum Ziel gesetzt [Gong, 2001;

Brookshier et al., 2002]. Zu diesem Zweck etabliert JXTA ein weitr¨

aumiges Peer-to-

Peer-Netzwerk, bei dem Dienste zun¨

achst lokal bekannt gegeben werden und dann

12http://www.jxta.org

Mobilit¨

at in der kooperativen Wissensarbeit

4.2.3 Netzwerktopologie 99

nach und nach mittels so genannter Rendezvous-Peers in anderen Netzwerken pro-

pagiert werden. So k¨

onnen auch entfernte Peers die beworbenen Dienste eines Peers

in Anspruch nehmen.

Beide L¨

osungen eignen sich f¨

ur eine Service Discovery in mobil-verteilten Ko-

operationsszenarien. W¨

ahrend mDNS eher auf die lokale Netzwerkumgebung zielt,

stellt JXTA ein komplexes Dienste-Netzwerk mit entsprechendem Kommunikations-

Overhead dar. Beide Ans¨

atze schliessen sich nicht gegenseitig aus und ihre Nutzung

kann von der gewollten Reichweite des bekanntzugebenden Dienstes abh¨

angig ge-

macht werden.

4.2.3 Netzwerktopologie

Mobile IP und Manets bilden zusammen mit den geeigneten Service Discovery-

Verfahren mobilit¨

atsfreundliche Netzwerkinfrastrukturen f¨

ur mobil-verteilte Koope-

rationsumgebungen. Besonders Manets zeichnen sich durch eine hohe Dynamik der

Verbindungen im Netzwerk aus; aber auch die Mobile IP Vernetzung enth¨

alt eine

Abkehr von statischen und zentral verwalteten Infrastrukturen. Klassische Koope-

rationssysteme hingegen orientieren sich an Client-Server-Architekturen mit f¨

ur die

Funktion kritischen zentralisierten Diensten.

Beispiel einer solchen zentralisierten CSCW-Architektur ist das im Heinz Nix-

dorf Institut (HNI) an der Universit¨

at Paderborn entwickelte open-sTeam. Es im-

plementiert das in Abschnitt 3.2 besprochene Konzept der kooperativen virtuellen

Wissensr¨

aume [Hampel, 2001]. Diese bilden einen raumbasierten Ansatz zur koope-

rativen Wissensorganisation. Der Wissensraum ist in virtuelle R¨

aume unterteilt, in

denen sich die Kooperationspartner, repr¨

asentiert durch virtuelle Avatare, treffen

und ihr Wissen anhand von Dokumenten und Kommunikationsmedien kooperativ

strukturieren. F¨

ur diesen dokumentenzentrierten Ansatz der Kooperation bilden die

Medienfunktionen die ben¨

otigte Grundfunktionalit¨

at ab [Hampel und Keil-Slawik,

2002].

Die zentrale Komponente des Systems bildet ein dedizierter open-sTeam-Server,

der den gesamten Wissensraum speichert. Er ist der zentrale Anlaufpunkt f¨

ur die Ko-

operationspartner und alleinverantwortlich f¨

ur die Verwaltung der Kooperationsum-

gebung und die Persistenz des Wissensraumes. Daher h¨

angt die Funktionsf¨

ahigkeit

der Kooperationsumgebung stark von der Erreichbarkeit des Servers ab.

Das Gros der g¨

angigen Kooperationssysteme basiert ebenfalls auf zentral ver-

walteten Arbeitsbereichen mit einer ebenfalls zentral gespeicherten gemeinsamen

Dokumetenbasis. Prominente Beispiele sind hier BSCW [Bentley et al., 1997] und

Lotus Notes [Kawell et al., 1988]. Lotus Notes ist eine Groupware-Umgebung mit

m¨

achtigen Replikationsmechanismen f¨

ur mobiles Arbeiten. Die Replikation ist aber

von dem zentralen Notes-Server abh¨

angig, so dass kooperative Interaktion nur im

verbundenen Zustand m¨

oglich ist.

Um diese zentrale Speicherung auf einem isolierten Server aufzubrechen, l¨

asst

sich mittels Verkn¨

upfung mehrerer isolierter Server ein Server-Verbund (Cluster)

mit einem gemeinsamen verteilten Datenraum schaffen. Dieser Ansatz basiert aber

Mobilit¨

at in der kooperativen Wissensarbeit

100 4.3 Persistenz

weiterhin auf der Annahme, dass Server im Netzwerk fest verf¨

ugbar sind und der

Wissensraum auf mehrere dedizierte Server verteilt gespeichert wird.

Einen Schritt weiter geht der Peer-to-Peer-Ansatz, der auch Clients in die Ver-

waltung und Speicherung der verteilten Softwareumgebung einbezieht [vgl. Eßmann

und Hampel, 2005; Eßmann und Funke, 2005]. Prinzipiell treten alle teilnehmenden

Knoten (Peers) in einem solchen Verbund gleichberechtigt auf und k¨

onnen notfalls

die Funktion von ausgefallenen Peers ¨

ubernehmen.

Das Groove Framework13 erlaubt es, eine Peer-to-Peer-Kooperationsumgebung

aufzubauen und mittels Kommunikations- und Dateiaustauschmechanismen zu ver-

netzen. F¨

ur einige Funktionalit¨

aten, wie Initialisierung der Kooperationssitzung und

Synchronisation der verteilten Arbeitsbereiche, ben¨

otigt Groove allerdings einen zen-

tralen Server, der die Kontaktaufnahme initiiert. Groove kann durch externe Werk-

zeuge erweitert werden, die in die Groove Arbeitsumgebung eingebettet werden.

Einen anderen Ansatz bez¨

uglich der Implementierung einer Peer-to-Peer-Umge-

bung verfolgt Speakeasy [Edwards et al., 2002b]. Speakeasy ist zun¨

achst ein Peer-

to-Peer Framework, um kooperative mobile Anwendungen zu implementieren. Mit

Casca [Edwards et al., 2002a] existiert aber bereits eine Beispielimplementierung f¨

eine Peer-to-Peer Kooperationsumgebung, die jedoch sitzungsbasiert ist und keine

persitenten Arbeitsbereiche zu Verf¨

ugung stellt.

Eine eingeschr¨

ankte Persistenz der Kooperationsmaterialien bietet Swifff [Eß-

mann et al., 2004c; Slawik et al., 2004]. Swifff ist eine verteilte Kooperationsum-

gebung, die auf das JXTA Peer-to-Peer Framework aufsetzt (vgl. Abschnitt 4.2.2).

Es bildet einen lose vernetzten gemeinsamen Wissensraum, in dem Objekte verteilt

bearbeitet werden k¨

onnen. Die Berabeitung eines entfernten Objektes erzeugt aber

stets eine lokale Kopie. Diese ist sodann als eigenst¨

andiges Objekt im Netzwerk ver-

f¨

ugbar. Eine Synchronisation der Kopien der verteilten und gemeinsam genutzten

Objekte findet nicht statt.

Es existieren also erste Ans¨

atze f¨

ur die mobile und verteilte Nutzung von gemein-

samen Arbeitsumgebungen. Insbesondere die Peer-to-Peer-Topologie verspricht hier

den Anforderungen einer dynamischen mobilen Kooperationsumgebung gewachsen

zu sein. Durch ihre verteilte Architektur wirft sie aber Fragen bez¨

uglich der konsis-

tenten und persistenten Speicherung der gemeinsam genutzten Objekte auf. Es gilt

daher, in einem n¨

achsten Schritt, verteilte Persistenzkonzepte auf ihre Eignung f¨

eine Kooperationsumgebung mit gleichberechtigten mobilen Knoten zu betrachten.

Dabei liegt der besonderere Fokus auf den Anforderungen, die aus der Dynamik

der spontanen Vernetzung und der Wahrung der Konsistenz des gemeinsamen und

verteilt gespeicherten Arbeitsbereiches erwachsen.

4.3 Persistenz

Die Netzwerkumgebungen in denen sich mobile Kollaborationsumgebungen bewe-

gen, zeichnen sich durch eine hohe Heterogenit¨

at aus und stecken so die technischen

13http://www.groove.net

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 101

Rahmenbedingungen f¨

ur die mobile Kooperation ab. Die hohe Dynamik l¨

asst eine

exklusive Speicherung von Objekten auf zentralen Servern nicht zu. In Netzwerkum-

gebungen mit Zugang zum Internet bietet ein Server als zentrale Anlaufstelle eine

Reihe von Vorteilen und vereinfacht die Verwaltung der Kooperationsumgebung.

Fehlt ein solcher Zugangspunkt jedoch, sind die Client-Anwendungen aufgrund der

Abh¨

angigkeit von zentralen Servern nicht l¨

anger nutzbar. Um eine Kooperations-

umgebung in einem Ad-Hoc-Netzwerk ohne Verbindung zu einem dedizierten Server

nutzen zu k¨

onnen, m¨

ussen deren Dienste verteilt auf den erreichbaren Knoten laufen.

Diese Forderung betrifft auch die Verf¨

ugbarkeit der zur Kollaboration ben¨

otigten

Objekte. Auch diese m¨

ussen verteilt ¨

uber die Ger¨

ate aller beteiligten Benutzer vor-

liegen. Bei der Bereitstellung eines verteilten Objektspeichers ist es wichtig, Strate-

gien und Konzepte zu entwickeln, die festlegen, welche Objekte auf welchen Ger¨

aten

gespeichert werden sollen. Beispielsweise kann die Strategie einer besitzorientierten

Speicherung verfolgt werden, bei der jeder Benutzer seine eigenen Dateien lokal spei-

chert und anderen Benutzern zur Verf¨

ugung stellt. Gerade in kooperativen Szenarien

f¨

allt eine solche Besitzzuordnung allerdings schwer.

Der Entwurf von Konzepten und Mechanismen f¨

ur die persistente und aus Benut-

zersicht transparente Speicherung der Kooperationsobjekte bildet daher eine zentrale

Forschungsfrage dieser Arbeit. Die Persistenzkonzepte m¨

ussen den Anforderungen

der Offline-Verf¨

ugbarkeit entsprechen, also eine Objektverf¨

ugbarkeit gew¨

ahrleisten,

auch wenn der Benutzer vom Rest der Kooperationsumgebung getrennt ist. In den

folgenden Abschnitten werden Ans¨

atze f¨

ur verteilte Persistenzsysteme in dynami-

schen Peer-to-Peer-Netzwerken insbesondere unter diesem Gesichtspunkt betrach-

tet.

4.3.1 Verteilte Persistenzsysteme

Eine verteilte Speicherung von Daten wird in Peer-to-Peer-Netzwerken oft mit Files-

haring-Anwendungen gleichgesetzt. Tats¨

achlich kamen viele Impulse zu den derzei-

tigen Peer-to-Peer-Speicherl¨

osungen aus diesem Bereich. Das wesentliche Problem

von Peer-to-Peer-basierten Filesharing-Anwendungen ist das Auffinden der im Netz-

werk verf¨

ugbaren Daten. Diese Fragestellung ist mit dem Auffinden der verf¨

ugbaren

Dienste in verteilten Umgebungen verwandt (vgl. Abschnitt 4.2.2).

Einer der fr¨

uhen Filesharing-Dienste, Napster14, benutzte zu diesem Zweck Index-

server, die ein Verzeichnis der Speicherorte der verf¨

ugbaren Dateien bereitstellen.

Zu diesem Zweck schicken die Peers Listen ihrer lokal gespeicherten Dateien an den

Indexserver, der diese in sein Verzeichnis aufnimmt. Sucht ein Peer eine bestimm-

te Datei, fragt er diese beim Indexserver an, der daraufhin m¨

ogliche Speicherorte

zur¨

uckliefert. Die eigentliche Daten¨

ubertragung erfolgt direkt zwischen den Peers

sobald ein Peer mit der Datei gefunden ist. Der Schwachpunkt eines solchen Vorge-

hens ist die Abh¨

angigkeit des Gesamtsystems von eben diesen Indexservern. Ohne

sie k¨

onnen die Daten im Peer-to-Peer-Netzwerk nicht lokalisiert werden.

14Napster ist inzwischen ein kommerzieller Musikdienst, der außer dem Namen kaum noch Gemein-

samkeiten mit dem urspr¨

unglichen Filesharing-Netzwerk besitzt. http://www.napster.com

Mobilit¨

at in der kooperativen Wissensarbeit

102 4.3 Persistenz

Gnutella15 [Karbhari et al., 2004] versucht dieses Manko zu beheben, indem es

Anfragen als Broadcast an verbundene Peers schickt. Sollten diese die gesuchte Da-

tei nicht selber bereitstellen, leiten sie die Anfrage ihrerseits an ihre Nachbar-Peers

weiter. Um das hohe Kommunikationsaufkommen aufgrund einer derartigen Such-

strategie zu reduzieren, bricht die Suche nach einer vorbestimmten Zahl von Wei-

terleitungen der Suchanfrage ab und vermeidet auch eine Ringsuche, bei der bereits

befragte Knoten erneut angefragt werden. Trotz dieser Maßnahmen erzeugt eine der-

artige Suchstrategie noch immer einen immensen Kommunikations-Overhead, ohne

garantieren zu k¨

onnen, dass eine derartige Suche bei Existenz der gew¨

unschten Da-

ten erfolgreich ist.

Distributed Hashtable (DHT)

Eine L¨

osung f¨

ur das Dilemma des Auffindens von Daten in Peer-to-Peer-Netzwerken

bietet das Verteilen der Daten auf die einzelnen Peers nach einem eindeutigen und

reproduzierbaren Schema. Diesen Ansatz verfolgen das Konzept der Distributed Has-

htables, das sich an dem Funktionsprinzip der klassischen Hash-Tabellen orientiert.

Von den zu speichernden Daten wird mittels einer Hash-Funktion16 ein Hash-Wert17

ermittelt, der dann als Index18 dar¨

uber entscheidet, an welcher Position in der Hash-

Tabelle die entsprechenden Daten hinterlegt werden.

Das grundlegende Vorgehen ist hierbei die Indizierung und Zuweisung von Wer-

ten auf feste Positionen einer Tabelle. Dabei hat die Tabelle eine festgelegte Gr¨

oße,

aus der sich ein ebenso fester Adressraum ablesen l¨

asst. Ein solches Verfahren er-

m¨

oglicht einen nahezu direkten Zugriff auf gesuchte Daten. Allerdings bietet dieser

Ansatz als Suchm¨

oglichkeit nur die Form des so genannten ”Exact-Matching“ an.

Anfragen f¨

uhren nur dann zum Erfolg, wenn der Suchbegriff exakt mit dem Wert

ubereinstimmt ¨

uber den der Hashwert erzeugt wurde.

Eine DHT ist eine algorithmische Umsetzung der Abbildung von Indizes aus einer

Hash-Tabelle auf die Rechnerknoten in einem Netzwerk. M¨

oglichkeiten und Eigen-

schaften einer Hash-Tabelle werden so auf Rechnernetze ¨

ubertragen und k¨

onnen

zur Speicherung von Daten, Routing- und Verteilungsinformationen genutzt wer-

den. Die Hash-Tabelle wird dazu auf die Knoten eines Peer-to-Peer-Netzes verteilt

gespeichert. Jeder Knoten eines solchen Netzwerkes ist ein Index in der verteilten

Hash-Tabelle und verwaltet ein Segment des Hash-Bereiches der Daten. Die Seg-

mente werden von den Nachbarknoten im Hash-Bereich begrenzt.

Daten, die in der DHT gespeichert werden sollen, werden ¨

uber eine eindeutige

Hash-Funktion in denselben Wertebereich abgebildet wie die Nertzwerkknoten. Sie

werden auf dem Knoten gespeichert, der ihrem Hash-Wert am ”n¨

achsten“ ist. Die

Berechnung der ”N¨

ahe“ h¨

angt dabei von deren Definition in der verwendeten DHT

15http://www.the-gdf.org/wiki

16Eine Abbildung h:K→Sheißt Hash-Funktion, wenn |K| ≥ |S|gilt.

17Ein Hash-Wert ist ein skalarer Wert, der aus einer komplexeren Datenstruktur (Zeichenketten,

Objekte, . . . ) mittels einer Hash-Funktion berechnet wird.

18Der Index ist eine Positionsangabe innerhalb strukturierter Speicherbereiche.

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 103

Umsetzung ab. ¨

Uber Verfahren der DHTs kann somit effizient herausgefunden wer-

den, welcher Knoten eines Netzwerks f¨

ur ein bestimmtes Datum verantwortlich ist.

In Peer-to-Peer-Netzwerken kennt ein Peer meist nur seine direkten Nachbarn.

Somit k¨

onnen viele Daten nicht direkt an den Zielknoten gesandt werden. Darum

setzen DHTs ein Key-Based Routing (KBR) ein, in dem die Daten gem¨

aß ihres

Hash-Wertes (key) durch das Peer-to-Peer-Netzwerk an ihr Ziel gesandt werden.

Dadurch entsteht ein Routingverfahren in der Anwendungsschicht, das das Routing

der Netzwerkschicht ¨

uberlagert – man spricht daher in Bezug auf DHTs auch von

Overlay-Netzwerken.

Der Weg im physikalischen Netzwerk wird durch eine schrittweise Vorgabe von be-

kannten Zwischenzielen im logischen Netzwerk aus der Anwendungsebene vorgege-

ben. Einen ¨

Uberblick ¨

uber DHT-Systeme inklusive eines Vergleichs zu ”klassischen“

Peer-to-Peer Filesharing-Anwendungen liefert [Balakrishnan et al., 2003].

Inzwischen existieren neben den DHTs weitere Verfahren, die auf das KBR zu-

r¨

uckgreifen. Da DHTs keine gezielte Speicherung von Daten auf bestimmten Knoten

zulassen und somit eine Lokalit¨

at der Daten vermissen lassen, bieten Decentraliced

Object Location and Routing (DOLR) Verfahren einen verteilten Verzeichnisdienst,

der die Speicherposition der Daten statt der Daten selbst speichert.

Besonders im kooperativen Anwendungsfeld wird f¨

ur die Kommunikation ¨

uber das

DHT Overlay-Netzwerk neben der Punkt-zu-Punkt-Kommunikation zwischen zwei

Peers auch eine effiziente Gruppenkommunikation ben¨

otigt. L¨

asst sich Erstere gut

uber DHTs bewerkstelligen, indem eine Nachricht mit der nodeID des Zielknotens

versendet wird, ist eine derart gestaltete Punkt-zu-Punkt Kommunikation mit allen

Knoten einer Gruppe oft ineffizient. Die Nachrichten m¨

ussen dabei auf dem Weg

zu den Zielknoten manche Knoten mehrmals passieren, wenn diese auf dem Pfad

zu mehr als einem der Zielknoten liegen. F¨

ur die Gruppenkommunikation existieren

daher die so genannten CAST Verfahren. Sie implementieren eine effiziente und

verteilte Anycast- und Multicast-Kommunikation in einem KBR-Netzwerk.

Die hier vorgestellten Verfahren auf Basis von DHTs werden von den Peer-to-

Peer-Anwendungen genutzt, um eine fehlerresistente und skalierbare Netzwerkkom-

munikation und Objektspeicherung zu erreichen. [Dabek et al., 2003] ordnet die

einzelnen L¨

osungen folglich in drei Schichten (engl. tiers) ein. Die unterste Schicht

(tier 0) bildet das Key-Based-Routing (KBR). Auf diese Schicht setzen die h¨

oheren

Protokollabstraktionen in tier 1 auf. Dazu geh¨

oren neben dem eigentlichen Distribu-

ted Hashtables (DHT) auch das Decentraliced Object Location and Routing (DOLR)

und Any- und Multicast (CAST). In der obersten Schicht (tier 2) sind alle Anwen-

dungen eingeordnet, die die Protokollabstraktionen nutzen oder gar direkt auf das

KBR zur¨

uckgreifen.

Zu den ersten vier Verfahren, die ein KBR f¨

ur Peer-to-Peer-Netzwerke bereit-

stellen geh¨

oren CAN [Ratnasamy et al., 2001], Chord [Stoica et al., 2001a], Pastry

[Rowstron und Druschel, 2001a] und Tapestry [Zhao et al., 2004]. Sie stellen neben

der Routing-Schicht (tier 0) auch einen Teil der Protokollabstraktionen aus tier 1 be-

reit. Inzwischen wurden einige der Verfahren stark weiterentwickelt und sind Vorbild

f¨

ur neue verbesserte Implementierungen geworden. Als Beispiel ist nach dem Vorbild

Mobilit¨

at in der kooperativen Wissensarbeit

104 4.3 Persistenz

von Pastry Bamboo [Rhea et al., 2005b] entstanden. Dieses kann besser auf ¨

Ande-

rungen im Peer-to-Peer-Verbund reagieren. Aus Chord ist Kademlia [Maymounkov

und Mazi`eres, 2002] hervorgegangen, welches u. a. in den Filesharing-Anwendungen

eMule19 und Bittorrent20 eingesetzt wird.

Um eine Kompatibilit¨

at zwischen den unterschiedlichen Implementierungen herzu-

stellen, schl¨

agt [Dabek et al., 2003] vor, an den Schnittstellen zwischen den Schich-

ten eine einheitliche Schnittstelle (Application Programming Interface (API)) zu

schaffen. Diese w¨

urde den Entwicklern von Peer-to-Peer-Anwendungen erlauben,

die unterschiedlichen DHT-Verfahren gegeneinander auszutauschen, bzw. mit ver-

schiedenen Overlay-Netzwerken zusammenzuarbeiten. Die meisten der derzeitigen

Anwendungen sind aber noch klar einem bestimmten DHT-Verfahren zugeordnet.

F¨

ur Pastry existieren mit PAST [Rowstron et al., 2001] ein verteilter Objektspei-

cher, mit Scribe [Castro et al., 2002] eine Multicasting L¨

osung und mit Splitstream

[Castro et al., 2003] sogar eine Streaming-Anwendung. Auf Chord setzt das verteilte

Dateisystem CFS [Dabek et al., 2001] auf. Tapestry nutzen OceanStore [Kubiato-

wicz et al., 2000] als ewigen Objektspeicher und Bayeux [Zhuang et al., 2001] als

Multicast-Anwendung.

W¨

ahrend die meisten der genannten Anwendungen Protokollabstraktionen in tier

1nutzen, gibt es auch Ausnahmen, die wie z. B. die Internet Indirection Infrastruc-

ture (I3) [Stoica et al., 2002] lediglich das Key-based Routing in tier 0 nutzen.

I3 erlaubt eine asynchrone Datenkommunikation in Peer-to-Peer Netzwerken und

setzt dazu auf Chords KBR auf. Diese Unterst¨

utzung asynchroner Kommunikation

zwischen den Peers wird zus¨

atzlich in ROAM genutzt, um in einem Peer-to-Peer-

Netzwerk der Mobilit¨

at der Peers st¨

arker Rechnung tragen zu k¨

onnen [Zhuang et al.,

2003]. Einen ¨

Uberblick ¨

uber die Zusammenh¨

ange der vorgestellten DHT-basierten

Protokolle und Peer-to-Peer-Anwendungen gibt Abbildung 4.3.

Eine Aussage ¨

uber die generelle Eignung DHT-basierter Persistenzsysteme f¨

ur die

mobil-verteilte Kooperationsumgebungen kann nur schwer getroffen werden. Zum

einen spannen DHT-Netzwerke selbstverwaltete und fehlerresistente Anwendungs-

umgebungen auf, zum anderen verf¨

ugen sie derzeit kaum ¨

uber L¨

osungsans¨

atze f¨

eine Offline-Verf¨

ugbarkeit der gemeinsam genutzten Datenbest¨

ande. Um das Po-

tential der DHTs f¨

ur die gew¨

unschte Kooperationsumgebung zu durchleuchten wird

daher zun¨

achst ein vielversprechender Vertreter bez¨

uglich der Etablierung einer mo-

bilit¨

atsfreundlichen verteilten Persistenz durchleuchtet.

Realisierung einer DHT-basierten Persistenzschicht am Beispiel von

Pastry und PAST

Das effiziente Auffinden von Objekten und das ¨

Ubertragen von Nachrichten sind

Schl¨

usselfaktoren einer verteilt verwalteten und gespeicherten Kooperationsumge-

bung. Die Eigenschaften des Routingsverfahrens und die Strategien zur Replikation

der Objekte innerhalb des verteilten Speichers bestimmen wesentlich die Eignung der

19http://www.emule-project.net

20http://www.bittorrent.com/

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 105

Legende:

CAN Chord

Bamboo

OceanStore

(Pond)

Bayeux

PAST

SCRIBE

SplitStream

OpenDHT

CFS

...

Pastry Tapestry

... Overlay-Netzwerk-Protokoll

Anwendungen

inspiriert von

genutzt für

Kademlia

Bittorrent

eMule

Abbildung 4.3: Auf DHTs basierende Overlay-Netzwerk-Protokolle und deren An-

wendungen

Persistenzschicht f¨

ur eine mobil-verteilte Kooperationsumgebung gem¨

aß den Anfor-

derungen in Kapitel 3. Daher sollen nun stellvertretend f¨

ur die Gruppe der DHT

Systeme die grundlegenden Mechanismen von Pastry inklusive der Persistenzschicht

PAST und der Any- und Multicast L¨

osung SCRIBE betrachtet werden (Die Be-

trachtung von SCRIBE erfolgt im Abschnitt Ereigniskontrolle (4.4)). Die Wahl fiel

aus zwei Gr¨

unden auf Pastry und seine Anwendungen: Zum einen handelt es sich um

etablierte Vertreter der Gruppe der DHT-L¨

osungen und zum anderen erg¨

anzen sich

die zur Verf¨

ugung gestellten Mechanismen zu den ben¨

otigten Grundfunktionalit¨

aten

einer Kooperationsumgebung. Die Diskussion eines mobil-verteilten Kooperations-

systems auf Basis dieser Verfahren findet sich Kapitel 5.

Das Design von Pastry beinhaltet Mechanismen f¨

ur ein selbst organisierendes,

virtuelles Netzwerk. In solch einem Netzwerk hat jeder Netzwerkknoten die Aufgabe,

eingehende Nachrichten zu verarbeiten und eigenst¨

andig weiterzuleiten. Es erfolgt

keinerlei Steuerung der Nachrichtenvermittlung von außen.

Der Adressraum von Pastry hat eine Gr¨

oße von 128-Bit. Innerhalb dieses Adress-

raumes verf¨

ugt jeder Knoten ¨

uber eine eindeutige Pastry-Adresse (nodeID)21. Mit-

tels einer zuf¨

alligen Vergabe der nodeIDs wird eine gleichm¨

aßige Verteilung der

Knoten in dem Adressraum sichergestellt22. Diese zuf¨

allige Verteilung verhindert

mit großer Wahrscheinlichkeit, dass ¨

ortlich benachbarte Knoten auch im logischen

Pastry-Adressraum direkt nebeneinander liegen. Ein Ausfall in einem physikalischen

Netzwerksegment hat so nicht gleich den Ausfall eines kompletten Pastry Segments

21In einem Pastry Netzwerk sind somit bis zu 2128 −1 Knoten m¨

oglich.

22Eine alternative M¨

oglichkeit ist es, die nodeIDs aufgrund eindeutiger Daten, wie zum Beispiel der

Macadresse oder dem Namen des Rechners, automatisch erzeugen zu lassen.

Mobilit¨

at in der kooperativen Wissensarbeit

106 4.3 Persistenz

Abbildung 4.4: Ein physikalisches Netzwerk von Knoten wird in einen logischen

Adressraum abgebildet. Hierbei impliziert die ¨

ortliche N¨

ahe zweier Knoten keines-

wegs auch eine N¨

ahe der logischen Adressen und umgekehrt

zur Folge – verteilt auftretende L¨

ucken in der logischen Netzwerkstruktur lassen

sich oft ohne eine komplette Neustrukturierung des Netzwerks schließen. Die Ent-

kopplung der physikalischen Position der Netzwerkknoten vom logischen Adressraum

wird in Abbildung 4.4 noch einmal verdeutlich.

Nachrichten23, die innerhalb des Pastry Netzwerkes versandt werden sollen, be-

kommen einen Schl¨

ussel (key) aus dem gleichen Adressraum wie die nodeIDs zuge-

ordnet. Eine Nachricht wird dabei stets an den Knoten gesandt, dessen nodeID dem

Nachrichtenschl¨

ussel am n¨

achsten liegt.

[Rowstron und Druschel, 2001a] beschreiben die prinzipielle Idee des Routingver-

fahren wie folgt: Nachrichtenschl¨

ussel und nodeID werden als Ziffernfolgen zur Basis

2b(bist ein beliebiger aber fester Wert) angenommen. In jedem Routingschritt wird

die Nachricht vom aktuellen Knoten an einen Knoten ¨

ubergeben, dessen nodeID

eine Ziffer (oder bBits) mehr ¨

Ubereinstimmung mit dem Nachrichtenschl¨

ussel hat

als der aktuelle Knoten. Die ¨

ubereinstimmenden Ziffern werden als Pr¨

afix (engl.

prefix) bezeichnet. Schritt f¨

ur Schritt stimmen so immer mehr Stellen des Nach-

richtenschl¨

ussels mit der nodeID des aktuellen Knotens ¨

uberein. Kann bei einem

Routingschritt kein Knoten mit l¨

angerem Pr¨

afix gefunden werden, wird der Knoten

ermittelt, der den numerisch geringsten Abstand zu dem Nachrichtenschl¨

ussel hat.

Dieser ist der Zielknoten der Nachricht.

23Nachrichten k¨

onnen u. a. Anfragen, Anweisungen, zu speichernde Daten oder auch Verwaltungs-

informationen beinhalten.

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 107

Aufgrund des Designs des Routings in Pastry erreicht ein Schl¨

ussel in einem Pa-

stry-Netzwerk mit NKnoten und aktuellen Routingtabellen sein Ziel in dlog2bNe

Schritten. Dabei ist bein beliebig gew¨

ahlter Konfigurationsparameter, der die Gr¨

ße der Routingtabellen bestimmt. Pastry initialisiert normalerweise b= 4 [Rowstron

und Druschel, 2001a].

Verwaltungsinformationen F¨

ur das Routing sind Angaben anderer Knoten und

weitere Informationen n¨

otig. Diese werden in jedem Knoten in drei Tabellen festge-

halten. Hierbei wird zwischen Routing Table,Neighborhood Set und Leaf Set unter-

schieden:

Die Routing Table (R) enth¨

alt dlog2bNeZeilen. Jede Zeile enth¨

alt 2b−1 Eintr¨

age,

welche aus einer nodeID und der dazugeh¨

origen Netzwerkadresse bestehen. Dabei

enth¨

alt die Zeile k(beginnend bei 0) immer nodeIDs mit gleichem Pr¨

afix der L¨

ange

k. Dieses Pr¨

afix stimmt mit den ersten kStellen der eigenen nodeID ¨

uberein. Ab

der Stelle k+ 1 differieren die nodeIDs von der eigenen nodeID. Die Eintr¨

age je-

der Zeile sind von links nach rechts nummerisch aufsteigend sortiert. Die Wahl des

Konfigurationsparameters bbestimmt also den Trade-off zwischen Gr¨

osse der Rou-

ting Tabelle (dlog2bNe × (2b−1)) und der Anzahl der maximalen Routing-Schritte

(dlog2bNe), die ben¨

otigt werden, um eine Nachricht zwischen zwei beliebigen Knoten

des Netzwerkes zu versenden.

Das Neighborhood Set (M) enth¨

alt eine Liste der – gem¨

aß eines festgelegten Maßes

der N¨

ahe (engl. Proximity Metric)24 – n¨

achsten |M|Nachbarn. Sie dient nicht direkt

dem Routingverfahren, sondern wird als Entscheidungshilfe bei der Erstellung der

Routing-Eintr¨

age eingesetzt.

Das Leaf Set (L) enth¨

alt |L|

2Eintr¨

age, die kleiner als die eigene nodeID sind und

|L|

2Eintr¨

age, die gr¨

oßer als die eigene nodeID sind. Die Eintr¨

age im Leaf Set haben

die besondere Eigenschaft, dass ihre nodeID numerisch am n¨

achsten bei der eige-

nen nodeID liegen. Dadurch befinden sich diese Knoten im Adressraum in logischer

N¨

ahe, was allerdings keinen R¨

uckschluss auf ihre physikalische N¨

ahe zul¨

asst, da die

Vergabe der nodeID zuf¨

allig geschieht. Das Leaf Set ist direkter Bestandteil des Rou-

tingverfahrens und bestimmt zu einem wesentlichen Teil auch die Ausfallsicherheit

des Netzwerkes. Nachrichten im Pastry-Netzwerk erreichen nur dann garantiert ihr

Ziel, wenn nicht mehr als j|L|

2kbenachbarte Knoten gleichzeitig ausfallen. |L|ist ein

Konfigurationsparameter und hat ¨

ublicherweise einen Wert von 16 oder 32. Abbil-

dung 4.5 veranschaulicht den Zusammenhang von Routingverfahren und Tabellen

anhand eines Beispiels.

Routing Jede Nachricht im Pastry-Netzwerk wird ¨

uber einen Schl¨

ussel (key) iden-

tifiziert, der aus demselben Wertebereich wie die nodeIDs stammt. W¨

ahrend dies bei

Nachrichten die nodeID des Zielknotens sein kann, ist es bei zu speichernden Ob-

jekten ein mittels einer fest definierten Hash-Funktion ¨

uber eine bestimmte Objek-

24Das Maß der N¨

ahe definiert, wann ein Knoten einem anderen nahe ist. N¨

ahe kann z. B. eine

besonders gute physikalische Netzwerkverbindung zwischen den Knoten sein.

Mobilit¨

at in der kooperativen Wissensarbeit

108 4.3 Persistenz

Abbildung 4.5: Verwaltungstabellen und grafische Darstellung der Routinginfor-

mationen eines Pastry-Knotens mit der nodeID 10233102,b= 2 und l= 8 (Alle

Ziffern haben die Basis 4)

teigenschaft, wie den Objektnamen oder den Inhalt, ermittelter Wert. Das Pastry-

Routingverfahren stellt dabei sicher, dass Nachrichten wie Objekte auch zu den

errechneten Zielknoten gelangen.

Sobald eine Nachricht mit dem Schl¨

ussel Deinen Knoten Aerreicht, wird zun¨

achst

gepr¨

uft, ob dieser Nachrichtenschl¨

ussel im Wertebereich der im Leaf Set gespeicher-

ten nodeIDs liegt und somit von seiner logischen Adresse her in unmittelbarer N¨

ahe

des aktuellen Knotens liegt. In diesem Fall wird die Nachricht direkt an den Knoten

aus dem Leaf Set gesandt, dessen nodeID dem Nachrichtensch¨

ussel Dnumerisch

am n¨

achsten liegt, wobei auch die eigene nodeID ber¨

ucksichtigt wird. Sollte jedoch

der Schl¨

ussel Dnicht innerhalb des Wertebereichs des Leaf Set liegen, wird ¨

uber

die Routing-Tabelle ein Knoten ermittelt, der eine um eine Stelle l¨

angeres Pr¨

afix als

der eigene Knoten besitzt. Dazu wird als Erstes die Anzahl der ¨

ubereinstimmenden

Stellen im Pr¨

afix zwischen der eigenen nodeID Aund dem Schl¨

ussel Dermittelt.

Da die Zeile kdie nodeIDs enth¨

alt, die auf kStellen mit der nodeID des aktuellen

Knotens ¨

ubereinstimmen, schl¨

agt das Verfahren in der Zeile k+1 der Routingtabelle

nach. Sollte dort kein passender Eintrag vorhanden sein oder der korrespondierende

Knoten nicht erreichbar sein, wird die Nachricht unter Ber¨

ucksichtigung der Verwal-

tungstabellen zu jenem Knoten weitergeleitet, der ¨

uber die gleiche Pr¨

afixl¨

ange wie

der aktuelle Knoten Azum Nachrichtenschl¨

ussel Dverf¨

ugt, jedoch numerisch n¨

aher

an dem Nachrichtenschl¨

ussel Dliegt.

Als Abwandlung dieses Routingverfahrens, das lediglich die Anzahl der Stellen der

Pr¨

afix¨

ubereinstimmung einbezieht, erlaubt Pastry, die N¨

ahe der Knoten zueinander

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 109

Abbildung 4.6: Bei Routing-Entscheidungen, die das Lokalit¨

atsprinzip nicht be-

r¨

ucksichtigen, werden zwar g¨

ultige Routingschritte in den Knoten durchgef¨

uhrt,

diese f¨

uhren aber nicht notwendigerweise zu einer optimalen Gesamtroute

gem¨

aß des vorgegebenen Maßes der N¨

ahe zu betrachten. Dieses Vorgehen erlaubt,

die Lokalit¨

at der Knoten f¨

ur den Aufbau der Verwaltungtabellen zu ber¨

ucksichtigen

und so ung¨

unstige Routing-Pfade innerhalb des Pastry-Netzwerkes zu vermeiden.

Abbildung 4.6 zeigt je einen Routing-Pfad mit und ohne Ber¨

ucksichtigung des Lo-

kalit¨

atprinzips. [Rowstron und Druschel, 2001a] weisen darauf hin, dass Pastry bei

Ber¨

ucksichtigung des Maßes der N¨

ahe beim Aufbau der Verwaltungstabellen und

Durchf¨

uhren des Routings einen stets ”guten“ Routing-Pfad w¨

ahlt.

Selbstorganisation Aufgrund der Selbstorganisation im Pastry-Netzwerk, muss

ein neuer Knoten mit nodeID Xzun¨

achst einen Einstiegsknoten ausfindig machen25,

dessen nodeID als Abezeichnet sei. Xschickt zun¨

achst eine join-Nachricht an den

Knoten A. Dabei ist der Nachrichtenschl¨

ussel gleich der nodeID Xdes neuen Kno-

tens. Von Einstiegsknoten wird die join-Nachricht ¨

uber das Pastry-Routingverfahren

zu dem Knoten Z gesandt, dessen nodeID dem Nachrichtenschl¨

ussel X numerisch am

n¨

achsten ist. Alle Knoten auf dem Pfad vom Einstiegsknoten Azum Zielknoten Z

25Das Aufsp¨

uren von Einstiegsknoten in das Pastry-Netzwerk kann z. B. durch einen so genannten

expanding ring mutlicast geschehen.

Mobilit¨

at in der kooperativen Wissensarbeit

110 4.3 Persistenz

Abbildung 4.7: Initialisierung der Verwal-

tungstabellen beim Anmelden eines neuen

Knotens in ein Pastry-Netzwerk

Abbildung 4.8: Pastrys Selbst-

organisation im Fall einer Netz-

werksegmentierung

senden zugleich die eigenen Verwaltungstabellen an den neuen Knoten X, der aus

diesen Informationen seine eigenen Verwaltungstabellen initialisiert:

Da der Einstiegsknoten Ain der N¨

ahe vom neuen Knoten Xliegt, ¨

ubernimmt der

neue Knoten dessen Neighborhood Set. Der Knoten Zwiederum ist der Knoten mit

dem geringsten numerischen Distanz zur nodeID Xdes neuen Knotens und liefert

daher sein Leaf Set als initiales Leaf Set f¨

ur den neuen Knoten X.

Der Inhalt der Routing Table wird in mehreren Schritten ermittelt. Die anfangs

leere Routing Table wird von Zeile 0 an erzeugt. Im Normalfall haben die nodeIDs

Aund Xkein gemeinsames Pr¨

afix. Daher kann die Zeile 0 der Routing Table von A

in die Zeile 0 der Routing Table von X¨

ubernommen werden. Nacheinander steuert

jeder Knoten auf dem Nachrichtenpfad die fehlenden Zeilen bis hin zur Zeile ibei,

wobei idie L¨

ange des mit dem Nachrichtenschl¨

ussel X¨

ubereinstimmenden Pr¨

afixes

ist (vgl. Abbildung 4.7).

Bei einem ¨

ubereinstimmenden Pr¨

afix mit iStellen des Einstiegsknotens Aund des

neuen Knotens Xwerden die ersten iZeilen der Routing Table von Ain die von X

ubernommen. Abschließend informiert der neue Knoten alle in seinen Verwaltungs-

tabellen eingetragenen Knoten durch das Senden der eigenen Verwaltungstabellen

[Rowstron und Druschel, 2001a].

Sollte ein Knoten im Pastry-Netzwerk ohne Warnung ausfallen, kann dies unter

anderem dadurch festgestellt werden, dass er nicht mehr ¨

uber seine topologischen

Nachbarn erreichbar ist. In einem solchen Fall m¨

ussen die Verwaltungstabellen Leaf

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 111

Set,Routing Table und Neighborhood Set reorganisiert werden, um ein korrektes

Routing zu gew¨

ahrleisten.

Um einen ausgefallenen Knoten im Leaf Set eines Knotens zu ersetzten wird zuerst

der Knoten mit der gr¨

oßten erreichbaren nodeID in der entsprechenden H¨

alfte des

Leaf Sets kontaktiert, dessen Leaf Set angefordert und mit dem eigenen verglichen.

Nach dem Pr¨

ufen der Erreichbarkeit wird der Knoten in das eigene Leaf Set ¨

uber-

nommen, der numerisch am n¨

achsten zum ausgefallenen Knoten liegt. Diese neue

nodeID ersetzt nun die nodeID des ausgefallenen Knotens. So hat jeder Knoten die

M¨

oglichkeit, sich selbst zu aktualisieren, solange nicht mehr als j|L|

2kKnoten des

Leaf Sets gleichzeitig ausfallen.

Bei einem Ausfall eines Knotens in der Routing Table werden alle anderen node-

IDs aus der Zeile der ausgefallenen nodeID der Reihe nach kontaktiert. Dabei wird

gepr¨

uft, ob diese in der Routing Table an der Stelle des ausgefallen Knotens einen

Eintrag haben, der erreichbar ist. Ist dies nicht der Fall, wird in der n¨

achsten Zeile

dasselbe Verfahren angewandt. So wird sichergestellt, dass ein im Pastry-Netzwerk

vorhandener Zielknoten auf jeden Fall gefunden wird.

Bei Ausfall eines Knotens im Neighborhood Set werden die noch verf¨

ugbaren Kno-

ten aus dem Neighborhood Set kontaktiert und deren Neighborhood Sets angefordert.

Die neuen nodeIDs werden gem¨

aß des Maßes der N¨

ahe auf ihre N¨

ahe zum eigenen

Knoten gepr¨

uft. Die n¨

achsten Knoten werden dann in das eigene Neighborhood Set

ubernommen.

Pastry ist also in der Lage, selbstst¨

andig auf Knotenausf¨

alle zu reagieren und die

Verwaltungstabellen zu korrigieren. Dabei nutzen die Knoten stets die Informan-

tionen der verbliebenen Knoten im Netzwerk, um sich zu reorganisieren. [Rowstron

und Druschel, 2001a] zeigt dar¨

uber hinaus M¨

oglichkeiten auf, wie auf sporadische

Knotenausf¨

alle und b¨

osartige Knoten im Netzwerk reagiert werden kann.

Durch die selbstst¨

andige Reorganisation des Pastry-Netzwerkes kann es bei dem

Ausfall von Knoten vorkommen, dass ein Pastry-Netzwerk partitioniert und sich

uber eine Reorganisation der Verwaltungstabellen voneinander unabh¨

angige Netz-

werke bilden. Um derart getrennte Pastry-Netzwerke wieder zusammenf¨

uhren zu

k¨

onnen, versuchen die Knoten eines Pastry-Netzwerkes ¨

uber periodische Expanding

Multicast-Nachrichten andere Pastry-Netzwerke zu finden und sich mit diesen ¨

uber

eine Reorganisation zu vereinen. Dieser Vorgang wird in Abbildung 4.8 noch einmal

veranschaulicht.

Verteilte Speicherung von Objekten in PAST

Das Pastry Routing-Verfahren implementiert ein selbstorganisiertes und gegen Kno-

tenausf¨

alle resistentes Overlay-Netzwerk, in dem Nachrichten effizient und sicher zu

den teilnehmenden Knoten gesandt werden k¨

onnen. F¨

ur die verteilte Speicherung

von Objekten in dem Pastry-Netzwerk existiert mit PAST [Rowstron und Druschel,

2001b] eine Persistenzschicht f¨

ur Pastry, die neben der verteilten Speicherung und

Suche von Objekten auch eine Replikation und Verschl¨

usslung der gespeicherten

Daten erlaubt. Ziel von PAST ist die persistente Speicherung von Daten in einem

Mobilit¨

at in der kooperativen Wissensarbeit

112 4.3 Persistenz

DHT-basierten Peer-to-Peer-Netzwerk unter den Gesichtspunkten der Verf¨

ugbarkeit,

Skalierbarkeit und Sicherheit. PAST stellt zu diesem Zweck einen globalen Speicher

ohne zentrale Verwaltung zur Verf¨

ugung. Bei der Entwicklung der PAST-Architektur

wurden folgende Designziele ber¨

ucksichtigt:

•Effizienz: F¨

ur eine effiziente Verwaltung der Daten in einem Peer-to-Peer-

Netzwerk wird das Pastry-Routingverfahren zum Verteilen und Anfordern von

Daten eingesetzt. Dies erlaubt Antworten auf Suchanfragen in durchschnittlich

weniger als dlog2bNeSuchschritten.

•Replikation: Die Objekte werden in einen engen Bereich im logischen Adress-

raum des Pastry-Netzwerkes repliziert. Durch die zuf¨

allige Natur des Pastry-

Adressraums bedeutet dies eine weit gestreute Replikation in das physikalische

Netzwerk. Die Replikation kommt ebenfalls ohne zentrale Steuerung aus.

•Dezentralisierte Datenverwaltung: Dank des Pastry-Netzwerkes besitzt jeder

Knoten die Informationen, die er ben¨

otigt, um auf ein Objekt zuzugreifen. Die

zuf¨

allige Natur des Adressraums stellt dabei eine balancierte Speicherung der

Objekte im Netzwerk sicher. Durch Zwischenspeichern h¨

aufig gestellter Anfra-

gen (Caching) werden k¨

urzere Antwortzeiten erreicht [Druschel und Rowstron,

2001].

•Quotaverwaltung: Damit der im Pastry-Netz zur Verf¨

ugung stehende Speicher

nicht unkontrolliert verbraucht wird, kann jedem Benutzer eine feste Speicher-

grenze zugewiesen werden [Rowstron et al., 2001].

PAST erlaubt jedem Knoten, Objekte in den verteilten Speicher abzulegen oder

selbst Speicher anzubieten. Die Knoten verwaltet PAST mit der von Pastry erzeug-

ten 128 Bit langen nodeID. Eine Datei besitzt im verteilten Speicher eine 160 Bit

lange fileID die beim Aufruf der insert()-Funktion erzeugt wird. Die fileID ist

ein Hash-Wert, der aus dem gegebenen Dateinamen, dem ¨

offentlichen Schl¨

ussel des

Besitzers und einer zuf¨

alligen Komponente berechnet wird. Die zuf¨

allige Kompo-

nente sorgt daf¨

ur, dass die Datei eine mit hoher Wahrscheinlichkeit eindeutige fileID

erh¨

alt. Zus¨

atzlich wird zu jeder Datei ein Zertifikat mit den Eintr¨

agen File-ID,Repli-

kationsfaktor (k),Streuungsfaktor,Einf¨

ugedatum und Hash-Wert des Dateiinhaltes

erzeugt. Das Zertifikat wird außerdem durch den Besitzer der Datei signiert und

danach zusammen mit der verschl¨

usselten26 Datei im PAST-Netzwerk gespeichert.

Zur Speicherung einer Datei im PAST-Netzwerk wird zun¨

achst mittels des Pastry-

Routingverfahrens ein passender Zielknoten ermittelt, dessen nodeID den numerisch

geringsten Abstand zur fileID hat. Dabei werden nur die 128 h¨

ochstwertigen Bits der

160 Bit langen fileID f¨

ur den Vergleich herangezogen. Gem¨

aß des Replikationsfaktors

(k) werden aus dem Leaf Set des Zielknotens kim logischen Adressraum direkt

benachbarte Knoten ausgew¨

ahlt, deren nodeIDs numerisch am n¨

achsten zur fileID

liegen. Auf diesen Knoten wird eine Kopie der Datei abgelegt (siehe Abbildung 4.9).

26Weiterf¨

uhrende Infomationen zum Zugriffsschutz in PAST finden sich in [Rowstron et al., 2001].

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 113

Abbildung 4.9: Das Replikationsverfahren von PAST mit dem Replikationsfaktor

k= 4

Die N¨

ahe der gespeicherten Replikate im logischen Adressraum hat eine breite

Streuung der Replikate im physikalischen Netzwerk zur Folge. Andererseits sind die

Replikate im logischen Adressraum leicht aufzufinden. Der Replikationsfaktor (k)

bestimmt somit die Verf¨

ugbarkeit der Datei und kann je nach Bedarf frei gew¨

ahlt

werden27. PAST bietet kein Verfahren um Daten verl¨

asslich zu l¨

oschen. Der Besitzer

einer Datei kann diese jedoch vom speichernden Knoten zur¨

uckfordern. Replikate auf

Knoten, die das Netzwerk verlassen haben, sind von dieser R¨

uckforderung allerdings

nicht betroffen. Des Weiteren erfolgt auf den Knoten des PAST Netzwerkes eine

Zwischenspeicherung von Dateien (Caching), um h¨

aufig angefragte Daten schnell

verf¨

ugbar zu machen. Auch diese zwischengespeicherten Dateien werden eventuell

durch die R¨

uckforderung nicht erreicht.

Soll eine zuvor in PAST-Netzwerk gespeicherte Datei angefordert werden, wird die

Anfrage zu dem erreichbaren Knoten geleitet, dessen nodeID numerisch am n¨

achsten

zu den 128 h¨

ochstwertigen Bits der gesuchten fileID ist. Wenn einer der kreplizie-

renden Knoten im Netzwerk verf¨

ugbar ist, wird dieser Knoten aufgrund der Eigen-

schaften des Pastry-Routingverfahrens gefunden, so kann die Datei an die nodeID

des anfragenden Knotens gesandt werden. Aufgrund der zuf¨

alligen Verteilung der

Replikate im physikalischen Netzwerk, der dezentralen selbstorganisierenden Netz-

werkverwaltung und einer unabh¨

angigen Netzwerkanbindung der kreplizierenden

Knoten wird mit hoher Wahrscheinlichkeit einer der kKnoten verf¨

ugbar sein.

27Auf Grund der Nutzung des Leaf Sets f¨

ur die Auswahl der Replikationsknoten muss gelten k < |L|.

Mobilit¨

at in der kooperativen Wissensarbeit

114 4.3 Persistenz

Diskussion DHT-basierter Persistenzkonzepte

PAST schafft durch die verwendete Speicherstrategie einen globalen und selbstor-

ganisierenden Speicher basierend auf Peer-to-Peer-Technologie. Durch die Replika-

tionsstrategie, die eine breite Verteilung der Replikate im physikalischen Netzwerk

verfolgt, wird zudem eine hohe Verf¨

ugbarkeit der gespeicherten Daten unabh¨

angig

von der Zuverl¨

assigkeit der einzelnen Netzwerkknoten erreicht. Allerdings l¨

asst sich

wegen der synchronen Befehlskommunikation in PAST eine replizierte Datei nicht

zur¨

uckfordern (l¨

oschen), wenn replizierende Knoten zeitweise nicht verf¨

ugbar sind.

Ahnlich wie in PAST sind auch die weiteren auf DHT-Verfahren basierenden Per-

sistenzkonzepte f¨

ur ein m¨

oglichst zuverl¨

assiges Gesamtsystem ausgelegt und betrach-

ten zugreifende Knoten nur im Online-Fall. Vom Netzwerk getrennt haben sie keinen

Zugriff auf die Persistenz. Das OceanStore Projekt verfolgt wie PAST ebenfalls die

Bereitstellung eines globalen verteilten Speichers, in dem Dateien nach Aussagen

der Entwickler nahezu ewig verbleiben sollen [Kubiatowicz et al., 2000]. Um die

Speicherung der Daten so zuverl¨

assig als m¨

oglich zu gestalten, versucht OceanStore

Daten in Bl¨

ocke zerteilt auf zuverl¨

assigen Knoten zu speichern. Zus¨

atzlich bietet

OceanStore neben einer Replikation auch die Versionierung der gespeicherten Daten

an. Es kennt keine Methoden, um Daten (oder deren Versionen) wieder aus dem

globalen Speicher zu entfernen. OceanStore ist f¨

ur den kommerziellen von profes-

sionellen Dienstleistern verwalteten Einsatz ausgelegt. Mit Pond [Rhea et al., 2003]

existiert auch ein erster Prototyp und ist, obwohl urspr¨

unglich f¨

ur Tapestry [Zhao

et al., 2004] entworfen, inzwischen auch f¨

ur den Pastry-Ableger Bamboo [Rhea et al.,

2005b] verf¨

ugbar.

Bamboo bietet auch die Grundlage f¨

ur OpenDHT [Rhea et al., 2005a], das ebenfalls

einen global verf¨

ugbaren Speicher implementiert. Die Besonderheit von OpenDHT

besteht in einer frei verf¨

ugbaren Infrastruktur, die f¨

ur alle Interessenten zug¨

anglich

ist. Allerdings sind die Daten in OpenDHT nur f¨

ur einen gewissen Zeitraum ge-

speichert und werden nach einer begrenzten Lebenszeit wieder aus dem verteilten

Speicher entfernt.

Das Cooperative FileSystem (CFS) [Dabek et al., 2001] ist ein auf dem Chord Pro-

tokoll [Stoica et al., 2001b] aufsetzendes Dateisystem, das ¨

ahnlich wie OceanStore

Dateien in Bl¨

ocke zerteilt und verteilt auf dem speichernden Knoten ablegt. Au-

ßerdem werden die Bl¨

ocke auf mehrere Knoten repliziert. CFS versucht dabei aber

die Komplexit¨

at von OceanStore zu vermeiden und bietet daher keine aufwendigen

Versionierungsmechanismen und Knotenauswahlverfahren.

Allen Konzepten ist gemeinsam, dass sie ihren Fokus auf die Aufrechterhaltung des

Gesamtsystems legen. Sie kennen keine Mechanismen, um bestimmte Daten auf ei-

nem Knoten verf¨

ugbar zu halten, wenn dieser offline ist. Eine gezielte Replikation auf

eine fest definierte Gruppe von Knoten ist ebenfalls nicht vorgesehen. Des Weiteren

kennt nur OceanStore eine Versionierung der gespeicherten Daten, die es erlauben

w¨

urde, Versionskonflikte bei gemeinschaftlich bearbeiteten Daten zu identifizieren

und zu l¨

osen.

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.1 Verteilte Persistenzsysteme 115

Persistenz von Kooperationsobjekten

auf verteilten Knoten

Skalierbarkeit Verfügbarkeit

online offline

Verteilung ohne Redundanz

Lokal, Zugriffsbasiert, Hashing

Verteilung mit wahlloser Redundanz

Hashing mit Replikation, Broadcasting

Verteilung mit gezielter Redundanz

Gruppenbasierte Replikation

Abbildung 4.10: Trade-off der Strategien zur Bereitstellung von persistenten Ob-

jekten auf mobilen und verteilten Knoten

Diese Designentscheidungen lassen die betrachteten Persistenzsysteme in ihrer der-

zeitigen Form f¨

ur eine mobile-verteilte Kooperationsumgebung ungeeignet erschei-

nen. Offensichtlich existiert ein Trade-off zwischen der Skalierbarkeit des Persistenz-

systems und der Verf¨

ugbarkeit der gespeicherten Daten (vgl. Abbildung 4.10). In-

teressant bleibt aber die M¨

oglichkeit der Bereitstellung einer selbstorganisierenden,

zuverl¨

assigen und effizienten Peer-to-Peer-Persistenzschicht. Durch eine Anpassung

der Replikationsstrategien und die Erg¨

anzung um eine verteilte Versionskontrolle

k¨

onnen DHT-basierte Persistenzsysteme die gew¨

unschten Eigenschaften prinzipiell

erf¨

ullen.

Die Konzepte der Distributed Hashtables bieten somit einen geeigneten Ausgangs-

punkt f¨

ur die gew¨

unschte Persistenzsschicht mobil-verteilter Wissensr¨

aume. Der Ent-

wurf eines Konzeptes f¨

ur eine auf DHT-Protokollen basierenden Persistenzschicht,

das sich gezielt an den Bed¨

urfnissen von mobil-verteilten Kollaborationsszenarien,

wie in Kapitel 2 vorgestellt, orientiert, ist somit eine der zentralen Forschungsfra-

gen dieser Arbeit. Um zus¨

atzlich den Zugang zu solch einer Persistenzschicht zu

erleichtern, ist es wichtig, die Komplexit¨

at der DHT-Protokolle f¨

ur die Entwick-

ler und Anwender bei der Nutzung des verteilten Speichers zu verbergen. Um diese

M¨

oglichkeiten zum Verbergen dieser Komplexit¨

at auszuloten, sind Ans¨

atze f¨

ur einen

transparenten Zugriff auf einen verteilten Speicher zu betrachten.

Mobilit¨

at in der kooperativen Wissensarbeit

116 4.3 Persistenz

4.3.2 Verteilte Persistenz als gemeinsamer Speicher

Der selbstorganisierende Charakter von verteilten Speicherkonzepten und die Hete-

rogenit¨

at der zugrunde liegenden Netzwerkumgebungen verlangen Entwicklern wie

Benutzern f¨

ur den Zugriff auf derartige Systeme ein Verst¨

andnis der grundlegenden

Konzepte und Mechanismen ab. Die Basistechnologien sind dar¨

uber hinaus nicht

gegeneinander austauschbar oder parallel nutzbar, ohne die Komplexit¨

at weiter zu

erh¨

ohen. Die Entwickler von Kooperationswerkzeugen m¨

ussen sich daher schon zu

Beginn auf eine Technologie festlegen oder im Nachhinein die Anwendungen m¨

uhsam

auf alternative Persistenzsysteme portieren.

Dabek et al. schlagen daher f¨

ur die DHT-Protokolle in [Dabek et al., 2003] ei-

ne Abstraktion der Programmierschnittstelle vor, die es erlaubt, Anwendungen f¨

DHT-Netzwerke unabh¨

angig vom genutzten DHT-Verfahren zu implementieren. Der

Vorschlag bezieht sich aber ausschließlich auf DHT-Protokolle zur Vernetzung der

Knoten – eine ¨

ahnliche Abstraktion f¨

ur die auf diese aufsetzenden verteilten Persis-

tenzsysteme ist nicht vorgesehen.

Aufgrund der Vielfalt und Komplexit¨

at der Schnittstellen zu verteilten Persis-

tenszsystemen, wird die Aufmerksamkeit der Entwickler von der Kooperationsun-

terst¨

utzung weg zur technischen L¨

osung der Probleme der Objektspeicherung und

-verwaltung sowie Koordinierung der teilnehmenden Knoten gelenkt. Da die Kno-

ten einer mobilen Kollaboration oft offline sind, befinden sich die einzelnen Teile der

mobil-verteilten Kooperationsumgebung mit einer gewissen Wahrscheinlichkeit nicht

gleichzeitig im Kooperationsnetzwerk und m¨

ussen sich dennoch untereinander ko-

ordinieren. Der Entwickler ben¨

otigt daher Werkzeuge zur L¨

osung der Probleme der

zeitlichen und r¨

aumlichen Entkopplung der Peers mit Hilfe der zu Grunde liegenden

Netzwerk- und Persistenztechnik.

Das Problem eines gemeinsamen Datenraums f¨

ur mehrere lose gekoppelte Pro-

zesse existierte bereits vor dem Aufkommen von verteilten und ¨

uber Peer-to-Peer-

Netzwerke gekoppelten Systemen. Die Multiprozesskommunikation in Mehrprozes-

sorsystemen warf ¨

ahnliche Fragestellungen auf. Obwohl auf derselben Hardware-

plattform laufend, ben¨

otigen parallele Prozesse einen gemeinsamen Datenraum, der

es ihnen erlaubt, miteinander zu kommunizieren, ohne direkt miteinander in Verbin-

dung treten zu m¨

ussen.

Zu diesem Zweck entwarf Gelernter Linda [Gelernter, 1985; Gelernter und Car-

riero, 1989], ein Framework, das Prozessen erm¨

oglicht, Tuple in einem Tuple Space

genannten gemeinsamen Datenraum abzulegen und ¨

uber diese zu kommunizieren.

Die Tuple verbleiben bei Bedarf ¨

uber die Lebenszeit des zugeh¨

origen Prozesses hin-

aus im Tuple Space. Prozesse legen dazu ihre Daten mittels der Funktion in() als

Tuple im Tuple Space ab, ohne sich um deren weitere Verarbeitung zu k¨

ummern.

Ein Prozess, der an diesen Daten interessiert ist, greift auf die Tuple mittels der

Funktionen read() (Tuple lesen und im Tuple Space belassen) oder out() (Tuple

dem Tuple Space entnehmen) zu. Der Zugriff auf die Tuple findet dabei nicht direkt

sondern ¨

uber Templates statt. Mittels des Templates wird ein so genanntes Matching

durchgef¨

uhrt, bei dem die Tuple im Tuple Space mit dem Template verglichen wer-

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.2 Verteilte Persistenz als gemeinsamer Speicher 117

den. Das erste ¨

ubereinstimmende Tuple wird als Ergebnis zur¨

uckgeliefert. Sollte kein

Tuple zu dem Template passen, verbleibt das Template so lange im Tuple Space, bis

ein passendes Tuple in den Tuple Space eingef¨

ugt wird.

Tuple Spaces sorgen so f¨

ur eine zeitliche Entkopplung der Kommunikation von

parallelen Prozessen und verhindern, dass sich Prozesse gegenseitig in ihrer Kom-

munikation blockieren. Linda implementiert diesbez¨

uglich einen fl¨

uchtigen Daten-

raum, der urspr¨

unglich f¨

ur die parallele Programmierung von Mainframes ausgelegt

und nicht f¨

ur verteilte Systeme vorgesehen ist. Der Tuple Space in Linda ist nicht

persistent und skaliert aufgrund einer fehlenden inneren Struktur schlecht f¨

ur große

Datenr¨

aume.

Wegen einer fehlenden Persistenz der Tuple in Linda erweitert Persistent Linda

(PLinda) [Anderson und Shasha, 1991] die Tuple Spaces um eine Datenbankfunk-

tionalit¨

at f¨

ur die Speicherung der Tuple. Ein ¨

ahnliches Konzept verfolgt auch der

von IBM Research gew¨

ahlte Ansatz der TSpaces [Wykoff et al., 1998; Lehman et al.,

2001], der ebenfalls eine Datenbankanbindung f¨

ur einen persistenten Tuple Space zur

Verf¨

ugung stellt. Zus¨

atzlich bietet der Ansatz eine Zugriffskontrolle auf Benutzer-

und Gruppenebene.

TSpaces ist auf eine Verwendung mit der Java-Programmiersprache zugeschnit-

ten und erlaubt eigene Objekttypen innerhalb des Tuple Space zu registrieren. Wie

TSpaces ist auch die in SUN Microsystems Jini Framework integrierte Tuple Space-

Implementierung namens JavaSpaces [Freeman et al., 1999] speziell auf eine Nutzung

in Java ausgelegt, sieht aber in ihrer Spezifikation keine Persistenz vor. Der server-

zentrierte Ansatz von TSpace verhindert eine generelle Eignung f¨

ur den Einsatz in

mobilen verteilten Szenarien. Auch verteilte und fehlertolerante Ans¨

atze f¨

ur Linda

[Xu und Liskov, 1989] und TSpaces [Lehman et al., 2001] ber¨

ucksichtigen stets nur

eine vor¨

ubergehende Unterbrechung der Verbindung zum Gesamtsystem, bieten aber

keine Offline-Verf¨

ugbarkeit f¨

ur einzelne Knoten.

Auf den Einsatz in einer verteilten Umgebung zielen Bestrebungen, mit JXTA-

Spaces28 Tuple Spaces auch f¨

ur das JXTA Peer-to-Peer-Framework zur Verf¨

ugung

zu stellen. Der aktuelle Stand der Implementierung erlaubt aber noch keine verteilte

Speicherung des Tuple Space.

Durch eine Ausrichtung auf ad hoc vernetzte Netzwerkknoten ist Linda in a Mobi-

le Environment (LIME) [Picco et al., 1999] eine f¨

ur die mobile Nutzung konzipierte

Tuple Space-Implementierung, die auf eine zentrale Speicherung verzichtet. Statt-

dessen wird der Tuple Space verteilt auf den beteiligten Hosts abgelegt. F¨

ur die

Organisation des verteilten Datenraumes bietet LIME Tuple Spaces und Eventme-

chanismen auf Host- und Netzwerkebene an und erlaubt eine Aufteilung des Tuple

Space in mehrere logische Partitionen.

LIME unterst¨

utzt neben der physischen Mobilit¨

at auch eine logische Mobilit¨

at,

die es Programmen erlaubt, zwischen den mobilen Ger¨

aten zu migrieren. In diesem

Zusammenhang wird in LIME bez¨

uglich der Programme von Agenten (engl. agents)

gesprochen. Jeder Agent hat Zugriff auf einen persistenten Interface Tuple Space

28http://jxtaspaces.jxta.org

Mobilit¨

at in der kooperativen Wissensarbeit

118 4.3 Persistenz

(ITS), der mittels Vernetzung mit anderen ITS einen fl¨

uchtigen gemeinsamen Tuple

Space bildet. Tuple sind im gemeinsamen Tuple Space so lange verf¨

ugbar, wie der

Knoten mit dem speichernden ITS im Netzwerk verf¨

ugbar ist.

In LIME k¨

onnen mehrere ITS auf einem Knoten gleichzeitig existieren. Sie bil-

den gegeneinander abgeschlossene Tuple Spaces und vernetzen sich jeweils separat

zu fl¨

uchtigen gemeinsamen Tuple Spaces. Die ITS werden dabei ¨

uber ihren Namen

identifiziert und schließen sich auf einem Knoten zu einem Host-Level Tuple Space

zusammen. Um zu garantieren, dass ein Agent im Netzwerk ein bestimmtes Tu-

ple erh¨

alt, ist es m¨

oglich, ein Tuple gezielt in die ITS eines entfernten Agenten zu

speichern, an den es bei der n¨

achsten Netzwerkverbindung ¨

ubergeben wird.

LIME bietet mit seinem Ansatz f¨

ur r¨

aumlich und zeitlich entkoppelte Kommunika-

tion ein wirksames Werkzeug, um die Koordinierung verteilter Systeme im mobilen

Nutzungsumfeld zu erm¨

oglichen, ohne dass eine st¨

andige direkte Verbindung zwi-

schen den teilnehmenden Knoten bestehen muss. Der Zugriff auf den gemeinsamen

Datenraum ¨

uber out(),in() und read() Kommandos erm¨

oglicht Entwicklern, sich

auf die Funktionalit¨

at der verteilten Anwendungen die auf dieses Konzept aufsetzen

zu konzentieren, ohne sich um die Spezifika der Vernetzung der verteilten Program-

minstanzen k¨

ummern zu m¨

ussen.

Die Frage der netzweiten Persistenz von Objekten bleibt bei LIME aber zum Teil

ungel¨

ost. Tuple in lokalen ITS sind zwar persistent und f¨

ur den Knoten jederzeit

erreichbar, um aber auf Tuple in entfernten ITS zugreifen zu k¨

onnen, m¨

ussen die

entsprechenden Knoten im Netzwerk verf¨

ugbar sein. Wenngleich die M¨

oglichkeit

Tuple direkt in entfernte ITS zu speichern eine gezielte Verteilung der gemeinsam

genutzten Daten erlaubt, fehlt hier doch ein durchg¨

angiges Replikationskonzept.

Auch bleibt die Entscheidung, in welche entfernten ITS welches Tuple einzuf¨

ugen

ist, den Entwicklern der Anwendungssoftware ¨

uberlassen. Weiterhin gilt es f¨

ur sie,

die Vernetzung der beteiligten Knoten zu beachten, um die Objekte der verteilten

Umgebung verf¨

ugbar zu halten. Auch die Frage nach der Konsistenz von redun-

dant gehaltenen Objekten in einem derartigen System bleibt von den vorgestellten

Systemen ungel¨

ost.

4.3.3 Konsistenz in verteilten Persistenzsystemen

Die Verf¨

ugbarkeit einer mobil-verteilten Kooperationsumgebung ist stark von der

Verf¨

ugbarkeit der gemeinsam genutzten Objekte abh¨

angig. In einem mobilen Nut-

zungszenario k¨

onnen Netzwerktrennungen nicht nur im Fehlerfall, sondern auch auf

ausdr¨

ucklichen Wunsch der Benutzer auftreten, wenn diese z. B. Batteriereserven

sparen wollen. Daher ist eine Replikationsstrategie, die den Bed¨

urfnissen mobiler

Benutzer angepasst ist, ein wichtiges Kriterium f¨

ur den Erfolg einer solchen mobil-

verteilten Kooperationsumgebung. Die Replikationsstrategie muss die Verf¨

ugbarkeit

der Objekte f¨

ur den Fall ber¨

ucksichtigen, dass Benutzer offline vom restlichen Koope-

rationsnetz sind und isoliert an den gemeinsamen Objekten weiterarbeiten m¨

ochten

(Offline-Verf¨

ugbarkeit ). Daten, die f¨

ur eine Kooperation ben¨

otigt werden, m¨

ussen

somit auf allen beteiligten Ger¨

aten lokal gespeichert sein.

Mobilit¨

at in der kooperativen Wissensarbeit

4.3.3 Konsistenz in verteilten Persistenzsystemen 119

Werden Objekte derart im Netzwerk repliziert und gemeinsam von mehreren Be-

nutzern ver¨

andert, m¨

ussen sie zudem st¨

andig synchronisiert werden, um nicht von-

einander abweichende lokale Kopien entstehen zu lassen. Dies h¨

atte eine Inkonsistenz

des replizierten Objektes zur Folge. Aufgrund der r¨

aumlich und zeitlich entkoppelten

Kooperation im mobilen Nutzungsumfeld ist eine zeitnahe Synchronisation oft nicht

m¨

oglich.

In einem Netzwerk, in dem mehrere Knoten einen Objektspeicher replizieren, ent-

steht bei einem ¨

uberlappenden Schreibzugriff auf zwei Repliken ein Konflikt bei deren

n¨

achster Synchronisation. Der einfachste Schutz gegen derartige Schreibkonflikte ist

es, Schreibzugriffe nur auf einem Knoten (Master) zuzulassen und allen anderen re-

plizierenden Knoten (Slaves) nur Lesezugriffe zu erlauben. Die ¨

Anderungen werden

dann vom Master zu den Slaves weitergegeben.

Sollen alle Knoten die replizierten Objekte lokal schreiben d¨

urfen (Multiple Write

Replication) und dennoch die Konsistenz der Repliken bewahrt werden, m¨

ussen die

Repliken vor einem Schreibzugriff gesperrt werden. Nach dem Schreiben der ¨

An-

derung und der Synchronisation der Repliken kann die Sperre wieder aufgehoben

werden.

Diese beiden konservativen Verfahren erlauben einen schreibenden Zugriff auf die

Daten nur, wenn eine Sperre auf (fast) alle betroffenen Knoten gesetzt werden kann.

Sie sind daher f¨

ur mobile Nutzungsszenarien eher ungeeignet.

Besser geeignet f¨

ur mobile Nutzungsszenarien sind optimistische Verfahren, die

Schreibvorg¨

ange erlauben, ohne von vornherein Konflikte zu vermeiden (Optimistic

Concurrency Control, [vgl. Kung und Robinson, 1981]). Die Knoten synchronisie-

ren ihre Repliken nach einem Schreibvorgang, ohne den Verwaltungsaufwand eines

Sperrmechanismus betreiben zu m¨

ussen. Sollte dabei ein Konflikt bemerkt werden,

m¨

ussen Mechanismen f¨

ur die Beseitigung dieses Konflikts bereitstehen. Das Ergeb-

nis ist ein schwach konsistenter Speicher, in dem die ACID-Eigenschaften29 [Gray,

1988] nicht mehr zu jeder Zeit gegeben sind.

Es existieren einige Implementierungen verteilter Speicher f¨

ur mobile Einsatzfel-

der. Neben einigen verteilten Datenbankkonzepten [vgl. Holliday et al., 2002] sind

die gr¨

oßte Zahl der L¨

osungen Dateisysteme. Letztere werden aufgrund ihrer Mecha-

nismen zur Aufrechterhaltung oder Wiederherstellung der Konsistenz im Folgenden

eingehender betrachtet.

Das Andrew File System (AFS) [Campbell, 1998; Howard et al., 1988] liefert ¨

uber

einen Server Dateien an die Clients aus und merkt sich, welche Clients eine Datei

ge¨

offnet haben. Bei einer ¨

Anderung der Datei durch einen der Clients werden die

anderen Clients vom Server informiert und aktualisiert. Dieses Vorgehen hilft, den

Netzwerkverkehr beim Zugriff auf entfernte Dateien zu reduzieren und kann auch

f¨

ur eine unverbundene Arbeit genutzt werden [Huston und Honeyman, 1993].

W¨

ahrend in AFS die Dateien von einem einzelnen Server bereitgestellt werden, hat

Ficus [Popek et al., 1990] das Ziel, Dateisysteme f¨

ur weitr¨

aumige Netzwerke (”Na-

29Gew¨

unschte Eigenschaften bei Transaktionen in verteilten Systemen, bestehend aus Atomicity,

Consistency,Isolation und Durability.

Mobilit¨

at in der kooperativen Wissensarbeit

120 4.4 Ereigniskontrolle

tionwide Networks“ ) [Popek et al., 1990] zu etablieren und zu dem Zweck gespiegelte

Datentr¨

ager im Netzwerk zur Verf¨

ugung zu stellen. Diese sollen trotz m¨

oglicher Ver-

bindungsabbr¨

uche konsistent gehalten werden k¨

onnen.

Coda [Kistler und Satyanarayanan, 1992; Satyanarayanan, 2002] besitzt eine ¨

ahn-

liche Client-Server-Topologie, wurde aber direkt auf ein unverbundenes und mobi-

lit¨

atsfreundliches Arbeiten zugeschnitten [Satyanarayanan et al., 1993]. Zu diesem

Zweck werden f¨

ur die Benutzer interessante Dateien lokal repliziert (Hoarding). Im

Fall eines Verbindungsabbruchs zu dem Server k¨

onnen die Benutzer auf den lokalen

Repliken weiterarbeiten und diese sp¨

ater wieder mit dem Server synchronisieren.

Tritt ein Konflikt wegen zeitgleicher ¨

Anderungen an einer Datei auf, wird diese ge-

sperrt und die verschiedenen Versionen in einem Verzeichnis mit dem Namen der

Datei abgelegt. Dort kann sie manuell von den beteiligten Teilnehmern zusammen-

gef¨

uhrt werden.

Das PRAYER File System (PFS) [Dwyer und Bharghavan, 1997] bietet ebenfalls

eine mobilit¨

atsfreundliche unverbundene Bearbeitung der lokal replizierten Objekte.

Es gestattet den auf die Daten zugreifenden Anwendungen aber zus¨

atzlich, selbst

eine Konsistenzstrategie f¨

ur diese zu bestimmen. Auf diese Art soll die L¨

osung des

in [Fox und Brewer, 1999] beschriebenen Dilemmas eines Trade-offs zwischen starker

Konsistenz und hoher Verf¨

ugbarkeit der Daten den Entwicklern der bearbeitenden

Anwendung ¨

uberlassen werden.

Diesen Ansatz verfolgen auch TACT [Yu und Vahdat, 2002] und GLOMAR [Cuce

und Zaslavsky, 2003]. Beide unterst¨

utzen Anwendungensentwickler darin, eine pas-

sende Replikationsstrategie gem¨

aß ihren Anforderungen an die St¨

arke der Konsistenz

der replizierten Anwendungsdaten zu w¨

ahlen.

W¨

ahrend Systeme wie Coda und PFS den Ansatz mobilit¨

atsfreundlicher Datei-

systeme verfolgen, betrachtet Bayou [Terry et al., 1995] direkt die Objektverteilung

in Peer-to-Peer-Systemen. In [Edwards et al., 1997] wird dieses Konzept auf asyn-

chron vernetzte Kooperationssysteme ¨

ubertragen, zielt aber nicht direkt auf mobil-

spontane Kooperationsl¨

osungen.

Die aufgef¨

uhrten L¨

osungsans¨

atze lassen die Vermutung zu, dass ein genereller

Speicheransatz wie ein Dateisystem oft nicht in der Lage ist, die bestm¨

ogliche Abw¨

gung zwischen Verf¨

ugbarkeit und Konsistenz zu bieten. Dieses Problem ¨

außert sich

in Systemen, die versuchen, die Entwickler einer Anwendung entscheiden zu lassen,

wie hoch die jeweiligen Anforderungen f¨

ur Verf¨

ugbarkeit und Konsistenz der Anwen-

dungsdaten sein sollen. Keiner der Ans¨

atze verf¨

ugt ¨

uber eine Replikationsstrategie,

die auf eine mobil-spontane Kooperation in virtuellen Wissensr¨

aumen zugeschnitten

ist.

4.4 Ereigniskontrolle

Da in kooperativen Umgebungen eine hohe Interaktivit¨

at der Benutzer charakteris-

tisch f¨

ur synchronisierte Arbeitsabl¨

aufe ist, m¨

ussen Ereignisse innerhalb der gemein-

sam bearbeiteten Bereiche so schnell wie m¨

oglich in den Wahrnehmungsraum der

Mobilit¨

at in der kooperativen Wissensarbeit

121

Kooperationspartner gebracht werden. Verteilte Systeme m¨

ussen sich dazu st¨

andig

uber Ereignisse in der gemeinsam bereitgestellten Umgebung austauschen k¨

onnen.

Um Ereignisse zwischen Systemen zu kommunizieren, existieren zwei wesentliche

Paradigmen: Das Request&Reply- bzw. Pull-Paradigma und das Publish/Subscribe-

bzw. Observer-Paradigma. Beim ersteren ist der Empf¨

anger der Ereignisse f¨

ur das

Abrufen der Zustands¨

anderungen zust¨

andig. Eine Synchronisation kann hier ¨

uber

regelm¨

aßiges Abfragen der aktuellen Ereignisse in geringen Zeitabst¨

anden geschehen

(Polling). Beim Observer-Paradigma [Gamma et al., 1995, S. 193ff] hingegen meldet

sich der Empf¨

anger einmalig beim Sender an und abonniert alle Ereignisse bez¨

uglich

der Zustands¨

anderungen bestimmter Objekte. Tritt ein Ereignis auf, benachrichtigt

der Sender direkt alle Abonnenten (Pushing).

Das Observer-Paradigma hat den besonderen Vorteil, dass es eine lose Kopp-

lung von Sender und Empf¨

anger erlaubt, da nur eine Kommunikation in Richtung

des Empf¨

angers notwendig ist und auch Multicast-Kommunikation unterst¨

utzt wird.

Mehrere Empf¨

anger k¨

onnen so gleichzeitig ¨

uber Zustands¨

anderungen informiert wer-

den. Beide Aspekte machen das Observer-Paradigma zu einem idealen Werkzeug f¨

die Ereignis-Behandlung in mobil-verteilten Kooperationssystemen. Im Folgenden

wird daher mit Scribe eine Implementierung dieses Paradigmas betrachtet, die auf

das DHT-basierte Pastry aufsetzt.

Scribe

Scribe [Rowstron et al., 2001; Castro et al., 2002] ist die Implementierung einer

Any- und Multicast-L¨

osung gem¨

aß dem Observer-Paradigma f¨

ur das Pastry Overlay-

Netzwerk (vgl. Abschnitt 4.3.1). Bei Scribe liegen alle teilnehmenden Knoten im

logischen Adressraum von Pastry. Die Eigenschaften von Pastry gelten somit auch f¨

Scribe. Als Publisher/Subscriber-System unterst¨

utzt es zwei Arten von Teilnehmern.

Zum einen gibt es Teilnehmer, die Themen ver¨

offentlichen und zum anderen welche,

die ver¨

offentlichte Themen abonnieren, an denen sie interessiert sind. Diese Themen

k¨

onnen auch Ereignisse ¨

uber Status¨

anderungen von Objekten sein.

Grunds¨

atzlich kann jeder Knoten eines Pastry-Netzwerks mit Hilfe von Scribe

Themen ver¨

offentlichen. Alle anderen Knoten k¨

onnen diese Themen abonnieren.

Der Herausgeber eines Themas kann nun die Abonnenten ¨

uber Ver¨

anderungen in

Kenntnis setzen. Dies wird ¨

uber Ereignisse realisiert, welche durch Scribe automa-

tisch versandt werden, ohne eine festgelegte Reihenfolge einzuhalten. Das System

ist so konzipiert, dass Knoten zugleich Abonnementen als auch Herausgeber sein

k¨

onnen. Bestehende Abonnements k¨

onnen in gleicher Weise gek¨

ungigt wie bestellt

werden. Zu jedem Thema im Netzwerk erstellt Scribe einen eigenen Multicast-Baum,

in dem sich alle Abonnenten des Themas wiederfinden.

Da Scribe eine reine Funktionserweiterung von Pastry ist, ist es ebenfalls v¨

ollig

dezentralisiert aufgebaut. Jeder Knoten kann dabei gleichzeitig mehrere Funktionen

einnehmen, wie z. B. Herausgeber, Wurzel eines Multicast-Baums, Knoten innerhalb

des Multicast-Baumes und Abonnement.

Mobilit¨

at in der kooperativen Wissensarbeit

122 4.4 Ereigniskontrolle

Jedes Thema wird eindeutig ¨

uber eine topicID identifiziert. Diese wird als Hash-

Wert aus dem Namen des Themas und der Identit¨

at des Herausgebers errechnet.

Diese topicID liegt wieder im logischen Adressraum des Pastry-Netzwerkes. Ein Kno-

ten, dessen nodeID den numerisch kleinsten Abstand zur topicID hat, wird als so

genannter Rendezvous-Knoten bestimmt. Jedes Thema besitzt genau einen Rendez-

vous-Knoten, aber ein Knoten kann zugleich der Rendezvous-Knoten mehrerer The-

men sein. Dieser Knoten ist dann auch die Wurzel des Multicast-Baumes [Rowstron

et al., 2001].

Um ein Thema in einem Scribe-Netzwerk anzulegen, muss Scribe zun¨

achst die

topicID des Themas erzeugen und mit Hilfe von Pastry an den zust¨

andigen Knoten

ubergeben. Dieser Knoten nimmt das neue Thema in seine Themenliste auf. An

diesem Punkt kann zus¨

atzlich eine Sicherheitspr¨

ufung durchgef¨

uhrt werden, welche

die Berechtigung des Verfassers dahingend pr¨

uft, ob dieser ein Thema anlegen darf.

Von nun an ist dieser Knoten der Rendezvous-Knoten des neuen Themas.

Abonenntenverwaltung Scribe erstellt f¨

ur jedes Thema einen Multicast-Baum,

dessen Wurzel der Rendezvous-Knoten bildet. Der Multicast-Baum f¨

ur das Versen-

den der Nachricht entsteht aus den Routen der Abonnenten zu dem Rendezvous-

Knoten. Die Abonnements werden dabei dezentral verwaltet, damit die Funktiona-

lit¨

at auch bei einer hohen Anzahl von Abonnenten sichergestellt werden kann, ohne

den Rendezvous-Knoten zu ¨

uberlasten. Teilnehmer eines Multicast-Baumes m¨

ussen

nicht selbst Abonennten des Themas sein sondern k¨

onnen auch lediglich Nachrich-

ten weiterleiten. Jeder Knoten besitzt f¨

ur jedes Thema eine eigene Nachfolgertabelle,

in der f¨

ur die eigenen Nachfolgeknoten im Multicast-Baum jeweils nodeID und IP-

Adresse gespeichert sind.

Wenn ein Knoten ein Thema abonnieren m¨

ochte, sendet er eine entsprechende

Anfrage ¨

uber Pastry an den zugeh¨

origen Rendezvous-Knoten. Die Anfrage enth¨

alt

entsprechend als ID f¨

ur den Nachrichtenschl¨

ussel die des Rendezvous-Knoten. Auf

der Route zu dem Rendezvous-Knoten wird auf jedem Zwischenknoten, ¨

uber den die

Nachricht gesandt wird, die Nachfolgertabelle aktualisiert, indem gepr¨

uft wird, ob

zu diesem Thema bereits eine Nachfolger-Tabelle existiert. Muss die Tabelle neu an-

gelegt werden, wird sie mit der nodeID des ¨

ubermittelnden Knoten initialisiert. Der

ubermittelnde Knoten ist somit neuer Nachfolger des aktuellen Knotens im Mulicast-

Baum. Die urspr¨

ungliche Anfrage des Abonnenten wird verworfen und der aktuelle

Knoten sendet seinerseits eine Abonnementanfrage zu dem Thema. Dieser Vorgang

wiederholt sich bis ein Knoten gefunden wird, bei dem die Tabelle schon vorhanden

ist. Dieser pr¨

uft, ob der anfragende Knoten bereits in der Nachfolger-Tabelle enthal-

ten ist. Ist dies der Fall, wird die Nachricht lediglich Richtung Rendezvous-Knoten

weitergeleitet, ansonsten wird zus¨

atzlich der Knoten als Nachfolger erg¨

anzt.

Auf diese Weise baut sich der sp¨

atere Multicast-Baum von den Bl¨

attern (Abon-

nenten) zur Wurzel (Rendevouz-Knoten) selbstst¨

andig auf. An Stellen, wo bereits

ein Weg zur Wurzel besteht, endet die Vervollst¨

andigung der Route zur Wurzel und

der existierende Weg wird ab dieser Stelle f¨

ur die Verteilung der Nachrichten mit-

Mobilit¨

at in der kooperativen Wissensarbeit

123

Abbildung 4.11: Abonnieren eines bereits ver¨

offentlichten Themas ¨

uber einen noch

nicht im Multicast-Baum enthaltenen Knoten

benutzt. Betrachtet man die ermittelten Wege nun von der Wurzel zu den Bl¨

attern,

ergibt sich aufgrund der Pastry-Eigenschaften ein optimaler Pfad. Außerdem wird

keine Nachricht im Multicast-Baum doppelt ¨

uber eine Verbindung zweier Knoten

gesandt. In Abbildung 4.11 wird das Abbonieren eines Themas schematisch darge-

stellt.

M¨

ochte ein Knoten nun ein zuvor abonniertes Thema abbestellen, so kennzeich-

net dieser Knoten das Thema als nicht mehr ben¨

otigt. Wenn keine Eintr¨

age in der

Nachfolger-Tabelle vorhanden sind, wird eine Abbestell-Nachricht an den Vorg¨

anger

im Multicast-Baum gesandt, der den Knoten daraufhin aus der Nachfolger-Tabelle

des Themas l¨

oscht. Die Nachricht wandert sukzessiv durch den Multicast-Baum in

Richtung Wurzel, bis sie einen Knoten erreicht, dessen Nachfolger-Tabelle nach L¨

schung des abbestellenden Knotens noch weitere Eintr¨

age enth¨

alt. So werden auch

die Knoten aus dem Multicast-Baum entfernt, die nur als Verteilerknoten f¨

ur die

Weiterleitung der Nachrichten an den abbestellenden Knoten enthalten waren (vgl.

Abbildung 4.12).

Das in Scribe enthaltene Verfahren zur Verwaltung der Abonnenten ist auch bei

einer hohen Anzahl von Abonnenten sehr leistungsf¨

ahig. Die Abonnentenliste wird

auf den Knoten der Multicast-B¨

aume gespeichert und ist durch die zuf¨

allige Zu-

ordnungsstrategie gleichm¨

aßig ¨

uber das Pastry-Netzwerk verteilt. Dies ist eines der

wesentlichen Merkmale von Scribe, das die Leistungsf¨

ahigkeit des Nachrichtenver-

sands auch bei großen Mengen von Themen und Abonnenten bewahrt.

Mobilit¨

at in der kooperativen Wissensarbeit

124 4.4 Ereigniskontrolle

Abbildung 4.12: Abbestellen eines abonnierten Themas: Knoten, die nur Weiter-

leitungsfunktionen haben, werden wieder aus dem Multicast-Baum entfernt

Die Abonnement-Anfragen werden lokal auf Knoten der bereits vorhandenen Mul-

ticast-B¨

aume bearbeitet und bilden somit eine dezentrale Verwaltungsstruktur. Zu-

s¨

atzlich wird eine Erweiterung des Multicast-Baums um einen neuen Knoten lokal

vorgenommen, was die Notwendigkeit einer zentralen Bearbeitung der Anfragen ver-

meidet. Der durch das Pastry-Routing optimale Multicast-Baum f¨

uhrt zu einer Nach-

richtenweitergabe, die Mehrfachversendungen und die damit einhergehende erh¨

ohte

Netzwerkkommunikation vermeidet. Abbildung 4.13 verdeutlicht den Unterschied

zwischen einem Nachrichtenversand in Scribe (Single-Mulicast) und dem herk¨

omm-

lichen Multiple-Unicast. Grunds¨

atzlich l¨

asst sich bei einem Vergleich der beiden

Ans¨

atze folgendes feststellen:

•Single-Multicast: Bei dieser Variante des Nachrichten-Versandes versendet der

Rendezvous-Knoten Nachrichten nur an seine direkten Nachfolger im Mul-

ticast-Baum. Dies l¨

ost auf diesen Knoten wiederum einen Versand zu de-

ren Nachfolgern aus. Diese Kette setzt sich solange fort, bis alle Knoten im

Multicast-Baum erreicht worden sind. Die gesandte Nachricht durchl¨

auft da-

bei den Multicast-Baum und wird lediglich einmal ¨

uber jede Kante zwischen

den Knoten ¨

ubertragen. Vorteilhaft ist auch, dass der Rendezvous-Knoten nur

wenige Knoten f¨

ur den Versand zu einem Thema direkt kennen muss.

•Multiple-Unicast: Der Rendezvous-Knoten muss bei diesem Verfahren alle Ziel-

knoten selbst kennen. Er versendet eine Nachricht der Reihe nach an alle Ziel-

Mobilit¨

at in der kooperativen Wissensarbeit

125

Abbildung 4.13: Gegen¨

uberstellung des in Scribe verwendeten performanten

Single-Multicast-Verfahrens und des ¨

ublichen Multiple-Unicast-Verfahrens

knoten. Die Nachricht wird somit mehrfach ¨

uber die gleichen Nachrichtenwege

versandt. Dieses Verfahren ben¨

otigt einen performanten Sender und eine Netz-

werktopologie mit einer entsprechend hohen Sende-Bandbreite.

Durch die positive Auswirkung des Pastry-Routings auf die Entstehung der Mul-

ticast-B¨

aume werden sowohl die physikalischen Verbindungseigenschaften im realen

Netzwerk als auch kurze Routen ¨

uber wenige Knoten ber¨

ucksichtigt.

Verbreitung von Nachrichten Soll eine Nachricht an die interessierten Knoten

versendet werden, so hat der Herausgeber der Nachricht zwei M¨

oglichkeiten, den

Rendezvous-Knoten zu erreichen. Bei der ersten Variante kennt der Herausgeber be-

reits die IP-Adresse des Rendezvous-Knoten und nimmt direkt Kontakt mit diesem

auf.

Ist die IP-Adresse des Rendezvous-Knotens dem Herausgeber jedoch nicht be-

kannt, kann die Nachricht ¨

uber Pastry versandt werden, indem sie mit der topicID

als Nachrichtenschl¨

ussel an den Rendezvous-Knoten ¨

ubermittelt wird. Der Rendez-

vous-Knoten teilt in diesem Fall seine IP-Adresse aufgrund einer in der Nachricht

enthaltenen Anforderung dem Herausgeber mit. ¨

Uber die IP-Adresse kann dieser

von nun an seine Nachrichten direkt zum Rendezvous-Knoten senden.

Vom Rendezvous-Knoten aus wird die Nachricht im Multicast-Baum an die Abon-

nenten verteilt. Sollte ein Rendezvous-Knoten durch einen neu ins Pastry-Netzwerk

Mobilit¨

at in der kooperativen Wissensarbeit

126 4.4 Ereigniskontrolle

hinzugef¨

ugten Knoten ersetzt werden, leitet er die Nachrichten zun¨

achst an den neu-

en Knoten weiter und teilt dem Herausgeber der Nachricht die neue IP-Adresse mit.

Auch die Variante des Sendens einer Nachricht mit der topicID als Nachrichten-

schl¨

ussel f¨

uhrt zu der Behebung des Defekts durch eine solche Ver¨

anderung. Da der

Versand stets ¨

uber einen Rendezvous-Knoten l¨

auft, k¨

onnen an dieser Stelle auch die

Berechtigungen f¨

ur den Nachrichtenversand verwaltet werden und Angriffe auf das

Nachrichtensystem abgeblockt werden.

Zuverl¨

assigkeit und Ausfallsicherheit Um eine Zuverl¨

assigkeit und Ausfallsi-

cherheit von Scribe zu gew¨

ahrleisten, m¨

ussen die Rahmenbedingungen relativ stabil

sein, da Scribe eine Zustellung der Nachrichten nicht garantiert. Besonders bei der

Verteilung von Ereignissen in verteilten Systemen muss aber eine gewisse Verl¨

asslich-

keit der Zustellung gewahrt bleiben. Scribe ist beim Nachrichtenversand zun¨

achst

einmal auf eine m¨

oglichst hohe Effizienz ausgerichtet. Durch eine Erweiterung, der in

Scribe genutzten Kommunikationsmechanismen kann die Zuverl¨

assigkeit allerdings

erh¨

oht werden.

Scribe benutzt f¨

ur eine verl¨

assliche Nachrichtenzustellung das verbindungsorien-

tierte TCP-Protokoll f¨

ur die Kommunikation zwischen den Knoten des Multicast-

Baumes [Rowstron et al., 2001]. Um die Zuverl¨

assigkeit dieses Verfahrens weiter zu

erh¨

ohen, wird f¨

ur jedes Ereignis eine eindeutige Nummer vergeben. Die nummerierte

Nachricht verbleibt ¨

uber eine fest definierte Zeit auf den Knoten im Multicast-Baum.

Sollte die Zustellung einer Nachricht fehlschlagen, kann so der Versand der Nachricht

wiederholt werden.

Durch diese tempor¨

are Zwischenspeicherung der Nachrichten und ihre Numme-

rierung k¨

onnen sowohl bei Ausf¨

allen des Rendezvous-Knoten, als auch bei Ausf¨

allen

von Knoten im Multicast-Baum, Fehler kompensiert werden. Dies geschieht durch

Vergleichen der aktuellen und der gespeicherten Ereignis-Nummer in den Knoten.

Wurde ein Ereignis noch nicht empfangen, wird es weitergeleitet und ansonsten ver-

worfen. So wird eine h¨

ohere Zuverl¨

assigkeit bei der Nachrichtenzustellung erreicht.

Um die Funktionsf¨

ahigkeit des Multicast-Baumes zu jedem Zeitpunkt zu gew¨

ahr-

leisten, stehen Anwendungen in Scribe verschiedene Mechanismen zur Verf¨

ugung, um

eine Reparatur des Multicast-Baumes im Fehlerfall zu bewerkstelligen. Um den Aus-

fall eines Knotens im Multicast-Baum fr¨

uhzeitig zu erkennen, senden die Multicast-

Knoten Kontrollnachrichten zu ihren Nachfolgern. Den Nachfolgern ist so der Status

ihrer Vorg¨

anger im Multicast-Baum bekannt. Zur Verringerung des Kommunikati-

onsaufkommens werden auch die normalen Nachrichten als Lebenszeichen genutzt.

Bleiben die Lebenszeichen eines Knotens f¨

ur eine bestimmte Zeit aus, wird eine

Prozedur zur Korrektur des Defekts gestartet. Der Knoten, der den Defekt entdeckt

hat, sendet dazu ¨

uber Pastry eine Abonnement-Anfrage mit der topicID als Nach-

richtenschl¨

ussel. Pastry findet aufgrund seiner Fehlerresistenz einen neuen Weg in

dem Multicast-Baum und umgeht den vermeintlich ausgefallenen Knoten. ¨

Uber diese

neue Wegsuche werden eventuell auch neue Knoten zum Multicast-Baum hinzuge-

f¨

ugt.

Mobilit¨

at in der kooperativen Wissensarbeit

127

Mittels dieser Methode kann Scribe auch den Ausfall eines Rendezvous-Knoten

im Multicast-Baum selbstst¨

andig beheben. Dazu werden im Betrieb die f¨

ur den

Nachrichtenversand ben¨

otigten Informationen des Rendezvous-Knotens analog zu

dem Replikationsverfahren in PAST (vgl. Abschnitt 4.3.1) auf kKnoten des Leaf Sets

repliziert. Da diese kKnoten aus dem Leaf Set des Rendezvous-Knoten stammen,

sind sie die direkten Nachbarn innerhalb des logischen Adressraumes.

Sollte ein Rendezvous-Knoten ausfallen, wird dies von seinen Nachfolgern erkannt

und ¨

uber Pastry eine neue Abonnement-Anfrage gesandt. Die Nachricht wird zu

dem Knoten gesandt, der nummerisch am n¨

achsten zur topicID liegt. Dies war zuvor

der ausgefallene Rendezvous-Knoten. Da dieser nicht mehr erreichbar ist, wird die

Nachricht zu der n¨

achstgelegenen nodeID im logischen Adressraum geleitet. Der

zugeh¨

orige Knoten stammt aufgrund der Eigenschaften des Pastry-Routings mit

hoher Wahrscheinlichkeit aus dem replizierenden Leaf Set des alten Rendezvous-

Knotens. Da auf dem Nachbarknoten eine Kopie der f¨

ur den Rendezvous-Knoten

ben¨

otigten Informationen hinterlegt ist, kann dieser nun die Rolle des Rendezvous-

Knotens nahtlos ¨

ubernehmen.

Die Herausgeber bemerken den Ausfall des alten Rendezvous-Knoten, da dieser

nicht mehr direkt ¨

uber seine IP-Adresse zu erreichen ist, und lassen ¨

uber Pastry eine

neue Route berechnen. So gelangen sie ebenfalls zu dem neuen Rendezvous-Knoten.

Die Eintr¨

age in den Nachfolger-Tabellen werden solange aufrechterhalten, wie re-

gelm¨

aßig Nachrichten von den Nachfolgern das bestehende Interesse an dem abon-

nierten Thema best¨

atigen, sonst werden sie automatisch entfernt, um den Multicast-

Baum nicht degenerieren zu lassen. Die Fehlerbehandlung ist unabh¨

angig von der

Gr¨

oße des Multicast-Baumes, da diese Nachrichten nur an eine kleine Auswahl

von Knoten gesandt werden m¨

ussen. Von einer Wiederherstellung eines defekten

Multicast-Baumes ist nur das direkte Umfeld des Fehlers betroffen. Somit k¨

onnen

Fehler an verschiedenen Stellen gleichzeitig behoben werden.

Analog zu dem hier vorgestellten Verfahren eines ereignisbasierten Nachrichten-

systems kann mit Hilfe von Scribe auch ein Gruppenverwaltung realisiert werden.

Dazu werden Gruppen wie Themen betrachtet, in denen nicht Abonennten, sondern

Gruppenmitglieder enthalten sind. Das Adressierungssystem f¨

ur die Gruppenkom-

munikation ist ¨

anlich dem des Nachrichtenversands, wobei die topicID durch die

groupID ersetzt wird. Der Rendezvous-Knoten wird wiederum durch einen Knoten

vertreten, dessen nodeID numerisch am n¨

achsten zur groupID ist. Alle Funktionen,

wie das Hinzuf¨

ugen oder Entfernen von Mitgliedern in den Gruppen, werden analog

zum Abonnieren und Abbestellen von Themen bewerkstelligt [Castro et al., 2002].

Bewertung von DHTs in mobil-verteilten Anwendungsszenarien

Scribe gibt den Enwicklern von verteilten Anwendungen ein m¨

achtiges Werkzeug

zur Multicast-Kommunikation und insbesondere zur Gruppenkommunikation in die

Hand. Zusammen mit der M¨

oglichkeit der Bereitstellung einer selbstorganisierten

Netzwerkstruktur (Pastry) inklusive eines replizierten verteilten Speichers (PAST)

Mobilit¨

at in der kooperativen Wissensarbeit

128 4.4 Ereigniskontrolle

erscheinen die DHT-basierten L¨

osungsans¨

atze als eine ideale Plattform f¨

ur die Im-

plementierung einer verteilten Kooperationsumgebung.

F¨

ur eine mobilit¨

atsfreundliche Infrastruktur fehlt noch die Unterst¨

utzung der Off-

line-Verf¨

ugbarkeit verteilt gespeicherter Daten. Unverbundene Knoten werden in

allen L¨

osungsans¨

atzen stets als defekt betrachtet und es existiert zudem keine M¨

og-

lichkeit, Kooperationsdaten gezielt auf eine bestimmte Knotengruppe zu replizieren.

Auch werden Nachrichten (mit Ausnahme von I3) stets nur synchron versandt, so

dass unverbundene Knoten auch beim Wiedereintritt von einem Teil der Ereignis-

kontrolle abgeschnitten bleiben.

Trotz dieser Defizite derzeitiger DHT-Implementierungen bleiben viele der ange-

botenen L¨

osungsans¨

atze vielversprechend f¨

ur die Umsetzung einer mobil-verteilten

Kooperationsumgebung. In dem folgenden Kapitel 5 sollen daher die fehlenden Bau-

steine erg¨

anzt werden und so zu einem Entwurfsmuster f¨

ur mobil-verteilte Kooperati-

onsumgebungen basierend auf dem Konzept der virtuellen Wissensr¨

aume kombiniert

werden.

Mobilit¨

at in der kooperativen Wissensarbeit

5 Musterarchitektur mobil-verteilter

Wissensr¨

aume

Bei Betrachtung der Szenarien mobil-verteilter Kooperation und der verf¨

ugbaren L¨

sungsans¨

atze ergibt sich ein zwiesp¨

altiges Bild. So scheinen f¨

ur viele der in Kapitel 3

ermittelten Anforderungen bereits geeignete L¨

osungen zu existieren, w¨

ahrend zur

Erf¨

ullung anderer kritischer Anforderungen keiner der betrachteten L¨

osungsans¨

atze

geeignet scheint.

Die Defizite zeichnen sich insbesondere mit Blick auf eine mobilit¨

atsfreundliche

verteilte Persistenz ab. Die zentrale Forderung nach Offline-Verf¨

ugbarkeit der Ko-

operationsdaten und zeitlich entkoppelter Ereigniskommunikation, die zusammenge-

nommen ein Fortsetzen der Arbeit in unverbundenen Kooperationssituationen er-

lauben w¨

urden, wird von keinem der betrachteten Ans¨

atze erf¨

ullt. Die Schaffung

einer geeigneten Persistenzschicht wird so zu einer zentralen Forschungsfrage f¨

ur die

Unterst¨

utzung mobil-spontaner Kooperationsszenarien.

Auf der anderen Seite existieren mit den vorhandenen L¨

osungsans¨

atzen einige

wichtige Bausteine f¨

ur die zuk¨

unftigen mobil-verteilten Kooperationsumgebungen.

So erlauben die Protokolle f¨

ur mobil-spontane Vernetzung das Verbinden von Mo-

bilger¨

aten und Diensten sowie das Einbinden existierender Netzwerkinfrastrukturen.

Mittels dezentraler Persistenzsysteme auf DHT-Basis l¨

asst sich ein verteilter globaler

Speicher f¨

ur die Kooperationsumgebungen realisieren, es fehlt aber an Mechanismen

f¨

ur eine gesteuerte Replikation und einer Synchronisation der Repliken. Mit anony-

men und zeitlich entkoppelten Speicherkonzepten in Form von Tuple Spaces besteht

zudem die M¨

oglichkeit, die technischen Strukturen einer mobil-verteilten Persistenz

in eine konsistente Metapher f¨

ur den Zugriff auf einen gemeinsamen und struktu-

rierten Speicher einzubinden.

In den folgenden Abschnitte werden die vorhandenen Komponenten um wich-

tige Bausteine zu einer Gesamtarchitektur erg¨

anzt. Diese enth¨

alt u. a. eine Per-

sistenzschicht f¨

ur die Bereitstellung mobil-verteilter Wissensr¨

aume in einer spon-

tan vernetzten Kooperationsumgebung. Zu diesem Zweck wird eine speziell auf die

Bed¨

urfnisse mobil-spontaner Kooperation zugeschnittene Replikations- und Versio-

nierungsstrategie und ein f¨

ur die Gruppenarbeit angepasstes Tuple Space-Konzept

vorgestellt. Zudem wird die Einbettung externer Kontext- und Persistenzdienste in

diese Strukturen behandelt. Die so gewonnenen Bausteine und Konzepte erg¨

anzen

sich schließlich zu einem neuartigen Entwurfsmuster einer Architektur zur Bereit-

stellung mobil-verteilter Wissensr¨

aume.

129

130 5.1 Replikationsstrategien f¨

ur die mobil-spontane Kooperation

Abbildung 5.1: Offline-Verf¨

ugbarkeit in einer verteilten Persistenzschicht

5.1 Replikationsstrategien f¨

ur die mobil-spontane

Kooperation

Der Zugriff auf einen ¨

uber ein Ad-Hoc-Netzwerk errichteten verteilten gemeinsamen

Speicher ist in mobil-spontanen Nutzungsszenarien von Verf¨

ugbarkeit einer Netz-

werkverbindung zum speichernden Knoten abh¨

angig1. Wenn die in so einem mo-

bilen Netzwerk verteilt gespeicherten Objekte nicht in intelligenter Weise ¨

uber die

beteiligten Knoten des Netzwerkes repliziert werden, sind sie wie in Abbildung 5.1

dargestellt bei einem entfernten Zugriff eventuell nicht verf¨

ugbar [vgl. Eßmann et al.,

2006].

Ein g¨

angiges Konzept zur Erh¨

ohung der Zuverl¨

assigkeit von Diensten in einer un-

zuverl¨

assigen Umgebung ist Redundanz (vgl. Kapitel 3). Diese f¨

uhrt aber gleichzeitig

zu einem erh¨

ohten Verwaltungsaufwand und Speicherbedarf. Basiert der Dienst zu-

dem auf einem gemeinsamen und ver¨

anderlichen Datenbestand, m¨

ussen die Kopien

der redundant gespeicherten Daten stets mit dem Original synchronisiert werden.

Erfolgt die Bearbeitung der replizierten Objekte auf allen redundant gehaltenen

Kopien, muss die Synchronisation in jede Richtung erfolgen. Zus¨

atzlich k¨

onnen in

diesem Fall Konflikte bei einer gleichzeitigen Bearbeitung eines replizierten Objektes

auf zwei unterschiedlichen Knoten auftreten.

Eine Erreichbarkeit aller Repliken eines Objektes zum Zeitpunkt einer ¨

Anderung

und der nachfolgenden Synchronisation kann in mobilen Netzwerken nicht garan-

tiert werden. Daher wird die Synchronisation eventuell zeitversetzt und epidemisch

zwischen den Knoten erfolgen. Epidemisch bedeutet in diesem Zusammenhang, dass

sich die Knoten untereinander synchronisieren, sobald sie in Reichweite kommen.

Alle synchronisierten Knoten gleichen ihrerseits die ¨

Anderungen mit weiteren nicht

aktualisierten Knoten ab. Diese Strategie verhindert, dass der ¨

andernde Knoten sich

mit allen replizierenden Knoten direkt synchronisieren muss und dementspechend

Bandbreite ben¨

otigt2. Obwohl das epidemische Verfahren eine dynamischere Struk-

1[Satyanarayanan, 1996] nennt als wesentliche Probleme mobiler Netzwerke deren hohe Schwan-

kungen in ihrer Leistungsf¨

ahigkeit und Verf¨

ugbarkeit.

Mobilit¨

at in der kooperativen Wissensarbeit

131

tur besitzt, ¨

ahnelt es stark dem Versand von Nachrichten im Multicast-Baum von

Scribe (vgl. Abschnitt 4.4).

M¨

ogliche Konflikte durch zeitgleiche ¨

Anderungen innerhalb der verteilten Um-

gebung erkennt die Synchronisation ¨

uber einen Concurrency Control-Mechanismus

und macht sie daraufhin kenntlich. Eine Sperrung der replizierten Objekte w¨

ah-

rend der Bearbeitung w¨

urde Konflikte verhindern, kommt aber schon deshalb nicht

in Frage, weil die Sperre unverbundene Knoten nicht erreichen w¨

urde und wie die

Anderung ebenfalls epidemisch ¨

ubertragen werden m¨

usste. Die einzige m¨

ogliche Vor-

gehensweise in sporadisch verbundenen Systemen ist ein so genanntes optimistisches

Sperren (engl. optimistic locking) der replizierten Objekte3. Dies bedeutet, dass ein

Objekt erst gesperrt wird, wenn ein Konflikt aufgetreten ist. Um die Sperre wieder

aufzuheben, muss infolgedessen der Konflikt zuerst behoben werden. Diese Strategie

basiert auf der Annahme, dass Konflikte die Ausnahme bleiben und selten auftreten.

Mit gr¨

oßeren zeitlichen Abst¨

anden zwischen den Synchronisationen der replizier-

ten Objekte erh¨

oht sich gleichzeitig die Wahrscheinlichkeit eines Konflikts. Daher

wird eine Synchronisation im optimalen Fall sofort nach der ¨

Anderung eines repli-

zierten Objektes erfolgen. Ist die Synchronisation aufgrund fehlender Verbindung

zu den replizierenden Knoten nicht m¨

oglich, erfolgt sie sp¨

atestens bei dem n¨

achsten

Verbindungsaufbau. Auch hier hilft eine epidemische Synchronisation im verteilten

Netzwerk die Abst¨

ande zwischen den Aktualisierungen zu verk¨

urzen.

Die im Folgenden vorgestellte Replikationsstrategie ist insbesondere f¨

ur die mobil-

verteilte Kooperation in virtuellen Wissensr¨

aumen ausgelegt, kann aber auf alle ko-

operativen Operationen in einem gemeinsamen Datenraum ¨

ubertragen werden. Die

Replikationsstrategie ist in der Lage, die replizierenden Knoten selbstst¨

andig zu

w¨

ahlen und zugleich die Offline-Verf¨

ugbarkeit der gemeinsam bearbeiteten Objekte

f¨

ur jeden Kooperationspartner zu gew¨

ahrleisten. Zus¨

atzlich wird ein Mechanismus

bereitgestellt, um Konflikte in der Synchronisation aufzudecken und zu beheben.

Um nicht beliebige Daten auf alle erreichbaren Knoten zu replizieren, stellt die

Replikationsstrategie Mechanismen bereit, die ermitteln, welche Daten auf welchen

Knoten repliziert werden sollen. Als Strukturierungsmittel f¨

ur die Replikation bie-

tet sich bei dem Konzept der virtuellen Wissensr¨

aume die Kooperationsgruppe an.

Da im virtuellen Wissensraum jeder Gruppe genau ein gemeinsamer Arbeitsbereich

zugeordnet ist, wird dieser mit allen enthaltenen Objekten zwischen den Gruppen-

mitgliedern repliziert. Im Idealfall hat so jedes Gruppenmitglied alle die Kooperation

betreffenden Daten auch im Fall einer gest¨

orten Verbindung verf¨

ugbar.

Sollen auch mobile Ger¨

ate mit wenig lokalem Speicherplatz in die Kooperation

integriert werden k¨

onnen, kann die Replikationsstrategie in mehreren Stufen abge-

schw¨

acht werden. Dazu werden die teilnehmenden Knoten in drei Klassen unterteilt.

Die erste Klasse sind die Independent Nodes, die alle Objekte der Kooperationsgrup-

pe replizieren. Die zweite Klasse der Selective Nodes kennt den Inhalt des gemeinsa-

men Arbeitsbereiches und w¨

ahlt die Objekte f¨

ur die lokale Replikation gezielt aus.

2Vgl. [Terry et al., 1995]

3Vgl. [Kung und Robinson, 1981]

Mobilit¨

at in der kooperativen Wissensarbeit

132 5.1 Replikationsstrategien f¨

ur die mobil-spontane Kooperation

Inhaltsbereich

Objektverzeichnis

Unterbereich

Benutzer1

Benutzer2

Inhaltsbereich

Objektverzeichnis

Abonnierte

Inhaltsbereiche

XYZ

2.1

Objekt

UVW

1.8

2.1 Benutzer1XYZ yes

... ...... ...

localSource IDVersionData ID

Benutzer2

Replikationstopologie

Abbildung 5.2: Schematische ¨

Ubersicht des Versionierungsmechanismus

Die dritte Klasse repr¨

asentiert Ger¨

ate, die ¨

uber quasi keinen lokalen Speicher verf¨

gen und die Objekte erst bei Bedarf ¨

uber das Netzwerk auf einem anderen Knoten

bearbeiten. Diese Klasse nennt sich On Demand Nodes.

Ger¨

ate der Klasse der On Demand Nodes sind nicht in der Lage ohne eine Netz-

werkverbindung zu mindestens einem Gruppenknoten der Klasse der Independent

Nodes, an der Kooperation teilzunehmen. Tats¨

achlich ist es m¨

oglich, mit einem

Independent Node und beliebig vielen On Demand Nodes, eine Art Client-Server-

System nachzubilden. Diese Konfiguration mit einem einzigen Independent Node ist

gleichzeitig die Untergrenze f¨

ur eine kooperationsf¨

ahige Infrastruktur mit der hier

vorgestellten Replikationsstrategie. Eine Aggregration des Datenraums aus den nur

zum Teil replizierten Daten auf den Selective Nodes ist nicht vorgesehen. Selective

Nodes k¨

onnen lediglich auf beiden Seiten vorhandene Repliken untereinander syn-

chronisieren.

Im Folgenden wird die technische Umsetzung der Replikationsstrategie auf Ba-

sis eines Overlay-Netzwerkes wie den Distributed Hash Tables (DHTs) aus Ab-

schnitt 4.3.1 diskutiert. Das Overlay-Netzwerk zeichnet sich f¨

ur die Zustellung der

Objekte und deren Aktualisierungen an die einzelnen Knoten verantwortlich. Die Re-

plikation b¨

undelt die beteiligten Knoten in Replikationsgruppen, sendet die Aktua-

lisierungen an deren Mitglieder und verwaltet die ben¨

otigten Daten f¨

ur die genutzte

Strategie. Die Konfliktaufdeckung und Behebung lehnt sich an den in Abschnitt 4.3.3

pr¨

asentierten Verfahren aus Bayou und Coda an. Sie geschieht im Wesentlichen ¨

uber

eine verteilte Versionierung der Objekte.

Mobilit¨

at in der kooperativen Wissensarbeit

133

Repliziert werden in der Regel komplette Inhaltsbereiche mit den enthaltenen

gemeinsamen Objekten. Um Konflikte mit geringen Datenaufkommen fr¨

uhzeitig er-

kennen zu k¨

onnen, existiert zu jedem Inhaltsbereich ein Verzeichnis der enthaltenen

Objekte. In dem Verzeichnis ist f¨

ur jedes im Inhaltsbereich enthaltene Objekt die

eindeutige Identifikationsnummer, die Version des Objektes und die Adresse des

Knotens, der die Version erstellt hat, gespeichert. Außerdem befindet sich dort ein

Vermerk, ob das Objekt schon lokal vorhanden ist oder noch empfangen werden

muss. Das Verzeichnis ist ein Objekt des Inhaltsbereiches wie jedes andere auch

und wird somit ¨

uber die gleichen Mechanismen verteilt und synchronisiert. Einen

Uberblick ¨

uber diese Struktur gibt Abbildung 5.2.

Zus¨

atzlich verwaltet jeder Knoten ein lokales Verzeichnis ¨

uber die abonnierten In-

haltsbereiche inklusive deren lokalen Versionsnummern. Wird ein Knoten aktiv und

meldet sich an dem Persistenznetzwerk an, kann er anhand dieses Verzeichnisses

vergleichen, welche Inhaltsbereiche noch aktuell sind und welche er aufgrund einer

neueren Version im Netz abgleichen muss. Stimmt die lokale Version mit der entfern-

ten Version eines replizierten Inhaltsbereiches ¨

uberein, ist dieser auf dem aktuellen

Stand. Bei abweichender Version liegt eine Diskrepanz im betroffenen Inhaltsbereich

vor und der Knoten f¨

uhrt einen Abgleich durch. Dabei kann er anhand der verf¨

ug-

baren Verzeichnisinformationen entscheiden, wie er mit den lokalen Repliken der

Inhaltsbereiche verfahren muss:

•Neue lokale Objekte werden in das Netzwerk verteilt. Dazu werden die Daten

uber das Overlay-Netzwerk epidemisch mit den replizierenden Nachbarknoten

abgeglichen.

•Aktuelle Objekte k¨

onnen ignoriert werden, da ihre Version mit der im Netzwerk

ubereinstimmt.

•Veraltete Objekte werden aus dem Netzwerk aktualisiert. Dazu kontaktiert der

Knoten die replizierenden Nachbarknoten und bittet um das Objekt. Diese sen-

den das Objekt ¨

uber das Overlay-Netzwerk an den anfragenden Knoten. Sollte

das Objekt noch nicht auf den replizierenden Nachbarknoten verf¨

ugbar sein,

ist das Objekt noch sehr neu und befindet sich in der epidemischen Verteilung.

Es wird den Knoten ¨

uber den Verteilungsprozess automatisch erreichen.

•Objekte mit Versionskonflikt, bei denen sowohl die lokale als auch die im Netz-

werk verf¨

ugbare Version eines Objektes aktueller sind als zum Zeitpunkt der

letzten Synchronisation, werden gesperrt und als inkonsistent markiert, bis

der Konflikt behoben ist. Um kaskadierende Konflikte zu vermeiden, werden

außerdem anhand der Verzeichniseintr¨

age die replizierenden Knoten ermittelt

und ¨

uber ein Ereignis ¨

uber den Konflikt in Kenntnis gesetzt. Nun ist es die

Aufgabe der Anwendungsschicht oder der Benutzer selbst, den Konflikt zu be-

heben. Ist der Konflikt gel¨

ost, wird das konfliktfreie Objekt als neue Version

uber das Netzwerk verbreitet und wieder freigegeben.

Mobilit¨

at in der kooperativen Wissensarbeit

134 5.1 Replikationsstrategien f¨

ur die mobil-spontane Kooperation

Mittels dieser Replikationsstrategie k¨

onnen alle Objekte so aktuell als nur m¨

og-

lich gehalten werden. Im verbundenen Zustand werden die Knoten automatisch mit

Aktualisierungen versorgt (Pushing). Nach einer Verbindungsunterbrechung erfolgt

der Abgleich direkt bei der Anmeldung an die verteilte Persistenz durch den Knoten

selbst (Polling). Der Abgleich der ¨

Anderungen mit der verteilten Persistenz wirft

die Frage nach der Vorgehensweise bei der Distribution der Aktualisierungen an die

Mitgliedsknoten der Replikationsgruppe auf. Als Replikationsgruppe wird diesbe-

z¨

uglich die Gruppe aller teilnehmenden Independent Nodes der Kooperationsgruppe

verstanden.

Eine m¨

ogliche Distributionsstrategie ist ein sternf¨

ormiger Punkt-zu-Punkt-Ab-

gleich mit allen replizierenden Knoten im Netz. In diesem Fall w¨

aren bei nreplizie-

renden Knoten alle nKnoten in einem Schritt aktualisiert. Dies w¨

urde bedeuten,

dass sich der ¨

andernde Knoten mit n−1 Nachbarn abgleichen muss. Dies k¨

onnte

z. B. ¨

uber ein DHT oder ein anderes Adressierungsverfahren geschehen. Betrachtet

man die Verteilungsstrategie als einen Graphen, kommt dies einem Knotengrad4

von n−1 gleich. Die ¨

Anderung muss ¨

uber jede Kante einmal verschickt werden.

Dies kann schnell zu einem Flaschenhals am ¨

andernden Knoten f¨

uhren, da alle ¨

An-

derungen ¨

uber eine einzige Netzwerkverbindung gesandt werden. Auch wenn der

Knoten ¨

uber mehrere Netzwerkschnittstellen verf¨

ugen w¨

urde, ist die Bandbreite, die

dem Knoten zur Verf¨

ugung steht, begrenzt. Da sich die f¨

ur die ¨

Ubertragung einer

Anderung ben¨

otigte Gesamtbandbreite aus der Formel ”Gr¨

oße der ¨

Anderung ∗Kno-

tengrad“ ergibt, und die Gr¨

oße der ¨

Anderung nicht beeinflussbar ist, ergibt sich die

einzige Optimierungm¨

oglichkeit im Bereich des Knotengrades.

Der Knotengrad l¨

asst sich verringern, indem die ¨

Anderungen in einer Reihento-

pologie von Knoten zu Knoten weitergereicht werden. Dies hat allerdings zur Folge,

dass die ¨

Anderung den letzten der nKnoten erst nach n−1 Schritten erreicht.

Ziel ist aber eine ¨

Ubertragung der ¨

Anderungen an alle Knoten mit m¨

oglichst wenig

Bandbreitenverbrauch je Knoten und in m¨

oglichst wenig Schritten. Gesucht wird al-

so eine Distributionsstrategie, die einen geringen Knotengrad hat und deren Graph

einen geringen Durchmesser besitzt.

So eignen sich die in Abschnitt 4.4 vorgestellten Verfahren mittels Multicast-

B¨

aumen, wie sie z. B. in Scribe zu finden sind, durch ihre Baumstruktur gut f¨

eine epidemische Verbreitung von Objekten im Graphen. Die H¨

ohe des Knotengrads

im (balancierten) Baum bestimmt dabei automatisch die Entfernung zum letzten

Knoten. Allerdings muss der Distributionsbaum bei einer hohen Knotendynamik,

wie sie in mobilen Nutzungszenarien vorkommt, h¨

aufig reorganisiert werden, um

nicht zu degenerieren. Des Weiteren ist ein solcher Graph nicht symmetrisch, da

alle Nachrichten zun¨

achst an den Wurzelknoten gesandt werden m¨

ussen, der diese

dann nach unten weiterverteilt. Somit k¨

onnen Knoten in der N¨

ahe des Wurzelkno-

tens ihre Nachrichten schneller verbreiten als die Knoten in tieferen Schichten des

Distributionsbaums.

4Knotengrad ist die Anzahl der Kanten, die einen Knoten verlassen.

Mobilit¨

at in der kooperativen Wissensarbeit

135

h(x) h(x) h(x)

h(x)

Hash-

Raum

komplett

synchronisierende

Peers

(Independent Nodes)

teilweise synchronisierende Peers

(Selective Nodes, On Demand Nodes)

Abbildung 5.3: Ein HC(3) als Distributions- und Replikationstoplologie, bestehend

aus Independent Nodes mit den ¨

uber den Hashraum verbundenen Selective/On

Demand Nodes

Die Symmetrieeigenschaft, von allen Knoten aus alle anderen gleich gut errei-

chen zu k¨

onnen, ist im Hypercube gegeben. Hypercubes sind f¨

ur einen guten Daten-

durchsatz und eine geringe Ausdehnung bekannt: Ein Hypercube mir dDimensionen

(HC(d)) verbindet n= 2dKnoten bei einer Ausdehnung von lediglich log(n) = d

und einem Knotengrad der ebenfalls bei log(n) liegt. Dies macht den Hypercube zu

einer interessanten Topologie f¨

ur die Verteilung der Aktualisierungen innerhalb der

replizierenden Gruppe.

In dem hier vorgestellten Verfahren wird bei der ¨

Anderung eines replizierten Ob-

jektes auf einem Knoten die Aktualisierung an die direkten Nachbarknoten im Hy-

percube gesandt5. Diese verteilen die Aktualisierungen wiederum an ihre Nachbarn

5Nutzt man eine Hypercube-Topologie f¨

ur die Synchronisation der Objekte in der replizierenden

Gruppe, ist jeder Mitgliedsknoten ein Eckpunkt des Hypercubes. In diesem Hypercube kann

man die Daten nun z. B. per hypercube mulicast [Jang, 1990] oder epidemisch [vgl. Terry et al.,

1995] verteilen.

Mobilit¨

at in der kooperativen Wissensarbeit

136 5.1 Replikationsstrategien f¨

ur die mobil-spontane Kooperation

bis die Aktualisierung alle Knoten erreicht hat. Dies geschieht aufgrund der Eigen-

schaften des Hypercubes in log(n) Schritten. Die Adressierung der Nachbarknoten

im Netzwerk geschieht dabei wie gewohnt ¨

uber das Overlay-Netzwerk. Jeder Knoten

muss daher lediglich die Adressen seiner Nachbarknoten in dem Hypercube kennen.

In dem Hypercube sind alle Independent Nodes der Kooperationsgruppe enthalten.

Die Selective Nodes und die On Demand Nodes werden mit den Independent Nodes

assoziiert. Mit diesen gleichen sie sich Punkt-zu-Punkt ab. Der Independent Node

verbreitet die ¨

Anderungen von seinen assoziierten On Demand und Selective Nodes

innerhalb der Replikationsgruppe. Die Zuordnung der Selective Nodes und der On

Demand Nodes zu den Independent Nodes erfolgt ¨

uber deren Abstand zueinander.

Beim einem konsistenten Hashverfahren6wird der Independent Node mit der

kleinsten Differenz zum Hashwert des Selective Nodes oder On Demand Nodes ge-

w¨

ahlt. Bei Pastry (vgl. Abschnitt 4.3.1) k¨

onnte auch das Neighborhood Set genutzt

werden, um eine gute Netzwerkverbindung zwischen den Knoten als Maß f¨

ur N¨

ahe zu

nutzen. Eventuell kann ¨

uber ein gewichtetes Hashing noch eine Lastverteilung ¨

uber

die Independent Nodes erreicht werden. Die Synchronisation zwischen den beteilig-

ten Knoten ¨

uber den Hypercube und das Overlay-Netzwerk wird in Abbildung 5.3

dargestellt.

In [Eßmann et al., 2005] wird das hier vorgestellte Replikationsverfahren mit ei-

ner Abwandlung des Hypercubes vorgestellt. Das abgewandelte Verfahren basiert auf

Sparse Graphen7deren Hauptidee die Aufteilung der Eckpunkte des Hypercubes in

mehrere Knoten ist. Dies erlaubt eine h¨

ohere Anzahl von Knoten pro Dimension (vgl.

Abbildung 5.4) und f¨

uhrt zu einer besseren Lastverteilung zwischen den Knoten im

Graphen, da der Knotengrad bei leicht h¨

oherer Pfadl¨

ange geringer ist. Der weitaus

gr¨

oßere Vorteil der Sparse Graphen gegen¨

uber dem Hypercube ist die Flexibilit¨

in Bezug auf die Knotenanzahl. Ein Sparse Graph muss nicht auf die n¨

achst h¨

ohere

Dimension erweitert werden, wenn die Knotenzahl des Hypercubes gef¨

ullt ist. Aus

Gr¨

unden der Optimierung kann dies jedoch bei Bedarf zu einem g¨

unstigen Zeitpunkt

nachgeholt werden. Knotenausf¨

allen kann oft mit lokalen Rekonfigurierungen begeg-

net werden. Erst eine ung¨

unstige Partitionierung des Netzwerkes w¨

urde zu einer

sofortigen Neuinitialisierung f¨

uhren.

Das hier betrachtete Verfahren f¨

ur die Replikation und Distribution der gemeinsa-

men Objekte einer Kooperationsgruppe in einem mobilen Nutzungsumfeld erg¨

anzt

die verf¨

ugbaren Technologien f¨

ur eine dynamische und verteilte Kommunikation in

Form von Overlay-Netzwerken um die wichtige Komponente der Offline-Verf¨

ugbar-

keit der Koopertationsobjekte bei m¨

oglichst allen Kooperationsteilnehmern. Durch

die Klassifikation der potentiell genutzten Ger¨

ate gem¨

aß ihrer F¨

ahigkeit zur Replika-

tion des gemeinsamen Arbeitsbereichs wird eine Teilnahme auch f¨

ur leistungsschwa-

che Hardwarekomponenten erm¨

oglicht. Des Weiteren sorgen die Mechanismen zur

Konfliktbehandlung f¨

ur eine fr¨

uhzeitige Aufdeckung von Konflikten und die M¨

oglich-

6Vgl. [Karger et al., 1997]

7Vgl. [Els¨

asser et al., 2001]

Mobilit¨

at in der kooperativen Wissensarbeit

137

Abbildung 5.4: Distributionstopologie basierend auf einem Sparse Graphen der

Dimension d= 3 mit 33 Knoten (G(33))

keit zur kooperativen Behebung derselben. Bei allen einbezogenen Verfahren wurde

ein starker Fokus auf Effizienz und Transparenz f¨

ur die Benutzer gelegt.

Auch wenn mit den hier vorgestellten Bausteinen bereits eine mobilit¨

atsfreund-

liche verteilte Persistenz in eine Anwendung eingebunden werden kann, w¨

urde die

Integration der Persistenzschicht doch einen Großteil der Entwicklungsarbeit f¨

den Anwendungsentwickler einnehmen. Ziel ist es, ein Konzept zu entwickeln, das

die komplexe Struktur der hier vorgestellten Persistenzschicht in einen gekapselten

und universellen verteilten Speicher verwandelt. Der folgende Abschnitt besch¨

aftigt

sich mit dem flexiblen Konzept der Tuple Spaces, das diese Aufgabe leisten kann.

5.2 Gruppen-Tuple Spaces als Paradigma f¨

ur eine

Persistenzschicht mobil-verteilter Wissensr¨

aume

Die Kombination von Technologien zur spontanen Vernetzung, Kommunikation und

Speicherung in verteilten Systemen mit der im vorigen Abschnitt vorgestellten Re-

plikationsstrategie, erm¨

oglicht einen strukturierten und verteilten Speicher, der die

gew¨

unschten Eigenschaften der mobil-spontanen Vernetzung und der Offline-Verf¨

ug-

barkeit erf¨

ullt. Der Zugriff auf einen derart verteilten und stark replizierten Speicher

setzt aber von Benutzern wie Entwicklern eine tiefgehende Kenntnis der Konzepte

und Strategien der verteilten Persistenz voraus. Die Komplexit¨

at des mobil-verteilten

Speichers erschwert die Erstellung und Benutzung der darauf aufsetzenden Koope-

rationsanwendungen erheblich. Idealerweise sollte sich der Zugriff auf die Objekte so

gestalten, als w¨

urden diese lokal vorliegen.

Mobilit¨

at in der kooperativen Wissensarbeit

138 5.2 Gruppen-Tuple Spaces

Auch fehlen in dieser Architektur noch geeignete Kommunikationsmechanismen

f¨

ur die mobile Kooperation mittels verteilter Anwendungen. Die Knoten, die die ver-

teilte Anwendung aufspannen, sind mitunter nicht zeitgleich im Netzwerk erreichbar

und k¨

onnen somit Nachrichten nicht direkt miteinander austauschen. Daher wird

die Kommunikation in der hier vorgestellten Architektur nicht nur r¨

aumlich sondern

auch zeitlich entkoppelt. Die in Abschnitt 4.4 beschrieben Mechanismen leisten diese

zeitliche Entkoppelung nicht, sondern bieten nur eine synchrone Kommunikation in

einer r¨

aumlich verteilten Topologie.

Die in Abschnitt 4.3.2 vorgestellten Tuple Spaces bieten genau die Eigenschaften

eines einfachen Objektzugriffs und einer r¨

aumlich und zeitlich entkoppelten Kom-

munikation. Der transparente Zugriff auf die gespeicherten Objekte wird mittels des

Tuple/Template-Konzepts bewerkstelligt. Dieses Konzept wird im Folgenden noch

einmnal kurz skizziert.

Eine Anwendung, die auf den Tuple Space zugreift, speichert ein Datum, indem

es dieses in Form eines Vektors von Attributen in ein Tuple verpackt und im Tuple

Space ablegt ( in(tuple) ). Um ein Objekt aus dem Tuple Space zu lesen oder zu

entnehmen wird ¨

uber ein Template das gesuchte Tuple mittels der gew¨

unschten At-

tributwerte definiert und bei einer ¨

Ubereinstimmung an die Anwendung ¨

ubergeben

(read(template) und out(template) ).

LIME zeigt, dass ¨

uber dieselben Mechanismen des Tuple Space auch eine zeit-

lich und r¨

aumlich entkoppelte Kommunikation etabliert werden kann. Nachrichten

werden analog zu den Datenobjekten ebenfalls als Tuple im Tuple Space abgelegt,

k¨

onnen aber zus¨

atzlich mit einer Empf¨

angeradresse versehen werden, damit sie nur

die gew¨

unschten Knoten erreichen. Sind die Zielknoten mit dem netzweiten Tuple

Space verbunden, liefert ein spezielles Template alle vorliegenden Nachrichten an

den Knoten aus.

Zwar basieren viele Implementierungen von Tuple Spaces, wie z. B. Linda,Java-

Spaces und TSpaces, auf einem lokalen Speicher f¨

ur die Multiprozess-Kommunikation

oder auf Client-Server-Konzepten mit zentralen Diensten im Netzwerk, aber es exis-

tieren auch Ans¨

atze zu spontan vernetzten und verteilten Tuple Spaces, wie z. B. LI-

ME (vgl. Abschnitt 4.3.2). Keiner der vorhandenen Ans¨

atze bietet jedoch eine wirk-

same Replikationsstrategie f¨

ur die Offline-Verf¨

ugbarkeit. Außerdem sind die existie-

renden Systeme nicht auf die Bed¨

urfnisse gruppenbasierter Kooperationskonzepte

zugeschnitten. Im Folgenden wird daher ein f¨

ur mobil-verteilte Kooperationsumge-

bungen geeigneter Tuple Space entworfen.

In weitr¨

aumig verteilten und dynamisch vernetzten Tuple Spaces existiert wie in

allen verteilten Speicherkonzepten das Problem der Distribution und Ortung der Da-

tenobjekte (Tuple). Prinzipiell existieren zwei m¨

ogliche Methoden f¨

ur die Verteilung

und Ortung der Tuple in einem ¨

uber das Netzwerk verteilten Tuple Space8. Die erste

Methode ist die ”Hash-based Distribution“, die eine Hashfunktion benutzt, um die

Tuple auf die verf¨

ugbaren Knoten zu verteilen und anschließend wieder aufzufinden.

Dieser Ansatz ¨

ahnelt stark den in Abschnitt 4.3.1 beschriebenen Distributed Hash-

8Vgl. [Fenwick und Pollock, 1997]

Mobilit¨

at in der kooperativen Wissensarbeit

139

tables (DHT). Die zweite Methode wird ”Operator-based Distribution“ genannt. Sie

nutzt eine Replikation der Daten ¨

uber die Knoten des verteilten Tuple Space.

Bei der ”Operator-based Distribution“ lassen sich entweder die Tuple oder die

Templates an alle beteiligten Knoten replizieren. Bei einem ”Positive Broadcast“

werden die Tuple auf alle beteiligten Knoten repliziert und in deren lokalen Tuple

Space gespeichert. Bei einem ”Negative Broadcast“ werden hingegen die Templates

an alle Knoten gesandt und dort gegen die lokal vorhandenen Tuple verglichen. Bei

einer ¨

Ubereinstimmung wird das lokale Tuple mit einer ¨

Ubereinstimmung an den

anfragenden Knoten gesandt. Dar¨

uber hinaus existiert mit dem ”Hybrid Broadcast“

eine dritte M¨

oglichkeit, die Tuple und/oder Templates jeweils an eine Teilmenge der

Knoten versendet. Somit existieren im Wesentlichen die folgenden Vorgehensweisen

f¨

ur einen verteilten Tuple Space:

•Hash-basierte Tuple Verteilung: Tuples werden nach einem Schl¨

ussel auf die

Knoten verteilt.

•Operator-basierte Verteilung: Tuple oder Templates werden an alle Knoten

oder eine Teilmenge der Knoten des Netzwerkes gesandt. Hier ergeben sich

wieder drei m¨

ogliche Varianten:

–Negativer Broadcast: Die Tuple werden lokal auf den Knoten gespeichert,

die Templates werden an alle Knoten verteilt (Broadcast) und liefern die

passenden Tuple zur¨

uck.

–Positiver Broadcast: Die Tuple werden an alle beteiligten Knoten verteilt

(Broadcast) und die Templates werden lokal auf die Tuple angewandt,

die einen Knoten erreichen.

–Hybrid Broadcast: Sowohl Tuple als auch Templates werden auf Unter-

mengen der Knoten des Netzwerkes verteilt.

Jedes der Verfahren hat je nach betrachtetem Anwendungskontext Vor- und Nach-

teile. Die Verteilung der Tuple anhand einer Hash-Funktion hat wie bei den DHTs

eine gute Lastverteilung auf Kosten der st¨

andigen Verf¨

ugbarkeit zur Folge. F¨

allt

der speichernde Knoten aus, ist das Tuple nicht l¨

anger erreichbar. Bei Operator-

basierten Verfahren entsteht ein h¨

oherer Speicherbedarf und es muss die Wahrung

der Koh¨

arenz beachtet werden. Wenn z. B. ein Negative Broadcast mehrere Tuple

zur¨

uckliefert, wird nur ein Tuple als Treffer gew¨

ahlt. Die anderen ebenfalls passenden

Tuple werden wieder in die Tuple Spaces eingef¨

ugt aus denen sie empfangen wur-

den. Des Weiteren zieht ein Positive Broadcast einen hohen Speicherbedarf bei allen

beteiligten Knoten nach sich und der replizierte Tuple Space muss zur Wahrung der

Konsistenz synchronisiert werden.

Mit den genannten Verfahren l¨

asst sich die im vorigen Abschnitt 5.1 beschrie-

bene Replikationsstrategie in einen verteilten Tuple Space einbetten. Die Benutzer

erhalten so einfach und transparent Zugriff auf die hochverf¨

ugbare Persistenzschicht

Mobilit¨

at in der kooperativen Wissensarbeit

140 5.2 Gruppen-Tuple Spaces

inklusive eines Mechanismus f¨

ur die zeitlich und r¨

aumlich entkoppelte Kommunika-

tion zwischen den beteiligten Knoten.

Um eine flexible Nutzung des verteilten Speichers zu erlauben und dennoch ge-

zielt ein gruppenbasiertes Arbeiten in gemeinsamen Arbeitbereichen zu unterst¨

utzen,

wird der Tuple Space in dem hier vorgestellten Ansatz in drei Ebenen gegliedert.

Einem Network Tuple Space, einem Host Tuple Space und einem Gruppen-Tuple

Space.

Erstere zwei sind den Konzepten von LIME entlehnt und bilden die netzwerk- und

ger¨

ateweite Speicherung und Kommunikation ab. Der Network Tuple Space spannt

sich ¨

uber die gesamte verteilte Umgebung und erlaubt die globale Speicherung von

Daten, die nicht st¨

andig verf¨

ugbar sein m¨

ussen. Um den Speicherbedarf m¨

oglichst

gering zu halten, wird der globale Network Tuple Space ¨

uber die beteiligten Knoten

gleichm¨

aßig verteilt (z. B. mittels Hashing). Der Host Tuple Space hingegen steht nur

lokal auf dem jeweiligen Ger¨

at zur Verf¨

ugung und wird auch nur lokal gespeichert.

Er ist f¨

ur den Austausch und die Kommunikation von lokalen Prozessen zust¨

andig.

Die dritte Ebene bilden die so genannten Gruppen-Tuple Spaces, die im Rah-

men dieser Arbeit speziell f¨

ur die Gruppenarbeit konzipiert wurden. Von ihnen darf

es in der Softwareumgebung beliebig viele geben. Die Knoten des verteilten Tu-

ple Space m¨

ussen einen Gruppen-Tuple Space explizit abonnieren, um diesen lokal

zu replizieren. Jeder Teilnehmer kann einen solchen Gruppen-Tuple Space spontan

gr¨

unden und von diesem Moment an ¨

uber einen eindeutigen Namen addressieren.

Der Gruppen-Tuple Space enth¨

alt den von einer Knotengruppe replizierten gemein-

samen Inhaltsbereich und liegt somit auf jedem beteiligten Knoten redundant vor.

Er wird gem¨

aß der in Abschnitt 5.1 vorgestellten Replikationsstrategie zwischen den

Abonnenten verteilt und synchronisiert. Zudem stellt der Gruppen-Tuple Space Me-

chanismen bereit, die der zugreifenden Anwendung Konflikte aufzeigen und diese

l¨

osen helfen.

Die in Abschnitt 5.1 angesprochenen Replikationsklassen ”Independent Nodes“,

”Selective Nodes“ und ”On Demand Nodes“ k¨

onnen auch im Gruppen-Tuple Space

genutzt werden, um die Replikationsstrategie anzupassen. Die Gruppenmitglieder

eines Gruppen-Tuple Space k¨

onnen bei ihrem Beitritt mitteilen, zu welcher der

drei Replikationsklassen sie geh¨

oren m¨

ochten. Die Independent Nodes replizieren

den Gruppen-Tuple Space vollst¨

andig und jedem Gruppen-Tuple Space muss min-

destens ein Independent Node zugeordnet sein. Andere Knoten replizieren lediglich

einzelne und explizit gew¨

ahlte Tuple lokal (Selective Nodes) oder greifen nur ent-

fernt ¨

uber einen Independent Node auf die Tuple des Gruppen-Tuple Space zu (On

Demand Nodes). Zwischen den Mitgliedern der Klasse der Independent Nodes wird

der Gruppen-Tuple Space wie in Abschnitt 5.1 beschrieben repliziert.

Je nach Berechtigung k¨

onnen auch Nichtmitglieder der Gruppe auf Tuple des

Gruppen-Tuple Space zugreifen solange ein Independent Node erreichbar ist, der

den Gruppen-Tuple Space repliziert. Die G¨

aste greifen wie Selective Nodes oder On

Demand Nodes auf die Tuple zu, besitzen aber nicht dieselben Berechtigungen wie die

Gruppenmitglieder. Die Zugriffsrechte h¨

angen von den von der Gruppe vergebenen

Berechtigungen f¨

ur die einzelnen Tuple ab.

Mobilit¨

at in der kooperativen Wissensarbeit

141

Legende:

Replikation (epidemisch) Lokaler Speicher

Gruppen-Tuple Space

Gruppe Persistenzdienst

(CSCW-Server)

mobile

Geräte

Abbildung 5.5: Replikation des Gruppen-Tuple Space zwischen Independent Nodes

der Gruppenmitglieder und einen optionalen und nicht sichtbaren Persitenzdienst

Um die Verf¨

ugbarkeit des Gruppen-Tuple Space f¨

ur On Demand Nodes und Se-

lective Nodes zu erh¨

ohen und gleichzeitig auch die Zeitabst¨

ande zwischen der Syn-

chronisation der Independent Nodes zu verringern, kann ein zentral positionierter

und stets erreichbarer Knoten als eine Art Persistenzdienst in Form eines nicht sicht-

baren Mitglieds der Gruppe beitreten und deren Gruppen-Tuple Space replizieren.

Dieses Vorgehen erm¨

oglicht auch klassische CSCW-Server in eine solche Struktur

einzubinden. Als unsichtbares Mitglied der Gruppe wird der Server automatisch

mit allen Ver¨

anderungen im Tuple Space der Gruppe abgeglichen und kann so ein

Abbild des gemeinsamen Arbeitsbereiches in der eigenen Persistenz vorhalten (vgl.

Abschnitt 5.3). Abbildung 5.5 zeigt einen Gruppen-Tuple Space mit voll replizieren-

den Mitgliedern und einem zus¨

atzlichen Knoten als Persistenzdienst.

Die Struktur des verteilten Tuple Space erinnert durch die Partitionierung in

Gruppen-Tuple Spaces stark an die Gruppenstrukturen in virtuellen Wissensr¨

au-

men. Das Konzept der Gruppen-Tuple Spaces kann daher leicht auf den virtuellen

Wissensraum abgebildet und ¨

ubertragen werden. Im virtuellen Wissensraum ist je-

der Gruppe ein Gruppenbereich (oder auch Gruppenraum) zugeordnet, in dem die

zur Kooperation ben¨

otigten Objekte abgelegt werden. Jede Gruppe im virtuellen

Wissensraum besitzt somit einen eigenen Gruppen-Tuple Space in der Perstistenz-

schicht und legt die gemeinsamen Objekte als Tuple in diesem ab. Der so gespeicher-

te gemeinsame Arbeitsbereich ist dank der Replikationsstrategie, zum einen stets so

synchron wie m¨

oglich und zum anderen stets f¨

ur die Kooperationsteilnehmer erreich-

Mobilit¨

at in der kooperativen Wissensarbeit

142 5.2 Gruppen-Tuple Spaces

Gruppen-Tuple Space 1 Gruppen-Tuple Space 2

Verbindung

Gruppe 1 Gruppe 2

Abbildung 5.6: Virtuelle Wissenr¨

aume zweier Kooperationsgruppen mit den zu-

geordneten Gruppen-Tuple Spaces

bar, unabh¨

angig von der Verbindung zu den anderen Gruppenmitgliedern (Offline-

Verf¨

ugbarkeit ).

Die Raumstruktur der Gruppenbereiche innerhalb des Wissensraumes ist ¨

ubli-

cherweise zwischen den einzelnen Gruppen ¨

uber so genannte G¨

ange verkn¨

upft. Diese

M¨

oglichkeit bleibt auch bei dessen verteilter Speicherung in Gruppen-Tuple Spaces

gegeben. Das Ger¨

at eines Nichtmitglieds, das ¨

uber einen Gang in einen fremden

Gruppenarbeitsraum gelangt, greift als Gast auf den entsprechenden Gruppen-Tuple

Space zu. Die Berechtigungen f¨

ur derartige ”externe“ Zugriffe legen die Gruppenmit-

glieder zuvor explizit fest. Abbildung 5.6 zeigt die ¨

uber den Gruppen-Tuple Space

verteilte Raumstruktur zweier Gruppen.

Die gesamte Gruppenkommunikation und -koordination kann ebenfalls ¨

uber den

Gruppen-Tuple Space abgewickelt werden, indem die Nachrichtenobjekte in diesem

abgelegt werden. Die Knoten erhalten die Nachrichten, sobald sie sich mit dem Per-

sistenzsystem verbinden. ¨

Uber den Network Tuple Space kann zus¨

atzlich eine zeitlich

entkoppelte Punkt zu Punkt Kommunikation zwischen beliebigen Knoten etabliert

werden. Ein Nachrichtenobjekt wird ¨

uber das Hashing in Richtung Knoten geroutet

und in dessen ”N¨

ahe“ gespeichert, bis dieser sich wieder an dem System anmeldet.

Eine begrenzte Lebenszeit von Nachrichten und Objekten hilft hier den Speicher-

platzbedarf zu kontrollieren und Knoten davor zu bewahren, Nachrichten zwischen-

zuspeichern, die nie ausgeliefert werden.

F¨

ur eine systemweite Suche nach Objekten kann eine Doppelstrategie angewandt

werden. Analog zu den Persistenzdiensten werden Indexdienste auf zuverl¨

assigen

Knoten etabliert, die alle verf¨

ugbaren Objekte verzeichnen. So ist eine schnelle und

zuverl¨

assige Suche in dem verteilten Tuple Space m¨

oglich, solange sich ein solcher

Dienst in Reichweite befindet. F¨

ur eine Suche wird ein entsprechendes Template

an den Indexdienst gesandt und dieser leitet es an den Knoten weiter, der ¨

uber das

Tuple verf¨

ugt. Die zweite Variante nutzt einen Negative Broadcast, der das Template

an alle Knoten des Tuple Space sendet. So ist eine globale Suche im System auch

ohne Indexdienste m¨

oglich, wenngleich diese nicht so performant und zuverl¨

assig ist,

wie die Suche ¨

uber einen Indexdienst.

Mobilit¨

at in der kooperativen Wissensarbeit

143

Das Konzept der hier vorgestellten Tuple Spaces offeriert Anwendungen einen

transparenten Zugriff auf eine verteilte und stark replizierte Persistenzschicht. Ei-

ne Anwendung, die ¨

uber die hier betrachteten Tuple Spaces auf den gemeinsamen

Speicher zugreift, kann dies in der gleichen Weise tun, als wenn alle Objekte lokal

vorl¨

agen. Durch die Erweiterung des Konzeptes der Tuple Spaces um die Gruppen-

Tuple Spaces wird diesem verteilten Speicher eine logische Struktur gegeben, die

eine auf die gruppenbasierte Arbeit zugespitzte Replikationsstrategie erlaubt.

Obwohl diese Konzepte auch f¨

ur andere Anwendungsszenarien nutzbar sind, eig-

nen sie sich doch im besonderen Maße f¨

ur die Implementierung eines mobil-verteilten

virtuellen Wissensraums. Die enthaltene Replikationsstrategie sorgt f¨

ur die Offline-

Verf¨

ugbarkeit der Kooperationsobjekte und orientiert sich intuitiv an der Gruppen-

struktur. Mittels der Abstraktionsschicht der Gruppen-Tuple Spaces und der darauf

aufsetzenden kooperationsst¨

utzenden Schicht eines mobil-verteilten Wissensraumes

sind auch die letzten L¨

ucken der Musterarchitektur f¨

ur eine verteilte Kooperations-

umgebung zur Kooperation in mobil-spontanen Nutzungsszenarien geschlossen.

F¨

ur eine offene Architektur fehlt noch ein Konzept zur Einbettung externer Diens-

te in dieses Modell. Daher besch¨

aftigt sich der folgende Abschnitt mit der flexiblen

Integration externer Dienste in die Kooperationsumgebung.

5.3 Einbettung externer Dienste in die mobil-verteilte

Kooperationsumgebung

Die Einbettung externer Dienste in eine Kooperationsumgebung bietet den Benut-

zern Zugriff auf Ressourcen außerhalb der Kooperationsumgebung, ohne diese f¨

deren Nutzung verlassen zu m¨

ussen. Weiterhin kann die Kooperationsumgebung mit

diesen externen Diensten die Kooperationsprozesse der Benutzer unterst¨

utzen oder

um lokal nicht vorhandene technische Funktionalit¨

aten erg¨

anzen.

Da die externen Dienste nicht ¨

uberall und in jeder Kooperationssituation verf¨

ug-

bar sind, darf sich die Kooperationsumgebung keinesfalls auf deren Pr¨

asenz verlassen

oder die Kooperation von diesen externen Diensten abh¨

angig machen. Wichtige Ziele

einer Einbettung externer Dienste sind daher eine lose Kopplung an deren Funktio-

nalit¨

at und eine stimmige Integration der Dienstleistungen in die Nutzungskonzepte

der Kooperationsumgebung.

Unter der Forderung nach einer losen Kopplung wird in diesem Zusammenhang

eine Einbettung der externen Dienste bei Verf¨

ugbarkeit, ohne Einschnitte in die

Grundfunktionalit¨

at der Kooperationsumgebung bei deren Abwesenheit, verstan-

den. Die stimmige Integration in die Nutzungskonzepte bezieht sich auf eine me-

dienbruchfreie Einbettung der externen Dienste in die Kooperationsumgebung, ohne

neue Nutzungshemmnisse zu schaffen.

Das Feld m¨

oglicher externer Dienste, die sich in eine Kooperationsumgebung ein-

betten lassen, um Kooperationsprozesse zu unterst¨

utzen, ist schwer einzugrenzen.

Im Folgenden werden die vier wichtigsten Gruppen externer Dienste kurz erl¨

autert.

Mobilit¨

at in der kooperativen Wissensarbeit

144 5.3 Einbettung externer Dienste

Eine wichtige Gruppe externer Dienste, die die Kooperationsumgebung bei der

Konfiguration und Darstellung des Wissensraums unterst¨

utzen, bilden die Kontext-

dienste. Ein Kontextdienst kann z. B. Positionsinformationen von Kooperationspart-

nern ¨

ubermitteln oder den r¨

aumlichen Kontext der Kooperationssituation bereit-

stellen [Eßmann und Hampel, 2004]. Man spricht in diesem Zusammenhang auch

von einer Location Awareness. Neben dem Ortsbezug k¨

onnen noch viele weitere

Kontextinformationen f¨

ur eine Awareness der Handlungen der Kooperationspartner

bereitgestellt werden9.

Persistenzdienste bilden eine weitere Gruppe externer Dienste, die insbesondere

f¨

ur die Erg¨

anzung mobil-verteilter Persistenzkonzepte interessant ist. Diese k¨

on-

nen z. B. von dedizierten CSCW-Servern bereitgestellt werden, die Teile des mobil-

verteilten Datenraumes spiegeln, so die Verf¨

ugbarkeit der enthaltenen Daten erh¨

ohen

und zugleich Zugangsm¨

oglichkeiten f¨

ur Client-Server-basierte Kooperationswerkzeu-

ge bereitstellen. Das Konzept des Gruppen-Tuple Space sieht bereits eine Integration

solcher Dienste als implizite Mitglieder vor (vgl. Abschnitt 5.2).

Auch Dienste, die nicht direkt in die Funktionalit¨

at der eigentlichen Kooperati-

onsumgebung eingreifen, sind oft f¨

ur eine Kooperationsunterst¨

utzung wertvoll. So

k¨

onnen z. B. Compute-Dienste genutzt werden, die Objekte außerhalb der Kooperati-

onsumgebung transformieren oder auswerten. Diese k¨

onnen Benutzern Hilfestellung

bei der Bearbeitung der Kooperationsobjekte geben oder rechenintensive Aufgaben

der mobilen Ger¨

ate ¨

ubernehmen. Beispiele sind hier die Einbindung von Visualisie-

rungssystemen zur Darstellung und kooperativen Manipulation komplexer Daten-

s¨

atze [G¨

otz et al., 2006, 2005; Eßmann et al., 2006a, b] und die Integration von

Computer Algebra Systemen (CAS) f¨

ur Berechnungen an mathematischen Objekten

innerhalb des gemeinsamen Arbeitsbereiches [Bleckmann et al., 2005].

Auch die automatische Generierung von Inhalten f¨

ur den gemeinsamen Arbeits-

bereich ist ein Anwendungfeld externer Dienste. Informationsdienste k¨

onnen z. B.

aufbereitete Informationen und Datenobjekte f¨

ur die Kooperationsgruppe bereit-

stellen. M¨

oglich ist hier beispielsweise die Einbindung von externen RSS Feeds in

den gemeinsamen Arbeitsbereich.

Bei der Integration verf¨

ugbarer und gew¨

unschter externer Dienste in die mobil-

verteilte Umgebung ist deren automatische Konfiguration wichtig. Die Integration

kann dabei in unterschiedlichen Schichten der Kooperationsumgebung geschehen.

Das Auffinden und die Konfiguration des Zugriffs auf externe Dienste ist eine

typische Aufgabe der Netzwerkschicht. In administrierten Netzwerkinfrastrukturen

werden hier h¨

aufig Verzeichnisdienste, wie z. B. Lightweight Directory Access Pro-

tocol (LDAP)-Server, f¨

ur die Ver¨

offentlichung der verf¨

ugbaren Dienste und deren

Konfiguration genutzt. Es existieren aber auch L¨

osungen, die vorhandene Dienste

ohne administrativen Eingriff sowohl in der lokalen Netzwerkumgebung als auch in

weitr¨

aumig verteilten Systemen bekannt machen (vgl. Abschnitt 4.2.2). Diese Dienst-

informationen werden in der Netzwerkschicht gesammelt und an die Kooperations-

9Vgl. [Dourish und Bellotti, 1992]

Mobilit¨

at in der kooperativen Wissensarbeit

145

umgebung weitergereicht, die diese externen Dienste einbindet und den Benutzern

zug¨

anglich macht.

Dienste, die auf Objekte in der Kooperationsumgebung zugreifen, m¨

ussen in die

Persistenzkonzepte eingebettet werden, um auf die externen Objekte auch bei Ab-

wesenheit des entsprechenden Dienstes zugreifen zu k¨

onnen. Um diese Integration zu

erleichtern bietet sich ein Vorgehen wie in Abschnitt 5.2 an, in dem Persistenzdienste

als implizites Gruppenmitglied in die Replikationskonzepte eingebettet werden und

so die Daten der Gruppe automatisch replizieren. Die Persistenzdienste werden also

nicht in der Schicht der Objektverwaltung und -replikation eingebunden, sondern

auf einer h¨

oheren Abstraktionsebene integriert. Dies erlaubt eine durchg¨

angige Ein-

bettung externer Persistenzdienste in die mobil-verteilte Kooperationsumgebung als

eine Art implizite Gruppenmitglieder.

Eine besondere Klasse externer Dienste bilden jene, die eine direkte Interaktion

mit dem Benutzer unterst¨

utzen. Sie sind in die Benutzerschnittstelle zu integrie-

ren und als eigenst¨

andige Objekte im gemeinsamen Arbeitsbereich zug¨

anglich zu

machen. F¨

ur die Kooperation innerhalb virtueller Wissensr¨

aume bedeutet dies die

Integration der Dienste in Form ¨

ublicher Kooperationsobjekte mit allen M¨

oglichkei-

ten zu deren kooperativen Bearbeitung ¨

uber die bereitgestellten Medienfunktionen

[vgl. Eßmann et al., 2006a].

Durch das hier beschriebene Vorgehen ergibt sich eine durchg¨

angige Einbettung

externer Dienste in eine mobil-verteilte Kooperationsumgebung f¨

ur virtuelle Wis-

sensr¨

aume. Mittels des hier vorgestellten Ansatzes der Integration externer Dienste

wird eine Anreicherung der Kooperation mit Kontextinformationen, die Erh¨

ohung

der Zuverl¨

assigkeit der verteilten Persistenz und eine Einbettung von Kooperati-

onsobjekten, die der Umgebung z. B. aufgrund beschr¨

ankter Ressourcen der mobi-

len Ger¨

ate nicht zur Verf¨

ugung stehen w¨

urden, erreicht. Besondere Aufmerksam-

keit wird dabei auf die Bewahrung der Unabh¨

angigkeit der Grundfunktionalit¨

at der

mobil-verteilten Kooperationsumgebung von exteren Dienstleistern und auf die Ver-

meidung von Medienbr¨

uchen gelegt.

5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume

Die in diesem Kapitel vorgestellten Technologien und entworfenen Konzepte f¨

ugen

sich zu dem gesuchten Architekturmuster f¨

ur eine Kooperationsumgebung zur Be-

reitstellung mobil-verteilter Wissensr¨

aume zusammen. Wie bereits zu Beginn des

Kapitels angedeutet, setzt sich diese Musterarchitektur aus mehreren Forschungs-

bereichen zusammen. Die unterste Ebene einer solchen Architektur bildet die Kom-

munikationsschicht mit dem physikalischen Netzwerk und den darauf aufsetzenden

Protokollen. Sie erm¨

oglicht als Fundament die Kommunikation zwischen den betei-

ligten Knoten.

Auf diese Schicht setzt die Schicht f¨

ur die Objektverwaltung und -distribution auf.

Diese Schicht enth¨

alt u. a. ein Overlay-Netzwerk das die Paket-basierte Kommunika-

tion zwischen den Knoten in der heterogenen Netzwerkschicht maskiert. Zus¨

atzlich

Mobilit¨

at in der kooperativen Wissensarbeit

146 5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume

findet sich hier die eigentliche verteilte Persistenz, die auf das Overlay-Netzwerk zu-

r¨

uckgreift und sich f¨

ur die Speicherung und das Auffinden von Objekten innerhalb

des verteilten Systems verantwortlich zeichnet. Diese Schicht bildet den technischen

Kern der mobil-verteilten Kooperationsumgebung.

Die dritte Schicht abstrahiert von der technischen Komplexit¨

at der verteilten Ob-

jektspeicherung und entkoppelt so die logische Struktur mobil-verteilter Kooperation

von der technischen Struktur der Vernetzung. Sie wird daher als Abstraktionsschicht

bezeichnet. Sie orientiert sich in ihren Konzepten am Tuple Space. Mittels dieser

Konzepte wird sowohl die intuitive Strategie zur Objektreplikation als auch eine

zeitlich wie r¨

aumlich entkoppelte Kommunikation zwischen den beteiligten Anwen-

dungen realisiert. Des Weiteren erlaubt diese Abstraktionsschicht den Entwicklern

von mobil-spontanen Kollaborationsumgebungen einen transparenten Zugriff auf die

Kooperationsobjekte, ohne sich mit den Fragen der zugrunde liegenden technischen

Infrastruktur besch¨

aftigen zu m¨

ussen. Dies hilft ihnen sich auf den Entwurf der

eigentlichen Kooperationsanwendung zu konzentrieren.

Die oberste Schicht des Architekturkonzeptes bildet der eigentliche mobil-verteilte

Wissensraum. Er bildet die Konzepte der Kooperation im virtuellen Wissensraum

ab. Diese Schicht strukturiert die Kooperationsumgebung ¨

uber die raumbasierte

Metapher der virtuellen Wissensr¨

aume und stellt die elementaren prim¨

aren Me-

dienfunktionen f¨

ur die Manipulation der enthaltenen Kooperationsobjekte zur Ver-

f¨

ugung. Diese Schicht ist zugleich die h¨

ochste Abstraktionsebene der Architektur

und bildet ¨

uber das Konzept des virtuellen Wissensraumes die Schnittstelle zu den

Benutzern der mobil-spontanen Kooperationsumgebung. Diese greifen ¨

uber die ge-

nutzten Anwendungen auf den Wissensraum zu.

In den nun folgenden Abschnitten wird dieses Vier-Schichten-Modell des Ar-

chitekturkonzeptes einer verteilten Persistenz f¨

ur virtuelle Wissensr¨

aume in mobil-

spontanen Nutzungsszenarien zusammengef¨

uhrt [Eßmann und Hampel, 2005b] und

Schicht f¨

ur Schicht betrachtet (vgl. Abbildung 5.7). Im Rahmen dieses ¨

Uberblicks

werden noch einmal die L¨

osungsans¨

atze f¨

ur die im Rahmen dieser Arbeit identifi-

zierten zentralen Forschungsfragen pr¨

asentiert.

Kommunikationsschicht

Die Vernetzung mobiler Knoten ist eine wesentliche Voraussetzung f¨

ur die Kommuni-

kation innerhalb der mobil-verteilten Kooperationsumgebung. Aufgrund der hohen

Mobilit¨

at der Benutzer wird eine Kooperationsanwendung auf den mobilen Ger¨

ten mit einem st¨

andig wechselnden Einsatzumfeld konfrontiert. Bei der Vernetzung

mit den lokalen aber auch entfernten Kooperationspartnern ergibt sich eine stark

heterogene Umgebung. Zugangspunkte zu etablierten Netzwerkinfrastrukturen sind

eventuell nicht vorhanden oder stark reglementiert (Funkl¨

ocher, Firewalls, etc.). Um

dennoch, zumindest mit lokalen Partnern mittels der mitgef¨

uhrten mobilen Ger¨

te spontan in Kooperation treten zu k¨

onnen, wird eine unabh¨

angige und direkte

Vernetzung zwischen den Beteiligten ben¨

otigt.

Mobilit¨

at in der kooperativen Wissensarbeit

147

Abstraktionsschicht

Kommunikationsschicht

mobil-verteilter Wissensraum

Persistenzschicht

Distribution & Replikation

Overlay-Netzwerk

Abbildung 5.7: Die exemplarische Architektur einer mobil-spontanen Kooperati-

onsumgebung gliedert sich in vier Schichten: Die physikalische Netzwerkschicht

stellt eine grundlegende Punkt-zu-Punkt Kommunikation zwischen den Knoten

bereit. Ein Overlay-Netzwerk gew¨

ahrleistet die Verbreitung von Nachrichten und

Objekten. Die Abstraktionsschicht (z. B. in Form eines Tuple Space) bietet einen

netzweiten Speicher. Der mobil-verteilte virtuelle Wissensraum erm¨

oglicht eine

flexible Kooperation in sowohl mobil-spontanen als auch klassischen Nutzungssze-

narien.

Mobilit¨

at in der kooperativen Wissensarbeit

148 5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume

Wie Abschnitt 4.2.1 zeigt, ist ein breites Spektrum an m¨

oglichen Technologien

f¨

ur eine Vernetzung von mobilen Knoten verf¨

ugbar. Besonders geeignet f¨

ur die so

genannte Face-to-Face Kooperation sind die Mobilen Ad-Hoc-Netzwerke, die unab-

h¨

angig von den technischen Gegebenheiten der Umgebung in der Lage sind, Kommu-

nikationsinfrastrukturen von Grund auf zu etablieren. Sollen auch r¨

aumlich entfernte

Partner oder externe Kooperationsdienste in die Kooperation eingebunden werden,

ist eine Mischung von spontanen und administrierten Netzwerkinfrastrukturen na-

hezu unumg¨

anglich. Auch hier existieren bereits einige L¨

osungen, die im Rahmen

dieser Arbeit in das Gef¨

uge einer Musterarchitektur integriert werden.

Die so entstehenden komplexen Strukturen, die in Kombination mit k¨

unstlichen

Restriktionen seitens der Dienstanbieter von Kommunikationsnetzwerken zu H¨

ur-

den f¨

ur die Vernetzung einer verteilten Softwareumgebung bilden k¨

onnen, werfen

Fragen bez¨

uglich der Etablierung stabiler Kommunikationsinfrastrukturen zwischen

den verteilten Knoten einer Kooperationsumgebung auf. Zum einen ist das Auffinden

von potentiellen Kooperationspartnern in solch komplexen und weitreichenden Infra-

strukturen schwierig, zum anderen wird die direkte Kommunikation zwischen zwei

Knoten durch eventuelle Inkompatibilit¨

aten zwischen den genutzten Protokollen und

durch k¨

unstliche Hemmnisse zum Schutz institutioneller Interessen erschwert.

Die L¨

osung bieten hier Peer-to-Peer-Netzwerke, die Mechanismen bereitstellen,

um derartige Hemmnisse in der Kommunikationsstruktur zu umgehen und m¨

og-

liche Kommunikationspartner zu finden. In Kombination mit einer spontanen und

direkten Vernetzung von anwesenden potentiellen Kooperationspartnern bietet solch

eine Technik die M¨

oglichkeit, auch große Kooperationsnetzwerke zu errichten. Eine

derartige Kommunikationsarchitektur wurde in [Eßmann et al., 2004c] umgesetzt.

Es existieren somit geeignete Technologien zur spontanen wie weitr¨

aumigen Ver-

netzung von Kooperationspartnern, wenngleich sie noch nicht f¨

ur die breite Masse

der Benutzer verf¨

ugbar ist. Um zuk¨

unftig eine flexible Kommunikation der Benut-

zer gew¨

ahrleisten zu k¨

onnen, wird es ein wichtiges Ziel sein m¨

ussen, im Bereich der

Technologien zur spontanen Vernetzung offene Standards zu etablieren und in die

physikalische Kommunikationsschicht g¨

angiger Betriebssysteme zu integrieren. In

Kombination mit Technologien zur automatischen Dienstekonfiguration und Peer-

to-Peer Kommunikation in stark heterogenen Netzwerkinfrastrukturen bildet dies die

technische Grundlage f¨

ur eine allseits verf¨

ugbare mobile Kommunikationschicht ohne

sp¨

urbare technische Barrieren. Eine derart flexibel vernetzte Kommunikationsinfra-

struktur bietet ein ideales Umfeld f¨

ur kooperationsunterst¨

utzende Anwendungen im

mobilen Nutzungsumfeld.

Objektverwaltung und -distribution

Um in einer sich st¨

andig dynamisch ¨

andernden verteilten Umgebung eine persis-

tente Speicherung von Kooperationsobjekten zu gew¨

ahrleisten, bedarf es einer eben-

falls verteilten Objektspeicherung und -verwaltung. Die hohe Wahrscheinlichkeit einer

Trennung der mobilen Kooperationspartner von etablierten Netzwerkinfrastruktur-

en verbietet ein auf einzelne zentrale Knoten konzentriertes Persistenzkonzept. Um

Mobilit¨

at in der kooperativen Wissensarbeit

149

die Verf¨

ugbarkeit der Kooperationsobjekte zu erh¨

ohen, werden diese daher auf den

beteiligten Knoten verteilt abgelegt und verwaltet.

Mit Hinblick auf die Unterst¨

utzung von Kooperationsprozessen zwischen mobi-

len Benutzern gen¨

ugt eine verteilte Objektpersistenz besonderen Anforderungen. So

sorgt die im Rahmen dieser Arbeit entworfene Persitenzschicht f¨

ur die Verf¨

ugbarkeit

der kooperationsrelevanten Objekte bei allen beteiligten Benutzern (Offline-Verf¨

ug-

barkeit). Die kooperativen Handlungen laufen somit nicht Gefahr in Abh¨

angigkeit

von Zeitfenstern und Pl¨

atzen mit Zugang zu den ben¨

otigten Objekten zu geraten.

Gerade hier zeigten sich die Schw¨

achen existierender verteilter Persistenzsysteme.

Eine Kooperation in replizierten Datenr¨

aumen mittels ebenfalls replizierter Ko-

operationsobjekte gelingt nur, wenn die Replikate stets zueinander konsistent sind.

Dies ist besonders im Fall einer unverbundenen Bearbeitung von replizierten Ob-

jekten nicht garantiert. Daher werden etwaige Inkonsistenzen so fr¨

uh wie m¨

oglich

aufgedeckt und behoben. Eine Weiterverwendung inkonsistenter Objekte w¨

urde au-

tomatisch zu kaskadierenden Inkonsistenzen f¨

uhren und h¨

atte einen divergierenden

und eben nicht mehr gemeinsamen Datenraum zur Folge.

Die verteilte Persistenzschicht der hier vorgestellten Architektur bietet sowohl

die st¨

andige Verf¨

ugbarkeit der Objekte innerhalb einer Kooperationsgruppe mittels

einer gezielten Replikation der Objekte auf alle an der Kooperation beteiligten Knoten

als auch die Wahrung der Konsistenz des gemeinsamen Wissensraum durch eine

epidemische Synchronisation der Kooperationsobjekte und deren Versionierung f¨

die Konflikterkennung und -aufl¨

osung (vgl. Abschnitt 5.1).

Diese positiven Eigenschaften werden durch die Komposition von bew¨

ahrten DHT-

Konzepten und einer engmaschigen epidemischen Replikationsstrategie erreicht. Das

resultierende Persistenzkonzept eignet sich insbesondere f¨

ur die mobile Gruppenar-

beit. Im Gegensatz zu g¨

angigen verteilten Persistenzsystemen ist es m¨

oglich die

Kooperationsobjekte gezielt auf die Knoten der beteiligten Kooperationspartner zu

replizieren und synchronisiert zu halten. F¨

ur den Fall eines Konflikts zwischen den

replizierten Versionen eines Objektes wird dieser aufgrund der Versionierung so-

fort erkannt und der Kooperationsumgebung angezeigt. Diese versucht draufhin den

Konflikt automatisch und im Hintergrund zu l¨

osen oder reicht ihn an die beteiligten

Benutzer weiter, die den Konflikt dann kooperativ beheben k¨

onnen. Der Einsatz

des DHT-Konzeptes erlaubt es, Objekte effizient ¨

uber das Netzwerk innerhalb der

Gruppe zu verteilen und bei Bedarf zus¨

atzlich global zug¨

anglich zu machen.

Die technische Realisierung der gezielten Objektreplikation geschieht mittels ei-

ner logischen Strukturierung von Inhaltsbereichen und im Netzwerk gespeicherten

Objektverzeichnissen inklusive Versionsinformationen der enthaltenen Objekte. Die

Objekte werden in den Inhaltsbereichen geb¨

undelt. Hier k¨

onnen sie anhand der In-

formationen ¨

uber die gespeicherte Version des Objektes mit ihrem jeweiligen lokal

replizierten Pendant verglichen werden, um festzustellen, ob eine Synchronisation

der Repliken notwendig ist, oder gar ein Versionskonflikt vorliegt. Gleichzeitig wird

in diesem Verzeichnis vermerkt, welche Knoten ein Objekt replizieren. So k¨

onnen

Anderungen direkt ¨

uber eine DHT an die betroffenen Knoten weiterverteilt werden.

Interessierte Knoten m¨

ussen einen Inhaltsbereich lediglich abonnieren, um an der

Mobilit¨

at in der kooperativen Wissensarbeit

150 5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume

Replikation der enthaltenen Objekte teilzunehmen. Ab diesem Zeitpunkt werden sie

automatisch mit den enthaltenen Objekten synchronisiert.

Zus¨

atzlich sieht die vorgestellte Replikationsstrategie eine Abstufung des Replika-

tionsgrades entsprechend der Ressourcen teilnehmender Knoten vor und erlaubt so

auch Ger¨

aten mit wenig Speicherplatz den Zugriff auf die stark replizierten verteil-

ten Objekte. Diese m¨

ussen aufgrund der mangelnden lokalen Replikation lediglich

einige Einschr¨

ankungen der Offline-Verf¨

ugbarkeit der Objekte in Kauf nehmen.

Ubertragen auf den gemeinsamen Wissensraum kann der Arbeitsbereich einer

Gruppe einen Inhaltsbereich der verteilten Persistenzschicht zugeordnet werden,

um so eine verteilte und synchronisierte Speicherung der Kooperationsobjekte zu

gew¨

ahrleisten. Zus¨

atzlich erlaubt das Konzept auch die Integration zentraler Per-

sistenzdienste wie CSCW-Server in die verteilte Persistenzschicht. So l¨

asst sich die

Verf¨

ugbarkeit der Kooperationsobjekte noch weiter erh¨

ohen. Der Persistenzdienst

muss dazu lediglich ebenfalls den Inhaltsbereich abonnieren und so den aktuellen

Inhalt des Arbeitsbereichs der Kooperationsgruppe spiegeln.

Abstraktionsschicht

Die verteilte Persistenzschicht ist offensichtlich in der Lage, die n¨

otigen Mechanismen

zur Verf¨

ugung zu stellen, um die Kooperationsobjekte f¨

ur mobile Benutzer st¨

andig

verf¨

ugbar zu halten und die Konsistenz des Datenraums ¨

uber eine weitreichende

Synchronisation zu wahren. Prinzipiell w¨

are schon an diesem Punkt die Implemen-

tierung einer mobil-verteilten Kooperationsumgebung m¨

oglich. Allerdings m¨

ussten

in diesem Fall die Kommunikation zur Koordinierung der beteiligten Knoten und die

Verwaltung der Inhaltsbereiche von jeder Kooperationsanwendung selbst implemen-

tiert werden. Dies schließt auch die Mechanismen zum Abgleich der lokalen Objekte

mit den abonnierten Inhaltsbereichen und deren Objektverzeichnisse mit ein. Zu-

s¨

atzlich erschwert ein solches Vorgehen einen Austausch oder eine Erg¨

anzung der

Persistenzschicht durch andere Persistenzkonzepte wegen der starken funktionellen

Bindung zwischen Kooperationsanwendung und Objektspeicherung.

Um eine hohe Abstraktion von der eigentlichen Objektverteilung und -replikation

f¨

ur die Entwickler der Kooperationsanwendungen zu wahren und eine nicht an Ko-

operationsmetaphern gebundene Kapselung der Persistenzschicht zu erreichen, wird

der verteilte und replizierte Objektspeicher als ein generischer Speicher abstrahiert.

In diesem k¨

onnen Objekte abgelegt und wieder geladen werden, ohne von der genau-

en Speicherposition des Objekts im Netzwerk zu wissen oder die Replikation explizit

festzulegen. Dennoch ist der generische Speicher in der Lage, die Offline-Verf¨

ugbar-

keit der Objekte und die Wahrung der Konsistenz des gemeinsamen Datenraums zu

garantieren (vgl. Abschnitt 5.2).

F¨

ur die Umsetzung dieser w¨

unschenswerten Eigenschaften wird im Rahmen dieser

Arbeit das Konzept des Gruppen-Tuple Spaces entworfen. Dieser f¨

ugt dem bew¨

ahrten

Konzept der Tuple Spaces eine an der Gruppenarbeit orientierte Replikationsstra-

tegie hinzu. In Gruppen-Tuple Spaces werden Knoten, die auf einen gemeinsamen

Mobilit¨

at in der kooperativen Wissensarbeit

151

und replizierten Datenraum zugreifen wollen, in einem gemeinsamen Tuple Space10

gruppiert und k¨

onnen dort mittels einfacher Operationen Objekte (Tuple) gespei-

chert und wieder entnommen werden (vgl. Abschnitt 4.3.2). Dabei kann ein Knoten

auf beliebig viele Gruppen-Tuple Spaces gleichzeitig zugreifen und ohne weiteres

selber welche generieren.

Auf Wunsch informiert der Tuple Space die Anwendungen wenn ein neues Objekt

erscheint oder ein bereits existierendes ver¨

andert wurde. Die Anwendung reagiert

somit nur auf diese Ereignisse. Ein besonderes Ereignis ist hier der Konflikt von

uberschneidend ge¨

anderten Objekten. Dieser kann insbesondere nach einer Trennung

eines Knotens von den anderen Mitgliedern des gemeinsamen und replizierten Tuple

Spaces auftreten. Durch die Ereigniskontrolle werden in so einem Fall automatisch

alle betroffenen Anwendungen benachrichtigt und das Objekt bis zur Behebung des

Konflikts f¨

ur eine weitere Bearbeitung gesperrt, um ein Kaskadieren der Konflikte

zu vermeiden.

Das Konzept des Gruppen-Tuple Spaces stellt zus¨

atzlich zu dem gemeinsamen re-

plizierten Speicher die Mechanismen f¨

ur eine mobilit¨

atsfreundliche Kommunikation

unter den beteiligten Knoten bereit. Zu diesem Zweck werden die Nachrichtenob-

jekte an eine Knotengruppe oder an einzelne Knoten ebenfalls als Tuple in dem

gemeinsamen Tuple Space abgelegt. Dies erlaubt eine zeitlich und r¨

aumlich entkop-

pelte Kommunikation zwischen den Knoten, die so Nachrichten auch dann erhalten,

wenn sie zeitweise nicht erreichbar sind oder ¨

uber keine direkte Verbindung zu dem

Absenderknoten verf¨

ugen. Dieses Nachrichtensystem wird auch f¨

ur die Verbreitung

von Ereignissen zwischen den verteilten Knoten genutzt.

Neben den replizierten und stark gekoppelten Gruppen-Tuple Spaces existieren

außerdem ein Network Tuple Space und je Ger¨

at ein Host Tuple Space, die es erlau-

ben, Objekte und Nachrichten global innerhalb des gesamten Netzwerkes oder lokal

auf den Ger¨

aten auszutauschen. Diese Tuple Spaces sind allerdings nicht persistent

und f¨

ur die Koordination zwischen fremden Anwendungen konzipiert. Gemein mit

den Gruppen-Tuple Spaces ist ihnen die r¨

aumliche und zeitliche Entkopplung der

Kommunikation und die Fehlerrobustheit gegen¨

uber Verbindungsabbr¨

uchen.

Aufgrund der Integration von automatischer Replikation, Ereigniskontrolle und

entkoppelter Kommunikation ist diese Schicht der ideale Ort f¨

ur die Einbettung ex-

terner Dienste in die Kooperationsumgebung. Externe Dienste, die Informationen

zur Verf¨

ugung stellen oder Daten mit der Kooperationsumgebung austauschen, k¨

on-

nen ihre Daten ¨

uber den Tuple Space an alle Teilnehmer verbreiten, ohne deren

aktuellen Verbindungsstatus beachten zu m¨

ussen. Dies gilt insbesondere f¨

ur eine

Einbindung von Persistenzdiensten, die mit ihrer hohen Erreichbarkeit die Verf¨

ug-

barkeit des gemeinsamen Datenraums deutlich erh¨

ohen. Der Persistenzdienst muss

dazu lediglich dem Tuple Space als implizites Mitglied beitreten, um diesen von da

an ohne weiteres Zutun zu spiegeln (vgl. Abschnitt 5.3).

10Um allerdings nicht die historischen Begrenzungen des Tuple Space in Linda (vgl. Abschnitt 4.3.2)

in Kauf nehmen zu m¨

ussen, orientiert sich das vorgestellte Konzept nur grob an seinem Vorbild.

Mobilit¨

at in der kooperativen Wissensarbeit

152 5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume

Die Gruppen-Tuple Spaces vereinen in einem schl¨

ussigen Konzept die Mechanis-

men der Replikation, Ereigniskontrolle und Gruppenkommunikation. Gleichzeitig

sind sie ein ¨

außerst geeignetes Werkzeug f¨

ur die Koordinierung von mobil-verteilten

Anwendungen und f¨

ur die persistente und konsistente Speicherung derer Daten.

Dabei erlaubt der Gruppen-Tuple Space einen transparenten Zugriff auf die Persis-

tenzschicht, ohne deren Flexibilit¨

at einzuschr¨

anken.

Mobil-Verteilter Wissensraum

F¨

ur die Bereitstellung eines mobil-verteilten virtuellen Wissensraums, basierend auf

der im Rahmen dieser Arbeit entworfenen verteilten Persistenzschicht, wird eine wei-

tere Schicht errichtet, die das Konzept des virtuellen Wissensraums auf die Gruppen-

basierten Tuple Spaces ¨

ubertr¨

agt. Ziel dieser Schicht ist die Bereitstellung der Struk-

turen und Mechanismen des virtuellen Wissensraumes auf Basis des Konstrukts der

Gruppen-Tuple Spaces.

Dazu bietet sich die Abbildung je einer Benutzergruppe mit ihrem gemeinsamen

Arbeitsbereich innerhalb des Wissensraumes auf je einen Gruppen-Tuple Space an.

In diesem werden alle gemeinsamen Objekte einer Kooperationsgruppe gespeichert.

Die Struktur des Gruppenbereichs mit den enthaltenen Unterarealen und Dokumen-

ten wird dabei streng objektorientiert als Attribute der korrespondierenden Objekte

im Tuple Space abgelegt. Dieses Vorgehen macht die Struktur des Wissensraums in

der verteilten Umgebung persistent und sorgt automatisch f¨

ur eine Verteilung s¨

amt-

licher ¨

Anderungen in der Struktur des gemeinsamen Wissensraums an alle Grup-

penmitglieder ¨

uber die Synchronisations- und Ereignismechanismen des Gruppen-

Tuple Space. So gew¨

ahrleistet diese zus¨

atzliche Schicht die erprobten kooperati-

onsf¨

orderlichen Konzepte des virtuellen Wissensraums und gew¨

ahrleistet zudem die

Synchronizit¨

at all seiner verteilten Instanzen.

Alle f¨

ur die Kooperation relevanten Daten, inklusive Benutzer- und Verwaltungs-

informationen, werden in dem gemeinsamen Datenraum abgelegt und so allen Teil-

nehmern zug¨

anglich gemacht. Da die Schicht des mobil-verteilten Wissensraumes

die Objekte aus der Persistenz gem¨

aß der Wissensraum-Metapher aufbereitet, kann

eine Anwendung f¨

ur eine mobil-verteilte Kooperation im virtuellen Wissensraum wie

gewohnt auf den gemeinsamen Arbeitsraum der Gruppe zugreifen und sich alle ent-

haltenen Dokumente, Unterareale und anwesenden Benutzer anzeigen lassen. Zudem

kann die Gruppenstruktur des mobil-verteilten Wissensraum dank der Nutzung der

Gruppenmetapher in den Speicherstrukturen des Gruppen-Tuple Space intuitiv auf

diesen abgebildet werden.

Eine weitere M¨

oglichkeit der Schicht des virtuellen Wissensraums liegt in der au-

tomatischen Aufl¨

osung von vielen Konflikten in der Struktur des Wissensraums. Da

die Semantik dieser Struktur bekannt ist, kann die Kooperationsumgebung entschei-

den, ob ein Konflikt zu Fehlern in der Semantik oder der Struktur des virtuellen

Wissensraums f¨

uhren w¨

urde und entsprechende Gegenmaßnahmen einleiten. Diese

Teilautomatisierung der Konkliktaufl¨

osung erlaubt eine Entlastung der Benutzer von

Mobilit¨

at in der kooperativen Wissensarbeit

153

trivialen Konflikten oder solchen, die im technischen Umfeld der Kooperationsum-

gebung verankert sind.

Die Benutzer erreichen nur noch Konflikte innerhalb des verteilten virtuellen Wis-

sensraums, deren Semantik der Kooperationsschicht nicht bekannt ist oder nicht mit

Hilfe dieses Wissens entschieden werden k¨

onnen. Dies ist z. B. bei dem Inhalt von

vielen Dokumenten der Fall. Da deren inhaltliche Struktur oft ebenfalls bestimmten

Struktureigenschaften entspricht, werden ungel¨

oste Konflikte zun¨

achst an die zuge-

h¨

origen Anwendungen ¨

ubergeben. Erst wenn auch diese nicht in der Lage ist, den

Konflikt zu l¨

osen wird er an die Benutzer weitergereicht. So ergibt sich eine L¨

osungs-

kette f¨

ur die Behebung der Konflikte innerhalb des mobil-verteilten Datenraumes,

in die der Benutzer nur noch eingreifen muss, wenn keines der betroffenen Glieder

den Konflikt im Hintergrund l¨

osen kann.

Durch die hier vorgestellte voneinander gekapselte und doch ineinander verzahn-

te Schichtarchitektur wird ein umfassendes Architekturkonzept bereitgestellt, das

die Anforderungen einer Kooperation in mobil-spontanen aber auch weitr¨

aumig-

verteilten Nutzungsszenarien unterst¨

utzt. Der virtuelle Wissensraum wird hierbei in

all seinen Facetten von einer zentralisierten Architektur in ein mobiles und verteiltes

Umfeld transportiert, ohne die Errungenschaften der klassischen Kooperationsum-

gebungen zu ignorieren. Die hier vorgestellte Architektur erlaubt zus¨

atzlich die In-

tegration zentraler Persistenzdienste und anderer externer Ressourcen in die Koope-

rationsumgebung. Dabei wird – wo m¨

oglich – auf existierende und offene Standards

gesetzt, die notfalls um ben¨

otigte Eigenschaften erweitert werden. Dieses Vorgehen

soll auch zuk¨

unftig eine leichte Integration der neuen mobil-verteilten Kooperations-

umgebung in existierende Infrastrukturen erlauben.

Mobilit¨

at in der kooperativen Wissensarbeit

154 5.4 Gesamtarchitektur mobil-verteilter Wissensr¨

aume

Mobilit¨

at in der kooperativen Wissensarbeit

6 Schluss und Ausblick

Im Anschluss an den Entwurf der Musterarchitektur mobil-verteilter Wissensr¨

aume

gilt es Fragen bez¨

uglich der erreichten Ziele und der neuen M¨

oglichkeiten einer sol-

chen Kooperationsinfrastruktur zu beantworten. Dies schließt eine Bewertung der

technischen und konzeptionellen L¨

osungen mit ein. Die Perspektiven f¨

ur die ko-

operative Wissensstrukturierung, die sich aus einer flexiblen und ortsungebundenen

Zusammenarbeit in mobil-verteilten Wissensr¨

aumen ergeben, sind ebenso zu be-

trachten, wie die aus dieser Arbeit resultierenden zuk¨

unftigen Arbeitsschritte und

Forschungsperspektiven.

Den Ausgangspunkt der Arbeit bildeten die unverbundenen Entwicklungsstr¨

ange

der kooperativen Wissensstrukturierung und der mobilen Ad-Hoc-Netzwerke. Trotz

der w¨

unschenswerten Nutzungskonstellation einer kooperativen Wissensstrukturie-

rung in mobilen Alltagssituationen fehlen geeignete Werkzeuge f¨

ur eine l¨

angerfristi-

ge mobile und computergest¨

utzte Zusammenarbeit. Es existierten kaum ¨

Uberg¨

ange

zwischen beiden Forschungsfeldern und die jeweiligen Nutzungsszenarien bewegten

sich stets streng in einem der beiden Bereiche. W¨

ahrend Nutzungsszenarien der

computergest¨

utzten Kooperation auf die Zusammenarbeit in festen Infrastrukturen

zielten, behandelten Nutzungsszenarien der mobilen Vernetzung zumeist Aspekte

mobilit¨

atsfreundlicher Netzwerkstrukturen. Nutzungsszenarien die beide Felder in

ihrem Wechselspiel betrachten waren nahezu unerforscht.

Da aber ein Systementwurf f¨

ur eine mobilit¨

atsfreundliche Kooperationsumgebung

ohne eine Kenntnis der Nutzungsszenarien und strukturellen Grenzen kaum m¨

oglich

ist, war ein erstes Ziel dieser Arbeit die Entwicklung entsprechender Nutzungsszena-

rien kooperativer Wissensstrukturierung. Erst mit Kenntnis der Nutzungsszenarien

ist ein Transfer der Welt der kooperativen Wissensstrukturierung in die der mobilen

Ad-Hoc-Netzwerke m¨

oglich. Diese Nutzungsszenarien wurden f¨

ur eine Differenzie-

rung der Anforderungsebenen in funktionale und technische Elemente getrennt, die

f¨

ur eine begriffliche Kl¨

arung als ”Handlungsebene“ und ”Umsetzungsebene“ bezeich-

net wurden.

Als Fundament f¨

ur die funktionalen Komponenten der Kooperationsumgebung

wurde das Konzept der virtuellen Wissensr¨

aume gew¨

ahlt. Da mobile Kooperations-

szenarien durch eine freie und flexible Zusammenarbeit charakterisiert sind, bieten

die virtuellen Wissensr¨

aume als Verk¨

orperung freier dokumentenzentrierter Grup-

penarbeit ein entsprechend flexibles Kooperationskonzept. Der Transfer der virtu-

ellen Wissensr¨

aume in mobile Ad-Hoc-Netzwerke war somit unter dem Begriff der

”mobil-verteilten Wissensr¨

aume“ zentrales Thema dieser Arbeit.

Als Basis f¨

ur die Betrachtung der ben¨

otigten Kooperationsunterst¨

utzung in einem

mobilen Nutzungsumfeld dienten die in Kapitel 2 aufgestellten Nutzungsszenarien.

155

156 6 Schluss und Ausblick

Sie orientieren sich sowohl an Formen der Pr¨

asenzkooperation, die stark der nat¨

ur-

lichen Zusammenarbeit im mobilen Umfeld entsprechen, als auch an Kooperations-

formen, die eine Einbeziehung r¨

aumlich entfernter Benutzer und Dienste ber¨

uck-

sichtigen. Letztere schließen auch die optionale Integration zentralisierter CSCW-

Strukturen in mobil-verteilte Kooperationsumgebungen mit ein. Die entwickelten

Nutzungsszenarien entstammen je zur H¨

alfte der Arbeitswelt, mit st¨

arker formalisier-

ten Kooperationsprozessen, und der Lernwelt, mit eher freien konstruktivistischen

Kooperationsans¨

atzen, um ein m¨

oglichst breites Spektrum von Kooperationsformen

abzudecken.

F¨

ur ein besseres Verst¨

andnis der Vorg¨

ange in mobilen Kooperationsszenarien wur-

de in Kapitel 3 ein Drei-Phasen-Modell mobil-verteilter Kooperation aufgestellt. Ne-

ben den Phasen der Gr¨

undung und Kooperation, die auch in klassischen Kooperati-

onsszenarien Beachtung finden, wurde der Phase der Aufl¨

osung ein hoher Stellenwert

einger¨

aumt. Diese in klassischen Kooperationsszenarien vernachl¨

assigte Phase tr¨

agt

der Tatsache Rechnung, dass in einem mobilen Umfeld eine Wiederaufnahme der

Kooperation in derselben Nutzungskonstellation aufgrund der Mobilit¨

at der Nutzer

nur selten gelingt. Durch den nahtlosen ¨

Ubergang zwischen den einzelnen Phasen

ist nach dem Ausscheiden aus einer Kooperationssitzung (Aufl¨

osung) jederzeit ein

Wiedereintreten in diese – auch in einer ge¨

anderten Nutzungskonstellation – m¨

oglich

(Gr¨

undung).

Aufbauend auf die Handlungsmuster der entworfenen Szenarien mobiler Koope-

ration wurden eine Reihe von technischen Anforderungen an mobil-verteilte Koope-

rationsumgebungen benannt. In der Arbeit wurden wesentliche Problemstellungen

aus den Bereichen der ”

Vernetzung und Sichtbarkeit“ der Kooperationspartner, der

”Kontextualisierung“ der Kooperationsumgebung und der ”Konsistenz“ der gemein-

sam genutzten und redundant gespeicherten Kooperationsobjekte identifiziert.

Die Forderung aus den Bereichen ”

Vernetzung und Sichtbarkeit“ ist insbesondere

in der Gr¨

undungsphase von zentraler Bedeutung. Eine Wahrnehmung potentieller

Kooperationspartner und verf¨

ugbarer Dienste ist, ebenso wie eine Kommunikations-

infrastruktur zwischen diesen, die Grundlage f¨

ur die Bildung einer Kooperations-

gruppe. Doch auch f¨

ur die sp¨

ateren Phasen im Kooperationsprozess benennt diese

Forderung das Mindestmaß technischer Unterst¨

utzung f¨

ur die mobile Zusammenar-

beit.

Eng verwandt mit der Vernetzung und Sichtbarkeit sind die Forderungen aus dem

Bereich der Kontextualisierung. Sie erlauben insbesondere in komplexeren Konfigu-

rationen und weitr¨

aumigen Strukturen die Auswahl geeigneter Kooperationspartner.

Das Wissen um den eigenen technischen wie sozialen Kontext und den der Ko-

operationspartner unterst¨

utzt die Konfiguration der Kooperationsprozesse, die nach

festgesetzten Regeln auch automatisch erfolgen kann. Der Nutzung von Kontext-

informationen f¨

allt daher besonders in der Gr¨

undungsphase eine hohe Bedeutung

zu.

Unter dem Begriff ”Offline-Verf¨

ugbarkeit“ wurde die Problemstellung einer durch-

g¨

angigen Verf¨

ugbarkeit der Kooperationsdaten zusammengefasst. F¨

ur die Unterst¨

ut-

zung mobil-verteilter Nutzungskonstellationen wurden die Distribution und Repli-

Mobilit¨

at in der kooperativen Wissensarbeit

157

kation als zentrale Forderungen f¨

ur eine durchg¨

angige Verf¨

ugbarkeit der gemeinsam

genutzten Kooperationsdaten auch in unverbundenen Nutzungssituationen heraus-

gearbeitet.

Die sich aus einer Replikation ergebenen Forschungsfragen bez¨

uglich einer red-

undanten Speicherung der Kooperationsdaten wurden unter dem Oberbegriff der

”Konsistenz“ gesammelt. Bei einer derartigen redundanten Speicherung der Koope-

rationsobjekte kommt der ”Synchronizit¨

at“ der gemeinschaftlich bearbeiteten Da-

ten eine hohe Bedeutung zu, wenn ein Divergieren der gemeinsamen Datenbest¨

ande

verhindert werden soll. Ist die Synchronizit¨

at, z. B. aufgrund l¨

angeren unverbun-

denen Arbeitens, nicht mehr gewahrt, sind zudem Mechanismen zur kooperativen

Konfliktl¨

osung und zur R¨

ucknahme und Anpassung der ¨

Anderungen bereitzustellen

(Reversibilit¨

at).

Das neue mobile Nutzungsumfeld und die daraus begr¨

undete verteilte Infrastruk-

tur macht auch die Anpassung der aus zentralisierten Kooperationssystemen be-

kannten Mechanismen zur Kooperationsunterst¨

utzung notwendig. Die betroffenen

Bereiche wurden in Kommunikation,Koordination und Kooperation unterteilt und

bilden die Basis f¨

ur die neuartige Zusammenarbeit in mobilen und spontanen Nut-

zungsszenarien, die im Rahmen dieser Arbeit mit dem Begriff der ”Kollaboration“

belegt wurde. Die Einbettung dieser klassischen Kooperationsfunktionen in ein de-

zentralisiertes und mobiles Kooperationsumfeld wurde als eine der wichtigen Anfor-

derungen identifiziert.

Anhand der in Kapitel 3 ermittelten Anforderungen an die mobil-verteilte Koope-

rationsumgebung erfolgte in Kapitel 4 eine Bestandsaufnahme verf¨

ugbarer L¨

osungs-

ans¨

atze. Aufgrund der herausgearbeiteten zentralen Stellung der Persistenz f¨

ur eine

Bereitstellung mobil-verteilter Wissensr¨

aume lag der Fokus auf den Technologien der

mobilit¨

atsfreundlichen Vernetzung und der verteilten Kommunikations- und Persis-

tenzsysteme. Aus ihnen wurde das technische Grundger¨

ust der Musterarchitektur

mobil-verteilter Wissensr¨

aume gebildet.

Die durchgef¨

uhrte Betrachtung der Technologien f¨

ur eine unabh¨

angige Vernetzung

mobiler Ger¨

ate jenseits der Zug¨

ange existierender Netzwerkinfrastrukturen ergab

die Verf¨

ugbarkeit einer Vielzahl von L¨

osungsans¨

atzen aus dem Forschungsfeld der

mobilen Ad-Hoc-Netzwerke (Manets). Es zeigte sich aber, dass diese noch keinen

Einzug in den Alltag der Benutzer gefunden haben. Dennoch wurden sie unter der

Annahme eines zuk¨

unftigen Alltagseinsatzes als Basis mobil-spontaner Vernetzung

betrachtet. Protokolle dieses Ursprungs zielen auf eine selbstorganisierende, spontane

und robuste Vernetzung mobiler Netzwerkknoten und etablieren auch weitr¨

aumige

Kommunikationsinfrastrukturen. ¨

Uber eine Hybridl¨

osung mit Mobile IP ist dar-

uber hinaus auch eine Einbindung etablierter Netzwerkstrukturen wie das Internet

m¨

oglich. In Kombination mit ebenfalls verf¨

ugbaren Mechanismen zur automatischen

Dienstekonfiguration und -verkn¨

upfung kann somit eine technische Infrastruktur zur

Initialisierung einer mobil-spontanen Kooperation bereitgestellt werden.

Ein besonderes Bild bot sich bei der Betrachtung verteilter Persistenzsysteme.

Zwar sind durch das wachsende Interesse an unabh¨

angigen Peer-to-Peer-Strukturen

eine große Anzahl verteilter Persistenzsysteme verf¨

ugbar, aber eine n¨

ahere Betrach-

Mobilit¨

at in der kooperativen Wissensarbeit

158 6 Schluss und Ausblick

tung offenbarte, dass diese f¨

ur mobil-spontane Kooperationsszenarien wenig geeignet

sind. Diese Feststellung begr¨

undete sich zum Teil in fehlenden Konzepten f¨

ur eine

Offline-Verf¨

ugbarkeit gemeinsam genutzter Daten oder einer mangelhaften Wahrung

der Konsistenz derselben.

Existierende verteilte Persistenzsysteme bewerten einen unverbundenen Knoten

stets als defekt und beachten bei der Fehlerbehandlung nur die Funktionalit¨

at des

Gesamtsystems. Die wichtige Unterst¨

utzung des isolierten Knotens in der Phase

der unverbundenen Arbeit fehlt zumeist. Gerade hier liegt aber die Besonderheit

mobiler Kooperationsszenarien, in denen Verbindungsabbr¨

uche h¨

aufig vorkommen.

Die Kooperationspartner wollen in der Regel auch bei Isolation von der Gruppe auf

den gemeinsamen Kooperationsobjekten weiterarbeiten k¨

onnen.

Jenseits der DHT-basierten Persistenzsysteme bietet das Konzept der Tuple Spaces

einen einfachen und zeitlich entkoppelten Zugriff auf die gespeicherten Daten. Tu-

ple Spaces erlauben Knoten, die nicht zeitgleich mit dem Netzwerk verbunden sind,

dennoch Daten auszutauschen. Diese Mechanismen lassen sich auch f¨

ur eine Koor-

dination der Kooperationsprozesse in mobilen Nutzungskonstellationen verwenden.

Aufgrund dieser interessanten Eigenschaften wurden sie ebenfalls im Rahmen die-

ser Arbeit betrachtet und zusammen mit den DHTs als m¨

ogliche Bausteine einer

Architektur f¨

ur mobil-verteilte Wissensr¨

aume herangezogen.

Im Anschluss der eingehenden Analyse der konzeptionellen wie technischen M¨

og-

lichkeiten und Defizite der verf¨

ugbaren verteilten Persistenzsysteme in Kapitel 4

wurden die vielversprechenden Ans¨

atze der DHTs und Tuple Spaces in Kapitel 5

als Bausteine f¨

ur eine Musterarchitektur mobil-verteilter Wissensr¨

aume herangezo-

gen und um fehlende Komponenten erg¨

anzt. Ziel dieser Musterarchitektur war es,

die M¨

oglichkeit einer Umsetzung mobil-verteilter Wissensr¨

aume mittels verf¨

ugbarer

Technologien aufzuzeigen und die identifizierten L¨

ucken mit speziell an die Bed¨

urf-

nisse mobiler Kooperationsszenarien angepassten Konzepten zu schließen.

Die Familie der Distributed Hashtables (DHT) wurde anhand des zuvor ermittel-

ten Anforderungskatalogs um Mechanismen f¨

ur eine Offline-Verf¨

ugbarkeit der Ko-

operationsdaten zu einer mobilit¨

atsfreundlichen verteilten Persistenzschicht erg¨

anzt.

Kern dieser Persistenzschicht ist eine gezielte Distributions- und Replikationsstra-

tegie, die zusammen mit der Versionierung der redundant gespeicherten Objekte

eine Offline-Verf¨

ugbarkeit der Kooperationsobjekte bei Beibehaltung der geforder-

ten Konsistenz erlaubt. Zus¨

atzlich ber¨

ucksichtigt das Replikationskonzept die un-

terschiedlichen Ausbauformen mobiler Ger¨

ate und erm¨

oglicht ¨

uber differenzierte

Replikationsklassen auch ressourcenarmen Ger¨

aten einen Zugriff auf die verteilte

Persistenz.

Konflikte bei einem konkurrierenden Zugriff auf die gemeinsam bearbeiteten Ob-

jekte werden durch die integrierte Versionskontrolle zeitnah aufgedeckt und den Be-

nutzern angezeigt. Zus¨

atzlich k¨

onnen ¨

uber die Versionierung und die Konfliktl¨

sungsmechanismen die betroffenen Objekte kooperativ wieder in Einklang gebracht

werden.

Dank der gezielten Distributions- und Replikationsstrategie ist eine Unterst¨

ut-

zung mobil-spontaner Kooperation sowohl im dynamischen Verbund mit Koope-

Mobilit¨

at in der kooperativen Wissensarbeit

159

rationspartnern als auch in isolierten Kooperationssituationen gew¨

ahrleistet. Diese

im Rahmen der vorliegenden Arbeit entworfene mobil-verteilte Persistenz wurde

durch eine Abstraktionsschicht um die Schl¨

usselkomponenten einer logischen Repli-

kationsstruktur, eines transparenten Objektzugriffs und einer zeitlich entkoppelten

Kommunikation zwischen zeitweise unverbundenen Kooperationspartnern erg¨

anzt.

War die Nutzung der mobil-verteilten Persistenz bis zu diesem Punkt noch an ein

Wissen ¨

uber die Netzwerkstruktur gebunden, kann nun dank des anonymen Spei-

cherkonzepts des Tuple Space auf die verteilten Objekte mit einfachen Operationen

zugegriffen werden.

Mit dem Konzept der Gruppen-Tuple Spaces wurde der mobil-verteilten Persis-

tenzschicht eine gruppenbasierte Replikationsmetapher hinzugef¨

ugt. Diese erlaubt

eine intuitive Replikation der gemeinsam genutzten Objekte zwischen den Gruppen-

mitgliedern. Die Versionierung und Synchronisierung der Repliken kann v¨

ollig im

Hintergrund geschehen und reduziert so die Komplexit¨

at des Zugriffs auf den ver-

teilten Speicher in einem erheblichen Maße. Auch die asynchrone Kommunikation

und Ereigniskontrolle zwischen den sporadisch verbundenen Knoten wird von den

Gruppen-Tuple Spaces ¨

ubernommen. ¨

Uber die enthaltene zeitlich entkoppelte Nach-

richtenverbreitung werden Nachrichten nach einem Verbindungsabbruch zugestellt,

sobald der Zielknoten wieder erreichbar ist. So ist jeder Knoten nach einer verbin-

dungslosen Phase bei Wiedereintritt in den Kooperationsverbund auf dem neuesten

Stand.

Die eigentliche Kooperationsumgebung bilden die mobil-verteilten Wissensr¨

au-

me, die auf diese technische Abstraktionsschicht aufgesetzt wurden. Jeder Koope-

rationsgruppe im virtuellen Wissensraum wird ein eigener Gruppen-Tuple Space in

der Persistenzschicht zugeordnet. In diesem werden alle die Kooperation betreffen-

den Objekte abgelegt und so automatisch zwischen den Knoten der Gruppenmit-

glieder repliziert. Jedes Gruppenmitglied verf¨

ugt dadurch lokal ¨

uber den gesamten

gemeinsamen Wissensraum der Gruppe. Auf diese Weise stehen die gemeinsamen

Kooperationsobjekte auch in Offline-Situationen zur Verf¨

ugung. Der gemeinsame

Wissensraum wird bei Kontakt zur Gruppe automatisch mit den Repliken der an-

deren verf¨

ugbaren Gruppenmitglieder abgeglichen.

Die so geschaffene Kooperationsumgebung stellt persistente virtuelle Wissensr¨

au-

me mit ihren bew¨

ahrten Kooperationsmechanismen inklusive der prim¨

aren Medien-

funktionen bereit. Durch die durchg¨

angige Verf¨

ugbarkeit der Kooperationsobjekte

beugt sie zudem Medienbr¨

uchen vor, die aus der Mobilit¨

at der Nutzer zu entstehen

drohen.

Das so entstandene Vier-Schicht-Modell bildet mit der Kommunikationsschicht,

der Objektverwaltung und -distribution, der Abstraktionsschicht und den mobil-ver-

teilten Wissensr¨

aumen eine m¨

ogliche Realisierung technischer Infrastrukturen f¨

die mobile Wissensstrukturierung gem¨

aß den ermittelten Anforderungen. Dabei wird

durch die Kapselung der einzelnen Schichten ein modularer Aufbau der Komponen-

ten gewahrt. Dies erlaubt eine einfache Anpassung der Kooperationsumgebung an

ein variables Nutzungsumfeld.

Mobilit¨

at in der kooperativen Wissensarbeit

160 6 Schluss und Ausblick

Durch die Einbettung von mobilen Ad-Hoc-Netzwerken zur spontanen Vernetzung

sowie den Einsatz innovativer L¨

osungen f¨

ur eine automatische Dienstekonfigurati-

on, wird eine flexible und mobilit¨

atsfreundliche Kommunikationsinfrastruktur f¨

die Kooperationsumgebung errichtet. Die besondere Ber¨

ucksichtigung einer geeigne-

ten Distributions- und Replikationsstrategie in der darauf aufsetzenden Persistenz-

schicht sorgt f¨

ur die ben¨

otigte Offline-Verf¨

ugbarkeit und Konsistenz der gemeinsam

genutzten Kooperationsobjekte. Mittels der in der Abstraktionsschicht eingesetzten

Gruppen-Tuple Spaces wird zudem ein anonymer Speicherzugriff in Kombination mit

einer intuitiven gruppenbasierten Replikation bereitgestellt sowie die Komplexit¨

der Persistenzschicht verbirgt. Zusammen mit der ebenfalls in der Abstraktions-

schicht angesiedelten zeitlich und r¨

aumlich entkoppelten Kommunikation und den

Mechanismen zur Integration externer Dienste entsteht so der technischer Rahmen

f¨

ur die mobile Kooperationsumgebung. Die oberste Schicht der mobil-verteilten Wis-

sensr¨

aume verbindet konsequent das bew¨

ahrte Konzept der virtuellen Wissensr¨

aume

mit den technischen L¨

osungen einer mobil-verteilten Persistenz. Die Kooperations-

partner erhalten so in allen Situationen ihrer Mobilit¨

at Zugriff auf ihre gemeinsam

bearbeiteten Materialien, ohne auf die Flexibilit¨

at einer dokumentenzentrierten Ko-

operation in virtuellen Wissensr¨

aumen verzichten zu m¨

ussen.

Aus dem zun¨

achst un¨

ubersichtlichen Problemfeld mobiler Kooperation wurde in

der vorliegenden Arbeit die Bereitstellung einer verteilten Persistenz f¨

ur eine durch-

g¨

angige Verf¨

ugbarkeit der Kooperationsobjekte als Kernproblem identifiziert. Die

entworfene Musterarchitektur zeigt entsprechende Wege f¨

ur die Verkn¨

upfung einer

verteilten Persitenz mit weiteren Komponenten zu einer mobil-verteilten Kooperati-

onsumgebung auf. Im Rahmen der Arbeit wurden zudem wesentliche Komponenten

der Musterarchitektur aus den Bereich der Vernetzung und Sichtbarkeit, der Kon-

textualisierung und der Distribution und Replikation prototypisch umgesetzt und

erprobt.

Die so entstandene Musterarchitektur offenbart wesentliche Forschungsperspek-

tiven, die sich durch eine Bereitstellung mobilit¨

atsfreundlicher Kooperationsinfra-

strukturen ergeben. Die zuk¨

unftigen Forschungsfragen bewegen sich dabei in den

Bereichen des Einsatzes virtueller Wissensr¨

aume in mobilen Kooperationsszenarien,

der Sicherheit und Identit¨

atskontrolle in offenen verteilten Kooperationssystemen,

der erweiterten Kontextualisierung entlang der Kooperationsprozesse und der Unter-

suchung alternativer Distributions- und Replikationsstrategien. Im Folgenden sollen

diese offenen Forschungsfragen kurz angesprochen werden.

Die in serverzentrierten Umgebungen bew¨

ahrten Konzepte der virtuellen Wissens-

r¨

aume k¨

onnen mittels neuartiger mobiler Infrastrukturen an einem mobilen Nut-

zungsumfeld gemessen und verfeinert werden. Insbesondere kann die Bereitstellung

mobil-verteilter Wissensr¨

aume ausschlaggebend f¨

ur die ¨

Uberpr¨

ufung existierender

und die Identifizierung weitergehender prim¨

arer Medienfunktionen sein.

Derart freie Kooperationsumgebungen wie die hier entworfenen mobil-verteilten

Wissensr¨

aume bed¨

urfen einer Integration dezentral gesteuerter Mechanismen zur

Verschl¨

usselung und Identit¨

atskontrolle. Diese verteilt verwalteten Sicherheitsme-

chanismen m¨

ussen ¨

ahnlich intuitiv nutzbar sein wie die vorgestellten Replikations-

Mobilit¨

at in der kooperativen Wissensarbeit

161

strategien. Darum sind neben technischen Erw¨

agungen auch Fragestellungen auf der

Handlungsebene zu ber¨

ucksichtigen.

Die als wichtige Komponente mobiler Kooperation identifizierte Kontextualisie-

rung der Kooperationsumgebung wirft neue Fragestellungen im technischen wie kon-

zeptionellen Bereich des Forschungsfeldes der Context Awareness auf. Dazu geh¨

oren

ebenso die besprochenen automatisierten Mechanismen der Gruppengr¨

undung an-

hand eines Ortsbezugs, wie auch die beil¨

aufige Strukturierung des Wissensraums

aus dem Kooperationskontext heraus. Des Weiteren m¨

ussen Kontextinformationen

aufbereitet werden, um die ¨

Ubersichtlichkeit der Kooperationsumgebung nicht zu

gef¨

ahrden. Besonders in stark mit Kontextinformationen angereicherten Umgebun-

gen wird es notwendig sein, nur bestimmte Kontextinformationen f¨

ur den Benutzer

zug¨

anglich zu machen. Die zuverl¨

assige Differenzierung von ”interessanten“ und ”un-

interessanten“ Kontextinformationen stellt die Entwickler somit vor neue Herausfor-

derungen.

Eine eingehendere Betrachtung verdient auch die Fragestellung nach weiterf¨

uh-

renden Distributions- und Replikationsstrategien f¨

ur spezielle mobile Nutzungssze-

narien. Die im Rahmen dieser Arbeit entworfene Replikationsstrategie anhand der

Gruppenstruktur ist ein universelles Mittel zur konsistenten Verkn¨

upfung von Ko-

operationspartnern in der Gruppenarbeit. Alternative Ans¨

atze k¨

onnten sich aber als

besser an bestimmte Kooperationsszenarien angepasst erweisen. So w¨

are z. B. eine

an die verf¨

ugbaren Bandbreiten zwischen den vernetzen Gruppenknoten angepasste

Replikationsstrategie denkbar. Auch eine umfassende Einbindung des Kooperations-

kontextes in die Objektverteilung und -replikation kann sich als probates Mittel f¨

eine Steigerung der Offline-Verf¨

ugbarkeit der Kooperationsdaten erweisen.

Die aufgeworfenen zuk¨

unftigen Forschungsfragen, die sich durch die hier entwor-

fene Musterarchitektur mobil-verteilter Wissensr¨

aume ergeben, heben die Relevanz

der Erforschung mobiler Kooperationsumgebungen hervor. Erst eine mobile Koope-

rationsumgebung, die unabh¨

angig von bestehenden Infrastrukturen funktioniert und

sich dennoch in diese integriert, vermag sich im Alltag der Benutzer zu etablieren.

Die in dieser Arbeit entworfene Musterarchitektur zeigt einen Weg auf, dieses Ziel

durch den Einsatz verf¨

ugbarer Technologien und innovativer Konzepte zu erreichen.

Die bis dahin fehlenden Bausteine wurden auf die Bed¨

urfnisse mobiler Kooperati-

onsszenarien ausgerichtet und fußen auf anerkannte Konzepte und Technologien.

Der im Rahmen dieser Arbeit geleistete Transfer virtueller Wissensr¨

aume in das

Spannungsfeld mobil-spontaner Netzwerkumgebungen zeigt somit einen Weg auf,

mobile Wissensstrukturierung im Einklang mit existierenden Kooperationsinfrastruk-

turen zu etablieren.

Mobilit¨

at in der kooperativen Wissensarbeit

162 6 Schluss und Ausblick

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis

Anderson und Shasha 1991

Anderson, Brian G. ; Shasha, Dennis: Persistent Linda: Linda + Transactions

+ Query Processing. In: Banatre, J.P. (Hrsg.) ; Le Metayer, D. (Hrsg.): Re-

search Directions in High-Level Parallel Programming Languages. Mont-Saint-

Michel, France : Springer Verlag, 1991, S. 93–109

Balakrishnan et al. 2003

Balakrishnan, Hari ; Kaashoek, M. Frans ; Karger, David ; Morris, Ro-

bert ; Stoica, Ion: Looking up data in P2P systems. In: Communications of

the ACM 46 (2003), Nr. 2, S. 43–48

Bentley et al. 1997

Bentley, Richard ; Appelt, Wolfgang ; Busbach, Uwe ; Hinrichs, Elke ;

Kerr, David ; Sikkel, Klaas ; Trevor, Jonathan ; Woetzel, Gerd: Basic

support for cooperative work on the World Wide Web. In: International Journal

of Human Computer Studies 46 (1997), Nr. 6, S. 827–846

Bleckmann et al. 2005

Bleckmann, Peter ; Sprotte, Ren`e ; Eßmann, Bernd ; Hampel, Thorsten:

Interactive Learning Objects in Mobile E-Learning. In: Proceedings of the World

Conference on E-Learning in Corporate, Government, Healthcare, and Higher

Education 2005 (E-Learn 2005), AACE, 2005, S. 2809–2816

Booch et al. 1998

Booch, Grady ; Rumbaugh, James ; Jacobson, Ivar: The Unified Modeling

Language User Guide. Addison-Wesley Professional, 1998

Bopp und Hampel 2005

Bopp, Thomas ; Hampel, Thorsten: A Microkernel Architecture for Distri-

buted Mobile Environments. In: Chen, Chin-Sheng (Hrsg.) ; Filipe, Joaquim

(Hrsg.) ; Seruca, Isabel (Hrsg.) ; Cordeiro, Jos´e (Hrsg.): Proceedings of the

Seventh International Conference on Enterprise Information Systems (ICEIS

2005) Bd. 4, 2005, S. 151–156

Broch et al. 1998

Broch, Josh ; Maltz, David A. ; Johnson, David B. ; Hu, Yih-Chun ; Jet-

cheva, Jorjeta: A performance comparison of multi-hop wireless ad hoc network

routing protocols. In: Proceedings of the 4th annual ACM/IEEE international

conference on Mobile computing and networking (MobiCom 1998), ACM Press,

1998, S. 85–97

163

164 Literaturverzeichnis

Brookshier et al. 2002

Brookshier, Daniel ; Govoni, Darren ; Krishna, Navaneeth: JXTA: Java

P2P Programming. SAMS, 2002

Buschmann et al. 1996

Buschmann, Frank ; Meunier, Regine ; Rohnert, Hans ; Sommerlad, Peter

;Stal, Michael: Pattern-Oriented Software Architecture – A System of Patterns.

John-Wiley and Sons, 1996

Campbell 1998

Campbell, Richard: Managing AFS: The Andrew File System. Prentice Hall,

1998

Campell et al. 2002

Campell, Andrew T. ; Gomez, Javier ; Kim, Sanghyo ; Wan, Chieh-Yih ;

Turanayi, Zoltan R. ; Valko, Andras G.: Comparison of IP micromobility

protocols. In: IEEE Wireless Communications 9 (2002), S. 72–82

Castro et al. 2003

Castro, Miguel ; Druschel, Peter ; Kermarrec, Anne-Marie ; Nandi, Ani-

mesh ; Rowstron, Antony ; Singh, Atul: SplitStream: High-bandwidth multi-

cast in a cooperative environment. In: Proceedings of the 19th ACM Symposium

on Operating Systems Principles (SOSP 2003), 2003, S. 298–313

Castro et al. 2002

Castro, Miguel ; Druschel, Peter ; Kermarrec, Anne-Marie ; Rowstron,

Antony: Scribe: A Large-Scale and Decentralized Application-Level Multicast

Infrastructure. In: IEEE Journal on Selected Areas in Communications (JSAC)

20 (2002), Nr. 8, S. 1489–1499

Cuce und Zaslavsky 2003

Cuce, Simon ; Zaslavsky, Arkady: Supporting multiple consistency models

within a mobility enabled file system using a component based framework. In:

Mobile Networks and Applications 8 (2003), Nr. 4, S. 317–326

Dabek et al. 2001

Dabek, Frank ; Kaashoek, M. Frans ; Karger, David ; Morris, Robert ;

Stoica, Ion: Wide-area cooperative storage with CFS. In: Proceedings of the

18th ACM Symposium on Operating Systems Principles (SOSP 2001), ACM

Press, 2001, S. 202–215

Dabek et al. 2003

Dabek, Frank ; Zhao, Ben Y. ; Druschel, Peter ; Kubiatowicz, John ; Stoi-

ca, Ion: Towards a Common API for Structured P2P Overlays. In: Kaashoek,

M. Frans (Hrsg.) ; Stoica, Ion (Hrsg.): Peer-to-Peer Systems II. Proceedings

of the Second International Workshop on Peer-to-Peer Systems (IPTPS 2003).

Springer Verlag, 2003, S. 33–44

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 165

Dourish und Bellotti 1992

Dourish, Paul ; Bellotti, Victoria: Awareness and coordination in sha-

red workspaces. In: Proceedings of the 1992 ACM Conference on Computer-

Supported Cooperative Work (CSCW 1992), ACM Press, 1992, S. 107–114

Druschel und Rowstron 2001

Druschel, Peter ; Rowstron, Antony: PAST: A Large-Scale, Persistent Peer-

to-Peer Storage Utility. In: Proceedings of the Eighth Workshop on Hot Topics

in Operating Systems (HOTOS 2001), IEEEE Computer Society, 2001, S. 75–80

Dwyer und Bharghavan 1997

Dwyer, Dane ; Bharghavan, Vaduvur: A Mobility-Aware File System for

Partially Connected Operation. In: ACM SIGOPS Operating Systems Review

31 (1997), Nr. 1, S. 24–30

Dyer und Boppana 2001

Dyer, Thomas D. ; Boppana, Rajendra V.: A comparison of TCP performance

over three routing protocols for mobile ad hoc networks. In: Proceedings of the

2nd ACM international symposium on Mobile ad hoc networking & computing

(MobiHoc 2001), ACM Press, 2001, S. 56–66

Edwards et al. 1997

Edwards, W. Keith ; Mynatt, Elizabeth D. ; Petersen, Karin ; Spreitzer,

Mike J. ; Terry, Douglas B. ; Theimer, Marvin M.: Designing and Implemen-

ting Asynchronous Collaborative Applications With Bayou. In: Proceedings of

the 10th annual ACM symposium on User Interface Software and Technology

(UIST 1997), ACM Press, 1997, S. 119–128

Edwards et al. 2002a

Edwards, W. Keith ; Newman, Mark W. ; Sedivy, Jana Z. ; Smith, Trevor F.

;Balfanz, Dirk ; Smetters, D. K. ; Wong, H. C. ; Izadi, Shahram: Using

Speakeasy for Ad Hoc Peer-to-Peer Collaboration. In: Proceedings of the Confe-

rence on Computer Supported Cooperative Work (CSCW’02), ACM Press, 2002,

S. 256–265

Edwards et al. 2002b

Edwards, W. Keith ; Newman, Mark W. ; Sedivy, Jana Z. ; Smith, Trevor F.

;Izadi, Shahram: Challenge: Recombinant Computing and the Speakeasy Ap-

proach. In: Proceedings of the International Conference on Mobile Computing

and Networking (MOBICOM’02), ACM Press, 2002, S. 279–286

Els¨

asser et al. 2001

Els¨

asser, Robert ; Kralovi, Rastislav ; Monien, Burkhard: Scalable Sparse

Topologies with Small Spectrum. In: Proceedings of the 18th Annual Symposium

on Theoretical Aspects of Computer Science (STACS 2001) Bd. 2010, Springer

Verlag, 2001, S. 218–229

Mobilit¨

at in der kooperativen Wissensarbeit

166 Literaturverzeichnis

Eßmann et al. 2005

Eßmann, Bernd ; Bleckmann, Peter ; Hampel, Thorsten ; Els¨

asser, Ro-

bert: Distributed Persistence in CSCW Applications / Heinz Nixdorf Institute,

Universit¨

at Paderborn. 2005 (tr-ri-05-268). – Technical Report

Eßmann und Funke 2005

Eßmann, Bernd ; Funke, Holger: Providing Peer-to-Peer Features to Existing

Client-Server CSCW Systems. In: Chen, Chi-Sheng (Hrsg.) ; Filipe, Joaquim

(Hrsg.) ; Seruca, Isabel (Hrsg.) ; Cordeiro, Jos´e (Hrsg.): Proceedings of the

Proceedings of the Seventh International Conference On Enterprise Information

Systems (ICEIS 2005) Bd. 4, INSTICC, 2005, S. 271–274

Eßmann und Hampel 2003a

Eßmann, Bernd ; Hampel, Thorsten: Human Computer Interaction and Co-

operative Learning in Mobile Environments. In: Harris, Don (Hrsg.) ; Duffy,

Vincent (Hrsg.) ; Smith, Michael (Hrsg.) ; Stephanidis, Constantine (Hrsg.):

Proceedings of the International Conference on Human Computer Interaction

(HCII 2003) Bd. 3, Lawrence Erlbaum Associates, Inc., 2003, S. 694–698

Eßmann und Hampel 2003b

Eßmann, Bernd ; Hampel, Thorsten: Integrating Cooperative Knowledge

Spaces into Mobile Environments. In: Rossett, Allison (Hrsg.): Proceedings

of the World Conference on E-Learning in Corporate, Government, Healthcare,

and Higher Education 2003 (E-Learn 2003), 2003, S. 225–232

Eßmann und Hampel 2004

Eßmann, Bernd ; Hampel, Thorsten: Collaborative eLearning in Real Pla-

ces – Deploying Location Awareness for Face-to-Face eLearning Support. In:

Proceedings of the World Conference on E-Learning in Corporate, Government,

Healthcare, and Higher Education 2004 (E-Learn 2004) Bd. 1, 2004, S. 2544–

2550

Eßmann und Hampel 2005

Eßmann, Bernd ; Hampel, Thorsten: A Framework For Distributed Objects in

Peer-To-Peer Cooperation Environments. In: Chen, Chi-Sheng (Hrsg.) ; Filipe,

Joaquim (Hrsg.) ; Seruca, Isabel (Hrsg.) ; Cordeiro, Jos´e (Hrsg.): Proceedings

of the Seventh International Conference On Enterprise Information Systems

(ICEIS 2005) Bd. 4, INSTICC, 2005, S. 157–162

Eßmann et al. 2004a

Eßmann, Bernd ; Hampel, Thorsten ; Bleckmann, Peter ; Sprotte, Ren`e:

A Whiteboard at Your Fingertips – Automatic Configuration of e-Learning Ser-

vices in Heterogeneous Network Environments. In: Proceedings of the World

Conference on E-Learning in Corporate, Government, Healthcare, and Higher

Education 2004 (E-Learn 2004) Bd. 1, 2004, S. 2601–2608

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 167

Eßmann et al. 2004b

Eßmann, Bernd ; Hampel, Thorsten ; Bopp, Thomas: A Network Compo-

nent Architecture for Collaboration in Mobile Settings. In: Seruca, Isabel

(Hrsg.) ; Filipe, Joaquim (Hrsg.) ; Hammoudi, Slimane (Hrsg.) ; Cordeiro,

Jos´e (Hrsg.): Proceedings of the Sixth International Conference on Enterprise

Information Systems 2004 (ICEIS 2004) Bd. 4, 2004, S. 337–343

Eßmann et al. 2006a

Eßmann, Bernd ; Hampel, Thorsten ; G¨

otz, Frank: An Open Architecture

for Collaborative Visualizations in Rich Media Environments. In: Proceedings of

the Eighth International Conference on Enterprise Information Systems (ICEIS

2006), 2006, S. to appear

Eßmann et al. 2006b

Eßmann, Bernd ; Hampel, Thorsten ; G¨

otz, Frank ; Elsner, Andreas: Em-

bedding Collaborative Visualizations into Virtual Knowledge Spaces. In: Pro-

ceedings of the Seventh International Conference on the Design of Cooperative

Systems (COOP 2006), 2006, S. to appear

Eßmann et al. 2004c

Eßmann, Bernd ; Hampel, Thorsten ; Slawik, Joanna: A JXTA-based Frame-

work for Mobile Cooperation in Distributed Knowledge Spaces. In: Karagianis,

Dimitris (Hrsg.) ; Reimer, Ulrich (Hrsg.): Proceedings of the Fifth Internatio-

nal Conference on Practical Aspects of Knowledge Management (PAKM 2004),

Springer Verlag, 2004, S. 11–22

Eßmann und Hampel 2005a

Eßmann, Bernd ; Hampel, Thorsten: Connectivity – Context – Consistency:

Key Factors for Mobility Supporting CSCW/L-Environments. In: Proceedings

of the ConferrenWorld Conference on E-Learning in Corporate, Government,

Healthcare, and Higher Education 2005 (E-Learn 2005), AACE, 2005, S. 2915–

2922

Eßmann und Hampel 2005b

Eßmann, Bernd ; Hampel, Thorsten: A Design Pattern for Mobile-Distributed

Knowledge Spaces. In: Proceedings of the Metainformatics Symposium 2005,

Springer Verlag, 2005, S. to appear

Eßmann et al. 2006

Eßmann, Bernd ; Hampel, Thorsten ; Keil-Slawik, Reinhard: Challenges to-

wards a Distributed Persistence Layer for Next Generation CSCW Applications.

In: Proceedings of the 4th IEEE International Conference on Pervasive Compu-

ting and Communications (PerCom 2006). 2nd IEEE International Workshop

on PervasivE Learning (PerEL 2006), IEEEE Computer Society, 2006, S. to

appear

Mobilit¨

at in der kooperativen Wissensarbeit

168 Literaturverzeichnis

Fenwick und Pollock 1997

Fenwick, James B. ; Pollock, Lori L.: Issues and Experiences in Implemen-

ting a Distributed Tuplespace. In: Software – Practice and Experience 27 (1997),

Nr. 10, S. 1199–1232

Fox und Brewer 1999

Fox, Armando ; Brewer, Eric A.: Harvest, Yield, and Scalable Tolerant Sys-

tems. In: Proceedings of the The Seventh Workshop on Hot Topics in Operating

Systems (HOTOS-VII), IEEEE Computer Society, 1999, S. 174–178

Freeman et al. 1999

Freeman, Eric ; Hupfer, Susanne ; Arnold, Ken: JavaSpaces(TM) Princip-

les, Patterns, and Practice. Addison-Wesley Professional, 1999

Gamma und Beck 2003

Gamma, Erich ; Beck, Kent: Contributing to Eclipse: Principles, Patterns, and

Plugins. Addison-Wesley Professional, 2003

Gamma et al. 1995

Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Design

patterns: elements of reusable object-oriented software. Addison-Wesley Long-

man Publishing Co., Inc. Boston, MA, USA, 1995

Gelernter 1985

Gelernter, David: Generative communication in Linda. In: ACM Transac-

tions on Programming Languages and Systems (TOPLAS) 7 (1985), Nr. 1, S.

80–112

Gelernter und Carriero 1989

Gelernter, David ; Carriero, Nicholas: Linda in Context. In: Communica-

tions of the ACM 32 (1989), Nr. 4, S. 444–458

Gong 2001

Gong, Li: JXTA: A network programming environment. In: IEEE Internet

Computing 5 (2001), Nr. 3, S. 88–95

G¨

otz et al. 2006

G¨

otz, Frank ; Domik, Gitta ; Eßmann, Bernd ; Hampel, Thorsten: Colla-

boration by Illustration: Real-Time Visualization in Web3D. In: Proceedings of

the 11th International Conference on 3D Web Technology (Web3D 2006), 2006,

S. to appear

G¨

otz et al. 2005

G¨

otz, Frank ; Eßmann, Bernd ; Hampel, Thorsten: Using a Shared White-

board for Cooperative Visualization. In: Proceedings of the HCI International

2005, 2005

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 169

Gray 1988

Gray, Jim: The transaction concept: virtues and limitations. In: Readings in

database systems. Morgan Kaufmann Publishers, Inc., 1988, S. 140–150

Gustafsson et al. 2000

Gustafsson, Eva ; Johnson, Annika ; Perkins, Charles E.: Mobile IP Regio-

nal Registration / IETF. 2000 (draft-ietf-mobileip-reg-tunnel-03.txt). – Techni-

cal Report

Gutknecht et al. 2001

Gutknecht, Olivier ; Ferber, Jacques ; Michel, Fabien: Integrating tools

and infrastructures for generic multi-agent systems. In: Proceedings of the Fifth

international conference on Autonomous agents (AGENTS 2001), ACM Press,

2001, S. 441–448

Guttman 2001

Guttman, Erik: Autoconfiguration for IP Networking: Enabling Local Com-

munication. In: IEEE Internet Computing 5 (2001), Nr. 3, S. 81–86

Hampel 2001

Hampel, Thorsten: Virtuelle Wissensr¨

aume : ein Ansatz f¨

ur die kooperative

Wissensorganisation. Paderborn, Universit¨

at Paderborn, Fachbereich 17 - In-

formatik, Diss., 2001

Hampel und Eßmann 2004

Hampel, Thorsten ; Eßmann, Bernd: Spatial Structuring of Virtual Know-

ledge Spaces – a Taxonomy. In: McKay, Elspeth (Hrsg.): Proceedings of the

International Conference on Computers in Education (ICCE 2004), 2004, S.

577–584

Hampel et al. 2003

Hampel, Thorsten ; Keil-Slawik, Reinhard ; Eßmann, Bernd: Jour Fixe –

We Are Structuring Knowledge Collaborative – Structuring of Semantic Spaces

as a Didactic Concept and New Form of Cooperative Knowledge Organization

Proceedings of E-Learn 2003. In: Rossett, Allison (Hrsg.): Proceedings of the

World Conference on E-Learning in Corp., Govt., Health., and Higher Ed. 2004

(E-Learn 2003), AACE, 2003, S. 225–232

Hampel und Keil-Slawik 2002

Hampel, Thorsten ; Keil-Slawik, Rheinhard: sTeam: Structuring Information

in a Team – Distributed Knowledge Management in Cooperative Learning En-

vironments. In: ACM Journal of Educational Resources in Computing 1 (2002),

Nr. 2, S. 1–27

Hightower und Borriello 2001

Hightower, Jeffrey ; Borriello, Gaentano: Location systems for ubiquitous

computing. In: IEEE Computer 34 (2001), Nr. 8, S. 57–66

Mobilit¨

at in der kooperativen Wissensarbeit

170 Literaturverzeichnis

Holliday et al. 2002

Holliday, Joanne ; Agrawal, Divyakant ; Abbadi, Amr E.: Disconnection

Modes for Mobile Databases. In: Wireless Networks 8 (2002), Nr. 4, S. 391–402

Howard et al. 1988

Howard, John H. ; Kazar, Michael L. ; Menees, Sherri G. ; Nichols, Da-

vid A. ; Satyanarayanan, M. ; Sidebotham, Robert N. ; West, Michael J.:

Scale and performance in a distributed file system. In: ACM Transactions on

Computer Systems (TOCS) 6 (1988), Nr. 1, S. 51–81

Hubbold et al. 1999

Hubbold, Roger ; Cook, Jon ; Keates, Martin ; Gibson, Simon ; Howard,

Toby ; Murta, Alan ; West, Adrian ; Pettifer, Steve: GNU/MAVERIK: a

micro-kernel for large-scale virtual environments. In: Proceedings of the ACM

symposium on Virtual reality software and technology (VRST 1999), ACM Press,

1999, S. 66–73

Huck et al. 2002

Huck, Paul ; Butler, Michael ; Gupta, Amar ; Feng, Michael: A Self-

Configuring and Self-Administering Name System with Dynamic Address As-

signment. In: ACM Transactions on Internet technology 2 (2002), Nr. 1, S.

14–46

Huston und Honeyman 1993

Huston, Larry B. ; Honeyman, Peter: Disconnected Operation for AFS. In:

Proceedings of the USENIX Mobile and Location-Independent Computing Sym-

posium, 1993, S. 1–10

Jang 1990

Jang, Jai E.: An optimal fault-tolerant broadcasting algorithm for a hyper-

cube multiprocessor. In: Proceedings of the 1990 ACM annual conference on

Cooperation (CSC ’90), ACM Press, 1990, S. 96–102

Jeong et al. 2005

Jeong, Jaehoon P. ; Park, Juangsoo ; Kim, Hyoungjun ; Kim, Dongkyun: Ad

Hoc IP Address Autoconfiguration / IETF. 2005 (draft-jeong-adhoc-ip-addr-

autoconf-05.txt). – Technical Report

Johnson 1994

Johnson, David B.: Routing in Ad Hoc Networks of Mobile Hosts. In: Procee-

dings of the Workshop on Mobile Computing Systems and Applications, IEEEE

Computer Society, 1994, S. 158–163

Johnson et al. 2004

Johnson, David B. ; Perkins, Charles E. ; Arkko, Jari: Mobility Support

in IPv6 / IETF Network Working Group. 2004 (RFC3775). – Request For

Comment

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 171

Karbhari et al. 2004

Karbhari, Pradnya ; Ammar, Mostafa H. ; Dhamdhere, Amogh ; Raj, Hi-

manshu ; Riley, George F. ; Zegura, Ellen W.: Bootstrapping in Gnutella:

A Measurement Study. In: Barakat, Chadi (Hrsg.) ; Pratt, Ian (Hrsg.):

Proceedings of the Passive and Active Network Measurement, 5th International

Workshop (PAM 2004) Bd. 3015, Springer Verlag, 2004, S. 22–32

Karger et al. 1997

Karger, David ; Lehman, Eric ; Leighton, Tom ; Panigrahy, Rina ; Levine,

Matthew ; Lewin, Daniel: Consistent hashing and random trees: distributed

caching protocols for relieving hot spots on the World Wide Web. In: Proceedings

of the Twenty-ninth annual ACM symposium on Theory of computing (STOC

1997), ACM Press, 1997, S. 654–663

Kawell et al. 1988

Kawell, Leonard J. ; Beckhardt, Steven ; Halvorsen, Timothy ; Ozzie,

Raymond ; Greif, Irene: Replicated document management in a group com-

munication system. In: CSCW ’88: Proceedings of the 1988 ACM conference on

Computer-supported cooperative work, ACM Press, 1988

Keil-Slawik und Hampel 2003

Keil-Slawik, Reinhard ; Hampel, Thorsten: Neue Wege kooperativen Lernens

- Das Paderborner Jour-Fixe-Konzept. In: DFN Mitteilungen 63 (2003), Nr. 11,

S. 16–20

Keil-Slawik et al. 2005

Keil-Slawik, Reinhard ; Hampel, Thorsten ; Eßmann, Bernd: Re-

Conceptualizing Learning Environments: A Framework for Pervasive eLearning.

In: Proceedings of the Third IEEE International Conference on Pervasive Com-

puting an Communications Workshops (PERCOMW 2005), 2005, S. 322–326

Keil-Slawik und Selke 1998

Keil-Slawik, Reinhard ; Selke, Harald: Forschungsstand und Forschungsper-

spektiven zum virtuellen Lernen von Erwachsenen. In: Kompetenzentwicklung

’98 – Forschungsstand und Forschungsperspektiven (1998), S. 165–208

Kistler und Satyanarayanan 1992

Kistler, James J. ; Satyanarayanan, M.: Disconnected Operation in the

Coda File System. In: ACM Transactions on Computer Systems (TOCS) 10

(1992), Nr. 1, S. 3–25

Kleinrock 1995

Kleinrock, Leonard: Nomadic computing-an opportunity. In: CM SIGCOMM

Computer Communication Review 25 (1995), Nr. 1, S. 36–40

Kubiatowicz et al. 2000

Kubiatowicz, John D. ; Weimer, Westley ; Wells, Chris ; Zhao, Ben Y. ;

Mobilit¨

at in der kooperativen Wissensarbeit

172 Literaturverzeichnis

Bindel, David ; Chen, Yan ; Czerwinski, Steven ; Eaton, Patrick ; Geels,

Dennis ; Gummadi, Ramakrishan ; Rhea, Sean C. ; Weatherspoon, Hakim:

OceanStore: An Architecture for Global-Scale Persistent Storage. In: ACM SI-

GOPS Operating Systems Review 34 (2000), Nr. 5, S. 190–201

Kung und Robinson 1981

Kung, H. T. ; Robinson, John T.: On Optimistic Methods for Concurrency

Control. In: ACM Transactions on Database Systems (TODS) 6 (1981), Nr. 2,

S. 213–226

Lehman et al. 2001

Lehman, Tobin J. ; Cozzi, Alex ; Xiong, Yuhong ; Gottschalk, Jonathan ;

Vasudevan, Venu ; Landis, Sean ; Davis, Pace ; Khavar, Bruce ; Bowman,

Paul: Hitting the distributed computing sweet spot with TSpaces. In: Compu-

ter Networks: The International Journal of Computer and Telecommunications

Networking 34 (2001), Nr. 4, S. 457–472

Lundgren et al. 2002

Lundgren, Henrik ; Lundberg, David ; Nielsen, Johan ; Nordstr¨

om, Erik ;

Tschudin, Christian: A Large-scale Testbed for Reproducible Ad hoc Protocol

Evaluations. In: IEEE Wireless Communications and Networking Conference

2002 (WCNC’02) 1 (2002), S. 412–418

Maymounkov und Mazi`eres 2002

Maymounkov, Petar ; Mazi`

eres, David: Kademlia: A Peer-to-Peer Informati-

on System Based on the XOR Metric. In: Druschel, Peter (Hrsg.) ; Kaashoek,

M. Frans (Hrsg.) ; Rowstron, Antony (Hrsg.): Peer-to-Peer Systems: First In-

ternationalWorkshop, IPTPS 2002. Revised Papers. Springer Verlag, 2002, S.

53–65

Oliveira et al. 1999

Oliveira, Manuel ; Crowcroft, Jon ; Brutzman, Don ; Slater, Mel: Com-

ponents for distributed virtual environments. In: Proceedings of the ACM sym-

posium on Virtual reality software and technology (VRST 1999), ACM Press,

1999, S. 176–177

OLSR 2003

Clausen, Thomas (Hrsg.) ; Jacquet, Philippe (Hrsg.): Optimized Link State

Routing Protocol (OLSR) / IETF Network Working Group. 2003 (RFC3626).

– Request For Comment

Park und Corson 1997

Park, Vincent D. ; Corson, M. S.: A Highly Adaptive Distributed Routing Al-

gorithm for Mobile Wireless Networks. In: Proceedings of the 16th Annual Joint

Conference of the IEEE Computer and Communications Societies (INFOCOM

1997), IEEEE Computer Society, 1997, S. 1405

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 173

Park und Corson 2001

Park, Vincent D. ; Corson, Scott M.: Temporally-Ordered Routing Algorithm

(TORA) Version 1 Functional Specification / IETF MANET Working Group.

2001 (20 Juli 2001). – Internet Draft

Perkins 1997

Perkins, Charles E.: Mobile IP: Design Principles and Practices. Addison-

Wesley, 1997

Perkins 2001

Perkins, Charles E.: Ad Hoc Networking. Boston, USA : Addison-Wesley, 2001

Perkins 2002

Perkins, Charles E.: IP Mobility Support for IPv4 / IETF Network Working

Group. 2002 (RFC3220). – Technical Report

Perkins et al. 2003

Perkins, Charles E. ; Belding-Royer, Elizabeth M. ; Das, S.: Ad hoc On-

Demand Distance Vector (AODV) Routing / IETF Network Working Group.

2003 (RFC3561). – Technical Report

Perkins und Bhagwat 1994

Perkins, Charles E. ; Bhagwat, Pravin: Higly Dynamic Destination-

Sequenced Distance Vector (DSDV) for Mobile Computers. In: SIGCOMM

1994 Conference on Communications Architectures, Protocols and Applications

(1994), S. 234–244

Perkins und Bhagwat 2000

Perkins, Charles E. ; Bhagwat, Pravin: DSDV – Routing over a Multihop

Wireless Network of Mobile Computers. In: Ad Hoc Networking (2000), S. 53–74

Perkins et al. 2001

Perkins, Charles E. ; Malinen, Jari T. ; Wakikawa, Ryuji ; Belding-Royer,

Elizabeth M. ; Sun, Yuan: IP Address Autoconfiguration for Ad Hoc Networks

/ IETF Mobile Ad Hoc Networking Working Group. 2001 (draft-ietf-manet-

autoconf-01.txt). – Technical Report

Perkins und Royer 1999

Perkins, Charles E. ; Royer, Elizabeth M.: Ad-hoc On-Demand Distance Vec-

tor Routing. In: Proceedings of the Second IEEE Workshop on Mobile Computing

Systems and Application (WMCSA 1999), IEEEE Computer Society, 1999, S.

90–100

Picco et al. 1999

Picco, Gian P. ; Murphy, Amy L. ; Roman, Gruia-Catalin: LIME: Linda

Meets Mobility. In: Garlan, D. (Hrsg.): Proceedings of the 21st International

Conference on Software Engineering (ICSE 1999), ACM Press, 1999, S. 368–377

Mobilit¨

at in der kooperativen Wissensarbeit

174 Literaturverzeichnis

Popek et al. 1990

Popek, Gerald J. ; Guy, Richard G. ; Page, Thomas W. ; Heidemann, John S.:

Replication in Ficus Distributed File Systems. In: Cabrera, Luis-Felipe (Hrsg.)

;Pˆ

aris, Jehan-Fran¸cois (Hrsg.): Proceedings of the First Workshop on the Ma-

nagement of Replicated Data, IEEEE Computer Society, 1990, S. 5–10

Ramjee et al. 1999

Ramjee, R. ; Varafhan, K. ; Salgarelli, L. ; Thuel, S. ; Wang, S. Y. ;

Porta, T. L.: HAWAII: A Domain-Based Approach for Supporting Mobility in

Wide-Area Wireless Networks. In: International Conference Network Protocols

(ICNP’99) (1999), S. 283–292

Rashid et al. 1989

Rashid, Richard ; Baron, Robert ; Forin, Alesandro ; Golub, David ; Jones,

Michael B. ; Julin, Daniel ; Orr, Douglas ; Sanzi, Richard: Mach: A Founda-

tion for Open Systems. In: Proceedings of the Second Workshop on Workstation

Operating Systems (WWOS2), IEEEE Computer Society, 1989, S. 176–178

Ratnasamy et al. 2001

Ratnasamy, Sylvia ; Francis, Paul ; Karp, Richard ; Shenker, Scott: A

Scalable Content-Addressable Network. In: Proceedings of the 2001 Conference

on Applications, Technologies, Architectures, and Protocols for Computer Com-

munications (SIGCOMM 2001), 2001, S. 161–172

Reinbold und Bonaventure 2001

Reinbold, Pierre ; Bonaventure, Oliver: A Comparison of IP mobility Pro-

tocols / Infonet Group, University of Namur, Belgium. 2001 (infonet-TR-13). –

Technical Report

Rhea et al. 2005a

Rhea, Sean C. ; Brighten, Godfrey ; Karp, Brad ; Kubiatowicz, John ;

Ratnasamy, Sylvia ; Shenker, Scott ; Stoica, Ion ; Yu, Harlan: OpenDHT:

a public DHT service and its uses. In: Proceedings of the 2005 Conference on

Applications, Technologies, Architectures, and Protocols for Computer Commu-

nications (SIGCOMM 2005), ACM Press, 2005, S. 73–84

Rhea et al. 2003

Rhea, Sean C. ; Eaton, Patrick ; Geels, Dennis ; Weatherspoon, Hakim

;Zhao, Ben Y. ; Kubiatowicz, John: Pond: the OceanStore Prototype. In:

Proceedings of the Second USENIX Conference on File and Storage Technologies

(FAST ’03), 2003, S. 1–14

Rhea et al. 2005b

Rhea, Sean C. ; Geels, Dennis ; Roscoe, Timothy ; Kubiatowicz, John:

Handling Churn in a DHT. In: Proceedings of the USENIX Annual Technical

Conference (USENIX 2004), 2005, S. 127–140

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 175

Rowstron und Druschel 2001a

Rowstron, Antony ; Druschel, Peter: Pastry: Scalable, distributed object

location and routing for large-scale peer-to-peer systems. In: Proceedings of the

IFIP/ACM International Conference on Distributed Systems Platforms (Midd-

leware), 2001, S. 329–350

Rowstron und Druschel 2001b

Rowstron, Antony ; Druschel, Peter: Storage management and caching in

PAST, a large-scale, persistent peer-to-peer storage utility. In: Proceedings of

the 18th ACM Symposium on Operating Systems Principles (SOSP 2001), ACM

Press, 2001, S. 188–201

Rowstron et al. 2001

Rowstron, Antony ; Kermarrec, Anne-Marie ; Castro, Miguel ; Druschel,

Peter: SCRIBE: The Design of a Large-Scale Event Notification Infrastructure.

In: Crowcroft, Jon (Hrsg.) ; Hofmann, Markus (Hrsg.): Proceedings of the

Third International COST264 Workshop on Networked Group Communication

(NDC 2001) Bd. 2233, Springer Verlag, 2001, S. 30–43

Satyanarayanan 1996

Satyanarayanan, M.: Fundamental challenges in mobile computing. In: Pro-

ceedings of the 15th annual ACM Symposium on Principles of Distributed Com-

puting (PODC’96), 1996, S. 1–7

Satyanarayanan 2002

Satyanarayanan, M.: The Evolution of Coda. In: ACM Transactions on

Computer Systems 20 (2002), Nr. 2, S. 85–124

Satyanarayanan et al. 1993

Satyanarayanan, M. ; Kistler, J.J. ; Mummert, L.B. ; Ebling, M. R. ; Ku-

mar, P. ; Lu, Q.: Experience with disconnected operation in a mobile compu-

ting environment. In: USENIX Symposium on Mobile and Location-Independent

Computing (1993), S. 11–28

Slawik et al. 2004

Slawik, Joanna ; Eßmann, Bernd ; Hampel, Thorsten: Shared Views on Mo-

bile Knowledge - A Concept of a Graphical User Interface. In: Karagianis,

Dimitris (Hrsg.) ; Reimer, Ulrich (Hrsg.): Proceedings of the 5th Internatio-

nal Conference on Practical Aspects of Knowledge Management (PAKM 2004),

Springer Verlag, 2004, S. 82–93

Stirling und Al-Ali 2003

Stirling, David ; Al-Ali, Firas: Zero Configuration Networking. In: ACM

Crossroads 9 (2003), Nr. 4, S. 19–23

Stoica et al. 2002

Stoica, Ion ; Adkins, Daniel ; Zhuang, Shelley ; Shenker, Scott ; Sonesh,

Mobilit¨

at in der kooperativen Wissensarbeit

176 Literaturverzeichnis

Surana: Internet Indirection Infrastructure. In: ACM SIGCOMM Computer

Communication Review 32 (2002), Nr. 4, S. 73–86

Stoica et al. 2001a

Stoica, Ion ; Morris, Robert ; Kargerm, David ; Kaashoek, M. Frans

;Balakrishnan, Hari: Chord: A Scalable Peer-to-peer Lookup Service for

Internet Applications. In: Proceedings of the Annual Conference of the ACM

Special Interest Group on Data Communication (SIGCOMM 2001), ACM Press,

2001, S. 149–160

Stoica et al. 2001b

Stoica, Ion ; Morris, Robert ; Kargerm, David ; Kaashoek, M. Frans

;Balakrishnan, Hari: Chord: A Scalable Peer-to-peer Lookup Service for

Internet Applications. In: Proceedings of the Annual Conference of the ACM

Special Interest Group on Data Communication (SIGCOMM 2001), ACM Press,

2001, S. 149–160

Terry et al. 1995

Terry, Douglas B. ; Theimer, M. M. ; Petersen, Karin ; Demers, A. J.

;Spreitzer, Mike J. ; Hauser, C. H.: Managing update conflicts in Bayou,

a weakly connected replicated storage system. In: ACM SIGOPS Operating

Systems Review 29 (1995), Nr. 5, S. 172–182

Teufel et al. 1995

Teufel, Stefanie ; Sauter, Christian ; M¨

uhlherr, Thomas: Computerunter-

st¨

utzung f¨

ur die Gruppenarbeit. Oldenbourg, 1995

Tschudin et al. 2005

Tschudin, Christian F. ; Gunningberg, Per ; Lundgren, Henrik ; Nord-

str¨

om, Erik: Lessons from experimental MANET research. In: Ad Hoc Net-

works 3 (2005), Nr. 2, S. 221–233

Tseng et al. 2003

Tseng, Yu-Chee ; Shen, Chia-Ching ; Chen, Wen-Tsuen: Integrating Mobile

IP with Ad Hoc Networks. In: IEEE Computer (2003), S. 48–55

Valko 1999

Valko, Andreas G.: Cellular IP: A New Approach to Internet Host Mobility.

In: ACM Computer Communication Review 29 (1999), S. 50–65

Watsen und Zyda 1998

Watsen, Kent ; Zyda, Michael: Bamboo – A Portable System for Dynamically

Extensible, Real-Time, Networked, Virtual Environments. In: Proceedings of

the IEEE 1998 Virtual Reality Annual International Symposium (VRAIS 1998),

IEEEE Computer Society, 1998, S. 252–259

Mobilit¨

at in der kooperativen Wissensarbeit

Literaturverzeichnis 177

Weiser 1991

Weiser, Marc: The Computer for the Twenty-First Century. In: Scientific

American (1991), S. 94–104

Wykoff et al. 1998

Wykoff, Peter ; McLaughry, Stephen ; Lehman, Tobin J. ; Ford, Daniel:

TSpaces. In: IBM Systems Journal 37 (1998), Nr. 3, S. 454–474

Xu und Liskov 1989

Xu, A. ; Liskov, B.: A design for a fault-tolerant, distributed implementation

of Linda. In: Proceedings of the 19th International Symposium on Fault-Tolerant

Computing 1989. (FTCS-19), 1989, S. 199–206

Yu und Vahdat 2002

Yu, Haifeng ; Vahdat, Amin: Design and evaluation of a conit-based continuous

consistency model for replicated services. In: ACM Transactions on Computer

Systems (TOCS) 20 (2002), Nr. 3, S. 239–282

Zhao et al. 2004

Zhao, Ben Y. ; Huang, Ling ; Stribling, Jeremy ; Rhea, Sean C. ; Jo-

seph, Anthony D. ; Kubiatowicz, John D.: Tapestry: A Resilient Global-scale

Overlay for Service Deployment. In: IEEE Journal on Selected Areas in Com-

munications (JSAC) 22 (2004), Nr. 1, S. 41–53

Zhou et al. 2003

Zhou, Hongbo ; Ni, Lionel M. ; Mutka, Matt W.: Prophet Adress Allocation

for Large Scale MANETs. In: Ad Hoc Networks Journal 1 (2003), Nr. 4, S.

423–434

Zhuang et al. 2003

Zhuang, Shelley Q. ; Lai, Kevin ; Stoica, Ion ; Katz, Randy ; Shenker, Scott:

Host Mobility Using an Internet Indirection Infrastructure. In: Proceedings of the

First International Conference on Mobile Systems, Applications, and Services

(MobiSys 2003), 2003, S. 129–144

Zhuang et al. 2001

Zhuang, Shelley Q. ; Zhao, Ben Y. ; Joseph, Anthony D. ; Katz, Randy ;

Kubiatowicz, John: Bayeux: An Architecture for Scalable and Fault-tolerant

Wide-area Data Dissemination. In: Proceedings of the Eleventh International

Workshop on Network and Operating Systems Support for Digital Audio and

Video (NOSSDAV 2001), ACM Press, 2001, S. 11–20

Mobilit¨

at in der kooperativen Wissensarbeit

178 Literaturverzeichnis

Mobilit¨

at in der kooperativen Wissensarbeit

Stichwortverzeichnis

Abstraktionsschicht . . . . . . . . . . . . . . 146

ACID-Eigenschaften. . . . . . . . . . . . . .119

Ad hoc On Demand Distance Vector

siehe AODV

Ad hoc Protocol Evaluation (APE)95

Ad-Hoc-Kooperation . . . . . . . . . . . . . . 63

Ad-Hoc-Netzwerk. . . . . .27, 62, 76, 91,

94 – 97, 100

Adressatenkreis, flexibler . . . . . . . . . . 78

AFS.............................120

aktive Objekte....................84

Andrew File System . . . . . . .siehe AFS

Anycast..........................103

AODV............................95

Apache Foundation. . . . . . . . . . . . . . . .90

API..............................103

Application Programm. Interfacesiehe

API

Arbeitsbereich

gemeinsamer17, 22, 28, 34, 79, 83

pers¨

onlicher . . . . . . . . . . . . . . . 21, 83

Archivierung......................70

ARP-Requests....................96

asynchrone Kooperation. . . . . . . . . . . 12

Aufl¨

osung.........................13

Automatische Konfiguration. . . . . . .62

Avatare...........................99

Awareness.......................144

Bamboo.....................103, 114

Bayeux...........................103

Bayou............................120

Berechtigungen....................83

Bittorrent........................103

Bluetooth.........................90

Broadcast....................94, 101

BSCW............................99

Caching.....................65, 112f

CAN.............................103

Care-of-Adresse. . . . . . . . . . . . . . . .93, 96

CAS..........................45, 144

Casca.............................99

CAST............................103

CellularIP.........................97

CFS.........................103, 114

Chord............................103

Coda.............................120

Compute-Dienste. . . . . . . . . . . . . . . . .144

Computer Algebra System siehe CAS

Cooperative FileSystem . . . siehe CFS

Cooperative Virt. Environments siehe

CVE

CSCW............................53

Cluster........................90

CVE..............................90

Bamboo.......................90

Decentraliced Object Location and Rou-

ting....................siehe

DOLR

Delay.............................93

Destination-Sequence Distance-Vector

siehe DSDV

DHT.......................101 – 116

Dienst

179

180 Stichwortverzeichnis

Verteilung.....................77

Diensteinfrastruktur. . . . . . . . . . . . . . .97

Distant Learning . . . . . . . . . . . . . . . . . . 41

Distributed Hash Table (DHTs) .. 132

Distributed Hashtable . . . . siehe DHT

Distributed Hashtable (DHT) . . . . 121

Distribution.......................78

DOLR..........................102f

Dreiecksrouting . . . . . . . . . . . . . . . . . . . 93

DSDV.........................95, 97

DSR..............................95

Duplicate Adress Detection. . . . . . . .96

Dynamic Source Routing. . siehe DSR

E-Learning........................41

Eclipse............................90

Einstiegsknoten . . . . . . . . . . . . . . . . . . 108

eMule............................103

epidemische Distribution . . . . . . . . . . 79

Ereigniskontrolle . . . . . . . 78, 121 – 128

Expanding Multicast . . . . . . . . . . . . . 111

externe Dienste . . . . . . . . . . . . . . . . . . 143

FA................................93

Ficus.............................120

Filesharing.......................101

Foreign Agent . . . . . . . . . . . . . . siehe FA

Foreign Domain Root Router. . . . . . 97

Forwarding Schemes. . . . . . . . . . . . . . .97

Freifunk Projekt . . . . . . . . . . . . . . . . . . 95

G¨

ultigkeitsdatum. . . . . . . . . . . . . . . . . .16

Gastrechte und -rollen . . . 24 f, 64, 81 f

GLOMAR.......................120

GNU/Maverik.....................90

Gnutella.........................101

Gr¨

undung.........................13

Graphen.........................134

Groove............................99

Groupware........................99

Gruppe

Gr¨

undung.....................56

Kalender.................19f, 80

Kommunikation . . . . . . . . . 128, 142

Koordination . . . . . . . . . . . . . . . . 142

Struktur. . . . . . . . . . . . .62 f, 71, 141

Verwaltung. . . . . . . . . . . . . . .83, 128

Gruppen..........................83

Gruppen-Tuple Space . . . . . . . . . . . . 140

Gruppenadministrator. . . . . . . . . . . . .17

Gruppenbereich . siehe Arbeitsbereich

Gruppengr¨

undung.................16

HA................................93

Handoff-Aware Wireless Access Inter-

net Infrastructure . . . . . . siehe

HAWAII

Hash

Exact-Matching. . . . . . . . . . . . . . 102

Funktion . . . . . . . . . . . . . . . . 102, 138

Index........................102

Tabelle......................101

Wert.........................102

Hash-based Distribution. . . . . . . . . .138

HAWAII..........................97

Hierarchical Mobile IP . . . . . . . . . . . . 97

Hivemind.........................90

Hoarding.........................120

Home Agent........................i

Hop...............................94

Host Tuple Space. . . . . . . . . . . .118, 140

Host-Level Tuple Space . . . siehe Host

Tuple Space

Hybrid Broadcast . . . . . . . . . . . . . . . . 139

Hypercube.......................135

I3................................103

IANA.............................94

IBM Research....................117

ICMP.............................96

Mobilit¨

at in der kooperativen Wissensarbeit

Stichwortverzeichnis 181

IEEE 802.11. . . . . . . . . . . .siehe WLAN

IEEE 802.15.1 . . . . . . . siehe Bluetooth

IEEE 802.16 . . . . . . . . . . siehe WIMAX

Independent Nodes . . . . . . . . . . 131, 140

Indexdienst. . . . . . . . . . . . . . . . . .101, 142

Informationsdienste . . . . . . . . . . . . . . 144

Inhaltsbereiche . . . . . . . . . . . . . . . . . . . 133

Integration externer Dienste . . . . . . . 72

Inter Domain Mobility. . .siehe Macro

Mobility

Interface Tuple Space . . . . . . siehe ITS

Internet Assigned Numbers Authority

siehe IANA

Internet Indirection Infrastructuresiehe

Intra Domain Mobility . . . siehe Micro

Mobility

IP-Adresse........................92

IPv4...........................92, 96

IPv6...........................93, 96

ITS..............................118

JADE.............................90

Jarkarta Projekt . . . . . . . . . . . . . . . . . . 90

Java.............................117

JavaSpaces.......................117

JBOSS............................90

JBossMicrokernel. . . . . . . . . . . . . . . . . .90

Jini..............................117

Jour Fixe.........................48

JXTA...................98, 100, 117

JXTASpaces.....................117

Kademlia........................103

KBR............................102f

Key.................siehe Hash-Wert

Key-Based Routing . . . . . . . siehe KBR

Knotenausfall.....................67

Knotengrad......................134

Kollaboration.....................73

Kommunikation . . . . . . . . . . . . . . 75 – 80

entkoppelte..................118

Kommunikationsschicht . . . . . . . . . 145 f

Konflikt. . . . . . . .siehe Versionskonflikt

Konflikterkennung. . . . . . . . . . . . . . . . .70

Konsistenz . . . . . 66 – 70, 79, 84, 118 ff

Gef¨

ahrdung der...............68

semantische..................68f

Kontext...........................63

Kontextdienste. . . . . . . . . . . . . . . . . . . 143

Kooperation . . . . . . . . . . . . . . . . . .13, 83 f

r¨

aumlich verteilt . . . . . . . . . . . . . . 34

Kooperationsgruppe. . . . . . . . . . . . . . . 56

tempor¨

are.....................29

Kooperationsphasen . . . . . . . . . . . . . . .13

Koordination......................80

Leaf Set...................106ff, 110

Lerngruppe.......................15

LIME.......................117, 138

Linda............................117

Linda in a Mobile Environment . . . . . i

Link-Local........................94

Location Awareness . siehe Ortsbezug

Locking

Optimistic. . . . . . . . . . . . . . . .69, 119

Pessimistic....................69

Lokalit¨

at....................102, 108

Lotus Notes.......................99

Maß der N¨

ahe...................107f

Macro Mobility . . . . . . . . . . . . . . . . 92, 96

MadKit...........................90

Manet.........................94, 97

Matching........................117

mDNS............................98

Medien..........................78ff

Medienbr¨

uche . . . . . . . . . 14, 57 f, 71, 80

Medienfunktionen . . . . . . . . . . . . . 58, 99

individuelle...................58

kooperative...................58

prim¨

are.......................58

Mobilit¨

at in der kooperativen Wissensarbeit

182 Stichwortverzeichnis

sekund¨

are.....................58

terti¨

are.......................58

Micro Mobility. . . . . . . . . . . . .92, 94, 96

Microkenel......................88ff

Microkernel.......................89

Mobile IP...................92ff, 96f

Mobility...........................92

Moderator........................64

Modul.............................90

Modularit¨

at.......................72

monolithische Architektur . . . . . 72, 89

Multicast . . . . . . . . . . 98, 103, 121 f, 134

Multicast DNS . . . . . . . . . . siehe mDNS

Multihop..........................94

Multiple Write Replication . . . . . . . 119

Multiple-Unicast . . . . . . . . . . . . . . . . . 125

Nachrichtenschl¨

ussel..............105

Nachrichtensystem. . . . . . . . . . . . .18, 77

Napster..........................101

Negative Broadcast. . . . . . . . . .139, 142

Neighborhood Set . . . . . . 106, 108, 110

Network Simulator 2 . . . . . . . siehe ns2

Network Tuple Space. . . . . . . . . . . . .140

Netzwerkprotokolle . . . . . . . . . . . . . . . .92

Netzwerksimulatoren . . . . . . . . . . . . . . 95

ns2................................95

Objekt

aktives. . . . . .siehe aktive Objekte

personalisiertsiehe personalisierte

Objekte

Sichtbarkeit...................81

Objektdistribution . . . . . . . . . . . . . . . 145

Objekte.........................78ff

Objektmigration . . . . . . . . . . . . . . . . . . 78

Objektsuche..................... 142

Objektverwaltung . . . . . . . . . . . . . . . . 145

Observer-Paradigma . . . . . . . . . . . . . 121

OceanStore . . . . . . . . . . . . . . 90, 103, 114

Offene Architektur. . . . . . . . . . . . . . .71 ff

Offline-Verf¨

ugbarkeit . . . 77 f, 101, 104,

117, 119, 128, 131, 141

OLSR.............................95

On Demand Nodes . . . . . . . . . . 132, 140

open-sTeam...................12, 99

OpenDHT.......................114

Operator-based Distribution. . . . . .138

Optimistic Concurrency Control siehe

Locking

Optimized Link State Routing . . siehe

OLSR

Ortsbezug . . . . . . . . . . . . . . . . 64, 98, 144

Overlay-Netzwerk . . . . . . . . . . . 102, 132

Partitionierung, Netzwerk- . . . . . . . 136

PAST. . . . . . . . . . . . . . . . .103, 105, 111 ff

Pastry . . . . . . . . . . . . . . . . 103 – 116, 121

Peer...............................53

Peer-to-Peer . . . . . . . . 53, 98 f, 102, 117

Persistent Linda . . . . . . . . siehe PLinda

Persistenz. . . . . . . . . . . . . . . . . . 100 – 120

verteilte. . . . .65, 78, 84, 101 – 120

Persistenzdienst . . . . . . . . . . . . . . . . . . . 79

Persistenzdienste . . . . . . . . . . . . . . . . . 144

personalisierte Objekte . . . . . . . . . . . . 84

PFS..............................120

Phasen der Kooperation

Abschluss.....................55

Gr¨

undung.....................55

Kooperation..................55

PLinda...........................117

Polling......................121, 134

Pond.............................114

portabel...........................87

Portability........................92

Positive Broadcast . . . . . . . . . . . . . . . 139

Pr¨

afix............................105

Pr¨

asenzkooperation . . . . . . . . . . . .14, 62

PRAYER File System . . . . . siehe PFS

proaktiv...........................95

Prophet Adress Allocation. . . . . . . . .96

Protokollabstraktion . . . . . . . . . . . . . 103

Mobilit¨

at in der kooperativen Wissensarbeit

Stichwortverzeichnis 183

Proximity Metric siehe Maß der N¨

ahe

Proxy.............................98

Publish/Subscribe-Paradigma . . . . 121

Pull-Paradigma . . . . . . . . . . . . . . . . . . 121

Pushing.....................121, 134

Quotaverwaltung. . . . . . . . . . . . . . . . .112

reaktiv............................95

Rechteverwaltung . . . . . . . . . . . . . . . . . 81

Redundanz . . . . . . . . . . . . . . . . 71, 79, 84

Rendezvous-Knoten . . . . . . . . . . . . . . 122

Rendezvous-Peers . . . . . . . . . . . . . . . . . 98

Replikation . . . . . . . . . . 66, 79, 112, 131

Replikationsfaktor. . . . . . . . . . . . . . . .112

Replikationsstrategie . . . . . . . . . . . . 130 f

Request&Reply-Paradigma . . . . . . . 121

Reversibilit¨

at.................68, 70f

ROAM...........................104

Robustheit....................77, 93

Rollen und Rechte . . . . . . . . . . . 64, 80 ff

Routing . . . . . . . . . . . . . . . . . 94, 102, 105

Routing Tabelle . . . . . . . . . . . . . 106, 110

Routing-Tabelle . . . . . . . . . . . . . . . . . . 108

RSS Feeds.......................144

Scribe . . . . . . . . . . . . . . . . .103, 121 – 128

Abonnentenverwaltung. . . . . . .122

Ausfallsicherheit . . . . . . . . . . . . . 125

Nachrichtenverbreitung . . . . . . 125

Thema abbestellen . . . . . . . . . . . 123

Thema abonnieren . . . . . . . . . . . 122

Selective Nodes. . . . . . . . . . . . . .131, 140

Semantische Inkonsitenz. . . . . . . . . . .48

Service Discovery. . . . . . . . . . . . . . . . .97 f

shared workspace. . . . . . . . . . . . . . . . . .34

Single-Multicast. . . . . . . . . . . . . . . . . .124

Skalierbarkeit.....................93

Sparse Graph....................136

Speakeasy.........................99

Speicher

verteilter . . . . . . . . . siehe Persitenz

Sperren................siehe Locking

Splitstream......................103

spontane Kooperation . . . . . . . . . . . . . 26

spontane Vernetzung . . . . . . . . . . . . . . 76

sTeam.............siehe open-sTeam

Suche.............siehe Objektsuche

SUN Microsystems . . . . . . . . . . . . . . . 117

Symmetrieeigenschaft . . . . . . . . . . . . 135

synchrone Kooperation . . . . . . . . . . . . 12

Synchronisation. . . . . . . . . .68, 119, 130

Online........................67

Synchronizit¨

at...................68ff

TACT...........................120

Tapestry....................103, 114

Template....................117, 138

Temporally-Ordered Routing Algorithm

siehe TORA

Terminbestimmung. . . . . . . . . . . . . . . .80

Terminfindung....................19

Tier..............................103

TORA............................95

TSpaces..........................117

Tuple.......................117, 138

Tuple Space......................117

Usecase...........................12

Vernetzung......................76ff

Verschl¨

usselung. . . . . . . . . . . . . . .81, 112

Versionierung.....................70

Versionskonflikt. . . .68 f, 119, 130, 133

verteilte Hash-Tabelle. . . . .siehe DHT

verteilte Systeme

offline-redundante . . . . . . . . . . . . . 67

online-redundante . . . . . . . . . . . . . 67

Mobilit¨

at in der kooperativen Wissensarbeit

184 Stichwortverzeichnis

Verteilungsstrategie . . . . . . . . . . . . . . 134

Verz¨

ogerung..............siehe Delay

Vier-Schichten-Modell . . . . . . . . . . . . 146

virtueller Wissensraum . 12, 58, 79, 99

Warteliste.........................24

WIMAX..........................90

Wireless Local Area Network . . . siehe

WLAN

WLAN............................90

Workflow..........................47

Workflows.........................84

Worldwide Interoperability for Micro-

wave Access . . . . . . . . . . . . siehe

WIMAX

Zeroconf Workinggroup (IETF). . . .98

Zugriffskontrolle . . . . 18, 48, 65, 81, 83

Mobilit¨

at in der kooperativen Wissensarbeit