Des alternatives de file d’attente à MSMQ sous Windows ?[fermé]

StackOverflow https://stackoverflow.com/questions/37579

  •  09-06-2019
  •  | 
  •  

Question

Si vous souhaitez utiliser un produit de file d'attente pour une messagerie durable sous Windows, exécutant .NET 2.0 et supérieur, quelles alternatives à MSMQ existent aujourd'hui ?Je connais ActiveMQ (http://activemq.apache.org/), et j'ai vu des références à WSMQ (pointant vers http://wsmq.net), mais le site semble être en panne.

Y a-t-il d'autres alternatives?

Était-ce utile?

La solution

Je ne peux pas commencer à dire assez de bonnes choses sur Tibco EMS - une implémentation de la spécification de messagerie Java JMS.Tibco EMS offre une excellente prise en charge des clients .NET, notamment Compact Framework .NET sur WinCE.(Ils ont également des bibliothèques clientes C.)

Ainsi, si vous créez une application distribuée hétérogène impliquant du code de messagerie exécuté sous Windows, Unix (AIX/Solaris), Linux ou Mac OS X, alors Tibco EMS est la solution idéale.

Consultez mon article ici :

Utilisation de JMS pour le développement de logiciels distribués

J'ai travaillé chez Microsoft et j'ai effectué quelques implémentations avec MSMQ pendant mon séjour.Mais vous savez, Microsoft ne s'intéresse qu'à Windows.Ils dépendaient de tiers pour fournir des clients MSMQ à d'autres plateformes.Ma rencontre avec Tibco EMS a été une bien meilleure expérience.Il était évident que Tibco comprenait la messagerie bien mieux que Microsoft.Et Tibco s'est efforcé de prendre en charge diverses liaisons client elles-mêmes.C'est pourquoi ils ont finalement changé le nom du produit Tibco JMS en Tibco EMS (Enterprise Messaging Service).

Et j'ai construit des systèmes logiciels hétérogènes autour de Tibco EMS.Clients C# .NET Winform laminés interagissant avec le niveau intermédiaire Java/JBoss via la messagerie Tibco EMS.(Et disposez également d'ordinateurs industriels intégrés WinCE qui utilisent le client Compact Framework .NET Tibco.)

Liens vers mes écrits JMS

Autres conseils

Ce n'est peut-être pas un conseil de "meilleure pratique" ici...mais basé sur des besoins et une expérience réels :nous avons un système distribué, 60 boîtes exécutant chacune 10 clients effectuent toutes la tâche X, et ils doivent prendre la tâche suivante dans une file d'attente.La file d'attente est alimentée par un autre "client"...

Nous avions utilisé la communication inter-processus, nous avons utilisé MSMQ, nous avons essayé le service Broker...Cela ne fonctionne tout simplement pas à long terme, car vous confiez le contrôle de votre application à Microsoft.Cela fonctionne très bien tant que vos besoins sont satisfaits.cela devient un enfer quand vous avez besoin de quelque chose qui n'est pas pris en charge.

La meilleure solution pour nous était :Utilisez une table de base de données SQL comme file d'attente.Ne réinventez pas la roue ici, car vous feriez des erreurs (verrouillages).Il existe des informations sur la façon de procéder, c'est très simple et nous avons traité plus de 200 000 messages par 24 heures (avec 60x10 = 600 lectures et écritures simultanées dans la file d'attente).Cela s'ajoute au même serveur SQL qui gère le reste des applications...

Quelques raisons pour lesquelles MSMQ ne fonctionne pas :

  1. Lorsque vous devez modifier la logique de la file d'attente non pas en FIFO, mais en quelque chose comme "le message ROUGE le plus ancien" ou "le message BLEU le plus ancien", vous ne pouvez pas le faire.(Je sais ce que les gens diront, vous pouvez le faire en ayant un file d'attente rouge et un file d'attente bleue...Mais que se passe-t-il si le nombre/les types de files d'attente sont dynamiques en fonction de la façon dont l'application est administrée et changent quotidiennement ?)

  2. Cela ajoute un point d'échec et un cauchemar de déploiement (la file d'attente est un point d'échec et vous devez définir les bonnes autorisations sur toutes les boîtes pour lire/écrire des messages, etc. dans les logiciels d'entreprise, vous payez du sang pour ce genre de choses) .Serveur SQL...tous les clients écrivent/lisent déjà à partir de la base de données, ce n'est qu'une table de plus.

Le framework RabbitMQ semble avoir été négligé ici.Si les gens s'en soucient toujours, il dispose d'une base de code .NET 2.0 et est livré avec une liaison WCF similaire à netMsmqBinding.La liaison nécessite naturellement au moins .NET 3.0 et possède plus de fonctionnalités que le netMsmqBinding intégré.En plus de tout cela, il est compatible avec Mono.Ça vaut le détour.

Qu'en est-il de SQL 2005 courtier en services?

Pourquoi ne pas utiliser ActiveMQ ?:)

Si le coût n'est pas un problème (il existe également un SKU Express), puis jetez un œil au gorille de 800 000 livres.WebSphere MQ (série MQ).Il fonctionne sur pratiquement toutes les plates-formes et prend en charge un si grand nombre de gestionnaires de files d'attente et de modèles de messagerie différents qu'il n'est vraiment pas approprié de les répertorier ici.

Si la haute disponibilité est importante, Amazon SQS mérite d’être examiné.Il n'y a pas beaucoup de surcharge supplémentaire si les messages proviennent de différents emplacements physiques.Pas cher et évolutif !

Redis est une autre race chaude sur cette plateforme.Vérifiez auprès de leur implémentation de mise en file d'attente basée sur Set ainsi que du modèle Pub/Sub.Ça a l'air promotionnel

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top