Client/Server Architektur realisieren - Ideen

[TheMiller]

Zitat von Sir Rufo:

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.

[Sir Rufo]

Zitat von DJ-SPM:

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.

Ja, kann man machen, erhöht zwar etwas die Komplexität, aber sei es drum.

Eine MessageQueue für den Service und pro Client eine Queue.

Der Service überwacht die eigene Queue und nimmt die Nachrichten und schickt diese an die API. Das was zurückkommt gibt er wieder in die Queue vom Client. Meldet die API, dass eine Änderung erfolgt ist, dann wird auch eine Nachricht in alle anderen Client-Queues geschrieben.

Der Service kann dadurch niemals durch einen nicht antwortenden Client ausgebremst werden. Die Clients sprechen nur mit den 2 Queues (Service, Eigene). Das ist recht einfach umzusetzen.

Eine Chat-Nachricht geht über die Service-Queue an der Service, der verteilt die Nachricht an die passenden Queues (oder erst zur API und dann erst wieder an die Client-Queues). Auf jeden Fall muss hier nicht das Rad neu erfunden werden und die Kommunikationswege sind inkl. der Protokolle ausgelatschte Trampelpfade und keine labile Hängebrücke über einer Schlucht.

[TheMiller]

Moin!

Zitat von Sir Rufo:

Das ist recht einfach umzusetzen.

Hm ja mag sein. Für mich noch sehr verwirrend, da ich - wie gesagt - noch nie mit MessageQueues gearbeitet habe. Hört sich aber gut an. Das heißt aber, dass ich ohnehin einen Windows-Service brauche? Nur halt eben nicht mit TCP-Client/Server, richtig?

Das wäre mir auch am liebsten, wenn ich einen solchen Dienst hätte. Aber ich wüsste nicht, wie es ohne gehen sollte. Du hast ja geschrieben, dass man es "zwar so machen kann", es aber die Komplexität erhöht. Also denkst du wohl an eine andere Lösung. Könntest du sie mir nochmal vorschlagen, ich habe sie wohl nicht mehr im Kopf.

[Sir Rufo]

Ja, der Dienst bleibt, allerdings ist die Kommunikation etwas anders.
Statt

Code:

[REST] <-> [SERVICE] <-> [TCP (Protokoll?) ] <-> [CLIENTS]

einfach

Code:

[REST] <-> [SERVICE] <-> [MSMQ] <-> [CLIENTS]

Wobei das zwischen Service und Clients dann so aussieht

Code:

[SERVICE] <-+-- [MSMQ:SERVICE] <-+
            +-> [MSMQ:CLIENT1] --+-> [CLIENT1]
            +-> [MSMQ:CLIENT2] --+-> [CLIENT2]
            :                     :
            +-> [MSMQ:CLIENTn] --+-> [CLIENTn]

[TheMiller]

Ah okay, das hilft schon sehr. Okay, dann werde ich mich mal ein wenig mit der MessageQueue beschäftigen und die Vor-/Nachteile zwischen MessageQueues und dem TCP-Server rausarbeiten.

Ich bedanke mich schonmal recht herzlich!