Почему метод createMessage в интерфейсе сеанса в JMS?

Question

Почему методы createMessage, createTextMessage и т. Д. Определены в интерфейсе сеанса в JMS?Я могу понять, почему, когда вы отправляете или получаете сообщение, вам понадобится сеанс, но не то, почему вы хотите создать сообщение, которое вы собираетесь отправлять из него.Почему, когда дизайнеры JMS создавали интерфейсы для него, они решили, что сообщения должны создаваться из сеанса, а не просто обновляться?

Answer 1

(Отличный вопрос разработки API.)

Вы концептуально путаете «сообщение JMS» с содержанием вашего сообщения.

Да. Похоже, что это немного связано с адресом сообщения жизненного цикла через сеанс. Но если вы рассмотрите случай отключенного узла, это не так уж странно с точки зрения дизайна.

Существенный момент заключается в том, чтобы отметить «зачем клиенту создавать сообщения, если он не подключен?» при рассмотрении вопроса «что такое« сообщение », если оно удалено из метаданных JMS «? (Пример метаданных сообщения: порядок сообщений.)

Итак, в принципе, должно быть ясно, что за исключением метаданных (которые очень сильно связаны как с сеансом, так и с поставщиком), ваш «пользовательский контент» действительно не имеет никакого отношения к JMS. Другими словами, концептуально у вас есть кортеж:

{ [meta-data] : [user-content] }

Так что «сообщение» - это действительно вышеприведенный кортеж. user-content на самом деле просто ваши данные. То есть, если вам предоставляется универсальный (не связанный / отключенный) интерфейс для общего «создания сообщений», все, что получается, - это (ненужное) создание «общих» «сообщений» (которые на самом деле просто оборачивают ваш контент) и не хватает всех необходимых «метаданных», которые сделали бы его правильным «JMS-сообщением». В какой-то момент это общее внеполосное сообщение необходимо «преобразовать» в правильное сообщение JMS, например, добавлены метаданные заказа, добавлена ​​метка времени и т. д.

Что вы получили от этих «общих» сообщений «JMS»? (Ничего, кажется.)

Как таковое, создание сообщений из сеанса является концептуально более понятным и более эффективным для реализации.

Answer 2

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

"Каждый провайдер JMS предоставляет набор фабрик сообщений со своим объектом Session для создания экземпляров сообщений. Это позволяет провайдеру использовать реализации сообщений, адаптированные к его конкретным потребностям."

Answer 3

Каждый провайдер JMS имеет свою собственную конкретную реализацию, свойства сообщения и т. Д., Которые инициализируются фабрикой сообщений.Так что, в любом случае, вам нужна какая-то фабрика сообщений.

Вероятно, они могли бы поместить фабричные методы в Connection вместо Session, но решили, что проще, чтобы один и тот же объект (сеанс в нашем случае) отвечал за обасоздание и отправка сообщений.

Я думаю, что это основные причины.

Answer 4

Существует стандартный интерфейс для TextMessage и других сообщений, но не стандартная реализация.Это означает, что у вас более одного JMS-провайдера, у вас будут разные реализации для этих классов.