Client/Server Architektur realisieren - Ideen

[TheMiller]

Hallo,

ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen. Das Programm besteht aus einem Hauptprogramm mit mehreren Modulen/Plugins. Die Datenspeicherung übernimmt eine MySQL-Datenbank.

Da das Programm und dessen Plugins hauptsächlich mit Daten aus der DB arbeiten, benötigt jedes Programmteil eine Datenbankverbindung und muss mit dem DB-Server kommunizieren können.

Das hat natürlich zum Nachteil, dass pro Benutzer mehrere Datenbankverbindungen (eine pro Programmteil) geöffnet wird. Weiterer Nachteil ist, dass es zu schwer abfangbaren Problemen im Programm kommt (keine Reaktion etc.), wenn die Verbidung zur Datenbank verloren geht. Dies kann durch remote-Zugriff via VPN etc. öfter mal passieren.

Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben. Dieser läuft auf dem Windows-Server 24/7. Programme/Plugins können bauen eine TCP-Verbindung zum Dienst auf, senden ihm ein command (zB getTasks), der Dienst verbindet sich zur Datenbank, liest die Daten aus und sendet sie per tcp (hier meine ich Indy-TCP-Server/Client) an den Clientprozess zurück. Wenn keine Internetverbindung besteht, kann man das echt gut abfangen und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet. Alle Datenbankoperationen (hinzufügen, ändern, löschen) würden dann vom Dienst übernommen werden. Dies ist auch einfacher zu Warten.

Die Kommunikation zwischen Client und Dienst würde per Strings/Records stattfinden. Da wir OOP nutzen, würden die Daten eines Objekts in ein Record übergeben und dann zum Dienst übertragen werden, da man ja keine Objekte verschicken kann. Oder, wenn es in Delphi auch sowas gibt, dann ein serialisiertes Objekt (ähnlich zu json_encode in php).

Macht man das so? Was haltet ihr davon? Habt ihr Tipps dazu?

Danke im Voraus

[Dejan Vu]

Früher konnte man das noch direkt mit Delphi-Bordmitteln lösen, jetzt sollte das doch auch noch gehen. Stichwort: TRemoteDatamodule

Es gibt auch Drittanbieter, die das noch 1000x besser gelöst haben (RemObjects)

Erfinde das Rad nicht neu.

[Der schöne Günther]

Schau doch mal nach wann die erste JSON-Serialisierung in Delphi kam. War es nicht sogar 2009 oder 2010?

[Olli73]

Zitat von DJ-SPM:

ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen.

Wenn du jetzt schon einen DB-Server einsetzt ist das doch bereits eine Client/Server-Anwendung; was du vorhast, wäre dann eine Multi Tier Architektur, oder liege ich da falsch?

Zitat von DJ-SPM:

und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet.

Dann (mit 1 Datenbankverbindung) kannst du allerdings i.d.R. die Abfragen nur nacheinander ausführen. Das heißt, wenn ein Client eine Abfrage schickt, die z.B. 20 Sekunden benötigt, müssen alle anderen warten. Daher sollte man das "Multi Threaded" lösen und dazu brauchst du i.d.R. wieder mehrere Datenbankverbindungen, was aber auch nicht schlimm ist.

Gruß,
Olli

[TheMiller]

Danke für die Antworten.

Mutil Tier habe ich zwar schon öfter gelesen, mich aber nie darum gekümmert, was es ist.

Die Datenbank läuft i.d.R auf einem Linux-Server (MySQL).

Es ist richtig, dass die Verarbeitung dann nacheinander durchgeführt wird. Man könnte ja überlegen, die Anzahl der offenen Verbindungen auf 2 Stk. pro User zu beschränken. Immernoch besser, als wenn jedes Plugin eine offene Verbindung hält. Manchmal sind nämlich gleichzeitig 4 Plugins offen. Das macht bei 10 Usern - die die Anwendung regelmäßig nutzen - 40 Verbindungen. Ich dachte, es wäre besser, dies zu reduzieren und das alles zentral abwickeln zu lassen.

Der Dienst soll darüber hinaus noch andere zentrale Aufgaben übernehmen, die nichts mit der Datenbank zu tun haben.

Wichtig wäre mir halt auch das Abfangen auftretender Verbindungsprobleme, was über einen Dienst mit Kommunikation zum Client besser gehandlet werden könnte. Denke ich.

Ich habe ein wenig über TRemoteDatamodule gelesen. Verstehe das alles noch nicht so ganz. Wüsste aber auch nicht, wo die Vorteile sind. Wenn ich dem Indy-TCP-Server einen Command schicke, weiß er, was damit zu tun ist, läd die Daten aus der Datenbank (dazu nutze ich übrigens UniDAC), und gibt das json zurück via Indy-TCP. Geht es wirklich noch einfacher, oder habe ich einen Denkfehler?

Ihr seht - das ist noch neu für mich.

[TheMiller]

Ein kleiner Nachtrag noch, warum ich diese Architektur in Erwägung ziehe. Bin aber dahingehend für alles offen

Der Server könnte so auch alle Clients mit aktivem Modul XY benachrichtigen, wenn sich Änderungen in ihm bzw. dem Datenbestand ergeben haben.

So könnten die Clients gleich die neuen Daten laden.

[Sir Rufo]

Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen

[TheMiller]

Genau das habe ich mir auch schon überlegt.

Nur leider soll der Dienst ja auch weitere, nicht-datenbankbezogene Aufgaben erledigen. Wie ich eben oben schrieb, soll er ja auch Nachrichten an die Clients schicken, wenn sich ein Datenbestand geändert hat, der gerade via Plugin von einem Client offen ist.

Auch soll sich der Dienst über die Benutzerverwaltung kümmern (wer ist mit welcher IP online, wer ist offline), kleiner Chat, Backup und einige weitere Funktionen aus dem Bereich der Textverarbeitung der Clients etc.

[fillibuster]

Hi,

Zitat von Sir Rufo:

Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen

... und hier das passende PHP Framework dazu: http://www.slimframework.com/. Habe ich genau für diesen Anwendungsfall sehr gute Erfahrungen mit gemacht.

Viele Grüße ....

[TheMiller]

Die Datenbankkommunikation könnten wir aber tatsächlich in eine PHP-Anwendung auslagern, da wir - zumindest Teilfunktionen - auch für andere Plattformen wie (na klar) iOS etc. planen. Da müsste man nur eine Stelle pflegen.

Dennoch bleiben die anderen Aufgaben übrig und die Benachrichtigung über neue Daten würde wieder schwerer zu realisieren sein. Ein Timer-Polling der Clients will ich eigentlich vermeiden.

Würde gerne so programmieren, dass man auch locker von außerhalb via VPN arbeiten kann, ohne, dass alles brechend langsam wird.