как правильно:
- на каждый интеграционный процесс создаем очередь
- одна очередь на несколько интеграционных процессов (не обязательно вообще одна), на каждый тип сообщения (JMSProperties) пишем свой обработчик

как?

BlazkowiczЭто уже ESB будет, а не JMS.
ESB уже есть. Как раз она и будет в JMS складывать сообщения.
BlazkowiczЧто с чем интегрируете?
Web (Jboss) с сторонними системами.
BlazkowiczОчередь лучше иметь под конкретного читателя. Т.е. чем более гомогенные данные в одной очереди, тем лучше. Но за исключением ситуации, когда одни и те же консюмеры вдруг должны читать из разных очередей.
Меня в общем беспокоит тот факт что из спеки JMS используется минимум. А как же приоритеты и проперти? Не будет ли более правильно использовать второй вариант а не плодить 100500 очередей? Понимаю что какой то из паблишеров может генерить на порядок больше сообщений (приоритеты/отдельная "нагруженная очередь").

Есть ли вообще паттерн которого стоит придерживаться в таких случаях?

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

Шаблоны есть, называются EIP (Enterprise Integration Patterns). Там и сообщения, каналы, пайплайны...
Ок. Допустим у нас N типа сообщений, разной структуры, не большие по размеру. Мы предполагаем что количество сообщений не будет большим. Наш вариант:
1. N очередей
2. 1 очередь

Почему 1 вариант лучше?

IgorKonovalovНе скажите, Blazkowicz, не скажите. Может ТимоН селекторы будет использовать?
Да, буду.

BlazkowiczДа не при чем тут "типы" вообще. Зависит от консюмеров. А гомогенные данные проще анализировать в случае чего. Но это не так важно. Т.е. если у тебя один продюсер, один консюмер, то нафига тебе N очередей для N типов, если консюмер всё равно их поочереди обрабатывает?
Продюсеров > 1. Консюмеров пока нет.
Не хочу использовать один консюмер. Хочу столько сколько типов (выбирать по селектору). Если добавится новый тип, пишем еще один MDB и все.

BlazkowiczПри чем здесь это? Я говорю что количество типов не особо влияет на количество очередей.
Утверждается, не мной, что один тип сообщения = одной очереди. Т.е. очередь конкретно под определенный тип сообщения и только.

BlazkowiczЭто не так. "Типы" сообщений вторичны. Важна сама организация продюсеров и консюмеров. Тут вообще не до конца понятно что у вас вкладывается в термин "тип".
Уточняю:
TestMessage (type='students')
<xml>описание студента</xml>

TestMessage (type='food')
<xml>описание еды</xml>

Предполагалось создать одну очередь для интеграции в общем. Под каждый тип (type='students') создается конкретный MDB. Существует утверждение что так делать не кошерно, а нужно создать столько очередей сколько типов (type='students'). Это позволит избежать "чего-то" в будующем.

BlazkowiczНу, вот допустим у нас есть Департамент обучения, Отдел кадров, и Кадровое агентсво. Они обмениваются данными по студентам.
Есть Столовая, Отдел Снабжения и поставщик. Они обмениваются данным о продуктах. Вопрос - нафига пихать всё в одну очередь?
Почему проблема отдела снабжения в один прекрасный день начнут влиять на работу отдела кадров?

С этим нельзя не согласиться. Таким образом нас не должно пугать количство очередей?

BlazkowiczНадо ещё смотреть как реализованы селекторы. Если сообщения нормально раскидать по таблице, так что селеторы найдут нужный тип по SQL запросу, то ОК. А если там тупой перебор? Загадили, например, всю очередь едой и селекторы студентов начнут тормозить. Если по какой-то админской причине очередь надо грохнуть-пересоздать. Вместо одной интеграции встанут сразу две. И т.п.
Ну с этим вроде все в порядке, тестил JMeter'ом.