Альтернативы JMS для очередей

Question

У нас есть веб-служба REST, которая получает запросы от внешних систем и соответственно обновляет нашу БД. Я хочу реализовать решение для кэширования/ожидания для входящих запросов, так как в последнее время у нас были проблемы с сервером БД, и утеряны некоторые сообщения, когда сервер БД опустился.

Прежде чем приступить к созданию простой постоянной очереди на основе файлов, я хочу посмотреть, есть ли какие-либо хорошие альтернативы JMS, поскольку использование ограничено в нашей среде.

Текущие платформы: JBoss 4.3 RichFaces 3,3 Spring 3.0.5 Resteasy

** ОБНОВЛЕНИЕ **

За вопрос skaffman в ниже, мои требования к кластеризации, сделок и т.д.

• Кластеризация: наши веб-серверы и серверы приложений сгруппированы, поэтому очереди (очереди) необходимо будет обрабатывать элементы из всех узлов кластера. Однако наши фиксации по сути являются атомарными, поэтому вопросы упорядочения и синхронизации крайне минимальны. Защита потоков и кластеров на самом деле не является фактором. Отдельных/независимых очередей на каждом кластере было бы достаточно.

• Сделки: опять же, из-за атомной природы наших данных, транзакционные потребности минимальны/не требуются за пределами каждого отдельного запроса.

• Безопасность: Умеренная озабоченность, но я бы ожидал, что это будет связано с нашей обычной безопасностью в веб-службе. Я бы не ожидал, что что-нибудь прочитает или напишет в очереди, кроме самого веб-приложения. Это было бы необходимо только в случаях большого объема или когда БД недоступна.

Спасибо,

Майк

Answer 1

Для одного проекта мы сделали использовать очереди (HornetQ), но была интегрирована в войне и развертываемых на сервере Tomcat, потому что клиент не хочет Weblogic или JBoss приложение серверов, но если ваша политика ограничения распространяется на архитектуру вашего приложения, то такое решение будет запрещено.

Для другого проекта мы не использовали реализацию JMS, и мы делаем асинхронную реализацию, используя базу данных сообщений и Service Activatorspring-integration framework для потребления событий. Таким образом, любой издатель сообщений просто вставляет строку в таблицу DB, а Service Activator запускает событие и вызывает любую другую услугу (Spring, Web-сервис и т. Д.).