Das Praktikum besteht aus zwei Teilen: Ziel des ersten Teils ist es, anhand einer einfachen Anwendung, die nach dem Client/Server-Modell in Java implementiert werden soll, praktische Erfahrungen mit verschiedenen Ansätzen zur Kommunikation in verteilten Systemen zu sammeln. Im zweiten Teil wird ein Peer-to-Peer-basiertes Chatsystem, wie es im vergangenen Praktikum entworfen wurde, weiter entwickelt, gemeinsam die Spezifikation entsprechend ergänzt und schließlich implementiert. Dabei sollen Anforderungen diskutiert, das Protokoll "verfeinert" und Sicherheitsaspekte berücksichtigt werden. Die Programmierung im ersten Teil erfolgt in Java. Im zweiten Teil können Sie die Programmiersprache selbst wählen.
Es sind alle Aufgaben in der angegebenen Reihenfolge und bis zu den angegebenen Terminen zu bearbeiten, d.h. es darf nicht etwa Aufgabe 1.1 ausgelassen oder verschoben werden, weil man der Ansicht sein könnte, man könne sie sich sparen, da Aufgabe 1.2 darauf aufbaut.
Wenn Sie weitere Herausforderungen über das Geforderte hinaus suchen :-), können Sie sich einige vorgeschlagene "Optionen" zu beiden Teilen anschauen und versuchen, Ihre Implementierung entsprechend zu ändern oder im Gespräch mit Ihrem Hiwi oder den Assistenten diese oder andere Aspekte diskutieren. Legen Sie aber stets zunächst das Hauptaugenmerk auf die grundlegenden Anforderungen. Unwichtig sind im Rahmen dieses Praktikums dagegen Dinge wie z.B. ein besonders hübsches User-Interface mit viel Plüsch.
Die Abnahme der Aufgaben findet in kleinen Kolloquiumsgesprächen mit Ihrem Hiwi im Rechner-Pool statt. Dabei müssen alle Teilnehmer Ihrer Gruppe anwesend sein, da auch alle zum Aufbau und zur Funktion Ihrer Lösungen und zu den verwendeten Mechanismen befragt und letztenendes einzeln bewertet werden. Sollte es einmal ausnahmsweise zu einer Verzögerung bei der Bearbeitung einer Aufgabe kommen, teilen Sie dies Ihrem Hiwi frühzeitig (mindestens 3 Tage vor Ablauf der Aufgabe) mündlich oder per EMail mit.
Wenn Sie grundlegende Probleme bei der Bearbeitung haben, sprechen Sie ebenfalls frühzeitig mit Ihrem Hiwi oder fragen Sie ihn per EMail. Benutzen Sie insbesondere auch die gemeinsame Mailingliste zum Praktikum (siehe Webseite) in der Sie inhaltliche Fragen mit anderen Praktikumsteilnehmern, den Hiwis und den Assistenten diskutieren können. Genieren Sie sich nicht. Wer fragt lernt mehr!
Im ersten Teil des Praktikums sollen Sie ein Programm zur Berechnung von Fraktalen in Java implementieren. Nach einer einführenden Single-Process Variante sollen Sie aus ihrem System verschiedene Formen verteilter Systeme ableiten, indem Sie verschiedene Mechanismen zur Kommunikation einsetzen. Machen Sie sich Gedanken zu den Aspekten Skalierbarkeit, Fehlertoleranz, DoS-Sicherheit. Diese müssen nicht alle zwangsläufig im Detail umgesetzt werden, sollten aber zumindest in den Kolloquiumsgesprächen diskutiert werden. Messen Sie ferner für die implementierten Ansätze bei gleichen Mandelbrotmengen-Parametern das kommunizierte Datenvolumen, die Gesamtlaufzeit und den Speicheraufwand.
Zunächst sollen Sie ein einfaches Java-Programm zur Berechnung und Anzeige von Fraktalen (vorzugsweise nach der Mandelbrotmenge, Dokumentation, Kapitel 5.3.1) erstellen. Das Programm soll die Eingaben der notwendigen Parameter (nmax, Koordinaten von G) erlauben und die errechnete Zugehörigkeit der Punkte in G zur Mandelbrotmenge grafisch anzeigen. Durch Anklicken von zwei Punkten bzw. Aufspannen eines Ausschnittes soll die Neuberchnung für ein Teilgebiet möglich sein.
Es ist ratsam, beim Entwurf dieses Programms bereits an die folgenden Aufgaben zu denken und die Berechnung für ein gegebenes Gebiet in eine separate Klasse zu kapseln.
Ausgehend von Ihrem Programm aus Aufgabe 1.1 soll nun die Berechnung der Punkte in ein separates Server-Programm ausgelagert werden. Dieser Compute-Server soll mehrfach im LAN gestartet werden. Das aus Aufgabe 1.1 entwickelte Client-Programm soll in der Lage sein, meherere dieser Compute-Server zur Berechnung von Teilgebieten zu benutzen und diese Teillösungen zur Gesamtlösung zusammenzusetzen.
Zur Kommunikation zwischen Client und Servern sollen TCP-Sockets oder UDP-Sockets (ggf. mit Multicast) benutzt werden. Wie die Daten eines Berechnungs-Requests und einer Response in Nachrichten oder Datagrammen kodiert werden, sollen Sie selbst entscheiden.
Wie Aufgabe 1.2. Jedoch soll zur Kommunikation der entfernte Methodenaufruf einer Service-Klasse per CORBA benutzt werden. Dazu muss zunächst die Dienstschnittstelle mittels CORBA-IDL spezifiziert werden und das System als CORBA Dienst und Client implementiert werden.
Wie Aufgabe 1.2. Jedoch soll zur Kommunikation der entfernte Methodenaufruf mittels SOAP benutzt werden. Entscheiden Sie selbst, ob Sie zunächst die Schnittstelle mittels WSDL beschreiben wollen und anschließend entsprechende Service- und Client-Programme entwickeln, oder ob Sie erste Ihre Java Service Klasse entwickeln, aus der Sie die WSDL-Beschreibung ableiten. In jedem Fall sollten Sie aus der WSDL-Beschreibung den Client ableiten.
Als SOAP Toolkit steht Ihnen Apache AXIS zur Verfügung (User's Guide). Diverse Tools, die die Entwicklung von SOAP basierten Anwendungen unterstützten (WSDL2Java, Java2WSDL, TcpMonitor) sind bereits integriert. Axis ist als Servlet implementiert und benötigt daher eine Servlet Engine. Für Testzecke (z.B. dieses Praktikum) gibt es den SimpleAxisServer, der diese Funktionalität übernimmt und mittels
java org.apache.axis.transport.http.SimpleAxisServer -p 8080
gestartet wird. Basisverzeichnis für das Deployment ist das Verzeichnis, aus dem der SimpleAxisServer gestartet wurde.
Diskutieren Sie bei der Abnahme mit Ihrem Hiwi alle drei realisierten Ansätze, insbesondere anhand der von Ihnen gemessenen Daten. Wann sind welche Ansätze zu bevorzugen?
Im zweiten, längeren und auch wesentlich umfangreicheren Teil des Praktikums soll ein Chat-System, das im Praktikum des vergangenen Jahres entworfen wurde, in seiner Spezifikation weiter verbessert und anschließend implementiert werden. Dabei gibt es ein paar Besonderheiten im Vorgehen und in den technischen Anforderungen.
Ein Chat-System erlaubt die Kommunikation innerhalb einer Gruppe von Personen durch den synchronen fortlaufenden Austausch von Text-Nachrichten, die von jeder Person geschrieben und an alle Teilnehmer einer Gruppe verteilt werden. Personen werden durch (hier EMail-)Adressen und Gruppen durch sog. Kanäle identifiert. Typische Chat-Programme präsentieren sich grafisch oder textbasiert meist mit einem großen Bereich, in dem die empfangenen (und selbst gesendeten) Nachrichten fortlaufend angezeigt werden, und einem kleinen Bereich, in dem eigene Nachrichten eingegeben werden.
Was das in diesem Praktikum zu entwickelnde Chat-System technisch von den meisten anderen Systemen unterscheidet, ist die Tatsache, dass es nicht auf einem zentralen Server (oder mehreren) beruht. Stattdessen sind alle "Knoten" im Netz der Chat-Teilnehmer gleichwertig. Sie erfüllen - abgesehen von Ihren unterschiedlichen Implementierungen - alle potentiell dieselben Funktionen. Es handelt sich also um eine Peer-To-Peer-Architektur und nicht um eine Client/Server-Architektur.
Die Programme, die von jeder einzelnen Praktikumsgruppe entwickelt werden, sollen am Ende des Semesters auch untereinander kommunizieren können. Es genügt also nicht, seine eigenen Überlegungen umzusetzen und mehrere Instanzen desselben Programms mittels eines eigenen Protokolls kommunizieren zu lassen. Stattdessen muss eine Phase der gemeinsamen Protokollspezifikation vorweggehen (Aufgabe 2.1). In diesem Fall gehen wir von einer (aus dem PVS 2003) gegebenen Spezifikation aus und wollen diese noch etwas optimieren. Das so spezifizierte Protokoll wird anschließend von allen Gruppen implementiert (Aufgabe 2.2).
Die Programmiersprache, in der Sie Ihr Chat-Programm implementieren, können Sie frei wählen. Sollten Sie sich hier für Java oder C entscheiden, können Sie damit rechnen, dass Ihre Hiwis und Assis Sie bei eventuell auftretenden Fragen oder Schwierigkeiten gut unterstützen können. Sollten Sie sich für eine "exotische(re)" Realisierung entscheiden (Perl, Python, Assembler, Ada, Caml, Emacs Lisp, ...), so ist das ebenfalls sehr willkommen, Sie sollten aber damit rechnen, bei Problemen ggf. auf ihren eigenen sportlichen Umgang mit Dokumentationen oder sonstigen Ressourcen angewiesen zu sein. Außerdem sollten Sie dann rechtzeitig prüfen, ob ggf. notwendige Software-Bibliotheken, etwa für die Socket-Kommunikation und die Verschlüsselung und Signierung von Nachrichten, verfügbar und hinreichend funktional sind.
Fragen jeder Art und in jeder Phase der Bearbeitung, z.B. Fragen zum Verständnis, Diskussion angedachter Lösungen, Suche nach Java-Klassen, C-Funktionen oder Bibliotheken mit bestimmter Funktionalität, organisatorische Fragen, etc., werden auf der Mailingliste besprochen. Dies dient dem fairen Austausch von Informationen unter allen Teilnehmern und Betreuern.
Im ersten Schritt geht es darum, die Anforderungen genau zu verstehen und zu konkretisieren. Dazu dient die "alte" Ausgangsspezifikation der Architektur und des Protokolls (draft-strauss-p2p-chat-03.txt) und die nachfolgend aufgeführten weiteren Anforderungen für Ihre Implementierung. Bitte machen Sie sich diese Trennung zwischen allgemeiner Spezifikation und implementierungsspezifischer Dokumentation deutlich. Ihre Situation ist vergleichbar mit der eines Software-Unternehmens, das eine Chat-Software entwirft und zugleich durch Standardisierungsarbeit Interoperabilität mit anderen Implementierungen anstrebt. Sie sollten sich in dieser Phase auch bereits Gedanken über mögliche Realisierungen und potentielle Probleme machen und diese Überlegungen niederschreiben.
Spezifikation:
Entwurf / Implementierung:
Es gibt eine Menge von Fragen, die Sie in dieser ersten Aufgabe zu klären haben. Hier nur ein kleine Auswahl...
Erstellen Sie im Rahmen der Aufgabe 2.1 ein Dokument, in dem Sie
Schicken Sie dieses Dokument bis zum angegeben Stichtag als Text-File oder PDF per EMail an pvsadm@ibr.cs.tu-bs.de.
An diesem Termin werden wir gemeinsam mit allen Gruppen ein großes "Entwicklertreffen" abhalten. Darin werden wir der ersten Teile Ihrer Dokumente, also die Vorschläge zur Überarbeitung der Protokoll-Spezifikation, diskutieren und uns (hoffentlich) auf ein überarbeitetes vollständiges und realisierbares Konzept einigen. Die Ergebnisse dieses Kolloquiums werden dann ca. eine Woche später als neue Spezifikation in Form eines neuen Internet-Drafts von den Assis zur Verfügung gestellt. Diese Arbeit entspricht somit etwa der Arbeitsweise von Arbeitsgruppen (Working Groups) der IETF.
Nun gilt es, die gemeinsam entworfene Spezifikation des Protokolls in eine individuelle Implementierung zu verwandeln. Wir empfehlen Ihnen, in einem Top-Down-Verfahren zunächst einen groben Entwurf ihrer Module bzw. Klassen vorzunehmen, deren Schnittstellen zu klären und dann in einer für Ihre Team-Arbeit angemessenen Weise die aufgaben-verteilte Detaillierung und Implementierung voranzutreiben. Die Termine für die Zwischenabgaben sind unbedingt einzuhalten. Dies dient der Sicherstellung, dass Sie auf dem richtigen Weg sind und bleiben. Außerdem werden sich sicherlich Möglichkeiten entwickeln, gemeinsam mit anderen Gruppen bereits im Laufe der Implementierungsphase die Interaktion der verschiedenen Realisierungen zu testen, so dass die Kolloquien zur endgültigen Abgabe in der letzten Semesterwoche dann möglichst wenige Überraschungen bringen.