Client/Server Architektur realisieren - Ideen

[Dejan Vu]

Zitat von mm1256:

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 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 von mm1256:

Jetzt hast du eindrucksvoll beschrieben...

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

[mjustin]

Zitat von DJ-SPM:

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

[Mavarik]

Zitat von DJ-SPM:

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.

Interessant... Ich arbeite zur Zeit an einer ähnlichen Lösung aufgrund von ähnlichen Problemen.
Mein Ansatz ist zwar etwas anders aber läuft aufs gleiche hinaus.

Clientseitig nur mir meiner Schicht reden ohne eine Datenbank Komponente. Somit kann ich in 2 Sekunden meine Software von Datenbank A auf Datenbank B umstellen uvm. Indy ist entgegen von overbyte meine Wahl, da die Overbyte Sourcen nicht Android/iOS kompatible sind. (Nach meinen Wissen, obwohl ich ein Overbyte-Fan bin).

Wichtig für mich ist auch ein "Shoot & Forget" ich mache 10000 Posts und meine App arbeitet sofort weiter als währen die Daten schon in der Datenbank angekommen... Die Zwischenschicht kann dann in einem netten WorkerThread die Daten "in Ruhe" weg schreiben und nur ggf. im Fehlerfall mir einen Callback schicken. (Vereinfacht)

Daher je einen Teil der Zwischenschicht in jedem Client und den anderen Teil zentral/dezentral. Hier können auch mehrere Server dann Synchronisiert werden.

Mavarik

PS.: Momentan "bastel" ich noch an einem Konzept für eine SELECT bla JOIN bla Umsetzung.

[sh17]

Also ich würde auch eine Zwischenschicht einbauen. Wir haben das bei einem Produkt auch so gemacht, mit der RemObjects SDK und Indy (Den DataAbstract-Überbau brauchst Du nicht)

[Mavarik]

Zitat von sh17:

(Den DataAbstract-Überbau brauchst Du nicht)

Für mich ist das eine Motivation die Zwischenschicht zu programmieren.

Jeder spricht von:
- Designpatten's
- dependency injection
- MVVM
- uvm.

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

Mavarik

[TheMiller]

Hallo zurück

Vielen Dank für die weiteren Antworten. Ich habe erst Sonntag entdeckt, dass neue Beiträge geschrieben wurden und seitdem leider keine Zeit mehr gehabt zum Antworten - aber zum Nachdenken!

----
Aber eines Vorweg: Meine Themen stellen oft auf abstrakte Fragen, Grundsätze, Aufbauftechniken etc. ab. In diesem Rahmen ist es durchaus gewollt, dass andere Leute ihre Erfahren und Bedenken teilen, weitere Vor- und Nachteile nennen/entwickeln und so mir und anderen einen erweiterten Blick auf die Themen zu geben. Denn niemand denkt an alle Eventualitäten. Ob das nun sinnvoll ist, kann ja jeder für sich entscheiden. Wenn es nun aber mit dem eigentlichen Thema garnichts mehr zu tun hat, tja, dann ist es wirklich fehl am Platze.

Aber ich schätze die DP eben gerade dafür, dass man nicht nur Stumpf die Frage beantwortet, sondern eben wie in einem Gespräch unter Kollegen auf weitere Sachen hingewiesen wird oder ein gänzlich anderer Vorschlag gebracht wird, weil es anders eben besser ist als ursprünglich gedacht.

Ich habe das Programmieren damals in der Schule angefagen, heute programmiere ich durchaus erfolgreich. Ich habe keine Ausbildung und kein Studium in der Programmierung. Alles nur durch Eigenstudium und die Hilfe der DP.

----

So. Ich werde definitiv eine Zwischenschicht einbauen. Es hat wirklich viele Vorteile. Sie wird höchstwahrscheinlich in PHP erstellt, also eine REST-API. Passt auch gut, da ich eine solche schon mehrfach umgesetzt habe.

Zusätzlich werde ich einen Server und einen Client brauchen. Ich denke, dafür reichen wirklich die Indys. Ich habe mir das nun folgendermaßen gedacht - da würde ich gerne wissen, ihr das die Methode für "okay" empfindet:

* Auf dem Windows-Server läuft in einem Windows-Dienst der Indy-TCP-Server.
* Der TCP-Client verbindet sich mit dem Server und sendet einen String in der Form: "/db/getObject/[objectname]/[db-id]".
* Der Server fragt in der API nach und sendet den json-String zurück.

Mir geht es hauptsächlich darum, ob die Kommandos in der o.g. Form eine gute Idee sind, oder ob ich ein anderes System/Format nutzen sollte. Dieser String könnte auch durchaus anders aussehen, z.B. so: "/user/registerOnline/192.168.1.6".
Oder man sendet gleich ein Record bzw. json-array. Es ist halt erstmal das Problem da, dass nicht absehbar ist, wie viele Parameter übergeben werden müssen, geschweige denn ganze ObjectLists.

Das sind so meine jetzigen Überlegungen. Nehmt gerne Stellung dazu!

Danke im Voraus!