То, используете ли вы очередь или тему, должно зависеть от того, существует ли экземпляр, где несколько потребителей должны обрабатывать одно и то же сообщение. Если это так, тогда требуется тема, сгенерируйте этот шаблон «один ко многим».
С другой стороны, если какое-либо одно сообщение будет когда-либо потребляться только одним потребителем, вы можете использовать очередь или тему, и потребители указывают тип сообщения в качестве селектора JMS. Таким образом, все потребители могут прослушивать одну и ту же очередь, и каждый выбирает разные подмножества сообщений. В случае, если одного приложения нет, его сообщения не «блокируют следующие сообщения, которые могут быть использованы другими потребителями», а просто складываются в очередь, и другие потребители по-прежнему получают свои сообщения на основе критериев выбора.
Пожалуйста, помните, что очереди - это облегченные конструкции, и вы можете легко иметь одну очередь на одного потребителя. Как правило, вещи, предоставляющие услугу, прослушивают хорошо известную очередь, и каждая очередь представляет отдельную функцию службы или другую службу. Таким образом, может быть много очередей ввода службы. Точно так же ответные сообщения, как правило, уникальным образом адресованы экземпляру приложения, которое отправило запрос, и отправляются в уникальную, часто динамическую, очередь ответа. Обе эти реализации, которые я описал, приводят к разделению трафика между очередями, а не объединению разных типов сообщений в одну и ту же очередь. Поскольку селекторы JMS всегда увеличивают стоимость обработки, использование большего количества очередей, как правило, более производительно, чем выбор множества типов сообщений из одной и той же очереди.
Я отвечаю на ваш вопрос о селекторах в разделе комментариев здесь, так как у меня больше места и я могу разместить ссылки в ...
Раздел 3.8.1 JMS 1.1 spec сообщает:
Селектор сообщений JMS позволяет клиенту указывать в заголовке сообщения
сообщения, в которых он заинтересован. Только сообщения, чьи заголовки и свойства
соответствие селектора доставлены. Семантика не доставленного отличается немного
в зависимости от используемого MessageConsumer. См. Раздел 5.8,
«QueueReceiver» и раздел 6.11 «TopicSubscriber» для более подробной информации.
Селекторы сообщений не могут ссылаться на значения тела сообщения.
Селектор сообщений соответствует сообщению, если селектор оценивается как true, когда
поле заголовка сообщения и значения свойств заменяются
соответствующие идентификаторы в селекторе.
Как отмечено выше, селекторы могут находиться в полях, которые неявно присутствуют в сообщении, таких как MsgID или CorrelationID, или могут быть в полях, специально установленных производителем сообщения, таких как свойство сообщения. В любом случае клиент должен указать значение любых селекторов, используемых получателем сообщения.