Client/Server Architektur realisieren - Ideen

[Sir Rufo]

Wenn du eine Zwischenschicht da einziehst, dann kannst du gerade was die Performance angeht sehr schön skalieren, denn wo die Zwischenschicht sich die Daten herholt, weiß der Client nicht und muss er auch nicht entscheiden. Steigt die Anzahl der Abfragen, dann kommen im Hintergrund einfach ein paar mehr Slave-Datenbank-Kisten und die werden dann eben gefragt (Last-Verteilung).

Für die kontinuierliche Benachrichtigung gibt es weitere Möglichkeiten (z.B. MessageQueues), die dann auch von der Zwischenschicht bedient werden.

[mm1256]

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

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.

Was ist denn daran derzeit "nicht" Client-Server?

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

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.

Ich habe ein ähnliches Programm-Konzept mit meinem WWS: ein Hauptprogramm und dazu 18 Module, wo jedes seine eigene Datenbankverbindung hat. Das Ganze läuft schon seit über 14 Jahren auf über 800 Installationen. Bisher konnte ich diese von dir angesprochenen Nachteile nicht nachvollziehen. Entweder die Datenbank und der Server kann das, oder irgendwas läuft falsch.

Abgesehen von den vermeintlichen Nachteilen hat das Prinzip auch (daten-)sicherheitstechnische Vorteile. Wenn ein Client (ein Modul auf einem PC im Netz) abraucht (nicht mehr reagiert) dann hat das auf die übrigen Verbindungen überhaupt keinen negativen Einfluss. Der Server trennt diese einzige Verbindung, ohne dass die anderen Clients davon was mitbekommen.

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben.

Also einen Dienst der den Datenbank-Dienst (nichts anderes ist ja (d)eine Datenbank) mit Daten "füttert". Und wenn die CS-Verbindung abraucht, dann raucht die (Netzwerk-)Verbindung deines Dienstes zu den Clients auch ab. Ich kann da beim besten Willen keinen Vorteil erkennen. Höchstens den Schluss daraus ziehen: Wenn deine Datenbank und/oder deren Clients mit Verbindungsabbrüchen bis hin zu Stromausfällen im laufenden Betrieb nicht richtig umgehen können, dann liegt das Übel nicht am System, sondern an der Datenbank, oder dessen Programmierer der die Möglichkeiten der Datenbank nicht ausschöpft.

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

Was haltet ihr davon?

Sorry, gar nichts.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1282374)

Was ist denn daran derzeit "nicht" Client-Server?

Umgangssprachlich wäre ein C/S auch ein N-Tier(N>2) System. Und wir wissen doch, was er meint. DJ-SPAM hat jetzt nicht um Nachhilfe in Sachen Nomenklatur gebettelt.

Zitat:

Ich kann da beim besten Willen keinen Vorteil erkennen.

Ich kann in einer Zwischenschicht besser auf Änderungen reagieren. Ich kann die eine exklusive Verbindung optimal nutzen. Die Verbindungsinformation ist nur an einer Stelle zu hinterlegen, Sicherheitskonzepte lassen sich wesentlich einfacher Umsetzen, nicht jede IT-Infrastruktur erlaubt es, von allen Clients eine Verbindung zu einem DB-Server herzustellen. Caching wäre auch noch eine lustige Option. Etc. Etc. Etc. Das sind jetzt nur die Vorteile, die mir sofort einfallen.

Zitat:

...Höchstens den Schluss daraus ziehen: Wenn deine Datenbank und/oder deren Clients mit Verbindungsabbrüchen bis hin zu Stromausfällen im laufenden Betrieb nicht richtig umgehen können, dann liegt das Übel nicht am System, sondern an der Datenbank, oder dessen Programmierer der die Möglichkeiten der Datenbank nicht ausschöpft.

Äh, hüstel. Schon mal was von instabilen Providern gehört? Schon mal in Asien gewesen? Schon mal einen Zusammenbruch des QoS bei einer TCP-Verbinduing mitgemacht, obwohl das laut OSI-Modell gar nicht geht? Es liegt nicht immer an der Datenbank und auch nicht am Programmierer... Und ich verstehe auch nicht, weshalb Du hier so rumzottelst.

Sachlichkeit und ein wenig mehr Grundwissen über C/S und N-Tier-Technologien sowie deren Vor- und Nachteile wäre wirklich angebracht. Nur weil dein Gurken :mrgreen: System seit 50 Jahren läuft, heißt das ja nicht, das das nicht besser, schlanker und moderner geht.

Wie und wo speicherst Du eigentlich die Verbindungsdaten zum Server? Also Login und Kennwort? Auf jedem Client? Hö. Viel Spaß mit Leuten, die Lust haben, den Zugang zu knacken. Ist popeleinfach, schätze ich. Bei einem N-Tier-System ist das dann schon etwas schwieriger.

Das nur mal so am Rande.

[mm1256]

Jetzt hast du eindrucksvoll beschrieben, dass du ein Oberchecker bist und ich eine rumzottelnde NULL mit popeleinfachem .... Vielen herzlichen Dank für die Aufklärung.

[TheMiller]

Angenommen, ich würde micht entscheiden, dass wir tatsächlich eine Server-Anwendung in Form eines Windows-Dienstes schreiben, welches Konstrukt sollte ich bevorzugen?

Ich dachte die ganze Zeit an einen Indy-TCP-Server/Client. Dem Server werden commands geschickt (ähnlich wie Parameter-Übergaben bei Webseiten). Diese liest er aus und führt die jeweilige Aktion durch.

Gibt es bessere/professionellere Wege als den Indy-TCP-Server? Das System sollte jedoch recht simpel gestaltet werden. Ein riesen Framework ist glaube ich nicht von nöten. Es werden bestimmt nie mehr als 30 Clients gleichzeitig mit dem Server kommunizieren. Wie viel hält der TCP-Server eigentlich aus?

Die Umsetzung war ja auch teil meiner Frage. Wie gesagt, habe sowas noch nie umgesetzt, außer micht mit einer Datenbank verbunden. Das zähle ich jetzt aber nicht mit ;)

Ich habe mich zwar noch nicht entschieden, aber bis jetzt ist die Dienste-Methode als Zwischenschicht im Rahmen des Möglichen.

[mkinzler]

Ich würde mir nicht zutrauen, in akzeptabler Zeit, das Rad "besser" neu zu erfinden. ;)

[Dejan Vu]

Schau dir mal RemObjects an. Die haben doch alles.
Oder die Delphi-eigenen Komponenten, damit geht das doch auch.
Oder die -sehr generisch- die Middleware-Suite von FPiette.

Nochmal: Mach das nicht selbst, das lohnt nicht (außer, ihr habt sonst nichts zu tun).

Zitat:

Zitat von mm1256 (Beitrag 1282386)

Jetzt hast du eindrucksvoll beschrieben...

Das war nicht meine Absicht, aber wer austeilt, sollte auch einstecken können, findest Du nicht auch?

[mjustin]

Zitat:

Zitat von DJ-SPM (Beitrag 1282388)

Ich dachte die ganze Zeit an einen Indy-TCP-Server/Client. Dem Server werden commands geschickt (ähnlich wie Parameter-Übergaben bei Webseiten). Diese liest er aus und führt die jeweilige Aktion durch.

Eine einfache Architektur wäre ein zentraler Windows Server mit einem auf dem Indy HTTP Server basierenden Service.

Darin würde ein MySQL Connection Pool dafür sorgen, dass immer frische, knusprige Datenbankconnections vorrätig sind.

Die Clients würden dann (ebenfalls Indy basierte) HTTP Verbindungen öffnen, Requests mit Parametern senden und die Daten dann als Anwtorten zum Beipisle JSON codiert erhalten.

Gegenüber reinem TCP hat HTTP einige Vorteile. Es können ständig geöffnete Verbindungen verwendet werden (keep-alive, HTTP 1.1) und über long polling kann eine Verbindung auch aktiv Daten vom Server erhalten ('Server-Push'). Dazu würde dann allerdings eine separate Connection benötigt, nicht die in der die normalen blockierenden Daten-Requests stattfinden.

p.s. natürlich sind bestehende Frameworks, wenn sie denn genau zu den Anforderungen und Rahmenbedingungen passen, sehr zu empfehlen. Nur bei kleinen bis mittleren Systemen würde ich eine Eigenentwicklung erwägen. Oder wenn man "experimentierfreudig" zu seinen soft skills zählt :)

[TheMiller]

Zitat:

Zitat von mkinzler (Beitrag 1282389)

Ich würde mir nicht zutrauen, in akzeptabler Zeit, das Rad "besser" neu zu erfinden. ;)

Wie habe ich das jetzt zu verstehen? Meinst du, man kann den Indy-Server benutzen und muss nicht zu was ganz eigenem greifen, oder denkst du, man sollte den Indy-Server nicht nutzen und lieber ein (großes?) Framework nutzen? Und wenn Framework - an welches denkst du?

DataSnap soll sehr langsam und fehlerbehaftet sein. Und die Geschichte mit TRemoteDatamodule hört sich gerade etwas kompliziert an.

Roter Kasten:
Danke für die weiteren Nachrichten. Ich muss mir mal die Vorteile / Unterschiede zwischen einer eigenen Lösung und den vorgeschlagenen Frameworks anschauen. Derzeit denke ich, dass wir nicht viele Funktionen brauchen, außer den Transport von json-"Objekten". Die HTTP-Methode hört sich auch sehr gut an.

Das Rad will ich keinesfalls neu erfinden. Dazu fehlt die Zeit. Nur abwägen zwischen dem Kauf neuer Komponenten (was mittlerweile ordentlich Geld kostet), den Funktionen die wir nutzen werden, und Boardmittel benutzen.

[mkinzler]

Ich meinte, Du solltest Dir vorhandene Lösungen ansehen und dann entscheiden, ob es wirklich sinnvoll ist selber Zeit zu investieren.

https://mikejustin.wordpress.com/201...n-with-delphi/
http://www.realthinclient.org/details/
http://www.tmssoftware.com/site/remotedb.asp
http://www.overbyte.be/frame_index.html
http://www.dataabstract.com/da/