Client/Server Architektur realisieren - Ideen

[TheMiller]

Guten Morgen!

Nachdem ich den Thread nochmal komplett gelesen und mir über das Wochenende viele Gedanken gemacht habe, möchte ich nochmal zusammenfassen und konkrete Umsetzungsvorschläge anbringen:

* Auf dem Datenbank-Server wird eine REST-API eingerichtet. (Diese habe ich zum Glück schon aus einem anderen Projekt fertig). Die API deshalb, weil wir tatsächlich planen, noch andere Plattformen zu bedienen und die Wartung ist viel einfacher (Queries nur auf einer Plattform aktualisieren/erstellen). Long-Polling kann umgesetzt werden.

* Auf dem Windows-Server wird ein Server-Dienst laufen. Dieser dient auch als Zwischenschicht zwischen Clients und Datenbank-Server. Die Verbindung wird über TCP-Server/TCP-Client von Indy realisiert. Der Server-Dienst nimmt requests entgegen und verarbeitet sie. Diese Requests sind vom Typ TRecord und haben mindestens folgende Felder: Absender, Empfänger, Timestamp, request_id, request_str (json_string). So sollte eine exakte Zuordnung und Verarbeitung der Nachricht möglich sein (genauer ist das noch nicht durchdacht). Je nachdem, was der TRequest dem Server aufträgt, führt er die Aktion durch (Aktion mit anderen Clients oder Anfrage an die DB). Danach sendet er an den ursprünglichen Absender oder einen "Broadcast" TResponse zurück.

* Der Server-Dienst prüft die Erreichbarkeit des Datenbank-Server (vllt. Ping, oder über eine UniDAC-Methode (weiß ich noch nicht)). Ist er mal nicht erreichbar, sendet er einen "Broadcast" (eher eine TCP-Nachricht an alle Clients), dass der Server weg ist. Diese zeigen es dann in der GUI an. Vllt. empfängt der Dienst Datenbank-Anfragen, die er zurückhalt, bis die Verbindung wieder aktiv ist. Weitere Aufgaben der Windows-Dienstes sind zeitgesteuerte kleinere Backups (kein Image o.ä.)/Aufräumarbeiten, Benachrichtigungssysteme etc.

* Benachrichtigungssysteme:
- User A und B haben Modul-1 offen. User B ändert Daten über Modul-1. Nun sendet der Dienst eine TCP-Nachricht an alle User, die Modul-1 offen haben, damit sie aktuelle Daten laden können. Bzw, der Server lädt einmal die aktuellen Daten und sendet sie schon an den User.
- Ein wichtiges Modul ist gerade nicht geöffnet. Es wurden aber von B wichtige Daten für A hinterlegt. So wird User A vom Server benachrichtigt, dass wichtige Daten vorliegen.

* Optimierungen: Da z.T. auch über außenstellen gearbeitet wird, ist VPN sehr wichtig (sensible Daten und einfachere Kommunikation). Die Daten sollen also klein gehalten werden. Ein Zwischending zwischen den hier genannten Vorschlägen wird einzuhalten sein. Wenn man gut plant, mitdenkt und den rest durch ausprobieren ermittelt, dann wird es kein Thema sein.

Soweit bin ich erstmal. Hab nur eine Frage zum Format der TCP-Anfragen. Wie soll ein Kommando an den Server aussehen? Es wird ja vermutlich ein String sein. Soll er wie Parameter in URLs aussehen (module=abc&action=getImportantData&dataId=123), soll er in URL-Form sein (/ABC/getImportantData/123), oder soll es ein Record sein TParams (Modul: abc, Action: xyz...). Was macht da Sinn? Man müsste immer mit Explode etc. arbeiten. Habt ihr dazu noch weitere Vorschläge?

Vielen Dank für die rege Anteilnahme!

[Mavarik]

Zitat von DJ-SPM:

Wie soll ein Kommando an den Server aussehen?

Immer ein Record nehmen... Da hast Du alle Felder getrennt und musst nicht extra wieder einen String analysieren.

Mavarik

[Sir Rufo]

Wenn die REST-API LongPolling kann wofür in Gottes Namen dieser Windows-Dienst?

Mehr Komplexität?

Und der Service soll auch noch direkt mit dem Datenbank-Server sprechen, also an der REST-API (Zwischenschicht) vorbei?

Respekt, so kann man viele Vorteile der Zwischenschicht auch gleich wieder mit dem Hintern einreissen

Ich hätte ja noch verstanden, wenn man, aus welchen Gründen auch immer, den Windows-Service per LongPolling mit der Zwischenschicht verbindet. Aber so ist das ein tolles Beispiel, wie man so etwas nicht machen sollte.

[TheMiller]

Ja sorry, du hast natürlich recht. Da habe ich mich vertran. Der Service soll auch nicht direkt mit der Datenbank sprechen. Die Kommuniaktion geht nur über die API. Aber irgendwie muss ich es realisieren, dass der Service prüft (ping o.ä.), ob die Datenbank erreichbar ist. Mehr soll der Service nicht mit der DB direkt machen. Das könnte man ja auch über einen API-Aufruf prüfen - da fällt der Ping weg, der ohnehin nichts darüber aussagt, ob die DB funktioniert/erreichbar ist.

[Sir Rufo]

Zitat von DJ-SPM:

Ja sorry, du hast natürlich recht. Da habe ich mich vertran. Der Service soll auch nicht direkt mit der Datenbank sprechen. Die Kommuniaktion geht nur über die API. Aber irgendwie muss ich es realisieren, dass der Service prüft (ping o.ä.), ob die Datenbank erreichbar ist. Mehr soll der Service nicht mit der DB direkt machen. Das könnte man ja auch über einen API-Aufruf prüfen - da fällt der Ping weg, der ohnehin nichts darüber aussagt, ob die DB funktioniert/erreichbar ist.

Hört sich ja schon besser an, allerdings ist das Benachrichtigungs-System wie du das skizzierst hast etwas ... seltsam.

Wenn du die Nachrichten jetzt pro Modul sendest, dann zieht ja jedes neues Modul eine Änderung in der Nachrichten-Struktur mit sich. Da wäre es doch besser, einfach Nachrichten zu schicken, wenn sich die Daten geändert haben. Das Modul selber bekommt dann diese Information mit, und entscheiden ob es damit etwas zu tun hat oder nicht. Hat es, dann lädt es die betroffenen Daten neu, wenn ich, dann eben einfach nicht.

Erweiterst du jetzt die Module, dann brauchst du das in der Benachrichtigung nicht zu berücksichtigen, denn die Module bekommen das schon mitgeteilt.

Zudem würde ich diese Benachrichtigungen sowieso an die Zugriffs-Interfaces verteilen, wo ich dann jeder den es interessiert registrieren kann.

Delphi-Quellcode:

TDataChangedEventArgs = class( TEventArgs )
  property Action : TDataAction read FAction; // Added, Changed, Removed
  property DataId : TDataId read FDataId;
end;

TDataChangeEventHandler = reference to procedure( const Sender : TObject; e : TDataChangedEventArgs );

IMyRepository = interface
  procedure Get( DataId : TDataId; out Data : TData );
  property DataChanged : IEvent<TDataChangedEventArgs>;
end;

An den DataChanged Event kann sich jeder dranhängen, der das wissen muss und entsprechend reagieren. Das Repository kümmert sich um den Empfang der Nachricht und verteilt diese. Schon können auch neu erstellte Module einfach so auf diese Nachrichten reagieren.

[Sir Rufo]

Kleine Anmerkung:

Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die Microsoft MessageQueue und der Drops ist gelutscht. Jeder Client bekommt eine Queue und für Rückmeldungen auch der Service.

Der Service spricht jetzt mit der REST-API und füllt die MessageQueues der Clients. Die Clients holen sich die Informationen aus Ihrer MessageQueue ab.

Das ist schneller implementiert und vor allem robuster als das mit dem TCP-Client/Server.

[Mavarik]

Zitat von Sir Rufo;1283452Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die [URL="http://technet.microsoft.com/de-de/library/cc771474.aspx":

Microsoft MessageQueue[/URL] und der Drops ist gelutscht.

Ist aber dann - wie ich meine - zu stark an Windows gebunden (ok ein Service auch) aber per TCP kann man auf anderen Plattformen entweder die Routinen dabei linken oder in eine externe App auslagern. Ohne die Kommunikation zu ändern.

Mavarik

[sh17]

Zitat von Sir Rufo:

Kleine Anmerkung:

Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die Microsoft MessageQueue und der Drops ist gelutscht. Jeder Client bekommt eine Queue und für Rückmeldungen auch der Service.

Der Service spricht jetzt mit der REST-API und füllt die MessageQueues der Clients. Die Clients holen sich die Informationen aus Ihrer MessageQueue ab.

Das ist schneller implementiert und vor allem robuster als das mit dem TCP-Client/Server.

Vielleicht auch ein Blick Wert: https://www.habarisoft.com/index.html