Если вы хотите использовать продукт массового обслуживания для долговременного обмена сообщениями под Windows, работающий на .NET 2.0 и выше, какие альтернативы MSMQ существуют сегодня? Я знаю ActiveMQ (http://activemq.apache.org/), и я видел ссылки на WSMQ (указывающий на http://wsmq.net), но сайт, похоже, не работает.
Есть ли другие альтернативы?
Я не могу начать говорить о хороших вещах о Tibco EMS - реализации спецификации Java JMS для обмена сообщениями. Tibco EMS обладает превосходной поддержкой для клиентов .NET, включая Compact Framework.NET на WinCE. (У них также есть библиотеки клиентов C).
Итак, если вы создаете гетерогенное распределенное приложение с кодом обмена сообщениями, работающим в Windows, Unix (AIX/Solaris), Linux или Mac OS X, то Tibco EMS - это билет.
Посмотрите мою статью здесь:
Использование JMS для разработки распределенного программного обеспечения
Я работал в Microsoft и выполнял некоторую реализацию с MSMQ там. Но вы знаете, Microsoft просто относится к Windows. Они зависели от третьих сторон для предоставления клиентам MSMQ другим платформам. Моя встреча с Tibco EMS была намного лучше. Было очень очевидно, что Тибко понимал сообщения гораздо больше, чем Microsoft. И Tibco прилагал усилия для поддержки разнообразных клиентских привязок. Именно поэтому они в конечном итоге изменили название продукта от Tibco JMS до Tibco EMS (Enterprise Messaging Service).
И я создал гетерогенные программные системы вокруг Tibco EMS. Обрабатываемые клиенты С#.NET Winform, взаимодействующие с средним уровнем Java/JBoss посредством обмена сообщениями Tibco EMS. (И также имеют промышленные встроенные компьютеры WinCE, которые используют клиент Compact Framework.NET Tibco.)
Не может быть советом "лучшей практики" здесь... но на основе реальных жизненных потребностей и опыта: у нас есть распределенная система, 60 ящиков, работающих на каждом из 10 клиентов, все выполняют задачу X, и им необходимо выполнить следующую задачу из очереди. Очередь подается от одного другого "клиента"...
Мы использовали взаимодействие между процессами, мы использовали MSMQ, мы пробовали сервис-брокера... Он просто не работает в долгосрочной перспективе, потому что вы отдаете контроль над своим приложением в Microsoft. Он отлично работает, пока ваши потребности удовлетворены. это становится адом, когда вам нужно что-то не поддерживаемое.
Лучшим решением для нас было: Использовать таблицу базы данных SQL в качестве очереди. Не изобретайте велосипед там, потому что вы будете делать ошибки (замки). Есть информация о том, как это сделать, это очень просто, и мы обрабатывали более 200 тыс. Сообщений на 24 часа (с одновременным чтением и записью 60х10 = 600 в очередь). Это в дополнение к тому же SQL-серверу, который обрабатывает остальную часть приложения...
Некоторые причины, по которым MSMQ не работает:
Когда вам нужно изменить логику очереди, а не FIFO, но что-то вроде "самого старого RED-сообщения" или "самого старого BLUE-сообщения", вы не можете этого сделать. (Я знаю, что скажут люди, вы можете сделать это, имея красную очередь и синюю очередь... Но что, если количество/типы очередей динамически зависит от способа администрирования приложения и ежедневных изменений?)
Он добавляет точку неудачи и развертывания кошмара (очередь является точкой отказа, и вам нужно иметь дело с настройкой правильных разрешений на все поля для чтения/записи сообщений и т.д.) в корпоративном программном обеспечении, которое вы платите в крови для такого рода вещей). SQL-сервер... все клиенты пишут/читают уже из БД, это всего лишь одна таблица.
Что относительно SQL 2005 сервис-брокер?
Структура RabbitMQ, похоже, здесь была упущена. Если люди по-прежнему заботятся, у него есть база данных .NET 2.0, и она поставляется с привязкой WCF, аналогичной netMsmqBinding. Для привязки, естественно, требуется, по крайней мере,.NET 3.0, и у нее больше возможностей, чем встроенный netMsmqBinding. Вдобавок ко всему, это Mono-friendly. Его стоит посмотреть.
Если стоимость не является проблемой (есть также Express SKU), то посмотрите на горилла 800 000 фунтов. WebSphere MQ (серия MQ). Он работает практически на любой платформе и поддерживает так много разных менеджеров очередей и шаблонов обмена сообщениями, которые действительно не подходят для их перечисления здесь.
Почему бы не использовать ActiveMQ?:)
Если важна высокая доступность, то стоит обратить внимание на Amazon SQS. Там не много дополнительных накладных расходов, если сообщения поступают из разных физических мест. Дешевый и масштабируемый!
Redis - еще одна горячая порода на этой платформе. Проверьте их реализацию на основе набора, а также шаблон Pub/Sub. Он выглядит обнадеживающим