Какую реализацию JMS вы используете?
Мы используем ActiveMQ 5.2 как нашу предпочтительную реализацию, и мы выбрали ее некоторое время назад. Он работает достаточно хорошо для нашего использования прямо сейчас. С тех пор мне было интересно, какие еще реализации Java Message Service используются и почему? Конечно, их больше, чем несколько.
Ответы 10
В одном из недавних проектов, в которых я участвовал, мы использовали Sonic MQ. Хорошая общая реализация с хорошими привязками к .NET.
У нас было немного проблем с масштабируемостью, но я должен признать, что требования к масштабируемости были очень строгими: если я правильно помню, примерно 20000 сбоев в секунду без каких-либо задержек между 200 разными клиентами (каждый клиент должен был получать каждое сообщение в то же время).
@Mani: У меня нет подробностей о точной конфигурации или архитектуре системы очередей, которая была внедрена, потому что я не был частью команды разработчиков промежуточного программного обеспечения, но да, мы в конечном итоге достигли этих уровней пропускной способности с Sonic MQ. . Однако потребовалось несколько итераций, опробовавших различные схемы конфигурации оборудования и очередей.
Я использовал JBossMQ, который поставляется с сервером приложений JBoss до версии 4, надежный, но ограниченный. JBoss Messaging был заменой, поставляется с JBossAS 5 и является огромным улучшением.
ActiveMQ мне очень не нравится. Похоже, что разработчики потратили на производительность и функции в ущерб стабильности, и это феноменально глючит. Учитывая, что это JMS-ткань для Geronimo, я волнуюсь.
Наш опыт показал, что версии 3 и 5 значительно лучше, чем 4 для ActiveMQ.
... с точки зрения глючности, я хотел печатать.
Я попробовал 5.1, когда она вышла, и обнаружил, что интеграция Spring была нарушена очень простыми и очевидными способами, тогда как 5.0 в этом отношении работала нормально. Я больше не верю в режим тестирования ActiveMQ.
Мы полагаемся на AMQ (5.1) через фреймворк Camel, и никаких проблем не возникло. AMQ 4 был немного подозрительнее.
TIBCO EMS. Это коммерческая служба сообщений с привязками Java / JMS, C, .net и другими.
OpenMQ от Sun с открытым исходным кодом (https://mq.dev.java.net/). Вы можете получить как бесплатную, так и платную поддержку.
См. Это сообщение в блоге о сравнении с ActiveMQ и т. д. - http://alexismp.wordpress.com/2008/06/06/openmq-the-untold-story/.
Я слышал, что OpenMQ более стабилен.
ActiveMQ более гибкий. например, вы можете использовать его с большим количеством языков. Вероятно, в списке рассылки ActiveMQ больше людей, чем OpenMQ.
IBM WebSphere MQ 5 и 6 Активный MQ 5.2.0
Также ознакомьтесь с Micro QueueManager по адресу http://codingjunky.com/page5/page4/page4.html. Он небольшой, его легко установить и использовать для небольших проектов.
Провайдер WebLogic JMS при использовании WebLogic. Прекрасно работает.
Спасибо. Это все еще в силе сейчас? Нам нужно реализовать очередь в среде веб-логики. Я думаю, выбрать ли мне ActiveMQ или внутреннюю Weblogic JMS?
Мы используем SonicMQ, JBossMQ и «микроброкер» Lotus Expeditor Integrator. Мы используем их для разных целей:
-JBossMQ используется внутри и для связи со всеми нашими приложениями Java EE, которые работают на JBoss. -Lotus Expeditor используется на «удаленных объектах», где у нас ограниченные ресурсы и ИТ-персонал. -SonicMQ - это наша магистраль обмена сообщениями, мы используем ее для подключения центральных систем, а также для подключения удаленных систем в течение прибл. 1000 сайтов.
У нас есть хороший опыт работы со всеми из них, но наш опыт также показывает, что в более сложной среде вам необходимо более активно администрировать систему обмена сообщениями. Это стало особенно актуально с SonicMQ на нашем сайте :-). С точки зрения производительности, мы добились наилучших результатов с SonicMQ, особенно с постоянным обменом сообщениями на основе очередей.
Я использовал ActiveMQ в продакшене пару лет, но никогда не был доволен его стабильностью (особенно с включенной кластеризацией). Никогда не оглядывался после перехода на OpenMQ. Возможно, вы захотите изучить RabbitMQ или ZeroMQ.
Прежде чем углубляться в JMS, рассмотрите также AMQP - возможно, это новый стандарт. Провайдеры JMS, с которыми я работал (в разной степени):
TIBCO EMS - очень быстрый и надежный, хорошая поддержка API, дружественный к Java, собственный C API. Лучший коммерческий выбор, который я использовал.
Websphere MQ (и его реализация на JMS) - так, так. Публикация / подписка не совсем быстрые, многие параметры конфигурации и варианты выбора являются «странными» и слишком сложными из-за долгой истории этого продукта. Вы только посмотрите на объем документации ...
Solace JMS - очень высокая пропускная способность (брокер JMS встроен в оборудование!), Хороший выбор протоколов подключения (MQTT, AMQP, XML через http в качестве протоколов администрирования)
Fiorano MQ - раньше был агрессивным в маркетинге, но потерял большую долю рынка, опасения по поводу зрелости
Sonic MQ - солидный продукт, также поддерживает C API
Active MQ - если вы хотите использовать продукт с открытым исходным кодом (недорогая поддержка, отличное сообщество, ограниченные дополнительные продукты, ограниченные корпоративные функции), это, вероятно, ваш лучший выбор. Работает "из коробки" и является основой нескольких инструментов, например, Apache Camel.
В чем разница между solace jms и tibco ems? Причина, по которой я спрашиваю, мы запускаем tibco ems на solace hw, но это брокер tibco ems. Я полагаю, что утешение jms - это полностью дикий зверь?
Вы уверены, что используете EMS на оборудовании Solace? Это было бы странное сочетание. TIBCO EMS - это только программное обеспечение (есть еще одна аппаратная версия), а Solace по умолчанию является аппаратным (у них также есть программная виртуальная машина для тестирования). И да, Solace JMS и TIBCO JMS (= EMS) разные - разные компании, но обе поддерживают один и тот же API (JMS).
Ага ... Я видел эту настройку в несколько местах. Они покупают инфраструктуру обмена сообщениями (hw) у Solace и запускают поверх нее tibco ... Для всех java-приложений они используют библиотеки tibco и для всего, что действительно имеет малую задержку, они пишут C++, который использует материал уровня системы утешения ... Я думаю, вы говорим о последнем. Если брокер встроен в hw, вам нужно перейти на низкий уровень, чтобы взаимодействовать с ним, это имеет смысл.
Интересно - почему бы им не использовать Solace Java API? Трафик Solace to EMS будет нелегко работать вместе. Я думал, что главная идея состоит в том, чтобы каждое приложение могло взаимодействовать с любым приложением. Что ж...
Я думаю, это охватывает суть solace.com/press-releases/…
Есть ли какая-нибудь реализация, которая может масштабироваться так высоко?