Websphere MQ - Pub/Sub

Question

Мы работаем над созданием архитектуры, в которой у нас будет два приложения для обработки, необходимые для получения информации из одной очереди (они будут использовать данные совершенно по-разному). Что считается лучшей практикой/перспективой для IBM WebSphere MQ в этой ситуации?

1. Паб/Суб-Один издатель и «n» количество подписчиков?
2. Люди, управляющие нашим MQ, предложили поклонник (триггер, который читается из именованного списка и распределяется по нескольким очередям). Это нам не кажется хорошей идеей.
3. Другие?

Любые предложения или предложения были бы весьма полезными.

Answer 1

Я задал вопрос одному из контактов WebShere MQ, которые у меня есть, и вот его ответ. Думал, что это может помочь другим.

«Если ожидается, что число приложений, обрабатывающих сообщения, будет повышаться, а шаблон обмена сообщениями не будет запрашиваться/отклик, тогда перейдите в pub/sub architecture. В противном случае используйте элемент, содержащий две очереди, из которых приложения получают сообщения. в файле amqsptl0.c для получения подробной информации о том, как отправить сообщение в список имен. "

--S

Answer 2

Решение об использовании Pub/Sub не исходит из того факта, что очереди не поможет ...

Если ваш сценарий типа запрос-ответ по сценарию очереди будет наилучшим образом подходит в большинстве случаев.

Если ваш сценарий будет иметь много потребителей, динамически добавляемых (или удаляемых), то Pub-Sub помогает.

Я думаю, что вы делаете маршрутизацию сообщений известным потребителям. Если в будущем вам нужно будет много дел о маршрутизации и преобразовании, вы можете использовать IBM Integration Bus. Если маршрутизация прост, как это, отправитель может отправить сообщение в очередь, а затем программа может читать сообщения из контекста транзакции и отправлять их в две разные очереди. Слушатель сообщений JMS может помочь в обработке aync.

Посмотрите на этот узор http://www.eaipatterns.com/MessageRouter.html. Думаю, это соответствует тому, что вы делаете.