Client/Server Architektur realisieren - Ideen

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

[Sir Rufo]

Ja, das kommt vom MSMQ, damit es eben keine Überflutungen gibt und die Programmierung des Abfrage-Threads ist sehr simpel (beispielhaft skizziert):

Delphi-Quellcode:

procedure TMSMQThread.Execute;
var
  LNachricht : ...
begin
  while not Terminated do
    if NachrichtInQueue( LNachricht ) then
      Queue( 
        procedure
        begin
          TuWasMitNachricht( LNachricht );
        end );
end;

Wenn Nachrichten da sind feuert der wie ein ganz Großer, ansonsten wartet der die meiste Zeit

[Mikkey]

Da muss ich mich mal einmischen...

Wenn man die COM-Objekte der MSMQ verwendet (IMSMQQueue), kann man beim Empfangsversuch die Wartezeit angeben.

Methode Receive:

Function Receive(vTransaction, vWantDestQueue, vWantBody, vReceiveTimeout, vWantConnectorType): IMSMQMessage; Dabei ist vReceiveTimeout ein Variant und gibt die Wartedauer in Millisekunden an.