Generelle Designfrage zur Client/Server - Kommunikation

mki_germo

Erfahrenes Mitglied
Hallo, ich grüble grade über eine eher grundsätzliche Designfrage.

Folgendes Szenario: Es geht um ein Client-Server System, bei dem Dateien von mehrerenn Servern zu den Anwendern gebracht und verarbeitet werden müssen. Die Anwender sitzen verteilt auf mehrere Standorte und haben nicht zwangsläufig immer eine Verbindung auf das Dateisystem des Servers.
Clientseitig kommt Windows zum Einsatz, wobei teilweise Terminalserver (sowohl von MS als auch Citrix) zum Einsatz kommen. Serverseitig kommt sowohl Microsoft als auch Solaris zum Einsatz.
Die Useranzahl liegt momentan bei ca. 800, wobei sich die Zahl in der Zukunft wohl erhöhen wird.

Als Lösungsansatz sind momentan zwei Möglichkeiten angedacht.

1. Direkte Kommunikation via TCP-IP mit Serialisierung:
Hätte den Vorteil, dass die Clients die Daten vom Client nicht groß parsen muss sondern direkt verwendet werden könnten. Nachteilig ist, das mann sich um die ganze Kommunikation selber kümmern muss (Portverteilung bei Terminalservern, Timeouts).

2. Kommunikation via JMS:
Hier stellt sich das Problem, dass nicht für jeden User eine eigene Queue oder eigenes Topic generiert werden kann, da dies der JMS-Server nicht mitmacht. Von daher muss jeder Client erstmal prüfen, was für ihn überhaupt relevant ist.


Ich bin mit beiden Lösungen nich gerade glücklich, tendiere aber eher zur zweiten Methode. Daher mal die Frage, ob euch eventuell noch ein weiterer Ansatz einfällt.


Vielen dank schonmal im Vorraus.
 
Grundsätzlich kämen ja noch einfache WebServices oder halt Sachen wie Hessian und Burlap in Frage. Um sowas zu entscheiden muss man aber die Anforderungen recht gut kennen. Bisher nicht genannt hast du Themen wie Security, Offlinearbeit (du erwähnst, dass es sein kann, das keine INetverbindung besteht). Von JMS ich würde ich (für die Client Server Kommunikation) erstmal absehen, zumindest solang die anderen Möglichkeiten ausgelotet sind. Da ist man recht schnell bei Asynchronität die nicht sein muss und Dinge nur verkompliziert.

Gruß
Ollie
 
Hallo,

ich denke du musst dein Szenario noch etwas genauer beschreiben. Am anfang sagst du das Dateien von mehreren Server zu den Clients gesendet werden müssen.

Ein wenig später redest du dann von den Clients die an Clients senden (wobei du dich hier wohl verschrieben hast).

Also wenn das ein reiner Dateiverteilungs Mechanismus werden soll, dann würde ich das so realisieren, dass ich eine Kombination aus RMI / oder Springs HTTP Invoker für Serviceaufrufe und normale Sockets für die Dateiübertragung verwenden würde. Auf dem Server könnte auch ein webserver laufen von wo die Clients diese dann über eine URLConnection / whatever via HTTP downloaden können.

Auf der Remoting schicht aufsetzend würde ich nochmal eine request/response abstraktion implementieren. Diese Requests kann man dann auch lokal beim Client in eine (eigene) Queue stellen wenn der Server mal nicht verfügbar sein sollte und beim nächsten Anwendungsstart absenden. In den Responses steckt dann die URL von wo man sich die entsprechende Datei(en) herunterladen kann.

Man sollte auch darauf achten RemoteCalls die sehr lange dauern asynchron auszuführen um die Anwendung nicht wegen IO lahmzulegen...
bzw. zumindest das Warten auf die Antwort sollte in einem anderen Thread passieren. Das geht wunderbar mit Futures :)
http://www.tutorials.de/forum/java/274056-fragen-threads-und-executorservice.html
http://www.tutorials.de/forum/java/276266-komplizierter-java-queue-mechanismus.html
http://www.tutorials.de/forum/java/286944-observer-muster.html

Gruß Tom
 
Zurück