Comment RabbitMQ se compare-t-il à Mule?
Comment RabbitMQ se compare-t-il à Mule? Je vais construire une application utilisant une architecture orientée message et AMQP (RabbitMQ) fournit tout ce que je veux, mais je suis perplexe devant tant de choix technologiques connexes et de concepts similaires tels que ESB. J'ai un doute si je fais un choix sans envisager d'autres solutions.
Je suis surtout clair que RabbitMQ est un courtier de messages et il m’aide à faire la médiation entre les producteurs et les consommateurs (abonnez-vous à tous les formulaires ou publiez et je pourrais comprendre comment il est utilisé à partir d’exemples réels comme Twitter, les mises à jour Facebook, etc.
Qu'est-ce que Mule, si je pouvais réaliser ce que je fais dans RabbitMQ en utilisant mule, devrais-je envisager un mule similaire à RabbitMQ?
Mule a-t-il un objectif différent de celui d'un courtier en messages?
Est-ce que mule suppose qu'il y a un courtier de messages sous-jacent qui délivre le message aux écouteurs appropriés (je pourrais facilement écrire un auditeur dans RabbitMQ)
Est-ce que mule est un système de bases Java complet (l'expérience actuelle que j'ai faite avec RabbitMQ m'a pris moins de 30 minutes pour écrire un serveur client RPC simple avec un client en C # et un serveur en Java, ces tâches seront-elles effectuées facilement dans Mule).
Mule est un ESB (Enterprise Service Bus). RabbitMQ est un courtier en messages.
Un ESB fournit des couches supplémentaires au sommet d'un courtier de messages, telles que le routage, les transformations et la gestion des processus métier. Il s’agit d’un médiateur entre les applications, intégrant les services Web, REST points de terminaison, les connexions à une base de données, les serveurs de messagerie et les serveurs ftp - vous le nommez. Il s’agit d’un backbone d’intégration de haut niveau qui orchestre l’interopérabilité au sein d’un réseau d’applications utilisant différents protocoles.
UNE courtier de messages est un composant de niveau inférieur qui vous permet, en tant que développeur, de relayer les messages bruts entre les éditeurs et les abonnés, généralement entre les composants du même système, mais pas toujours. Il est utilisé pour permettre le traitement asynchrone afin de maintenir les temps de réponse bas. Certaines tâches prennent plus de temps à traiter et vous ne voulez pas qu'elles retardent les choses si elles ne sont pas urgentes. Publiez plutôt un message dans une file d'attente (en tant qu'éditeur) et demandez à un abonné de le récupérer et de le traiter "plus tard".
Mule est un service de "niveau supérieur" implémenté avec un courtier de messages. De la docs
Le backbone de messagerie du ESB est Généralement implémenté à l'aide de JMS, mais toute Autre implémentation de serveur de messagerie Peut être utilisée.
Vous pouvez construire un ESB avec un lapin. toutefois, vous ne pourrez envoyer que des paquets d'octets [] et vous devrez créer votre système à partir de primitives de messagerie telles que les sujets et les files d'attente. Cela pourrait être un peu plus rapide (sans aucune analyse comparative, test ou donnée), car il y a moins de couches de traduction. Mule fournit une abstraction supplémentaire, parle une variété de transports et peut gérer une logique de routage.
RabbitMQ, un logiciel de courtier de messages open source est écrit en langage de programmation Erlang et repose sur la plate-forme Open Telecom pour la mise en cluster et le basculement. Il est facile à utiliser, prend en charge un grand nombre de plates-formes de développement et fonctionne sur tous les principaux systèmes d'exploitation. Il fonctionne sur un concept appelé Exchange. Mule connecte RabbitMQ au connecteur AMQP.
Mule est un bus de service d'entreprise offrant une solution d'intégration de bout en bout dans laquelle Rabbit est un courtier de messages pour la mise en file d'attente des messages entre l'abonné et le destinataire.