File d’attente message vs Web Services ?

Question

Sous quelles conditions une faveur applications de parler par l'intermédiaire d'un message de la file d'attente au lieu de via des services web (je veux dire simplement XML ou JSON ou YAML ou que ce soit sur HTTP ici, pas n'importe quel type)?

J'ai à parler entre deux applications sur un réseau local. L'une sera une application web et pour demander des commandes sur une autre application (en cours d'exécution sur un matériel différent). Les demandes sont des choses comme la création d'utilisateurs, le déplacement de fichiers, et créer des répertoires. Dans quelles conditions je préfère de Services Web XML (ou directement TCP ou quelque chose) à l'aide d'un Message de la file d'attente?

L'application web est Ruby on Rails, mais je pense que la question est plus vaste que cela.

Answer 1

Lorsque vous utilisez un service web que vous avez un client et un serveur:

1. Si le serveur tombe en panne, le client doit prendre la responsabilité de gérer l'erreur.
2. Lorsque le serveur est de nouveau opérationnel le client est responsable de le renvoyer.
3. Si le serveur donne une réponse à l'appel et le client d'échec de l'opération est perdu.
4. Vous n'avez pas de contention, c'est: si des millions de clients font appel à un service web sur un serveur dans un second, plus probablement, votre serveur sera en baisse.
5. Vous pouvez vous attendre à une réponse immédiate à partir du serveur, mais vous pouvez gérer les appels asynchrones.

Lorsque vous utilisez un message de la file d'attente comme RabbitMQ, ActiveMQ, IBM MQ Series, Smoking vous des attentes différentes et plus de tolérance de pannes résultats:

1. Si le serveur tombe en panne, la file d'attente de conserver le message (en option, même si l'arrêt de la machine).
2. Lorsque le serveur est de nouveau opérationnel, il reçoit le message en attente.
3. Si le serveur donne une réponse à l'appel et le client, si le client ne reconnaissent pas la réponse, le message est conservé.
4. Vous avez des problèmes de contention, vous pouvez décider combien de demandes sont traitées par le serveur (appelons-la travailleur à la place).
5. Vous ne vous attendez pas immédiatement une réponse synchrone, mais vous pouvez exécuter/simuler des appels synchrones.

Files d'attente de messages a beaucoup plus de fonctionnalités, mais c'est une règle de base pour décider si vous voulez gérer les conditions d'erreur vous-même ou de les laisser à la file d'attente de messages.

Answer 2

Il y a eu une bonne quantité de la recherche récente en considérant combien il RESTE HTTP appels pourrait remplacer le message de la file d'attente concept.

Si vous introduisez la notion de processus et une tâche comme une ressource, la nécessité pour le centre de messagerie de la couche commence à s'évaporer.

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

Une tâche peut avoir plusieurs étapes pour l'initialisation, et un processus de retour d'état quand il est interrogé ou par la POSTE à une URL de callback.

C'est très simple, et devient très puissant quand vous vous rendez compte que vous pouvez désormais vous abonner à un flux rss/atom de tous les processus en cours et les tâches sans couche intermédiaire. Tout système de file d'attente va nécessiter une certaine sorte de web front-end de toute façon, et ce concept a construit en sans une autre couche de code personnalisé.

Vos ressources d'exister jusqu'à ce que vous les supprimiez, ce qui signifie que vous pouvez afficher les informations d'historique de temps après le processus et de la tâche complète.

Vous avez construit dans le service de découverte, même pour une tâche qui a de multiples étapes, sans supplément compliqué protocoles.

GET /task/name
    - returns form with required fields

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

Votre service à la découverte d'un formulaire HTML universelle et format lisible par l'homme.

L'ensemble des flux peut être utilisée par programme ou par un humain, à l'aide universellement acceptée outils. C'est un client, et donc Reposant. Chaque outil créé pour le web peut piloter vos processus d'affaires. Vous avez encore suppléant message chaînes en Affichant de manière asynchrone dans un tableau distinct des serveurs de journalisation.

Après vous considérez que c'est pour un certain temps, vous vous asseyez en arrière et vous commencez à réaliser que le REPOS peut simplement éliminer la nécessité d'une file d'attente de messagerie et d'un ESB tout à fait.

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

Answer 3

Les files d'attente sont idéales pour les demandes qui peuvent prendre beaucoup de temps. Les demandes sont en attente et peuvent être traitées hors ligne sans bloquer le client. Si le client doit être avisé de la fin, vous pouvez fournir un moyen pour le client de vérifier périodiquement l'état de la demande.

Files d'attente de messages vous permettent également à l'échelle de mieux dans le temps. Il améliore votre capacité à supporter des explosions de forte activité, car le traitement peut être distribué à travers le temps.

Notez que les files d'attente et les services web sont orthogonales concepts, c'est à dire qu'ils ne sont pas mutuellement exclusives. E. g. vous pouvez avoir une base de XML web service qui agit comme une interface pour un message de la file d'attente. Je pense que la distinction que vous cherchez pour est les Files d'attente du rapport Demande/Réponse, le second est lorsque la demande est traitée de façon synchrone.

Answer 4

Les files d'attente de messages sont asynchrones et peuvent réessayer plusieurs fois si la remise échoue. Utilisez une file d'attente de messages si le demandeur n'a pas besoin d'attendre une réponse.

L'expression "services Web" me fait penser aux appels synchrones vers un composant distribué via HTTP. Utilisez les services Web si le demandeur a besoin d'une réponse.

Answer 5

En général, je pense que vous souhaitez un service Web pour une tâche de blocage (ces tâches doivent être effectuées avant d’exécuter plus de code) et une file de messages pour une tâche non bloquante (cela peut prendre un certain temps, mais nous ne le faisons pas). pas besoin de l'attendre).