Multidiffusion, messagerie, ActiveMQ vs.MSMQ ?

Question

Je travaille sur un système de messagerie/notification pour nos produits.Les exigences de base sont :

• Tire et oublie
• Ensemble persistant de messages, éventuellement mis à jour, pour y rester jusqu'à ce que l'expéditeur demande de les supprimer

Les bibliothèques seront écrites en C#.Spring.NET vient de publier une version importante avec de nombreuses abstractions de messagerie intéressantes, ce qui est génial - je prévois de l'utiliser intensivement.Ma question fondamentale se résume à la question des courtiers de messages.Mon architecture ressemblera à quelque chose comme application -> file d'attente du courtier de messages -> application serveur qui écoute, distribue tous les messages là où ils doivent aller et gère le cycle de vie de ces messages de longue durée -> file d'attente ou sujet du courtier de messages -> écoute applications.

Enfin, la question :Quel courtier de messages dois-je utiliser ?Je suis partisan ActiveMQ - Nous l'avons utilisé sur notre dernier projet et nous l'avons adoré.Je ne peux pas vraiment penser à une seule attaque contre lui, sauf qu'il s'agit de Java et qu'il nécessitera que Java soit installé sur un serveur quelque part, ce qui pourrait être difficile à vendre à certaines des personnes qui utiliseront ce service.L'autre option que j'ai envisagée est MSMQ.Je suis partial contre cela pour une raison inconnue, et il ne semble pas non plus avoir un excellent support de multidiffusion.

Quelqu'un a-t-il utilisé MSMQ pour quelque chose comme ça ?Y a-t-il des avantages ou des inconvénients, des éléments qui pourraient influencer le vote dans un sens ou dans l’autre ?

Une dernière chose, nous utilisons .NET 2.0.

Answer 1

Je suis un peu partial lorsque je travaille sur ActiveMQ mais presque tous les avantages répertoriés ci-dessus pour MSMQ s'appliquent également à ActiveMQ.

Certains autres avantages d'ActiveMQ incluent

• un grand soutien pour accès client multilingue et prise en charge multi-protocoles
• un excellent soutien pour modèles d'intégration d'entreprise
• une tonne de fonctionnalités avancées comme files d'attente exclusives et groupes de messages

Le principal inconvénient que vous mentionnez est que le courtier ActiveMQ est écrit en Java ;mais vous pouvez l'exécuter sur IKVM en tant qu'assembly .net si vous le souhaitez vraiment - ou l'exécuter en tant que service Windows, ou le compiler en DLL/EXE via GCJ.MSMQ peut ou non être écrit en .NET - mais la manière dont il est implémenté n'a pas vraiment d'importance, n'est-ce pas ?

Que vous choisissiez MSMQ ou ActiveMQ, je vous recommande au moins d'envisager d'utiliser le API NMS qui, comme vous le dites, est parfaitement intégré à Spring.NET.Il existe une implémentation MSMQ de cette API ainsi que des implémentations pour TibCo, ActiveMQ et STOMP qui prendront en charge tout autre fournisseur JMS via StompConnect.

Ainsi, en choisissant NMS comme API, vous éviterez de vous enfermer dans une technologie propriétaire - et vous pourrez alors facilement changer de fournisseur de messagerie à tout moment ;plutôt que de verrouiller votre code dans une API propriétaire

Answer 2

Avantages pour MSMQ.

• Il est intégré à Windows
• Il prend en charge les transactions, il prend également en charge les files d'attente sans transactions
• C'est vraiment facile à configurer
• Intégration AD
• C'est rapide, mais vous devrez comparer ActiveMQ et MSMQ pour votre trafic afin de savoir lequel est le plus rapide.
• .NET prend en charge la nativité
• Supporte le feu et oublie
• Vous pouvez jeter un coup d’œil à la file d’attente si vous avez des lecteurs qui se contentent de regarder.Je ne sais pas si vous pouvez modifier un message dans la file d'attente.

Les inconvénients:

• Taille limite des messages de 4 Mo
• Limite de taille de file d'attente de 2 Go
• Les éléments de la file d'attente sont conservés sur le disque
• Ce n'est pas un produit MS grand public, les documents sont un peu incertains, ou cela fait quelques années que je ne l'ai pas utilisé.

Voici un bon blog pour MSMQ

Answer 3

Jeter un coup d'œil à zéromq.C'est l'une des files d'attente de messages les plus rapides du marché.

Answer 4

Je vous suggère de jeter un œil à TIBCO Enterprise Messaging Service - EMS, qui est un produit de messagerie hautes performances qui prend en charge la multidiffusion, le routage, prend en charge la spécification JMS et fournit des fonctionnalités à l'échelle de l'entreprise, y compris vos exigences telles que l'oubli du feu et la persistance des messages à l'aide de fichiers/bases de données. état partagé.

En tant que référence, FedEx fonctionne sur TIBCO EMS comme infrastructure de messagerie.

http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp

Il y a beaucoup d'autres références si je vous les fournis, vous seriez vraiment surpris.

Answer 5

Il y a tellement d'options dans ce domaine...

Gratuit:MantaRay, un système peer to peer entièrement conforme à JMS.La partie intéressante de Mantaray est qu'il vous suffit de définir où va le message et MantaRay l'achemine de toute façon pour que votre message arrive à sa destination - il est donc plus résistant aux pannes de nœuds individuels dans votre structure de messagerie.

Payé:Dans mon travail quotidien, j'administre un système de messagerie IBM WebSphere MQ avec plusieurs centaines de nœuds et je le trouve très performant.Nous avons également récemment acheté Tibco EMS et il semble que ce sera également très agréable à utiliser.

Paul/