Einzelnen Beitrag anzeigen

Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#77

AW: Client/Server Architektur realisieren - Ideen

  Alt 17. Dez 2014, 10:47
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).
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat