Client/Server Architektur realisieren - Ideen

[mm1256]

Zitat:

Zitat von Dejan Vu (Beitrag 1282390)

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:

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:

Zitat von mm1256 (Beitrag 1282400)

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

Zitat von mm1256 (Beitrag 1282400)

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? :lol:

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:

Zitat von Dejan Vu (Beitrag 1282433)

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.

[humbuck]

Es ist ja nun noch nicht genau zu ersehen, für was für eine Lösung du dich nun entschieden hast, aber du solltest dich vielleicht mit einer Kombilösung anfreunden.

Deine Verwaltung deiner wichtigsten Daten kannst du doch durchaus 'sicher' und unabhängig lösen:

Zitat:

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

Halte ich persönlich bei der vorherrschenden Serverarchitektur als absolut sinnvoll.

Wenn du dann ergänzend für nicht 'so wichtigen' Dienste für deine Kunden/User eine Multithread-Verbindung á la TCP-Client-Server einrichtest, schaffst du dir eine passable Lösung für deine Probleme. Selbst die Datensicherung via Netz/Internet lässt sich dann verwirklichen.
Client-seitig solltest du dann vielleicht ein Programm-Update für deine Kunden in Erwägung ziehen, um Einzelverbindungen aus den Plugins für die TCP-Client-Server-Lösung in dein Hauptmodul zu verlagern...

Das Rad nicht neu erfunden und doch verwendbar.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1282436)

Es ging um "mehrere Datenbankverbindungen" und um "schwer abfangbare Probleme bei Verbindungsabbrüchen".

Seufz, man wird wohl noch bei einer allgemeinen Diskussion um Vor- und Nachteile diese Punkte erwähnen dürfen.

Zitat:

werde ich mich jetzt aus dem Thema raus halten

Oh, bitte.

Zitat:

Zitat von humbuck (Beitrag 1282457)

Zitat:

..klatsch dir da mit PHP ein REST drauf ...

Halte ich persönlich bei der vorherrschenden Serverarchitektur als absolut sinnvoll...

Auch hinsichtlich der allgemeinen Erweiterbarkeit (thin client, mobile) sicherlich eine sehr gute Lösung.

[Mavarik]

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)

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:

Zitat von sh17 (Beitrag 1282740)

(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!