Client/Server Architektur realisieren - Ideen

[vagtler]

Zitat von Dejan Vu:

[...] 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.[...]

Ich denke, MSMQ hat mit seinen mittlerweile fast 20 Jahren Existenz schon einen gewissen Reifegrad erreicht - wenn nicht sogar seinen Zenit überschritten. Heutzutage sind moderne Message Queue-Server oder (Enterprise) Service Bus-Implementierungen doch schon Standard und werden von Aktor-basierten eventgetriebenen Systemen wie z.B. Akka flankiert.

[Dejan Vu]

Kannste mal sehen, wie langsam ich inzwischen bin. Ich kenne noch nicht einmal mehr die 20 Jahre alten Techniken. das kommt davon, wenn man selbstständig war.

[Mavarik]

Zitat von Dejan Vu:

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.

Sehe ich auch so... Ich versuche mit jedem neuen Projekt auch mindestens "EINE" neue Technik zu verwenden und somit auch zu erlernen.
Aber besonders, wenn man nicht für andere programmiert, sondern selber etwas benötigt. Ist Zeit noch mehr Geld als sonst...

[OT]
Neue Techniken immer wieder:

Blockwrite -> Stream
Record -> Classen
ISAM -> Nativ MySQL -> FireDac
Classen -> ARC -> Interfaces
Create -> Depentency Injection
RAD -> MVVM
Proceduren -> Anonyme Methoden -> Thread's -> Task -> Future
SOAP -> REST -> SOAP
Perl -> ISAPI.DLL -> ASP.NET
DOS -> Windows -> iOS -> Android
TList -> TList<T>
TCP/IP -> Tethering

Jeden Tag was neues.

[/OT]

Mavarik

[Dejan Vu]

Das wichtigste:
Bier->Wein->Rotwein->Rioja->Bier.

[Mavarik]

Zitat von Dejan Vu:

Das wichtigste:
Bier->Wein->Rotwein->Rioja->Bier.

Kaffee -> Sourcecode
oder für die Hacker unter Euch...
Chips & Cola -> Keygenerator

[TheMiller]

Koffeintabletten -> Sourcecode
danach einen Single Malt

Eine Frage habe ich zu den MQs noch: Kann ich damit realisieren, dass andere Clients über Änderungen durch einen Dritten in einem aktiven Plugin automatisch benachrichtigt werden? Ich hatte ja das Szenario beschrieben: 4 Clients haben Plugin A offen, Client 1 ändert Daten und die anderen bekommen mit der Mitteilung, dass sich etwas geändert habe auch automatisch die neuen Daten zur Anzeige mitgeschickt. So wie ich das verstanden habe, funktioniert das. Richtig?
Die MQs schaue ich mir ab heute Abend an.

Und da ohnehin ein Dienst auf der Windows-Kiste läuft, kann ich damit ja auch meine Notfall-Sicherung und Aufräumarbeiten auf Dateiebene erledigen lassen. Oder ist das schädlich für die MessageQueue, weil der Dienst dann mit etwas anderem beschäftigt ist? Ok, Multithreading klar, aber vielleicht sperren sich die Abläufe gegenseitig. Wie gesagt, kenne die MQs noch nicht. Es hört sich aber sehr vernünftig an.

[Sir Rufo]

Also zu den Benachrichtigungen und den Plugins:

Stellen wir uns mal vor, das Modul/Plugin A kann eine Adresse ändern. Es fordert die Adresse mit der ID 42 an, präsentiert diese und der Benutzer kann fleißig ändern. Dann speichert der diese Adresse ab.

Als Nachricht wird nun der gesamte Daten-Satz in Richtung REST-API gesendet, die sich um das tatsächliche Speichern kümmert. Wenn die Daten gespeichert werden konnten, dann wird eine Nachricht in die Runde gesendet, dass sich die Adresse mit der ID 42 geändert hat.

Beispiel (in JSON - das Format ist egal, es geht um die Information)

Code:

{ "context": "address",
  "id": 42,
  "action": "change" }

Jetzt weiß also jeder, dass sich an der Adresse mit der ID 42 etwas geändert hat.

Somit kann auch jeder Client, jedes Modul, jedes Plugin selber entscheiden, ob diese Nachricht relevant ist. Wenn, dann holt man sich diesen Datensatz einfach neu. Den gesamten Datensatz würde ich nicht in die Runde schicken. Wozu auch ... und auch keine speziellen Nachrichten für ein spezielles Plugin/Modul. Wozu?

Jetzt soll irgendwann Modul A nicht nur eine Adresse bearbeiten, sondern auch noch die zugehörigen Rechnungen anzeigen (die werden mit Modul R angezeigt/bearbeitet). Also reagiert das Modul A auch dann, wenn eine Nachricht zu einer Rechnung kommt

Code:

{ "context": "invoice",
  "id": 142421,
  "action": "change" }

Und diese Nachrichten werden einfach per MQ übertragen.

Nachricht in die SERVICE-Queue (der das zur REST-API weiterleitet)

Code:

{ "context": "address",
  "id": 42,
  "firstname": "Peter",
  "lastname": "Lustig" }

und die Nachricht, die der Service an alle CLIENT-Queues sendet, wenn die Aktion erfolgreich war

Code:

{ "context": "address",
  "id": 42,
  "action": "change" }

Man kann die Queues auch fragen, ob die Nachricht xy schon abgeholt wurde. Dadurch kann man verhindern, dass in der Queue für einen Client (nur weil der gerade offline ist) 1000x die Nachricht reinkommt

Code:

{ "context": "address",
  "id": 42,
  "action": "change" }

denn die Nachricht reicht dem einmal. Es ist unerheblich ob ich auf meinem Schreibtisch nach dem Mittag 1000 Zettel oder einen Zettel mit einer Rückrufbitte vorfinde. Die Information ist da und ich will ja auch nicht 1000x zurückrufen, sondern nur einmal. Wenn ich nicht zurückrufen will, dann können da auch 10000000 Zettel liegen, und wenn ich zurückrufen will reicht eben 1 Zettel.

Die MQ laufen völlig unabhängig von den anderen Anwendungen. Die Queue wird abgefragt (wenn die leer ist, dauert die Abfrage 10-20 Sekunden) oder eben mit einer Nachricht gefüttert. MQ kümmert sich darum, dass die Nachrichten bei der Abfrage durch den Consumer in der Reihenfolge ausgeliefert werden, wie die dort eingegangen sind.

Stell dir das einfach wie mit der Email vor. Du schickt die ab und dann kannst du das vergessen (fire-and-forget). Den weiteren Transport erledigen jetzt andere für dich. Und wie im wahren Leben erreicht die Nachricht den Empfänger dann, wenn der in seinen Postkorb schaut (Queue fragt).

[TheMiller]

Wow - Vielen Dank für die sehr gute Erklärung!

Das hat mir schonmal sehr geholfen! Aber hier hast du dich wohl vertippt, oder?

Zitat von Sir Rufo:

Die Queue wird abgefragt (wenn die leer ist, dauert die Abfrage 10-20 Sekunden) oder eben mit einer Nachricht gefüttert.

Du meintest bestimmt Millisekungen, oder?

Ich kann es eigentlich garnicht erwarten, dieses System umzusetzen. Bin gerade begeistert und gespannt!

[Sir Rufo]

Zitat von DJ-SPM:

Wow - Vielen Dank für die sehr gute Erklärung!

Das hat mir schonmal sehr geholfen! Aber hier hast du dich wohl vertippt, oder?

Zitat von Sir Rufo:

Die Queue wird abgefragt (wenn die leer ist, dauert die Abfrage 10-20 Sekunden) oder eben mit einer Nachricht gefüttert.

Du meintest bestimmt Millisekungen, oder?

Ich kann es eigentlich garnicht erwarten, dieses System umzusetzen. Bin gerade begeistert und gespannt!

Nein, ich habe diesen Punkt schon mehrfach erwähnt und es ist so wie gesagt 10-20 Sekunden. Das ist ein sogenannter LongPoll. Du kannst die Queue in einem Thread einfach immer fragen. Wenn dort eine Nachricht ist, bekommst du die sofort geliefert und du kannst die verarbeiten und sofort wieder die Queue fragen. Ist keine Nachricht da, dann bremst dich der MSMQ (aber ja nur den Thread), damit du nicht sinnlos Abfragen durchs Netz flutest. Wenn etwas neues da ist, bekommst du das sofort.

[TheMiller]

Ok, dann ist das ja nicht weiter tragisch. Also wird es in der Praxis so gemacht, dass man ständig pollt. Ich gehe jetzt davon aus, dass die Queue 5 Minuten leer bleibt. Das Programm startet einen MQ-Poll-Thread, wird 10 Sekunden gebremst, kehr mit nichts wieder zurück. Das Programm reagiert im Callback, hat nichts zu verarbeiten und pollt daher unverzüglich wieder die MQ. Es ist aber nicht so, dass die eine Anfrage so lange offen bleibt, bis Daten in der MQ liegen? So wäre es ja bei Ajax/PHP. Das Limit von 10/20 Sekunden ist daher fest von MQ-Server vorgegeben?