Client/Server Architektur realisieren - Ideen

[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 :thumb:

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:

Zitat von DJ-SPM (Beitrag 1283441)

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

Delphi-Quellcode:

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:

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:

Zitat von Sir Rufo (Beitrag 1283452)

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

[Sir Rufo]

Zitat:

Zitat von Mavarik (Beitrag 1283456)

Zitat:

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

Natürlich, weil die Mobile Devices immer eine ganz hervorragende Netzwerkverbindung haben. Sehr stabil und immer verfügbar. Und wir machen uns zusätzlich noch einen Port auf damit die darüber auch mit dem Windows-Service sprechen können. :roll:

Mobile Devices dürfen bei mir nur über HTTP(S) kommunizieren. Z.B. mit der REST-API. Wenn die eine Instant-Benachrichtigung benötigen, dann benutzte ich die Push-Dienste (dafür sind die wohl auch gedacht, gelle) und die werden von der REST-API dann auch gleich benachrichtigt/gefüttert.

Also wofür wird der Windows-Dienst jetzt nochmal benötigt? ;)

[TheMiller]

Zitat:

Zitat von Sir Rufo (Beitrag 1283469)

Also wofür wird der Windows-Dienst jetzt nochmal benötigt? ;)

So wie ich das verstanden habe, stellt doch der Windows-Dienst die Zwischenschicht zwischen Client und Datenbank-Server dar. Der Cleint sendet die Anfrage an die Zwischenschicht, diese leitet sie an den Datenbank-Server weiter.

Darüber hinaus wollte ich doch noch Datensicherung, Chats, Userverwaltung (Online/Offline-User nebst gültiger IP/VPN-IP), Nachrichtengrabber (enorm wichtig für das Projekt), Update-Service, etc.pp. darüber laufen lassen. Oder nicht?

[Sir Rufo]

Und so wie ich das verstanden habe, willst du eine REST-API vor den Datenspeicher setzen.

Oder wo und was macht die da?

Egal ob Update, Chat, was auch immer, es geht im Grunde immer um Daten holen und Daten speichern. Kann so eine REST-API auf jeden Fall.

[TheMiller]

Genau, die REST-API liegt auf dem Apache-Web-Server auf der Linux-Maschine. Dort liegt auch die MySQL-Datenbank. Auf dem Windows-Server - so dachte ich - ist der Windows-Server-Dienst meines Programmes installiert, der für die Clients mit der API kommuniziert und die Anfragen/Antworten hin und her sendet.