Projekt FTraQ - File Transfer Queue

Link zur Projekthomepage

Projektbeteiligte und Zuständigkeiten

Steffen Sauder - FTP-Protokollfunktionalität und logisches Dateisystem
Alexander Jasse - Warteschlange
Erik Möller - XML-Datenhaltungsschicht, Programmoptionen
Andreas Dribbusch - Lesezeichenbibliothek
Martin Wehner - Grafische Benutzeroberfläche

Projektziel

Ziel unseres Projekts war die Entwicklung eines FTP-Clients mit Java. Der Client sollte unter anderem folgende Eigenschaften aufweisen:

Wir entschieden uns, für dieses Projekt die folgenden Bibliotheken zu verwenden:

Der Client selbst ist unter der GNU General Public License lizenziert. Dies erlaubt anderen die Veränderung des Quellcodes und ermöglicht uns, ebenfalls unter der GPL lizenzierte Bibliotheken zu verwenden.

Projekterfolg

Die Muss-Eigenschaften des Pflichtenhefts wurden erfüllt, darüber hinaus wurden einige Kann- und sogar einige Könnte-Funktionen umgesetzt:

Erfahrungen

Gruppenarbeit: Wir haben uns entschieden, unser Projekt bei SourceForge kostenlos zu hosten. SourceForge bietet neben einem CVS-Server verschiedene andere Leistungen an, u.a. Projekt-Mailinglisten und Webspace. Die Verwendung einer Mailing-Liste hat sich als gute Entscheidung erwiesen, da so Informationen schnell und effizient ausgetauscht werden können und gleichzeitig auch online archiviert werden, was sehr nützlich ist, wenn man gerade keinen direkten Zugriff z.B. auf bestimmte Dateien hat.

CVS selbst ist eine große Erleichterung, wobei man sich allerdings auch gegenseitig behindern kann, wenn z.B. die eingecheckte Version plötzlich nicht mehr compilefähig ist. Man muss sich auch erst einmal daran gewöhnen, dass man die Dateien von Teammitgliedern bearbeiten kann. Man sollte nicht ständig Angst vor Konflikten haben, da diese in der Praxis eher selten auftreten.

FTP-Zugriff: Das RfC 959 ist in seiner Spezifikation des FTP-Protokolls eindeutig und weitgehend vollständig. Theoretisch sollte es deshalb kein Problem sein, einen Client zu schreiben, der auf beliebige FTP-Server zugreift. Nichtsdestotrotz weichen die verschiedenen FTP-Server in vielerlei Hinsicht von den Spezifikationen ab. Das betrifft z.B. die Reaktion beim Abbruch einer Übertragung, aber auch die Rückgabe bestimmter Fehlercodes. Im FTP-Client kann deshalb im Falle eines Fehlers nicht immer ein exakter Fehlergrund angegeben werden.

Datenbankschicht: Mit Hilfe der JDOM-API laden und schreiben wir XML-Dokumente. Die JDOM-API erzeugt mit Hilfe eines SAX- oder DOM-XML-Parsers ein Objektmodell von XML-Dokumenten. Dieses JDOM besteht aus einem Document-Objekt, das sogenannte Element-Objekte enthält. Jedes der Element-Objekte repräsentiert ein Element aus der XML-Datei, also in unserem Fall z.B. <folder name="Lesezeichen"> aus der Lesezeichen-XML-Datei. Für uns war nun die Frage, wie wir mit diesem Dokumentmodell innerhalb des FTP-Clients arbeiten sollen.

Die ursprüngliche Architektur, die wir für die Lesezeichenbibliothek auch implementierten, sah vor, das Dokumentmodell im Speicher zu halten und mit Klassen aus der Logikschicht darauf zuzugreifen. Ein logischer Aufruf getBookmarkName würde also weitergereicht an die Datenbankschicht, die das zugrundeliegende Element aus dem Dokumentmodell nach dem Attribut "name" fragen würde. Das Problem mit einer solchen Architektur ist, dass die XML-Datei selbst nur unzureichend den Objekten, wie man sie im Speicher benötigt, entspricht.

Wenn ein XML-Element ein anderes enthält, heißt das z.B. nicht, dass daraus zwangsläufig ein Java-Objekt erzeugt wird, welches ein anderes als Kompositum enthält. Beispielsweise enthält ein Element des Typs <folder> in der Lesezeichenbibliothek Elemente des Typs <folder> oder <item> -- in diesem Fall entspricht die XML-Hierarchie der Objekthierarchie. Ein Element des Typs <item> enthält aber Unterelemente des Typs <server>, <localDirectory> usw. - im Objekt sind dies jedoch Attribute. Eine Architektur, die ständig auf das dynamische XML-Modell zugreift, wird also sehr schnell sehr kompliziert, da in den Zugriffsklassen viele redundante Zusatzinformationen mitgespeichert werden müssen.

Wir haben die entsprechenden Klassen deshalb dahingehend überarbeitet, dass mit Hilfe der JDOM-API zwar wie gehabt zunächst ein Document Object Model erzeugt wird, dieses DOM aber sofort in die gewünschten Java-Objekte konvertiert wird. Beim Abspeichern wird wiederum aus den Java-Objekten das Document Object Model erzeugt, welches sich dann mit einem JDOM-Methodenaufruf in eine XML-Datei schreiben lässt.

JDOM selbst ist eine zuverlässige Bibliothek; das JDOM-Objektmodell ist wesentlich komfortabler zu bedienen als das klassische DOM, und die Auswahl von Parsern mit JDOM ist äußerst komfortabel. Gute Erfahrungen haben wir auch mit dem Crimson-Parser gemacht, der XML-Dateien auch anhand einer DTD validiert und dem Programmierer damit sehr viel Arbeit abnimmt: Dank der DTD müssen wir viele Ausnahmefälle (ein Item darf keine Folders enthalten usw.) nicht von Hand abfangen.