Nachrichtenwarteschlange vs. Webdienste? [geschlossen]

Unter welchen Bedingungen würde man Apps bevorzugen, die über eine Nachrichtenwarteschlange anstatt über Webdienste kommunizieren (ich meine hier nur XML oder JSON oder YAML oder was auch immer über HTTP, keinen bestimmten Typ)?

Ich muss zwischen zwei Apps in einem lokalen Netzwerk sprechen. Eine davon ist eine Web-App und muss Befehle für eine andere App anfordern (die auf einer anderen Hardware ausgeführt wird). Bei den Anforderungen handelt es sich beispielsweise um das Erstellen von Benutzern, das Verschieben von Dateien und das Erstellen von Verzeichnissen. Unter welchen Bedingungen würde ich XML-Webdienste (oder direktes TCP oder ähnliches) der Verwendung einer Nachrichtenwarteschlange vorziehen?

Die Web-App ist Ruby on Rails, aber ich denke, die Frage ist weiter gefasst.

Wenn Sie einen Webdienst verwenden, haben Sie einen Client und einen Server:

1. Wenn der Server ausfällt, muss der Client die Verantwortung für die Behandlung des Fehlers übernehmen.
2. Wenn der Server wieder funktioniert, ist der Client für das erneute Senden verantwortlich.
3. Wenn der Server eine Antwort auf den Anruf gibt und der Client fehlschlägt, geht der Vorgang verloren.
4. Sie haben keine Konflikte, das heißt: Wenn Millionen von Clients in einer Sekunde einen Webdienst auf einem Server aufrufen, fällt Ihr Server höchstwahrscheinlich aus.
5. Sie können eine sofortige Antwort vom Server erwarten, aber Sie können auch asynchrone Anrufe verarbeiten.

Wenn Sie eine Nachrichtenwarteschlange wie RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series und Tuxedo verwenden, erwarten Sie unterschiedliche und fehlertolerantere Ergebnisse:

1. Wenn der Server ausfällt, bleibt die Nachricht in der Warteschlange erhalten (optional auch, wenn der Computer heruntergefahren wird).
2. Wenn der Server wieder arbeitet, erhält er die ausstehende Nachricht.
3. Wenn der Server eine Antwort auf den Anruf gibt und der Client fehlschlägt, bleibt die Nachricht bestehen, wenn der Client die Antwort nicht bestätigt hat.
4. Wenn Sie Konflikte haben, können Sie entscheiden, wie viele Anforderungen vom Server verarbeitet werden (nennen Sie es stattdessen Worker).
5. Sie erwarten keine sofortige synchrone Antwort, können jedoch synchrone Anrufe implementieren / simulieren.

Nachrichtenwarteschlangen bieten viel mehr Funktionen. Dies ist jedoch eine Faustregel, um zu entscheiden, ob Sie Fehlerbedingungen selbst behandeln oder in der Nachrichtenwarteschlange belassen möchten.

In jüngster Zeit wurde viel darüber nachgedacht, wie REST-HTTP-Aufrufe das Konzept der Nachrichtenwarteschlange ersetzen könnten.

Wenn Sie das Konzept eines Prozesses und einer Aufgabe als Ressource einführen, beginnt der Bedarf an mittlerer Messaging-Schicht zu schwinden.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Eine Aufgabe kann mehrere Schritte für die Initialisierung umfassen, und ein Prozess kann den Status bei Abfrage zurückgeben oder nach Abschluss an eine Rückruf-URL senden.

Dies ist denkbar einfach und wird sehr leistungsfähig, wenn Sie feststellen, dass Sie jetzt einen RSS / Atom-Feed aller laufenden Prozesse und Aufgaben ohne mittlere Ebene abonnieren können. Jedes Warteschlangensystem erfordert ohnehin eine Art Web-Frontend, und dieses Konzept hat es ohne eine weitere Ebene von benutzerdefiniertem Code eingebaut.

Ihre Ressourcen sind vorhanden, bis Sie sie löschen. Dies bedeutet, dass Sie historische Informationen lange nach Abschluss des Prozesses und der Aufgabe anzeigen können.

Sie haben die Serviceerkennung selbst für eine Aufgabe mit mehreren Schritten ohne besonders komplizierte Protokolle integriert.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Ihre Serviceerkennung ist ein HTML-Formular - ein universelles und für Menschen lesbares Format.

Der gesamte Fluss kann programmgesteuert oder von einem Menschen unter Verwendung allgemein anerkannter Werkzeuge verwendet werden. Es ist kundenorientiert und daher RESTful. Jedes für das Web erstellte Tool kann Ihre Geschäftsprozesse steuern. Sie haben immer noch alternative Nachrichtenkanäle, indem Sie asynchron auf ein separates Array von Protokollservern POSTEN.

Nachdem Sie eine Weile darüber nachgedacht haben, lehnen Sie sich zurück und stellen fest, dass REST möglicherweise keine Messaging-Warteschlange und keinen ESB mehr benötigt.

http://www.infoq.com/presentations/BPM-with-REST

Nachrichtenwarteschlangen sind ideal für Anforderungen, deren Verarbeitung lange dauern kann. Anforderungen werden in die Warteschlange gestellt und können offline verarbeitet werden, ohne den Client zu blockieren. Wenn der Client über den Abschluss informiert werden muss, können Sie dem Client die Möglichkeit geben, den Status der Anforderung regelmäßig zu überprüfen.

Mit Nachrichtenwarteschlangen können Sie auch im Laufe der Zeit besser skalieren. Es verbessert Ihre Fähigkeit, Bursts mit hoher Aktivität zu verarbeiten, da die eigentliche Verarbeitung über die Zeit verteilt werden kann.

Beachten Sie, dass Nachrichtenwarteschlangen und Webdienste orthogonale Konzepte sind, dh sich nicht gegenseitig ausschließen. Sie können beispielsweise einen XML-basierten Webdienst verwenden, der als Schnittstelle zu einer Nachrichtenwarteschlange fungiert. Ich denke, der Unterschied, den Sie suchen, ist Nachrichtenwarteschlangen gegenüber Anfrage / Antwort. Letzteres ist, wenn die Anfrage synchron verarbeitet wird.

Nachrichtenwarteschlangen sind asynchron und können mehrere Male wiederholt werden, wenn die Zustellung fehlschlägt. Verwenden Sie eine Nachrichtenwarteschlange, wenn der Anforderer nicht auf eine Antwort warten muss.

Der Ausdruck "Webdienste" lässt mich an synchrone Aufrufe einer verteilten Komponente über HTTP denken. Verwenden Sie Webdienste, wenn der Anforderer eine Antwort benötigt.

Ich denke, im Allgemeinen möchten Sie einen Webdienst für eine Blockierungsaufgabe (diese Aufgaben müssen abgeschlossen sein, bevor wir mehr Code ausführen) und eine Nachrichtenwarteschlange für eine nicht blockierende Aufgabe (kann eine Weile dauern, aber wir tun es nicht muss nicht darauf warten).