Zentrale Dateiverwaltung. Client-Server-Modell

[Markus123456789]

Hey,

IST:

Server: - User- & Gruppenverwaltung (steht)

Client: - GUI
-> User können sich anmelden (steht)

- Im Backgroud läuft eine H2 DB, die auch schon die Benutzer- und gruppeninformationen enthält.

SOLL:

Server: + Dateiverwaltung

Client: - GUI
+> User können Dateien von dem Server auswählen und herunterladen.
+> User können Ordern auf dem Server (innerhalb der Dateiverwaltung) anlegen und löschen
+> User können Dateien von der lokalen Festplatte auf den Server hochladen (in einen vorher ausgewählten Ordner)
--> Die Sicht der User auf die Dateiverwaltung sollte am besten mit Hilfe eines JTrees realisiert werden.

Das sind meine Vorstellungen.
Die Verwaltung steht schon und ich habe das komplette System (Client-Server Kommunikation) bis jetzt mit Hilfe von RMI realisiert.

Meine Frage ist jetzt: Wie würdet ihr "das" realisieren, was ich oben beschrieben habe?
Es ist weniger, dass ich 100%ig ratlos bin und nicht weiß, wie man eine Datei auf nen server schiebt...
Es ist eher der grundlegende Ansatz wie man die Dateiverwaltung auf dem Server programmieren sollte. Wie bildet man den JTree persistent auf der Festplatte ab?
Ne Liste wo jeder Eintrag nen parent attribut enthält klingt mir zu simpel.

Wie schafft man es, dass der Client die Dateiverwaltung bei sich in der GUI angezeigt bekommt?
Also wie würdet ihr es realisieren.
Und wie kann bei einem Client die Jtree aktualisiert werden, wenn ein anderer Client einen neuen Ordner angelegt hat.

Vielleicht hat jemand schon etwas in diese Richtung gemacht und kann mir ein paar gute Tipps geben.
Oder jemand hat eine Zündende Idee, die mir im Augenblick fehlt.

Viele Grüße

Markus

 

[Franz Degenhardt]

Ist das ein Trainingsprojekt oder möchtest du Anforderungen möglichst effizient abbilden?
RMI, Client? Das hört sich nach einem echten Client wie applet oder java application an. Wenn es auch mit einem HTML-Client umzusetzten ist, ist dies immer vorzuziehen. Versionrollout, Sicherheit, Vertrauen, Wahl der richtigen Technologie, Eleganz und Mündigkeit der Nutzer sind alles Aspekte, die gegen einen "fatclient" sprechen. Die meisten Anwender im Internet deaktivieren Java grundsätzlich im Browser und überlegen kritisch ob es die Anwendung wert ist, an dieser Stelle die Hosen runterzulassen.
Googlemaps bietet alle Funtiontionalität die man sich wünschen kann, selbst wenn im Browser alles auf Paranoia gestellt ist. Das ist Software. Amateurhafte Konkurenten können die selbe Funktionaltität nur mit der vollen Bandbreite der Technologie umsetzten.
/rant

java.io.File bietet alle Möglichkeiten um die Struktur von Verzeichnissen und Dateien herauszubekommen. Ich würde die tatsächlichen Verzeichnisse als Datenbasis für Clients nehmen, statt eine für die ganze Festplatte erstellten eigenen Dateistruktur. Also für jeden Request des Clients wie /dir /mkdir /cd usw eine entsprechende Operation mittels File durchzuführen und anschliessend den aktuellen Status wieder life über File zuermitteln und anzuzeigen.
Dies hätte den Vorteil, dass Operationen von anderen Clients sich automatisch beim nächsten Request synchronisieren.

Eine vom Server gesteuerte Aktualisierung des Clients ist etwas, was einer Javaaplication näher ist, als die request-response philosophie von dynamischem html.

 

[markus123456789]

hey,

Die serververbindung läuft zwischen client und server mittels rmi.
ich habe es mit 2 Klassen realisiert, die auf dem Server verwaltet werden.

FolderEntry
id
Name
parentId

FileEntry
id
Name
ParentId
PathToRealFile

Hat super funktioniert

viele grüße