Si vous souhaitez utiliser un produit de mise en 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?
Peuvent ne pas être les "meilleures pratiques" des conseils ici... mais basé sur la vie réelle des besoins et des feuilles: nous avons distribué système, 60 boîtes de l'exécution de chaque 10 clients tout faire tâche X, et ils ont besoin pour prendre la prochaine tâche à partir d'un "Q". Le Q est alimenté à partir d'un autre "client"...
Nous l'avions utilisé inter processus communication, nous avons utilisé MSMQ, nous avons essayé de service broker... Il ne fonctionne tout simplement pas dans le long terme parce que vous êtes loin de donner le contrôle de votre application pour Microsoft. Il fonctionne très bien aussi longtemps que vos besoins soient satisfaits. il devient l'enfer quand vous avez besoin de quelque chose n'est pas pris en charge.
La meilleure solution pour nous a été: Utilisation d'une Base de données SQL de la table comme le "Q". Ne pas réinventer la roue, car vous allez faire des erreurs (écluses). Il y a des infos là-bas sur la façon de le faire, c'est très facile et nous avons géré plus de 200 messages par 24H (avec 60x10 = 600 simultanées lit et écrit sur le "Q"). C'est en outre à même de SQL server le traitement du reste de l'application des trucs...
Quelques raisons pour lesquelles MSMQ ne fonctionne pas:
Lorsque vous avez besoin de changer la logique de la Q non FIFO, mais quelque chose comme "le plus vieux message ROUGE" ou "le vieux BLEU message" vous pouvez;t le faire. (Je sais ce que les gens disent, vous pouvez le faire en ayant un ROUGE Q et un BLEU Q.. .Mais que faire si le nombre de/types de Ques est dynamique basée sur la façon dont l'application est administré et change tous les jours?)
Il ajoute un point de défaillance et de déploiement de cauchemar (le Q est un point de défaillance et vous devez traiter avec réglage du droit des autorisations sur tous les boîtiers de lire/écrire des messages etc " dans les logiciels d'Entreprise que vous payez dans le sang, pour ce genre de choses). SQL server... tous les clients d'écriture/lecture de déjà à partir de la DB, c'est juste un plus de la table..
Je ne peux pas commencer à dire assez de bonnes choses au sujet de Tibco EMS - une implémentation de Java messagerie JMS spec. Tibco EMS a un superbe soutien pour .NET clients - y compris le Compact Framework .NET sur WinCE. (Ils ont aussi C des bibliothèques clientes trop.)
Donc, si vous êtes la construction d'une hétérogènes distribués les applications de messagerie code en cours d'exécution sur Windows, Unix (AIX/Solaris), Linux, ou Mac OS X, Tibco EMS, c'est le billet.
Découvrez mon article ici:
À l'aide de JMS Pour la distribution de Logiciels de Développement
J'ai l'habitude de travailler chez Microsoft et fait de la mise en œuvre avec MSMQ alors qu'il. Mais vous savez, Microsoft vient de l'une des préoccupations majeures de Windows. Ils dépendaient de 3ème parties à fournir les clients MSMQ à d'autres plates-formes. Ma rencontre avec Tibco EMS a été une bien meilleure expérience. Il était bien évident que Tibco compris la messagerie beaucoup plus que Microsoft. Et Tibco mettre l'effort en soutenant diverses client liaisons eux-mêmes. C'est pourquoi ils ont finalement changé le nom du produit de Tibco JMS pour Tibco EMS (Enterprise Messaging Service).
Et j'ai fait construire hétérogène de systèmes logiciels autour de Tibco EMS. Roulé En C# .NET Winform clients d'interagir avec Java/JBoss niveau intermédiaire par Tibco EMS, messagerie. (Et aussi avoir de la Crispation industrielle embarquée ordinateurs qui utilisent le Compact Framework .NET Tibco client.)
Le cadre RabbitMQ semble avoir été négligé ici. Si les gens s'en soucient toujours, il a une base de code .NET 2.0 et il est livré avec une liaison WCF similaire à netMsmqBinding. La liaison nécessite naturellement au moins .NET 3.0 et elle a plus de fonctionnalités que le netMsmqBinding intégré. En plus de tout cela, il est convivial mono. Ça vaut le coup d'oeil.
Pourquoi le courtier de services SQL 2005?
Si le coût n'est pas un problème (il y a aussi un SKU Express), puis prendre un regard sur les 800 000 gorille. WebSphere MQ (MQ Series). Il fonctionne sur pratiquement n'importe quelle plate-forme de soutien, pour beaucoup de différents gestionnaires de file d'attente et les modèles de messagerie, il n'est vraiment pas nécessaire de les énumérer ici.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
