Meine Frage ist: wird es nicht schneller, wenn der Server anstatt den Client zu Benachrichtigen den Datensatz direkt an den Client weiterleitet? So wird eine
DB-Abfrage und somit auch die wertvolle Zeit gesparrt. Wäre das nicht schneller?
Vorausgesetzt der Client ist gerade nicht durch andere Aufgaben stark ausgelastet, und die Datensätze kommen nicht zu schnell an, ist das sicher eine Option.
Der Server muss aber möglicherweise den Datensatz erst einmal speichern und wieder auslesen bevor er ihn zum Client sendet, falls Trigger oder andere Automatismen in der Datenbank den Satz verändern können (zum Beispiel Defaultwerte die beim Insert von NULL Werten aktiv werden).
Was aber macht der Server wenn die Clientverbindung während der Übertragung abbricht? Message Broker Clients können Nachrichten auch transaktional empfangen, oder je Nachricht ein "Acknowledge" senden damit der Server die Übertragung als erfolgreich ansieht. Die Nachricht wird dann so lange gesendet bis der Client sie erhalten hat ("Guaranteed Delivery"), optional sogar wenn der Client zwischendurch offline war.
Im konkreten Anwendungsfall hätte es aber einen Nachteil, die Datensätze komplett zu senden: wenn der Client die Nachricht erst mit Verspätung erhält, zum Beispiel weil ein ganzer Stapel auf einmal eintrifft, ist die letzte Nachricht möglicherweise schon nicht mehr auf dem aktuellen Stand. Die Gefahr veralteter Daten ist geringer, wenn man die Datensatz-ID in die Nachricht mit aufnimmt, und den Client damit in die Lage versetzt auf den aktuellen Stand des Satzes zuzugreifen.
Hier ist ein Pseudocodebeispiel wie ein Message Broker die (gefilterten) Nachrichten an den Client sendet. Es geht davon aus, dass eingehende Aufträge nach Postleitzahlgebieten den Mitarbeitern zugeordnet werden.
Code:
Client: CONNECT (meldet sich an mit Benutzer / Password)
Server: CONNECTED
Code:
Client: SEND "Hallo Server, bitte konfiguriere mich!"
Server: MESSAGE Ihre Postleitzahlgebiete sind: QUEUE4A=PLZ40000-44999, QUEUE6=PLZ60000-69999
Der Client wählt, welche Queues (Auftragswarteschlangen) er bearbeiten möchte:
Code:
Client: SUBSCRIBE QUEUE4A
Client: SUBSCRIBE QUEUE6
Der Client kann jetzt (in einer Schleife in einem Backgroundthread) auf neue Nachrichten prüfen. Das Prüfen ist dabei
kein Polling, sondern nur ein Überwachen des
TCP Sockets auf eintreffende Pakete. Der Client kann einen Timeout angeben und bei einem Kommunikationsfehler erneut mit dem Server verbinden.
Sobald ein neuer Auftrag eintrifft, sendet der Server ihn an die jeweilige Queue:
Code:
Server: MESSAGE ID=123, Auftrag="12356", (weitere Daten)
Client stellt Daten in
GUI dar und besätigt Empfang:
Client: ACK 123
Durch das ACK erfährt der Server, dass der Client die Daten erhalten und bestätigt hat. Das ist sehr wichtig, da Senden über
TCP/
IP nicht heisst, dass der Client die Daten empfangen hat.
Diese Aufteilung auf "Queues" ist auch eine einfache Lösung für den Fall, dass zwei Mitarbeiter den gleichen Postleitzahlenbereich bearbeiten, aber ein Auftrag immer nur von einem Mitarbeiter zur Bearbeitung angenommen werden darf.
Denn das ist ein Merkmal der "Queues" in einem Message Broker: es wird maximal nur ein Client die Nachricht erhalten. Die Aufträge für ein PLZ-Gebiet werden dadurch automatisch auf alle angemeldeten Clients verteilt, die sich an dieser Queue registriert haben. Falls der Empfang oder die Verarbeitung der Nachricht scheitert und der Server kein ACK erhält, wird die Nachricht dem nächsten passenden Client zugestellt.