Client/Server Architektur realisieren - Ideen

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

[Sir Rufo]

Zitat von DJ-SPM:

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!

Die beiden kann man schlecht vergleichen. Das ist so wie einen Haufen Sand mit einem belebten Bürogebäude zu vergleichen. Natürlich kann man aus einem Haufen Sand auch ein Bürogebäude bauen und dann beleben.

Aber will man sich das wirklich antun? Wäre es da nicht besser, wenn man gleich Einziehen könnte und den Sand in den Sandkasten für die Kinder kippt?

Wenn es jetzt nichts geben würde, oder erst kostspielig angeschafft werden müsste ... ok, ist eine Überlegung wie sich das rechnet, aber MSMQ ist einfach schon da, den muss man nur anhauchen, damit der anfängt zu atmen.

[Mavarik]

Zitat von DJ-SPM:

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.

Die MessageQueue läuft sowieso - wie "alles" im Netzwerk - über UDP/TCP.

Bei einem "kurzen" Telefonat mit Sir Rufo musste ich wieder mal feststellen:
- Nicht die beste Technik ist das wichtigste
- Nicht die schnellste Technik ist das wichtiges
- und auch nicht immer die aus gereifteste Technik ist immer die beste.

Abgesehen davon, dass wir uns in diesem Thread wahrscheinlich viel zu viel über die Technik dahinter unterhalten.

Nach einem sehr kurzen Einblick in MSMQ musste ich feststellen...

- Nutze die Techniken die Du kennst
- Erstelle ein Interface das alles was die Clientapp braucht unterstützt.
- Kümmere Dich später um "das dahinter"

Klar hat MSMQ sicherlich Vorteile - weil ausgereift... Davon gehe ich mal aus...
Aber für das was ich brauche habe ich fertige Routinen. Mit diese Routinen kann ich sofort umgehen.
Bis ich mich in eine neue Technik eingelesen habe, ist mein POC fertig. Vielleicht nicht so toll wie es MS kann...
Aber für meine belange wird es funktionieren.

Mavarik

PS.: Und ich wette ich habe einen größeren Datendurchsatz... Nur so am Rande...

[sh17]

<HALB OT>
Gibt es für Amazon AWS (SQS,...) irgendwie eine OpenSource SDK/Lib für Delphi? Hab nichts gefunden. Das was in Delphi drin ist, ist denke ich erst ab der Enterprise-Version, oder? Sonst müsste ich ganz bei 0 anfangen.
</HALB OT>

[TheMiller]

Zitat von Mavarik:

- Nutze die Techniken die Du kennst

...

Bis ich mich in eine neue Technik eingelesen habe, ist mein POC fertig. Vielleicht nicht so toll wie es MS kann...

Danke für den Hinweis. Deswegen bin ich auch hin- und hergerissen! Einerseits lese ich mich gerne in neue Techniken ein (auch wenn es länger dauert), andererseits wurden die MQ als schnell, zuverlässig und bequem zu nutzen angepriesen. Da fehlt mir die persönliche Erfahrung, habe mir noch kein Umsetzungsbeispiel angesehen und weiß daher auch nicht, wie viel Code es sein wird.

Aus diesen Faktoren habe ich gesagt, dass ich mir die Vor und Nachteile von beiden Möglichkeiten nochmal ansehe und dann entscheiden werde. Ich hatte gehofft, dass ich hier im Forum eine deutlichere Empfehlung bekomme, die mir die Entscheidung ganz klar abnimmt

Aber so ist das auch super. Man muss halt jetzt überlegen, die eigenen Szenarien bewerten und dann bewerten. Mein Favorit ist derzeit der TCP-Server, da ich den kenne und den Aufwand abschätzen kann. Und auch, weil mir die MQ derzeit noch nichts sagt. Es kann natürlich sein, dass ich sofort auf die MQ springe, wenn ich mal eine Umsetzung angesehen habe. Ich hoffe, hier gibt es ein Tutorial zu den MQs.

Auch mit Interfaces (Vor- /Nachteile und Umsetzung) habe ich mich leider noch nicht beschäftigt. Da muss ich mir auch noch Infos und Tutorials suchen.

Ich informiere mich halt ganz genau vorher, da es wirklich ein größeres Projekt ist, welches wir umstellen und nicht in 6 Monaten wieder von vorne anfangen wollen, weil der TCP-Server doch keine so gute Idee war.

[Dejan Vu]

Mir hat vor Jahrzehnten ein damals schon sehr erfahrener IT-Guru gesagt: "Wenn Du den Standards nicht folgst, gehst Du unter".

Natürlich würde ich in meiner Produktivzeit, wenn Termine anstehen, kein neues Projekt mit einer neuen Technik angehen. Aber wenn man immer nur das bewährte verwendet (wogegen grundsätzlich nichts einzuwenden ist), dann ist man wirklich irgendwann einmal 'von gestern', weil man bei keiner aktuellen Technik mehr mitreden kann. Problemlos ist es, wenn man in seiner eigenen Realitätsblase lebt (Selbstständige mit festem Kundenstamm tun das meistens). Allerdings wird man dann mal eben -vroooom- von anderen Überholt, weil man beim Anwenden des Altbewährten eben vergessen hat, vorwärts zu kommen.

Ich will niemanden damit in eine Ecke oder Blase stecken, aber ganz so praktisch orientiert wäre ich da nicht.

Ich halte es so, das ich Arbeiten in bewährter Technik abliefere, aber eifrig dazulerne. Erstens macht das Spaß und zweitens spart mir das morgen eine gehörige Portion Arbeit.

Ich kenne diese MSQ nicht, kann mir aber vorstellen, das in ein paar Jahren im Intranet einiger Firmen keine handgebissenen TCP-Server mehr installiert werden dürfen, sondern alles nur über MSQ realisiert werden darf. Ist man vorbreiteit, kann man sein Angebot mit breitem Grinsen unterbreiten. Hat man den MSQ-Zug verschlafen, darf man kleinlaut abziehen.

[sh17]

Zitat von Dejan Vu:

Mir hat vor Jahrzehnten ein damals schon sehr erfahrener IT-Guru gesagt: "Wenn Du den Standards nicht folgst, gehst Du unter".

Natürlich würde ich in meiner Produktivzeit, wenn Termine anstehen, kein neues Projekt mit einer neuen Technik angehen. Aber wenn man immer nur das bewährte verwendet (wogegen grundsätzlich nichts einzuwenden ist), dann ist man wirklich irgendwann einmal 'von gestern', weil man bei keiner aktuellen Technik mehr mitreden kann. Problemlos ist es, wenn man in seiner eigenen Realitätsblase lebt (Selbstständige mit festem Kundenstamm tun das meistens). Allerdings wird man dann mal eben -vroooom- von anderen Überholt, weil man beim Anwenden des Altbewährten eben vergessen hat, vorwärts zu kommen.....

Jupp. so sieht es aus.