Oneixee5
Top Contributor
Mich würde interessieren, was dieser "ClientServer" für eine Aufgabe hat.
Wir synchronisieren in einem Projekt über 3600 Datenbanken in Schulen über eine zentrale DB und dadurch auch untereinander, als Teil eines größeren Projektes. So eine merkwürdige Architektur ist aber dafür nicht notwendig. Das Kultusministerium war immer der Meinung, dass das Internet nichts Beständiges ist und auch nur selten verfügbar. Diese Ansicht war auch teilweise berechtigt, z.B.: in ländlichen Gebieten, Baustellen. Daher musste jede teilnehmende Schule eine eigene DB bzw. Server und eine oder idR. mehrere (Rich-)Clientanwendungen haben. Die Synchronisierung der Daten wird immer durch einen Client initiiert. Daher ist es gar nicht notwendig, dass der Server der Schule selbsttätig mit der Außenwelt kommuniziert.
Alle Änderungen/Updates/usw., egal auf welcher Seite, werden in Datenpaketen (Projektjargon: ZIP-Dateien) zusammengefasst und in einem WebDAV (einziger Punkt mit erforderlichem Login außerhalb der Schule) abgelegt(natürlich nach Nutzern getrennt). Jede Seite holt sich automatisch die betreffenden Datenpakete ab und verarbeitet diese, und sendet selbst welche. Solche Datenpakete kann man sehen als würde man eine Datei speichern. Es können sehr viele Änderungen enthalten sein oder sehr wenige. Es könnte auch sein, dass ein Client die Datenpakete 3 Monate nicht abholt und dann alle auf einmal.
Es gibt noch einen Sonderfall. Es kann sein, dass ein Client die DB bzw. Server neu installieren muss. In so einem Fall wird nach der Installation ein Setup-Datenpaket vom zentralen Server angefordert und auch dieses wird im WebDAV abgelegt und kann vom Client abgeholt werden.
Das Verfahren läuft also vollständig asynchron, erfordert nur wenige Serverkomponenten, wenig Nutzerinteraktion und ist leicht zu überblicken bzw. zu warten.
Nachteil ist, dass manchmal Schulen auf Daten anderer Schulen warten, weil diese gerade keine Datenpakete senden (wollen/können). Es gibt aber einen zentralen fachlichen und technischen Support, welcher hier vermitteln kann.
Eine lokale Installation von DB's, Severn oder auch Clientsoftware kann aber idR. von einer Schule nicht sinnvoll und fehlerfrei gewährleistet werden. So sind Frust und Kosten für Vor-Ort-Support sowie Dienstleister mit der Zeit immer mehr gestiegen. Eine solche Architektur ist in Zeiten von Glasfaser und mobilem Internet nicht mehr zeitgemäß und wird deshalb durch eine reines Onlineportal abgelöst. Diese ist schneller, moderner, kostengünstiger, kann ohne Installation von Clientsoftware verwendet werden und bietet trotzdem alle Funktionen und Möglichkeiten, welche vorher vorhanden waren (und mehr).
Wir synchronisieren in einem Projekt über 3600 Datenbanken in Schulen über eine zentrale DB und dadurch auch untereinander, als Teil eines größeren Projektes. So eine merkwürdige Architektur ist aber dafür nicht notwendig. Das Kultusministerium war immer der Meinung, dass das Internet nichts Beständiges ist und auch nur selten verfügbar. Diese Ansicht war auch teilweise berechtigt, z.B.: in ländlichen Gebieten, Baustellen. Daher musste jede teilnehmende Schule eine eigene DB bzw. Server und eine oder idR. mehrere (Rich-)Clientanwendungen haben. Die Synchronisierung der Daten wird immer durch einen Client initiiert. Daher ist es gar nicht notwendig, dass der Server der Schule selbsttätig mit der Außenwelt kommuniziert.
Alle Änderungen/Updates/usw., egal auf welcher Seite, werden in Datenpaketen (Projektjargon: ZIP-Dateien) zusammengefasst und in einem WebDAV (einziger Punkt mit erforderlichem Login außerhalb der Schule) abgelegt(natürlich nach Nutzern getrennt). Jede Seite holt sich automatisch die betreffenden Datenpakete ab und verarbeitet diese, und sendet selbst welche. Solche Datenpakete kann man sehen als würde man eine Datei speichern. Es können sehr viele Änderungen enthalten sein oder sehr wenige. Es könnte auch sein, dass ein Client die Datenpakete 3 Monate nicht abholt und dann alle auf einmal.
Es gibt noch einen Sonderfall. Es kann sein, dass ein Client die DB bzw. Server neu installieren muss. In so einem Fall wird nach der Installation ein Setup-Datenpaket vom zentralen Server angefordert und auch dieses wird im WebDAV abgelegt und kann vom Client abgeholt werden.
Das Verfahren läuft also vollständig asynchron, erfordert nur wenige Serverkomponenten, wenig Nutzerinteraktion und ist leicht zu überblicken bzw. zu warten.
Nachteil ist, dass manchmal Schulen auf Daten anderer Schulen warten, weil diese gerade keine Datenpakete senden (wollen/können). Es gibt aber einen zentralen fachlichen und technischen Support, welcher hier vermitteln kann.
Eine lokale Installation von DB's, Severn oder auch Clientsoftware kann aber idR. von einer Schule nicht sinnvoll und fehlerfrei gewährleistet werden. So sind Frust und Kosten für Vor-Ort-Support sowie Dienstleister mit der Zeit immer mehr gestiegen. Eine solche Architektur ist in Zeiten von Glasfaser und mobilem Internet nicht mehr zeitgemäß und wird deshalb durch eine reines Onlineportal abgelöst. Diese ist schneller, moderner, kostengünstiger, kann ohne Installation von Clientsoftware verwendet werden und bietet trotzdem alle Funktionen und Möglichkeiten, welche vorher vorhanden waren (und mehr).
