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

Question

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

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

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

Answer 1

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

1. сообщение отправлено (Очередь) / опубликовано (Тема) по назначению (Очередь / Тема)
2. ActivationSpec прослушивает сообщения в определенном месте назначения (очередь / тема)
3. ActivationSpec: назначение является отношением 1: 1
4. Бин (MDB, являющийся потребителем) настроен на прослушивание ActivationSpec.

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

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

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

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

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

1. Шина является базовой инфраструктурой, которая может содержать «n» пунктов назначения. Одна ActivationSpec прослушивает один пункт назначения.
2. С фабрикой соединений с очередями - фабрика (фабричный шаблон J2EE) для создания очередей.

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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