Überprüfen Sie den Status und das Ergebnis der MSMQ-Nachricht.

Question

Ich arbeite an einem RESTful-Webservice, der Folgendes tut:

1. Bei einer POST-Anfrage startet er eine langlaufende Aufgabe. Er fügt eine Nachricht in die MSMQ-Warteschlange ein, die in der Windows-Dienst gehosteten Anwendung verarbeitet wird. Er gibt den HTTP-Statuscode 202 Accepted zusammen mit der ID des von uns eingereihten Jobs zurück.
2. Die Client-Anwendung ruft den Service kontinuierlich (mit GET) mit der ID des gerade eingereihten Jobs ab. Wenn der MSMQ-Client mit der Aufgabe fertig ist, sollte er das Ergebnis der Operation zurückgeben. Andernfalls wird er 202 Accepted mit dem geeigneten Ablaufdatum für den nächsten empfohlenen Abruf zurückgeben.

Meine Frage ist: Wie sollte ich die Kommunikation von MSMQ zum Webservice implementieren? Speziell, wie würde mein Webservice wissen, ob eine Nachricht vom MSMQ-Client verarbeitet wurde?

Mein erster Gedanke war, eine "job" -Tabelle in der SQL-Datenbank zu haben, die eine JobId, einen Flag zur Anzeige anzeigt ob ein Job abgeschlossen ist und ein Ergebnis der Berechnung enthält. Die MSMQ-Anwendung würde dann in diese Tabelle schreiben, wenn sie einen Job beendet hat, während der Webservice die Datenbank bei jeder Anfrage nach dem Status eines Jobs abfragen würde. Mir gefällt dieser Ansatz nicht so gut, da mein Webservice sonst keinen SQL-Server verwenden würde - die Ergebnisse des Jobs sind idempotent (aber zeitaufwendig) und ich beabsichtige nicht, die von ihm zurückgegebenen Daten auf irgendeine Weise zu speichern.

Ich frage mich, ob es einen idiomatischeren Ansatz für dieses Problem gibt, da dies das erste Mal ist, dass ich mit MSMQ oder Nachrichtenwarteschlangen im Allgemeinen umgehe.

Answer 1

Wenn Sie einen asynchronen Schritt in Ihren Prozess integrieren, sind Sie, ob Sie es wollen oder nicht, in den Bereich der eventuellen Konsistenz eingetreten.

Es gibt inhärente Nachteile bei diesem Ansatz, einer davon ist, dass es erforderlich wird, kontinuierlich nach Konvergenz zu prüfen, wenn der Aufrufer die Wiederherstellung der Systemkonsistenz benötigt.

Dies soll nicht heißen, dass ich mit Ihrem Ansatz nicht einverstanden bin, aber wenn Sie Vanilla MSMQ verwenden, müssen Sie sich der Auswirkungen bewusst sein. MSMQ alleine gibt Ihnen keinerlei Nachrichtenaustauschsemantik, die Sie von einer Service-Bus-Plattform erwarten würden, die Ihnen mehr Optionen bieten würde, wie Sie Ihr aktuelles wahrgenommenes Problem lösen könnten.

Zum Beispiel, wenn Sie über MSMQ "antworten" könnten (indem Sie etwas wie NServiceBus verwenden), könnten Sie eine Art Server-Push-Technologie wie WebApi mit SignalR verwenden, um den Client in Echtzeit zu benachrichtigen, ohne dass dies in die Datenbank persistiert werden muss.

Alternativ könnten Sie den asynchronen Schritt verlieren und durch einen synchronen Aufruf ersetzen, was möglich wäre, wenn der Offline-Prozess schnell genug abgeschlossen würde.

Es sind jedoch komplizierte Ansätze, und Ihre aktuelle Lösung ist meiner Meinung nach viel einfacher.