Message Queue vs. Web Services?
Dans quelles conditions est-il préférable de préférer les applications qui parlent via une file d'attente de messages plutôt que via des services Web (je parle simplement de XML, JSON ou YAML ou peu importe via HTTP ici, pas de type particulier)?
Je dois parler entre deux applications sur un réseau local. L'une d'elles sera une application Web et devra demander des commandes sur une autre application (exécutée sur un matériel différent). Les demandes concernent par exemple la création d'utilisateurs, le déplacement de fichiers et la création de répertoires. Dans quelles conditions préférerais-je utiliser les services Web XML (ou TCP ou quelque chose du genre) plutôt que d'utiliser une file d'attente de messages?
L'application Web est Ruby sur Rails, mais je pense que la question est plus large que cela.
Lorsque vous utilisez un service Web, vous avez un client et un serveur:
- Si le serveur échoue, le client doit assumer la responsabilité de gérer l’erreur.
- Lorsque le serveur fonctionne à nouveau, le client est responsable de le renvoyer.
- Si le serveur répond à l'appel et que le client échoue, l'opération est perdue.
- Vous n'avez pas de problème, c'est-à-dire que si des millions de clients appellent un service Web sur un serveur à la seconde, votre serveur tombera probablement en panne.
- Vous pouvez vous attendre à une réponse immédiate du serveur, mais vous pouvez également gérer les appels asynchrones.
Lorsque vous utilisez une file d'attente de messages telle que RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, vous attendez des résultats différents et plus tolérants aux pannes:
- Si le serveur échoue, la file d'attente conserve le message (éventuellement, même si l'ordinateur est arrêté).
- Lorsque le serveur fonctionne à nouveau, il reçoit le message en attente.
- Si le serveur répond à l'appel et que le client échoue, si le client n'a pas accusé réception de la réponse, le message est conservé.
- Vous avez des conflits, vous pouvez décider du nombre de demandes traitées par le serveur (appelez-le travailleur à la place).
- Vous ne vous attendez pas à une réponse synchrone immédiate, mais vous pouvez implémenter/simuler des appels synchrones.
Message Queues a beaucoup plus de fonctionnalités mais c'est une règle de base pour décider si vous voulez gérer vous-même les conditions d'erreur ou les laisser dans la file d'attente des messages.
Des recherches récentes ont été effectuées pour déterminer comment REST appels HTTP pourrait remplacer le concept de file d'attente de messages.
Si vous introduisez le concept de processus et de tâche en tant que ressource, le besoin d'une couche de messagerie intermédiaire 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 comporter plusieurs étapes pour l'initialisation et un processus peut renvoyer l'état lorsqu'il est interrogé ou POST à une URL de rappel une fois l'opération terminée.
C'est très simple et cela devient assez puissant quand vous réalisez que vous pouvez maintenant vous abonner à un flux rss/atom de tous les processus et tâches en cours d'exécution sans couche intermédiaire. De toute façon, tout système de file d'attente nécessitera une sorte de serveur Web, et ce concept l'a intégré sans autre couche de code personnalisé.
Vos ressources existent jusqu'à ce que vous les supprimiez, ce qui signifie que vous pouvez afficher des informations historiques longtemps après la fin du processus et de la tâche.
Vous avez intégré la découverte de services, même pour une tâche comportant plusieurs étapes, sans aucun protocole compliqué supplémentaire.
GET /task/name
- returns form with required fields
POST (URL provided form's "action" attribute)
Votre découverte de service est un formulaire HTML - un format universel et lisible par l'homme.
L'ensemble du flux peut être utilisé par programme ou par un humain, à l'aide d'outils universellement acceptés. C'est un client axé, et donc RESTful. Chaque outil créé pour le Web peut piloter vos processus métier. Vous disposez toujours de canaux de messages alternatifs en POSTant de manière asynchrone sur un tableau séparé de serveurs de journaux.
Après y avoir réfléchi pendant un moment, vous vous reposez et commencez à réaliser que REST peut simplement éliminer le besoin d'une file d'attente de messagerie et d'un ESB.
Les files de messages sont idéales pour les demandes dont le traitement peut prendre beaucoup de temps. Les demandes sont en file d'attente et peuvent être traitées hors ligne sans bloquer le client. Si le client doit être averti de l'achèvement, vous pouvez lui fournir un moyen de vérifier périodiquement le statut de la demande.
Les files de messages vous permettent également de mieux évoluer dans le temps. Il améliore votre capacité à gérer les pics d'activité, car le traitement réel peut être réparti dans le temps.
Notez que les files de messages et les services Web sont des concepts orthogonaux, c’est-à-dire qu’ils ne s’excluent pas mutuellement. Par exemple. vous pouvez avoir un service Web basé sur XML qui sert d’interface à une file de messages. Je pense que la distinction que vous recherchez est celle de Message Queues versus Request/Response, cette dernière étant lorsque la demande est traitée de manière synchrone.
Les files 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 à des appels synchrones à un composant distribué via HTTP. Utilisez les services Web si le demandeur a besoin d'une réponse.
Je pense qu'en général, vous voudriez un service Web pour une tâche de blocage (cette tâche doit être terminée 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 pas besoin d'attendre).