I.  INHALTSVERZEICHNIS  

I.  INHALTSVERZEICHNIS  2

II.  TEXTTEIL  8

1.  EINLEITUNG  9

2.  METHODIK  13

2.1.  BEGRIFFSBESTIMMUNG  13

2.2.  ZIEL  14

2.3.  WERKZEUGE  15

2.4.  BETRIEBSUMGEBUNG  15

2.5.  BENEFIT  15

2.6.  E-LEARNING  16

2.7.  CODEREVIEW  17

3.  SOFTWARE  18

3.1.  APACHE WEBSERVER  18

3.2.  MYSQL DATENBANK SERVER  18

3.3.  XAMPP  18

4.  JABBERD 2 SERVER  19

4.1.  JABBER  19

4.2.  XMPP  19

4.3.  ENTSCHEIDUNGSFINDUNG FÜR JABBER-VERSION  20

4.4.  JABBERD 2 INSTALLATION  21

4.4.1.  Libidn  21

4.4.2.  MySQL  22

4.4.3.  Jabberd 2 fertigstellen  22

4.5.  PKGCONFIG  22

4.6.  GLIB  22

Diplomarbeit  Peter Reinhardt  

Synchrone  Kommunikation mit Chat Whiteboard  

Seite  2 von  148

4.7.  JABBER COMPONENT RUNTIME  23

4.8.  MULTI USER CHAT  23

5.  KONFIGURATION DES JABBERD 2 SERVERS  24

5.1.  KONFIGURATION DER C2S.XML - CLIENT/SERVER KONFIGURATION  24

5.2.  KONFIGURATION DER MUC-JCR.XML / KONFERENZRAUM KONFIGURATION  25

5.3.  BELEGUNG DER ERLAUBTEN JABBERD-BENUTZER IN ROUTER-USERS.XML  27

5.4.  SCHNITTSTELLE ZWISCHEN JABBERD UND MUC IN ROUTER.XML  27

5.5.  KONFIGURATION DES SESSIONMANAGERS IN SM.XML  27

5.6.  JABBER MIT MULTI USER CHAT STARTEN  28

6.  INTERAKTION VON JABBERD, ESTUDY, EINEM CHAT-CLIENT UND DEM CODE  

REVIEW  -MODUL  29

6.1.  JABBERD AUTHENTIFIZIERUNG  29

6.2.  MUC-RAUM KONFIGURATION  30

6.2.1.  Konfiguration des MUC-Raums  30

6.2.2.  Benutzer startet IM Client  32

7.  ESTUDY VORBEREITUNGEN  37

7.1.  ANPASSUNG DER DATENBANK  37

7.1.1.  Hinzufügen der Jabber-Tabellen  37

7.1.2.  Hinzufügen der Codereview-Tabellen  38

7.2.  DIE KLASSE CLASS.JABBER.PHP  38

7.3.  ANPASSUNG DER BENUTZERVERWALTUNG FÜR INSTANT MESSAGING  40

7.3.1.  Jabber-User einrichten (Passwort setzen)  40

7.3.2.  Anonymität vermeiden  41

7.4.  ANPASSUNG DER KURSVERWALTUNG  41

7.4.1.  Einrichten eines MUC - Raumes  41

7.5.  EINRICHTEN DES WEBINTERFACES  45

7.5.1.  Auswahl des Interfaces  45

7.5.2.  Vorraussetzungen für das Web Interface  47

Diplomarbeit  Peter Reinhardt  

Synchrone  Kommunikation mit Chat Whiteboard  

Seite  3 von  148

7.5.3.  Tomcat Webserver Installation  48

7.5.4.  Web Jabber einrichten  49

7.5.5.  Einrichtung in eStudy  50

8.  CHAT-CLIENT COCCINELLA  52

8.1.  FUNKTIONSUMFANG  52

8.2.  GRAPHISCHES WHITEBOARD  54

8.3.  ENTSCHEIDUNGSHILFE  54

8.4.  ANDERE CHAT-CLIENTS  55

9.  CODE REVIEW  57

9.1.  LEISTUNGSBESCHREIBUNG  57

9.2.  DATEIEN ÖFFNEN, AUSLESEN, IN TABELLEN ABLEGEN  58

9.3.  DATEIEN BEARBEITEN  61

9.4.  DATEIEN SICHERN  62

9.5.  RÜCKGÄNGIG  64

9.6.  ÄNDERUNGEN SICHERN  64

9.7.  ANGEMELDETE USER ANZEIGEN  65

9.8.  DATENHALTUNG  66

9.8.1.  Tabellenlogik  67

9.8.2.  Tabelleninteraktion (Jabber, eStudy und Codereview)  67

9.8.3.  Mögliche Abfragen  67

9.9.  SYNCHRONISIERUNG VON ZUGRIFFEN  70

9.9.1.  Abfrage vor Änderung  70

9.10.  EINPASSUNG IN ESTUDY  71

9.10.1.  Code Review ist Kursen vorbehalten  71

10.  ZUKÜNFTIGE IMPLEMENTIERUNGSVORSCHLÄGE  72

III.  ZUSAMMENFASSUNG  73

11.  ZUSAMMENFASSUNG  74

Diplomarbeit  Peter Reinhardt  

Synchrone  Kommunikation mit Chat Whiteboard  

Seite  4 von  148

12. EIDESSTATTLICHE ERKLÄRUNG 76

IV. VERZEICHNISSE 77

13. VERZEICHNIS VON ABBILDUNGEN, TABELLEN, SHELLBEFEHLEN, CODEFRAGMENTEN UND MYSQL ANWEISUNGEN 78

13.1. LITERATUR- UND LINKVERZEICHNIS 78

13.2. ABBILDUNGSVERZEICHNIS 79

13.3. TABELLENVERZEICHNIS 80

13.4. SHELL - VERZEICHNIS 81

13.5. CODE - VERZEICHNIS 81

13.6. MYSQL - VERZEICHNIS 81

V. ANHANG 82

ANHANG A „CODEREVIEW/CLASSES/CLASS.CODEREVIEW.INC.PHP“ 83

ANHANG B „CODEREVIEW/CODEREVIEW.PHP“ 91

ANHANG C „CODEREVIEW/SAVE.PHP“ 93

ANHANG D „CODEREVIEW/SHOW.PHP“ 94

ANHANG E „CODEREVIEW/NEW.PHP“ 96

ANHANG F „CODEREVIEW/CLOSEBOARD.PHP“ 98

ANHANG G „CODEREVIEW/CLOSE.PHP“ 100

ANHANG H „CODEREVIEW/BLOCKBOARD.PHP“ 101

ANHANG I „CODEREVIEW/ABFRAGE.PHP“ 102

ANHANG J „CLASS.JABBER.PHP“ 103

ANHANG K „CLASS.SAVEFILE.INC.PHP“ 127

ANHANG L „USER/EDITIM.PHP“ 129

ANHANG M „USER/DELETEIM.PHP“ 131

ANHANG N „USER/CLASSES/CLASS.EDITIM.INC.PHP“ 133

ANHANG O „USER/CLASSES/CLASS.IM.INC.PHP“ 136

ANHANG P „IM/IM.SQL“ 142

Diplomarbeit Peter Reinhardt

ANHANG Q „CODEREVIEW/CODEREVIEW.SQL“ 145

ANHANG R „IM/IM.MKF“ 146

ANHANG S „CODEREVIEW/CODEREVIEW.MKF“ 147

Diplomarbeit Peter Reinhardt

Danksagung

Ohne die Unterstützung von

- Tamara Stumpf, meiner Freundin, die mir in den vergangenen Monaten soviel Geduld entgegengebracht hat

- Clementine Reinhardt, meiner Mutter, die immer daran geglaubt hat, dass ich mein Diplom schaffe

- allen meinen Freunden, die mich in Zeiten der Frustration wieder aufgeheitert haben

wäre ich wohl nie soweit gekommen. Deshalb an dieser Stelle ein ganz herzliches Dankeschön!

Diplomarbeit Peter Reinhardt

1. Einleitung

Kommt nun das neue Arbeitsmittel für den Informatiker? Schon jetzt hat das eStudy-Portal einen festen Sitz im Studienalltag der Informatikstudenten und den Dozenten an der FH Gießen. Und das, obwohl noch viele Funktionen zum Gesamtbild fehlen. Eine wichtige Funktion, die derzeit nur teilweise in das System implementiert ist, aber eine integrale Rolle in einem auf Kollaboration basierendem Ganzen darstellt, ist die Möglichkeit zur Kommunikation der einzelnen Portalmitglieder untereinander. Bisher ist es möglich, eine private Nachricht an ein oder mehrere Mitglieder zu versenden über den im Portal angebotenen Dienst. Gleichzeitig kann man zusätzlich auswählen, dass die Nachricht ebenfalls per Standard-Email an die vom Adressaten dem System mitgeteilten Mailadresse zugestellt wird.

Das Prinzip dieser Möglichkeit zur Kommunikation ist asynchron. Man kann zwar sehen, ob ein Mitglied, an das man in diesem Moment schreibt, online ist, aber man kann nicht kontrollieren, wann der Adressat die Nachricht tatsächlich liest. Dies ist nicht kritisch, sofern man keinen zeitlichen Restriktionen unterliegt. Allerdings sind unter diesen Vorraussetzungen niemals Anwendungen denkbar, die einer Art von Echtzeit unterliegen. Da das Portal allerdings als Kommunikationsplattform für Studenten, Dozenten und andere Mitarbeiter konzipiert wurde, bedarf es auf jeden Fall einer Erweiterung desselben in die Richtung der synchronen Medien.

Effektiv kann nur an Projekten gearbeitet und Nachrichten ausgetauscht werden, wenn Anfragen innerhalb eines festgesetzten maximalen Zeitrahmen beantwortet werden. Um eine kurze Illustration zu geben, wann die synchrone Kommunikation in einem Fallbeispiel der Asynchronen vorzuziehen ist, erläutert folgende Situation: Eine zweiköpfige Studentengruppe soll eine C++-Datei am nächsten Tag abgeben, ist jedoch in der letzten Übung nicht fertig geworden. Nun arbeitet jeder für sich getrennt an einer Lösung und sendet diese per Email an den jeweils anderen. Jeder der beiden muss sich nun zeitraubend in das Coding des anderen einlesen, um zu verstehen, bzw. dem anderen in einer Rückmail erläutern, was er zu verstehen glaubt, nachdem er den Code gelesen hat. Überlege man nun, die Entwicklungsgruppe bestände nicht nur aus zwei Studenten, sondern aus drei, vier, eventuell sogar acht bis zehn Studenten. Ein enormer Synchronisationsaufwand, nicht nur zeitlich, sondern auch in Diskussionen wäre auf diese Art und Weise zu erbringen. Einfacher wäre es doch, wenn die Studenten gleichzeitig an ein und derselben Datei arbeiten könnten und über ein entsprechendes System imstande sind, zeitnah die Änderung des Codes zu erklären und zu dokumentieren.

Diese Überlegung bringt die Idee eines Kollaborationsmediums sehr viel näher, als es die bisherige Kommunikationsform über Email oder Foren erlaubt hätte. Genau an diesem Punkt soll angesetzt werden. Erst durch die Einrichtung einer synchronen Kommunikationsplattform kann also das bestehende System zu einem duplexfähigem, virtuell-synchronem Kollaborationsportal werden.

Wie kann man nun diese Überlegungen umsetzen auf ein System, das ohne weiterführende Änderungen zu dem bestehenden Portal ergänzt werden kann? Welche konkreten Erweiterungen für das Portal sind sinnvoll? Zielgerecht wäre ein System, das es den Studenten erlaubt, unkompliziert und schnell gemeinsam und virtuell an einer Lösung zu arbeiten. Hierzu ist eine Kombination aus einem Chat-Diplomarbeit Peter Reinhardt

tool und einem Whiteboard denkbar, die einerseits im Whiteboard die reine Codiermöglichkeit findet und im Chat die Diskussions-und

Dokumentationsplattform bindet.

Das System beansprucht den Charakter einer Lehrplattform und sollte deshalb auch in dieser Richtung weiterentwickelt werden. Hierzu gibt es einen Vorschlag des Bildungsserver Hessen ¹ . Ein System aus OpenSource - Bestandteilen, das aus einer weitverbreiteten Server - Software und clientseitig einem Instant Messaging System besteht, und den proprietären Diensten ICQ oder AIM ähnelt. Die beiden letztgenannten Systeme des kommerziellen Anbieters AOL, sowie weitere ebenfalls kommerzielle Lösungen werden nicht bevorzugt bei der Wahl der geeigneten Anwendung, da diese keinerlei Möglichkeiten der Anpassung an die Bedürfnisse des eStudy - Portals bieten ohne die Urheberrechte der Autoren zu verletzen. Stattdessen bietet der Vorschlag des Bildungsserver Hessen eine interessante Alternative an, da die von dem Betreiber referenzierte Software bereits über ein graphisches Whiteboard verfügt.

Coccinella ² ist eine frei nutzbare Software, die für verschiedene Rechnerplattformen konzipiert ist und sich alleine aus diesem Grund für die Wahl als Kommunikationswerkzeug qualifiziert hat. Ebenso ist Jabber ³ ein Standard in nichtproprietärem Instant Messaging-Einsatz. So hat Google ⁴ vor einiger Zeit einen eigenen IM - Dienst, Google Talk entwickelt, der auf Basis des Jabber - Servers läuft. Google Talk umfasst zwar einen eigenen Client, jedoch kann man Google Talk auch mit jedem anderen Jabber-fähigen Client benutzen. Um eine ungefähre Vorstellung der einzelnen IM - Anbieter in der Menge ihrer Nutzer zu bekommen, sei folgende Tabelle hilfreich.

¹ http://www.portal.bildung.hessen.de/service/freeware/coc

² „http://hem.fyristorg.com/matben/index.html“ - Coccinella 0.95.10 von Mats Bengtsson

³ „http://www.jabber.org“

⁴ „http://www.heise.de/newsticker/meldung/63152“

Diplomarbeit Peter Reinhardt

Aufgrund der Tatsache, dass seit einiger Zeit Apple mit iChat und Google mit einer Version des Jabber - Servers arbeiten, dürfte die Nutzerzahl für diese Lösung in den letzten Monaten enorm angestiegen sein. Ebenso arbeiten laut Jabber Software Foundation ⁵ „…BellSouth, FedEx, EDS, France Telecom, HP, Oracle, Orange, Portugal Telecom, Sun, die meisten der Wall Street Investment Banken, zahlreiche Behörden der USA, und unzählige andere Organisationen…“ mit Jabber. Interessant ist der Vorstoß Google auf jeden Fall, fragt man sich warum Google sich für das Jabber - System entschieden hat. Laut einer offiziellen Stellungnahme auf der Entwicklerseite ⁶ von Google ist der Grund Jabber zu benutzen der, dass man über einen Jabber-Server nicht limitiert ist auf das XMP ⁷ Protokoll, sondern auch ICQ, MSN und andere Netze bedienen kann. So soll es möglich sein, sich innerhalb des Google Talk Jabber-Netzes zu registrieren und an Mitglieder aus ICQ, MSN oder AIM Mitglieder zu schreiben.

Wenn man nun überlegt, dass solch mächtige Unternehmen die Wahl hatten zwischen Eigenentwicklung und einer OpenSource-Lösung und sich für diese entschieden haben, kann man davon ausgehen, dass diese Unternehmen enorme Anstrengungen im Vorfeld unternommen hatten um sicherzustellen, dass diese Lösung die passende für sie ist.

Kommen wir zurück zu der Frage, inwiefern ein solches System aus Chat und Whiteboard das Lernen der Studenten vereinfachen kann. Sicherlich wird das zu entwickelnde System keine vollständige Ersetzung des Lehralltags mit festgesetzten Übungsstunden bedeuten. Dies soll auch nicht das Ziel sein, sondern eine Hilfestellung für den Augenblick, in dem kein Lehrbetrieb stattfindet, also abends, in der vorlesungsfreien Zeit, oder in der Freizeit der jungen Entwickler. Das System soll Studenten die Möglichkeit bieten, gemeinsam an einem Projekt zu arbeiten, und entweder persönlich, telefonisch oder aber per Chat die Entwicklung des Codes im Whiteboard zu besprechen und zu dokumentieren. Denkbar wäre sogar ein Einsatz während der Übungsstunden, wobei der Chat in den Hintergrund rückt und nur das Whiteboard als gemeinsames virtuelles Arbeitsbrett verwendet wird. Dies hat den Vorteil, dass jeder Student einen eigenen Rechner zur Verfügung hat, also auch das ungeteilte Recht auf die Tastatur erhält. Aus eigener Erfahrung des Autors wirkt es störend für den „Tipper“, dass während seiner Eingabe der Partner immer wieder eingreift, um seine Ideen einzubringen, und andererseits ermüdend für den anderen, der Mangels Zugriff auf die Tastatur von der Bearbeitung abschweift und unkonzentriert wird. Dies hat sehr schnell zur Folge, dass ein Mitglied einer Gruppe sehr viel mehr in die Entwicklung einbringt als andere.

Noch etwas weiter gedacht, könnte eine komplette Übungsgruppe, bestehend aus einem Dozenten und vielen Studenten, sich die Vorteile des Whiteboards zunutze machen. Der Dozent kann während er referiert direkt an seinem Rechner Änderungen am Code bereiten und seine Kommentare direkt in diesen einfliessen

⁵ „http://www.jabber.org/journal/2005-08-24.shtml“ - Jabber Software Foundation Journal

⁶ „http://www.google.com/talk/developer.html“ - Google Talk Developer Site

⁷ „http://www.ietf.org/rfc/rfc3920.txt“ - Extensible Messaging and Presence Protocol

Diplomarbeit Peter Reinhardt

lassen. Das Whiteboard ermöglicht in diesem Falle eine Aktiv/Passiv - Option. Passiv sind in diesem Fall die Studenten, die in jenem Moment keine Schreibrechte, sondern nur Leserechte auf den Code im Whiteboard haben. Aktiv ist dagegen der Dozent, der den Studenten eben diese Schreibrechte entzieht und selber aktiv editieren kann. Um dem Beispiel der zwei oder mehr Studenten, die am nächsten Tag ihren Code abgeben sollten ein gutes Ende bereiten zu wollen, existiert eine Erweiterung zu dem Client, welches Multi - User - Conferencing unterstützt. So ist also nicht nur ein 1 zu 1 - Gespräch möglich, sondern auch eine Diskussion mehrerer Benutzer. Das System lässt es zu, Chat-Räume mit speziellen Themen vorzudefinieren, sodass die an einem Projekt beteiligten Studenten jederzeit eine Möglichkeit haben, mit anderen des Projektes zu reden. In diesen Räumen besteht die Möglichkeit einer History-Funktion, sodass Projektmitglieder immer nachvollziehen können, was bisher überlegt, dokumentiert und gemacht wurde. Die Gesprächsprotokolle können auch lokal gesichert werden. Die Raumfunkionalität ist gedacht für die unterschiedlichen Kurse, die in eStudy von Dozenten kreiert werden. Der Dozent hat bei Erstellung eines neuen Kurses die Option zu bestimmen, ob es einen vordefinierten Raum für Diskussionen innerhalb der Gruppe geben soll und ob Nichtmitglieder Lese- oder Schreibrecht erhalten sollen.

Nun zu einigen Forderungen, die das neue System erfüllen muss. Das zu entwickelnde codebasierte Whiteboard muss sich strikt an die Vorgaben des XMP Protokolls halten und darf sich auf den verschiedenen Plattformen nicht in der Bedienung unterscheiden. Es soll intuitiv anwendbar sein auch für Laien, die sich mit der Theorie hinter dem fertigen Produkt nicht auseinander setzen können oder wollen. Die Integration in das bestehende eStudy-Portal muss reibungslos funktionieren und darf den Betrieb des Portals nicht beeinträchtigen. Im Portal muss ein Verweis auf das Angebot der synchronen Kommunikation gerichtet sein. Die benötigten Tools, also Coccinella und das neue codebasierte Whiteboard müssen als Ressource aufgenommen werden für die unterschiedlichen Betriebssysteme, sofern die Entwicklung es nicht zulässt eine gemeinsame Version für alle Plattformen zu schaffen. Es muss vor der Benutzung darauf hingewiesen werden, dass jedwede Form von Austausch illegaler Inhalte, die Urheberrechtsgesetze verletzen nicht zulässig sind. Eine interaktive Hilfe muss Bestandteil des Programms sein. Das fertige Produkt muss einer intensiven Qualitätskontrolle unterzogen werden und diese bestehen. EStudy ist ein OpenSource Projekt, also werden auch alle Erweiterungen diesem Prinzip folgen. Es werden keine proprietären Teile kommerzieller Anbieter verwendet werden und nach Abschluss dieser Arbeit wird die Weiterentwicklung in die Hände der OpenSource-Gemeinde gelegt.

Diplomarbeit Peter Reinhardt

2. Methodik

Die folgenden Abschnitte sollen vermitteln, wie die vorliegende Arbeit ein System konzipiert, das an eStudy verknüpft, fehlerfrei funktioniert. Hierzu ist es zu allererst nötig, das Zielsystem zu beschreiben. Im vorhergehenden Abschnitt Fehler! Verweisquelle konnte nicht gefunden werden. sind wir auf die Motivation eingegangen, warum ein solches System der synchronen Kommunikation sinnvoll ist. Nun wollen wir uns mit der technischen Durchführung beschäftigen. Wie oben angesprochen, wird eine Implementierung des Jabber - Servers eingesetzt werden. Die Zielplattform, auf der dieser laufen soll, ist ein Linux-System namens „juno.mni.fh-giessen.de“. Aus den verschiedenen Jabber - Server -Implementierungen wurde die Version Jabberd 2.0 ausgewählt. Dies liegt einerseits an der Masse der vorhandenen Dokumentation, andererseits an der Tatsache, dass diese Version für die unterschiedlichsten Systemplattformen geeignet ist. Jabberd 2.x unterliegt, wie schon die Vorgängerversion 1.4.x der GPL ⁸ und ist somit sehr gut geeignet, da nicht kommerziell. Die Reihenfolge der Entwicklung fängt beim Einrichten des Jabberd-Server an, der in das vorhandene System eingebunden wird. Dadurch muss eStudy angepasst werden mit neuen Menüs und Dialogen. Daraufhin wird der Codereviewteil eingefügt.

2.1. Begriffsbestimmung

Kommen wir nun erst einmal zur Begriffsbestimmung der Themenschwerpunkte. Ein Chat ist ein synchrones Kommunikationsmittel zwischen zwei oder mehr Personen, die an unterschiedlichen Plattformen miteinander kommunizieren wollen. Man bezeichnet das Bedienen eines Chats auch „chatten“ ⁹ . Als Mitteilungsmedium wird meist geschriebene Sprache verwendet, manchmal jedoch auch gesprochene Sprache. Im folgenden ist, wenn von „chatten“ die Rede ist, das geschriebene Wort gemeint. Mit „synchron“ ist die Tatsache gemeint, dass innerhalb einer Zeitspanne, die sich in den Grenzen der subjektiven Anforderung der einzelnen Teilnehmer an das System einpendelt, eine Antwort des Gesprächpartners erscheint. Dabei können nur Sekunden vergehen, es können jedoch auch einige Stunden vergehen. Jedoch sollte ein Chat so ausgelegt sein, dass er zeitnahe Kommunikation zulässt. Email - Verkehr ist demgegenüber als asynchrone Kommunikation zu behandeln, da nicht zwangsläufig eine Antwort des Empfängers folgen muss. Im Gegensatz zu Email oder Snailmail im allgemeinen werden beim Chatten keine großen Textmengen am Stück erwartet, sondern eher kleine, kurze Sätze, eben so wie in einer normalen gesprochenen Unterhaltung. Für größere Textmengen oder Dateitransfers wird die Übertragung per Email bevorzugt. Ein Whiteboard ¹⁰ erweitert die Funktionalität des Chattens um den graphischen Aspekt. Während Chatten Informationsaustausch per Text ist, kann man mit Hilfe eines Whiteboards zeitgleich mit anderen Chatteilnehmern mit Hilfe einer geeigneten Applikation Zeichnungen bearbeiten, formatierte Texte überarbeiten und kommentieren, oder Präsentationen betrachten.

⁸ GPL = GNU Public License

⁹ engl. chat = plaudern

¹⁰ engl. = Zeichenbrett

Diplomarbeit Peter Reinhardt

Das Whiteboard bietet eingebaute Funktionen, die die gerade angesprochenen Möglichkeiten zeitnah umsetzt. Ein Codereview-Board ist eine Abwandlung des Whiteboards. Es folgt den gleichen Grundlagen, ist aber nicht für graphische Bearbeitung ausgelegt, sondern dient der gleichzeitigen Bearbeitung von textbasierten Dateien.

Das eStudy-Portal bietet Studenten, Mitarbeitern und Dozenten eine Möglichkeit, zu kommunizieren, die belegten Vorlesungen und Kurse zu verwalten und Foren zu füllen. Bisher existiert in diesem System eine asynchrone Kommunikationsform per Quickmessages, ähnlich dem Emailsystem, bzw. die Option per Forum Nachrichten auszutauschen. Diese Art der Unterhaltung soll erweitert werden durch ein neues Kommunikationssystem.

2.2. Ziel

Das Ziel der vorliegenden Arbeit ist ein System, das per Chat und Whiteboard dem eStudy-Portal eine Ergänzung bietet, die bisher so nicht vorhanden ist. Wie in Kapitel 2.1 angesprochen, existieren derzeit zwei Möglichkeiten der Kommunikation im eStudy-Portal. Einmal besteht die Möglichkeit der Zusendung von Kurznachrichten, das andere System ist das Forum, in welchem man Postings hinterlassen kann, die von allen anderen Berechtigten eingesehen werden können. Berechtigt ist grundsätzlich jeder, der eingetragenes Mitglied des Portals ist, oder aber in der Beschränkung eines Kurses Mitglied ist. In beiden Fällen funktioniert die Übersendung von Informationen an ein Gegenüber nicht zeitkritisch. In beiden Fällen ist nicht gewährleistet, dass der Empfänger der Nachricht jemals auch wirklich diese Nachricht liest. Interessanter ist die Überlegung, ein System zu benutzen, das ähnlich dem Telefon Nachrichten sofort versendet, bzw. nur dann versendet, wenn beide Benutzer online sind und eine Verbindung zwischeneinander mit Hilfe eines geeigneten Werkzeugs aufgebaut ist. Weiterhin soll ein System entstehen, das es Studenten erlaubt, zeitgleich an Dateien zu arbeiten, ohne dabei an einem gemeinsamen Rechner zu sitzen. Die Studenten sollen über das synchrone Nachrichtensystem Softwareentwicklungen diskutieren, die sie dann in einem Codereview-Board umsetzen können.

Diplomarbeit Peter Reinhardt

2.3. Werkzeuge

Als erste Wahl hat sich Jabber, der Server, der Verbindungen für Instant Messaging Systeme verwaltet, durchgesetzt. Er wird benutzt, weil der ausgesuchte Client „Coccinella“ ¹¹ auf Jabber basiert. Coccinella ist interessant, da es bereits einen Chat und Whiteboard integriert hat und auf eine Empfehlung des Bildungsservers Hessen ¹² favorisiert wurde. Coccinella ist fast Betriebssystem-Unabhängig, da es für die gängigsten Betriebssysteme Versionen gibt. Außerdem ist der Quellcode frei verfügbar, sodass man diesen auf dem jeweiligen Zielsystem kompilieren und linken kann. Der benutzte Jabber Server ist „jabberd 2“ ¹³ und ist derzeit in der Version 2.0s9 als Open-Source verfügbar.

2.4. Betriebsumgebung

In der Betriebsumgebung muss man zwischen Client und Server unterscheiden. Der Server läuft auf einem Linux System zusammen mit einem Apache Tomcat Webserver, einem Apache Webserver und einem MySQL Datenbankserver. Clientseitig ist die Plattform nicht fest vorgegeben, allerdings wurde bisher nur auf Windows und Linux getestet.

2.5. Benefit

Für was wird nun dieser Weg der Kommunikation benötigt? Reicht es nicht aus, wie auch auf anderen Portalen im Internet, die Mitglieder mit Email/Quickmail und Forenbeiträgen zu versorgen? Muss es eine dritte Möglichkeit geben, in der die Mitglieder in Echtzeit miteinander kommunizieren können? Die Antwort lautet „Ja“! Die Intention hinter dem eStudy-Portal ist die Idee, ein Kommunikationsportal für Studenten, Mitarbeiter und Dozenten zu schaffen, auf dem Mitglieder gemeinsam beispielsweise an Hausarbeiten arbeiten können, ohne sich aus Ihrer gewohnten und produktiven Lernumgebung fortzubewegen. Das geplante System dient ebenso nicht der Belustigung, sondern hat den ernsthaften und professionellen Hintergrund, Studenten eine virtuelle Lernumgebung anzubieten. Bisher war es im Meinungsaustausch nur möglich, sich Quickmails/Emails zu schreiben, oder im Forum entsprechende Nachrichten zu hinterlassen. Nun bietet sich eine produktive Möglichkeit an, ohne großen Zeitverlust sich online zu verabreden und gleichzeitig an ein und derselben Datei zu arbeiten. Dies kann jederzeit geschehen, auch ohne dass ein oder mehr andere Kommilitonen online sind. Der Chat bietet hier die Möglichkeit, die Veränderungen simultan mitzudokumentieren. Dies hilft zur Nachverfolgung der Änderungen.

¹¹ http://hem.fyristorg.com/matben/

¹² http://portal.bildung.hessen.de/service/hilfen/cocci/

¹³ http://jabberd.jabberstudio.org/2/

Diplomarbeit Peter Reinhardt

2.6. E-Learning

Was ist eLearning, und wie kann das geplante Kommunikationssystem eLearning betreiben oder unterstützen? ELearning ist laut Wikipedia folgendermaßen definiert: „E-Lernen bzw. E-Learning 14 ist Lernen unter Einbezug elektronischer Kommunikationsmitteln und verschiedener Publikationsformen, indem PC, CD-ROM oder das Internet eingesetzt werden.“ Im Fall des eStudy-Portals findet man sich bei PC und Internet wieder. Der PC wird auf jeden Fall benötigt, um das Portal anzeigen zu können und natürlich das Internet, sprich einen graphischen HTMLfähigen Browser. Die Definition ist nun genannt. Aber welchen Nutzen bring E-Learning? Wird es überhaupt benutzt? Wenn ja, wo, wenn nicht, warum basiert dann diese Diplomarbeit auf einem Thema, das uninteressant ist? Viele Fragen nach dem Sinn von E-Learning. E-Learning ist, und das ist eine Tatsache, eine immer weiter expandierende Idee, die gerne von Unternehmen genutzt wird, die ihre Mitarbeiter schulen müssen. Beispielsweise sei hier die Pharmaindustrie genannt, die die Angestellten verpflichtet, bestimmte Trainings zu machen, bevor sie überhaupt anfangen dürfen zu arbeiten. Diese Industriesparte unterliegt solch strenger Auflagen durch die Regierung, dass nur trainierte Mitarbeiter, die wirklich wissen was sie tun, in Bereichen, die gesundheitsrelevant ¹⁵ sind, eingesetzt werden dürfen. Da dies natürlich ein extremer Kostenaufwand ist, alle Mitarbeiter regelmäßig zu schulen, wird zunehmend die persönliche Mitarbeiterschulung in Kursen ersetzt werden durch onlinebasierte, interaktive Kurse. Damit entfällt die aufwändige Vorbereitung des Schulenden auf den Lehrtermin. Er kann somit seine Produktivität ganz auf seine eigentlichen Aufgaben konzentrieren und wird nicht abgelenkt durch Planung, Vorbereitung und Durchführung eines Trainingskurses. Die Angestellten, die geschult werden müssen, werden in Ihrer Arbeit unterbrochen und können nicht selbst bestimmen, wann es ihnen besser passen würde, das Training zu absolvieren.

Hier kommt E-Learning ins Spiel. Ein vorbereiteter Online-Kurs mit den gleichen Inhalten eines mitarbeitergeführten Kurses ist einfacher zu handhaben und ergänzt die Produktivität eines Angestellten. Statt fester Termine steht dem Lernenden nun die Freiheit zu, selber zu bestimmen, wann er einen Trainingskurs besuchen will. Das heißt, in Zeiten wo nicht besoonders viel Arbeit anliegt, kann er diese nutzen, um sich den Sachverhalt bestimmter, für ihn relevanter Trainingseinheiten anzueignen. Der große Vorteil dieser Art des Lernens ist der, dass man jederzeit die Möglichkeit hat, wieder auf Trainingsinhalte zurückzugreifen, die man nicht mehr bis ins letzte Detail im Kopf hat.

Für bestimmte Arbeitsbereiche ist diese Form des Lernens natürlich nicht sinnvoll, aber für Arbeiten am Schreibtisch, wie etwa die Unterweisung für die Arbeit mit einer neuen Software, bietet sich das E-Learning auf jeden Fall an.

Um noch einmal auf den Faktor Finanzen bei Schulungen zu kommen. Es ist bewiesen, dass ein einmalig erstellter E-Learning-Kurs zwar in der Anschaffung

¹⁴ englisch electronic learning - elektronisch unterstütztes Lernen

¹⁵ GMP - Good Manufacturing Practices, staatlich überwachte Produktionsbereiche, die direkt mit der Gesundheit von Menschen zu tun haben, streng beobachtet werden müssen.

Diplomarbeit Peter Reinhardt

erheblich teurer ist als die Schulung mehrere Mitarbeiter, aber sobald das E-Learning-System eines Unternehmens mit den entsprechenden Kursen vollständig ist, wird bares Geld gespart. So müssen keine externen Schulungen mehr angeboten werden und die Mitarbeiter des eigenen Hauses müssen keine Kurse mehr vorbereiten und können sich stattdessen voll auf ihre Arbeit konzentrieren.

Eine andere Facette des E-Learning ist das gemeinsame Lernen, was das konventionelle Moderationsschema mit den Möglichkeiten der synchronen Kommunikation über weite Entfernungen verbindet. Auf dieser Idee basiert das eStudy-Portal mit der in dieser Arbeit beschriebenen Einführung von E-Learningmitteln Chat, Whiteboard und Codereview-Board.

2.7. Codereview

Das neue System wird neben der Instant Messaging Kommunikation auch ein weiteres synchrones Medium beinhalten, das es Anwendern ermöglicht, gleichzeitig auf einem webbasierten Werkzeug Textdateien zu editieren. Die Anwendung wird aufgebaut als Teil des eStudy-Portals und wird in PHP mit Zugriff auf eine MySQL Datenbank und HTML realisiert. Die Überlegung war zunächst, ob man das Codereview Werkzeug als Erweiterung des gewählten IM Clients Coccinella erstellt. Jedoch hat sich die Idee durchgesetzt, das Codereview-Board als weiteres Modul in das eStudy Portal einzubinden. Dies hätte zur Folge gehabt, dass das Werkzeug auch außerhalb eStudy funktioniert, jedoch würde in den alten Strukturen von Tcl/Tk programmiert, die nicht mehr zeitgemäß sind. Aus diesem Grund hat sich die Idee durchgesetzt, die Implementierung in PHP zu entwerfen und das Werkzeug als weiteres Modul in eStudy einzubinden. Jedoch hat sich die Idee durchgesetzt, das Codereview-Board als weiteres Modul in das eStudy Portal einzubinden.

Diplomarbeit Peter Reinhardt

3. Software

Für die Arbeitsumgebung auf dem Server ist es nötig, eine Menge an Software zu kompilieren und zu installieren. Die folgenden Schritte geben darüber Auskunft, welche Software wie zu handhaben ist, damit alle Pakete am Ende Hand in Hand zusammenarbeiten und keine Systemabstürze auftreten. Zunächst muss ein Linux-PC vorbereitet werden mit einem C-Compiler, der die benötigten Pakete für das System verarbeitet. Zweitens muss das System die Mindestvorraussetzungen erfüllen, die für ein störungsfreies und schnelles Arbeiten stehen. Empfehlenswert ist also ein aktueller PC mit einem oder zwei Prozessoren, 2 GB RAM und etwa 10 GB freien Plattenplatz für die spätere Ablage von Log-Dateien und Nutzerdaten.

3.1. Apache Webserver

Der Apache Webserver ¹⁶ wird nur benötigt für die Installation und Konfiguration des Jabber-Servers auf der Zielmaschine und natürlich zum Hosten des eStudy-Portals verwendet. Für den Client wird keine Installation benötigt. Apache hat den Vorteil, dass dieser Server Open Source ist und für die verschiedenen Betriebssysteme verfügbar ist. Bei der Installation sollte darauf geachtet werden, dass PHP mitinstalliert wird. Zusätzlich zum Standard - Apache Server muss noch eine Instanz des Apache Tomcat laufen, die Java Servlets unterstützt.

3.2. MySQL Datenbank Server

Ebenso wie der Apache Webserver muss auch der MySQL ¹⁷ - Server nur auf der Zielmaschine des Jabber-Servers installiert werden. Der MySQL - Server sollte entweder per phpMyAdmin oder über die Funktionalitäten eines Webmin Frontend administriert werden können. Die vorliegende Arbeit wurde zu 95% per phpMyAdmin konfiguriert.

3.3. XAMPP

XAMPP ¹⁸ ist ein Paket der Apachefriends.org bestehend aus Distributionen von Apache, MySQL, Perl, PHP, das für die Entwicklung der vorliegenden Arbeit eine maßgebliche Rolle gespielt hat. Die Einfachheit der Installation der zur Entwicklung benötigten Pakete war ausschlaggebend in der Wahl dieses Produktes.

¹⁶ http://www.apache.org

¹⁷ http://www.mysql.com

¹⁸ XAMPP = Von LAMPP, bzw. WAMPP abgewandelt. Das X steht für das jeweilige Zielsystem. A = Apache, M = MySQL, P = Perl, P = PHP

Diplomarbeit Peter Reinhardt

4. Jabberd 2 Server

4.1. Jabber

Ähnlich den proprietären Systemen von AOL, also AIM und ICQ bietet auch Jabber ein Instant Messaging System an. Gegenüber den kommerziellen Anwendungen ist Jabber jedoch frei erhältlich und öffentlich verfügbar. Man darf jedoch Jabber nicht als Firma verstehen, die ein Instant Messaging Produkt vertreibt. Jabber ist öffentlich. Jeder kann sich des bisherigen Entwicklungsstandes bedienen und eine eigene Serverimplementierung aufbauen. Jabber wurde 1998 von Jeremie Miller entworfen und ist inzwischen eine stabile Lösung, dank hunderter von Entwicklern, die das Jabber-Projekt immer weiter vorantreiben.

Eine Jabber-Instant-Messaging-Lösung kann mehrere Kommunikationsmethoden beinhalten. Es ist möglich einen einfachen Chat zu betreiben, aber auch Dateiaustausch, Kollaborationswerkzeuge oder Spiele können in der entsprechenden Umgebung einfach eingearbeitet werden. Eine interessante Möglichkeit der Jabber Technologie ist die der sogenannten „Transports“, die eine Kommunikation über die Grenzen eines Jabber-Netzes hinaus zu proprietären Netzen wie ICQ, MSN, AIM oder YIM zulässt. Der Nutzer meldet sich am Jabber-Server an, übergibt diesem seine Benutzerinformationen für eines der anderen Netze, so zum Beispiel derer von ICQ. Vorraussetzung ist natürlich, dass der Nutzer eingetragenes Mitglied bei einem der anderen Dienste ist. Der Jabber-Server meldet dann den Nutzer, ohne dessen weiteres Zutun an dem entsprechenden Fremdnetz an und interagiert sozusagen als Übersetzer zwischen dem proprietären Netz und dem eigenen Jabber-Netz. Die Grundlage für diese verschiedenen Möglichkeiten der synchronen Kommunikation liegt im XMPP, dem „Extensible Messaging and Presence Protocol“ (Erweiterbares Nachrichten und Präsenz Protokoll). XMPP wurde von der IETF ¹⁹ als Standard des „XML Streaming for instant messaging and presence protocol“ definiert.

4.2. XMPP

XMPP, das „Extensible Messaging and Presence Protocol“ ist laut IETF in der RFC3920 ²⁰ und RFC3921 ²¹ folgendermaßen definiert: „Ein Protokoll für die Extensible Markup Language (XML) für strukturierten Informationsaustausch in zeitnahem Umfeld zwischen zwei Netzpunkten. Während XMPP verallgemeinerte, erweiterbare Rahmenbedingungen für den XML Datenaustausch anbietet, wird es hauptsächlich für Zwecke des Aufbaus von Instant Messaging Systemen und Verfügbarkeitsanwendungen genutzt, die auf dem RFC2779 ²² basieren. Das Protokoll bietet die Möglichkeit per XML nicht nur Text zu kapseln und

¹⁹ IETF = Internet Engineering Task Force

²⁰ RFC3920 - http://www.ietf.org/rfc/rfc3920.txt

²¹ RFC3921 - http://www.ietf.org/rfc/rfc3921.txt

²² RFC2779 - http://www.ietf.org/rfc/rfc2779.txt

Diplomarbeit Peter Reinhardt

auszutauschen, sondern ebenfalls andere Medien wie Bilder, Töne oder Animationen. XMPP erlaubt es den Instant Messaging Anwendungen also, graphische Whiteboards, Chats und Konferenzräume zu implementieren. Aus diesem Grund wird diese Technologie für die Zwecke des Aufbaus eines synchronen Kommunikationsmedium für das eStudy Portal genutzt.

4.3. Entscheidungsfindung für Jabber-Version

Mittlerweile existieren mehrere dutzend verschiedene Jabber - Versionen. Einige davon sind in der unteren Tabelle dargestellt. Unterschiede gibt es in der Lizenzierung. Manche sind kommerziell, andere unterliegen der GPL. Für das geplante System sind jedoch nur zwei Versionen in die engere Auswahl gekommen. Jabberd 1.4 und Jabberd 2.0. Beide Versionen haben eine ausführliche Dokumentation und bieten sich allein aus diesem Grund an, für Neulinge auf diesem Gebiet ausgewählt zu werden. Außerdem gibt es seit Version 1.4 die Unterstützung des Multiuserchats (MUC), also die Grundvorraussetzung für den Lehrbetrieb. Da Version 1.4 jedoch keine Datenbankanbindung bietet, wurde die Version 2.0, eine Weiterentwicklung der Version 1.4, gewählt. Diese bietet eine ausgereifte Datenbankanbindung für SQL, PostGreSQL und weiteren Datenbankarchitekturen. Der einzige Wermutstropfen ist jedoch die noch nicht ganz ausgereifte Einbindung einer MUC-Lösung. Um trotzdem eine Möglichkeit für Konferenzen zu schaffen, bedarf es einer etwas hakeligen Einbindung der MUC-Lösung aus der alten Version 1.4 in die neuere Version.

4.4. Jabberd 2 Installation

Um eine lauffähige Version eines Jabberd 2 Servers zu erhalten, bedarf es einigen Schritten der Installation und Konfiguartion. Für ausführliche Details zur Installation darf auf die offizielle Seite der Jabberd 2 Implementierung verwiesen werden ²³ . Die im folgenden benutzte Version ist 2.0s8 ²⁴ . Es wird stattdessen auf jene Teile ein erhöhtes Augenmerk gelegt, die einer besonderen Aufmerksamkeit bedürfen. Als Vorraussetzung einer gelungenen Installation ist die Erstellung eines neuen Nutzers namens „jabberd2“, der wie folgt erstellt wird.

4.4.1. Libidn

Die erste Hürde betrifft das externe Paket Libidn ²⁵ . In früheren Versionen war es noch Bestandteil des Jabberd 2 Pakets, aber aus Lizenzgründen wurden die Distributionen getrennt. Für die Installation von Jabberd 2 muss mindestens die Version 0.3.0 installiert werden. Im folgenden wird mit Version 0.5.9 gearbeitet. Das Libidn Paket wird entpackt und per „configure“ und „make“ installiert. Jabberd 2 kann dann darauf zugreifen.

²³ Jabberd 2 Installationsdokumentation - http://jabberd.jabberstudio.org/2/docs/jabberd_guide.html

²⁴ Jabberd 2 Installationsdateien -

http://jabberstudio.org/projects/jabberd2/releases/download.php?file=jabberd-2.0s8.tar.gz

²⁵ Libidn Releases: „http://josefsson.org/libidn/releases/“

Diplomarbeit Peter Reinhardt

4.4.2. MySQL

Die von Jabberd 2 empfohlene Datenhaltung ist MySQL. Da auch das eStudy-Portal auf einer MySQL - Datenbank basiert ergänzen sich die beiden Systeme bereits hier. Für die spätere Raumkonfiguration ist diese Situation sehr vorteilhaft. Jabberd 2 wird entpackt und mit bestimmten Schaltern konfiguriert. Dies sind in diesem Fall „-enable-mysql“ und „--enable-idn“.

4.4.3. Jabberd 2 fertigstellen

Nachdem die Konfiguration abgeschlossen ist, wird Jabberd 2 mit „make“ und „make install“ compiliert und installiert. Nach der geglückten Installation bedarf es noch einer Rechtezuweisung auf die ausführbaren Dateien, sodass diese nur vom eigentlichen „jabberd2“-User aufgerufen werden können. Dies hilft gegen potentielle Hackangriffe, die bei Erfolg nur einen Benutzer ohne Administratorrechte erhielten. Genauso soll es ausgeschlossen werden, dass niemand anderes die Konfiguartionsdateien, aus der der jabberd-Prozess seine Daten bezieht, verändern kann.

4.5. Pkgconfig

Pkgconfig ist ein Paket, auf das GLib aufbaut, auf dem wiederum die Jabber Component Runtime basiert, die eine Schnittstelle darstellt zwischen der MUC-Version, die eigentlich für die Jabberd Version 1.4 ist aber mit dieser Funktion auch mit der Version 2 des Jabberd Servers funktioniert. Pkgconfig ist erhältlich auf „http://pkgconfig.sourceforge.net“. Dieses Werkzeug hilft bei der Erstellung von Bibliotheken und Anwendungen, indem es bestimmte Pfade in die Kompilierung mit einbindet. Ein Beispiel hierfür wäre:

4.6. GLib

In der Version 2.2.3 wird GLib benötigt, um die Installation von JCR vorzubereiten. GLib ist eine Bibliothek, die benötigte Datentypen, Makros, Typkonversionen und sonstige nützliche Helferlein zur Verfügung stellt, die von anderen Quellcodedateien genutzt werden sollen. GLib ist unter „ftp://ftp.gtk.org/pub/gtk/v2.2/“ erhältlich. GLib muss mit „gmake“ und „gmake install“ erstellt werden.

Diplomarbeit Peter Reinhardt

4.7. Jabber Component Runtime

Nachdem nun die Vorraussetzungen für die Einbindung des alten MultiUserChat-Systems gesetzt worden sind, müssen noch weitere Softwarepakete zusammengetragen und auf dem Zielsystem konfiguriert, compiliert und installiert werden. Die JCR ²⁶ stellt dabei die Schnittstelle zwischen den beiden Jabber Versionen dar. Leider ist auch diese Version erst in der Ausgabe 0.2.4 verfügbar, sodass noch einige Fehler in der Programmlaufzeit auftreten, die erst durch manuell eingefügte Patches getilgt werden können. Hierzu müssen die Änderungen der Dateien „jcr-0.2.4-log-patch“, „patch-jcr024-mforssen“ und „patch-jcr024-memleak“ in den Quellcode von JCR eingepflegt werden. Die Patches sind unter „http://www.marquard.net/jabber/“ erhältlich. „jcr-0.2.4-log-patch“ fordert einen Zeitstempel an für jeden Logeintrag. Dies hilft beim Nachvollziehen der auf dem Server ablaufenden Routinen im Fehlerfall. Standardmäßig wird ein Logeintrag ohne Zeitstempel gesetzt. „patch-jcr-024-mforssen“ umgeht den Absturz nach einer unbekannten Nachricht. Zuletzt wirkt sich „patch-jcr024-memleak“ positiv gegenüber eines Speicherlecks aus und bereinigt diesen Fehler. Nach Einarbeitung der diversen Änderungen kann das JCR-Paket nun per Make-Routine erstellt werden.

4.8. Multi User Chat

MUC ²⁷ ist die Möglichkeit, mit mehreren Jabber-Nutzern gleichzeitig in einem gemeinsamen Chat- oder Konferenzraum über Texteingabe zu kommunizieren. Die Multi User Chat Architektur bietet diverse Einstellungsmöglichkeiten, den Raum so zu konfigurieren, dass er z.b. persistent ist, oder nicht öffentlich. Einzelheiten zu den Einstellungen sind in Kapitel 7.4.1 beschrieben. Im folgenden wird die Installation der zum Zeitpunkt dieser Arbeit aktuellen Version 0.6.0 erläutert. Das heruntergeladene Paket wird im Verzeichnis der JCR entpackt. Nun müssen die Datei „main.c“ und „jcomp.mk“ aus „jcr/src“ in das eben erstellte Verzeichnis „mu-conference-0.6.0“ kopiert werden. Vor dem kompilieren muss auch in diesem Paket noch manuell gearbeitet werden, um ein paar Patches zu integrieren. Benutzer des späteren Systems sollen natürlich nicht in der Lage sein, ihren zugewiesenen Benutzernamen ändern zu können. Es soll immer nachvollziehbar sein, wer welche Nachricht geschrieben hat. Dies beugt der Patch „patch-locknicks-v2“ vor. Er sorgt dafür, dass in Konferenzräumen der Nutzername nicht getauscht werrden kann. Ein zweiter Patch, „patch-muc-confroom“ verhindert den Softwareabsturz aus der Situation heraus, in der ein Raumkonfigurationsformular angefordert wurde, obwohl der das Formular aufrufende Benutzer der entsprechende Nutzer noch nicht den Raum betreten hat.

²⁶ Jabber Component Runtime - JCR - http://jabber.terrapin.com/

²⁷ Multi User Conference - MUC - http://mu-conference.jabberstudio.org/

Diplomarbeit Peter Reinhardt

5. Konfiguration des Jabberd 2 Servers

Im XMP Protokoll ist beschrieben, dass Instant Messaging Systeme über einen XML Datenaustausch Informationen von einem Netzknotenpunkt an einen anderen senden. Da Jabber eben auf diesem Protokoll aufbaut, sind alle Datenströme, die zwischen einem Client und dem Jabber-Server transferiert werden, in XML gekapselt. Für die Konfiguration selber, das heißt für die Initialisierung des Jabber-Servers bedarf es einiger Einstellungen, die in XML-Dateien abgelegt werden. Beim Start des Servers werden nun diese Dateien ausgelesen und in den Prozess eingebettet.

5.1. Konfiguration der C2S.XML - Client/Server Konfiguration

Die Datei c2s.xml konfiguriert die Interaktion zwischen Client und Server und enthält die Einstellungen für die Kommunikationsbedingungen. So wird etwa der Listening Port eingetragen, auf dem der Server eine Anfrage eines Clients annimmt, die höchste Anzahl von Wiederholungen, bevor ein Fehler gesendet wird und wie der Server nach außen hin benannt wird. Im aktuellen Fall hört der Server auf den Namen „juno.mni.fh-giessen.de“. Anhand der folgenden Ausschnitte wird die Bedeutung der c2s.xml deutlicher.

5.2. Konfiguration der MUC-JCR.XML / Konferenzraum Konfiguration

Die aus dem Kompilationsvorgang für MUC - Unterstützung hervorgegangene „MUC-JCR.XML“ beschreibt die Konfiguration für den Multi - User - Conference -Prozess. Diese XML-Datei wird eingebunden, wenn der Prozess gestartet wird. MUC-JCR.XML ist so konfiguriert, dass es auf Port 5347 auf Verbindungen wartet. Durch einen Patch wurde es den Benutzern der Konferenzräume verboten, Ihren Nicknamen, das heißt, der Name, der in der Konferenz benutzt wird zu ändern. Dies regelt man durch den Eintrag „“ im Bereich

„“. Leider unterstützt MUC-JCR noch keine Sicherung in Datenbanken, deshalb ist es noch wichtig, die Pfade einutragen, in denen der Prozess die Protokollierung der einzelnen Räume ablegt.

5.3. Belegung der erlaubten Jabberd-Benutzer in router-users.xml

Diese Datei teilt dem System mit, welche Benutzer den Router benutzen dürfen. Dies ist für die Trennung zwischen Funktionsdaten und Zugangsdaten gedacht. Es können mehrere User angelegt werden, die dann jeweils durch die Tags „“ getrennt gelistet werden.

5.4. Schnittstelle zwischen Jabberd und MUC in router.xml

Der Router des Jabber - Servers stellt den Backbone des Systems dar. Alle Komponenten wenden sich an dieses Subsystem um kommunizieren zu können. Aus diesem Grund ist die router.xml die wichtigste Konfigurationsdatei. Beispielsweise greift der MUC auf diese Datei zu und verbindet damit sich und den Jabberd-Prozess. In folgender Tabelle werden die wichtigsten Einstellungen erläutert.

5.5. Konfiguration des Sessionmanagers in sm.xml

Der Sessionmanager überwacht die Login-Versuche und die eingeloggten Jabber-Nutzer. Hierzu ist ebenfalls eine Konfiguration nötig. Je nachdem, welche Datenhaltung in 5.1, der c2s.xml definiert ist, wird hier bestimmt, wie der Sessionmanager auf die Daten zur Laufzeit zugreifen kann. In dieser Arbeit wurde mit „mysql“ gearbeitet.

5.6. Jabber mit Multi User Chat starten

Erst wenn alle Konfigurationsdateien sorgfältig und korrekt bearbeitet sind, kann man sich dem Startverhalten des Servers nähern. Bei den Einstellungen ist höchste Sorgfalt Pflicht, da schon kleine Ungereimtheiten den Server daran hindern ordnungsgemäß zu starten und zu funktionieren.

Wie oben bereits erwähnt, stellt die Jabberd 2 Implementierung keine eigene Konferenzoption zur Verfügung, sodass eben das Altsystem der Jabberd 1.4 Version genutzt wird. Dies erkennt man nun auch am Startablauf. Man startet zuerst den normalen Jabber - Server und ruft dann in einem eigenen Prozess den MUC-Dienst auf. Gut zu sehen ist dies in der folgenden Abbildung 1. Zur Übersicht, welche Prozesse mit dem laufenden Jabberd 2 Server zusammenarbeiten, wurde noch „ps“ ausgeführt.

6. Interaktion von Jabberd, eStudy, einem Chat-Client und

dem Code Review-Modul

6.1. Jabberd Authentifizierung

Die Authentifizierung eines Versuchs der Anmeldung an einem Jabberd - Server erfodert mehrere Schritte. Ein Nutzer des eStudy-Portals meldet sich an diesem an. Es kommt nicht darauf an, ob er dies zum ersten mal tut, oder ob er bisher schon das Portal genutzt hat. Er definiert in seinem Profil das Passwort, mit dem er sich über einen Jabber - Client am vorbereiteten Jabberd - Server anmelden kann. Das Passwort ist nicht das LDAP - Passwort, sondern kann getrennt von dem Zugangspasswort für andere Dienste an der FH Gießen gesetzt werden. Wenn er ein Passwort gewählt hat, werden zwei neue Datensätze in der benutzten Datenbank angelegt. Einmal für die eStudy-interne Benutzerverwaltung und zweitens in der Tabelle, aus der der Jabberd-Server seine Informationen bezieht. Der Benutzer meldet sich wie gehabt an einem Kurs an und wartet auf die Bestätigung zum Eintreten. Mit dieser Bestätigung kommt, falls vom Dozenten gewollt, eine Einladung zu dem zum Kurs gehörenden Multi-User-Chatraum. Nun kann der Benutzer auf das Codereview-Modul zugreifen, sofern der Besitzer des Kurses dieses Modul erlaubt hat und ist Mitglied in dem für den Kurs eingerichteten Konferenzraum.

6.2. MUC-Raum Konfiguration

6.2.1. Konfiguration des MUC-Raums

Bevor ein Benutzer des Instant Messaging Dienstes Zugriff auf einen

Konferenzraum bekommt, bedarf es einiger Datenbankabfragen und Nachrichtensendungen. So wird nach Abschluss der manuellen Konfiguration, sprich dem Anhaken von Einstellungsmöglichkeiten (siehe 7.4), dem Setzen der maximalen Benutzerzahl und der Definition eines Passworts eine Nachricht an den Jabberd-Server versandt und Einträge in der Datenbank gesetzt.

Diplomarbeit Peter Reinhardt