Client/Server Architektur realisieren - Ideen

[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.

[TheMiller]

Zitat von mkinzler:

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/

[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?

[mm1256]

Zitat von Dejan Vu:

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

Da liegst du in mehrerlei Hinsicht falsch. Ich habe nicht ausgeteilt, sondern du. Wenn du der Meinung bist, das hier ist eine "Austeilstation" dann ist das zu tolerieren eine Angelegenheit der Mod's. Der TE hat auch nicht nach Asien oder instabilen Providern gefragt. Das sind Argumente die du dir selber aus der Nase gezogen hast, um deinen Kommentar zu rechtfertigen. Mit Sachlichkeit hat das jedenfalls nicht viel zu tun.

Ich habe lediglich meine Meinung kund getan. Vielleicht in einer etwas "direkten Formulierung", doch was soll daran falsch sein. Es geht doch - um zur urspünglichen Frage zurück zu kommen

Zitat von DJ-SPM:

...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.

...und da bin ich nach wie vor der Meinung, dass eine Zwischenschicht das Problem nicht lösen kann und wird, denn wenn (in der jetzigen Situation) die Verbindung zur Datenbank verloren geht, dann wird danach eben anstelle zur Datenbank die Verbindung zur Zwischenschicht verloren gehen. Wo ist da (für den Client) der Unterschied oder der Vorteil? Ich sehe keinen. Zumindest keinen, den eine normale Datenbank (Stichwort failsave transactions) nicht auch handeln kann. Eine Zwischenschicht macht doch nur Sinn, wenn ich unterschiedliche Clients (Workstations, WEB-Clients, mobile Geräte) zusammenführen muss. Ich lasse mich aber gerne eines Besseren belehren.

[mjustin]

Zitat von mm1256:

...und da bin ich nach wie vor der Meinung, dass eine Zwischenschicht das Problem nicht lösen kann und wird, denn wenn (in der jetzigen Situation) die Verbindung zur Datenbank verloren geht, dann wird danach eben anstelle zur Datenbank die Verbindung zur Zwischenschicht verloren gehen. Wo ist da (für den Client) der Unterschied oder der Vorteil? Ich sehe keinen. Zumindest keinen, den eine normale Datenbank (Stichwort failsave transactions) nicht auch handeln kann.

Naja, ein paar Vorteile fallen mir da schon ein:

* keine Datenbank-Clientinstallation auf den Clients erforderlich => was nicht da ist, kann auch nicht ausfallen oder falsch konfiguriert werden
* keine datenbankspezifische Programmierung (Transaktionsbehandlung) im Client => Komplexität nur noch im Middle-Tier, die ohne Roll-out neuer Clients gepflegt werden kann
* durch asynchrone Requests (Message Queues) können DB-Aktionen die zum Beispiel während einer Downtime der Datenbank nicht möglich sind, zeitversetzt erfolgen. Ein Middle-Tier System kann auch Caching dazu einsetzen, dass Clients während eines Datenbankausfalls noch eingeschränkt weiter arbeiten können.

Hochverfügbarkeit kann man in einem klassischen Client/Server System nur mit höherem Aufwand erreichen.

[Dejan Vu]

Bei einem Kunden ist es nicht möglich und nicht gewollt, vom Client aus direkt auf die DB-Server zuzugreifen. Eine Zwischenschicht löst das Problem, ohne das die Sicherheitspolitik zur Disposition steht. Oft gemacht (mit Delphi-Bordmitteln).

Zitat von mm1256:

Der TE hat auch nicht nach Asien oder instabilen Providern gefragt. Das sind Argumente die du dir selber aus der Nase gezogen hast

Eigentlich nicht, sondern Belege aus meiner Arbeit. Ich könnte Dir da auch noch tolle Beispiele aus USA benennen, was die dort teilweise unter einem stabilen Netzwerk verstehen. Ich bin halt rumgekommen und kann was erzählen. Tut mir leid, soll ich mein Wissen für mich behalten? Vor allen Dingen, wenn ein naseweiser Neunmalkluger meint, alles besser zu wissen? Nein, Du bist damit natürlich nicht gemeint.

Zitat:

...und da bin ich nach wie vor der Meinung, dass eine Zwischenschicht das Problem nicht lösen kann und wird, denn wenn (in der jetzigen Situation) die Verbindung zur Datenbank verloren geht, dann wird danach eben anstelle zur Datenbank die Verbindung zur Zwischenschicht verloren gehen.

Deine Meinung in Ehren, aber so einfach ist das vielleicht doch nicht:

Wie reagierst Du denn bei deiner Lösung, wenn der Server ausfällt und der Backup-Server nun einspringen muss (andere IP)? Dann rennst Du doch zu allen Clients und änderst die Konfiguration, oder wie löst Du das sonst? Doch nicht etwa über eine im Netz stehende Konfigurationsdatei?

Na ja, wenn du von deiner Lösung überzeugt bist, dann ist das ja ok. "Never change a running system". Aber wenn das System vom TE nicht gut läuft, sind erprobte und etablierte Alternativen ('N-Tier', Proxy) doch wohl besser angebracht, als ein: "Bringt doch nix". Mach doch erst einmal Erfahrungen mit mehrschichtigen Anwendungen. Entweder wirst Du deine Meinung bestätigt sehen, oder nicht: Gewonnen hast Du dann auf jeden Fall.

[mm1256]

Zitat von Dejan Vu:

Bei einem Kunden ist es nicht möglich und nicht gewollt, vom Client aus direkt auf die DB-Server zuzugreifen....

Von diesem Sachverhalt hat der TE bisher nichts erwähnt. Es ging um "mehrere Datenbankverbindungen" und um "schwer abfangbare Probleme bei Verbindungsabbrüchen". Da der Thread aber nicht unter "Klatsch und Tratsch" läuft, werde ich mich jetzt aus dem Thema raus halten, weil unsachliche Beiträge meiner Meinung nach nicht zweckdienlich sind.