Компоненты, управляемые сообщениями - одна шина, множественные спецификации активации

Question

У меня есть 2 компонента, управляемых сообщениями. 2 Спецификации активации для этих бобов. У меня есть одна шина сообщений, и обе спецификации активации настроены на эту шину. У меня есть 2 разные очереди и одна фабрика соединений очереди, настроенная для этой одной шины сообщений.

Теперь я бы написал свой код для отправки сообщения в одну из очередей во время выполнения после определения очереди. Однако оба моих MDB получают одно и то же сообщение. Как эта конфигурация вообще делается? Всегда ли я настраиваю 1 очередь - > 1 фабрика соединений в очереди - > 1 шина сообщений - > 1 МБ? Это все отношения один-к-одному?

О, я забыл упомянуть об этом: я использую Websphere Application Server v6.1

Answer 1

В общем, концепция такова:

<Ол>

сообщение отправлено (очередь) / опубликовано (тема) в пункт назначения (очередь / тема)

ActivationSpec прослушивает сообщения в определенном месте назначения (очередь / тема)

ActivationSpec: назначение является отношением 1: 1

Бин (MDB, являющийся потребителем) настроен на прослушивание ActivationSpec.

Это означает, что в действительности бин связан с пунктом назначения со слоем косвенности, предоставляемым ActivationSpec.

Откуда приходит шина - SIBus - это инфраструктура обмена сообщениями, которая делает все это возможным. Направления размещаются на автобусе.

Переходя к вопросу - ActivationSpec будет настроен на прослушивание пункта назначения на шине, на которую будут отправляться сообщения. Фабрика соединений решает шину, на которую будет отправлено сообщение. Пока имя получателя является уникальным и предназначено для определенной очереди (очередь JMS связана с пунктом назначения на шине), одно сообщение будет получено только одним ActivationSpec.

сколько мест назначения (по ссылке SIBus в консоли администратора WAS) было создано на шине? Не могли бы вы проверить / проверить правильность конфигурации?

чтобы ответить на ваши вопросы - "Это одна шина на спецификацию активации и одна фабрика соединений с очередью на очередь. " - ответ НЕТ.

<Ол>

Шина - это базовая инфраструктура, которая может содержать " n " направления. Одна ActivationSpec прослушивает один пункт назначения.

С фабрикой соединений с очередями - фабрика (фабричный шаблон J2EE) для создания очередей.

Answer 2

Я думаю, вы говорите, что хотите, чтобы оба MDB получали одно и то же сообщение, верно?

Если это так, то MDB должны слушать тему , а не очередь .

В качестве альтернативы, вы можете настроить IBM MQ для пересылки сообщений, например, сообщение, отправленное в определенную очередь , может быть повторно отправлено в n другой < em> queues , но я видел только то, что использовалось, когда какое-то обогащение сообщений происходит перед повторной публикацией, и поэтому я подозреваю, что это излишне для того, чего вы пытаетесь достичь.

Answer 3

Зачем вам нужна шина сообщений?

Обычно я связываю MDB с очередью - это отношение 1: 1. Отправьте сообщение в очередь, слушатель получит его. Какой автобус покупает тебя?

Я сделал JMS с WebLogic, и такой конструкции, как шина сообщений, не требуется. Я думаю, что это вещь IBM.

Вот пример того, как сделать JMS с помощью Spring. Вот как я бы рекомендовал продолжить.

ОБНОВЛЕНИЕ: я неверно истолковал ваш вопрос. Когда вы сказали, что обе ваши очереди получают одно и то же сообщение, я не думал, что это желаемое поведение. Если это так, то темы - правильный путь. Очереди - это обмен сообщениями точка-точка; темы публикуются / подписываются.

Answer 4

Я подозреваю, что ваша конфигурация настроена не так, как вы думаете. Мы используем ту же конфигурацию, которую вы описали, со многими MDB (с очередью и спецификацией активации), единой фабрикой и шиной сообщений, и все работает как положено.

Получить поведение, которое вы видите, на самом деле невозможно, если вы не отправите одно и то же сообщение в обе очереди или не определите тему вместо очереди. Я уверен, что даже если оба MDB читают из одной и той же очереди, сообщение получит только один, поскольку очередь поддерживает только двухточечную передачу сообщений. То, что вы описали, - это поведение, основанное на темах.