Доступность получателя отправителя в пабе / субдомене JMS

Question

Здесь указывает, что «отправитель и получатель не должны быть доступны одновременно для связи». И здесь указывает, что в пабе / поддомене «Клиент, подписывающийся на тему, может использовать только сообщения, опубликованные после того, как клиент создал подписку, а подписчик должен продолжать оставаться активным, чтобыдля этого потреблять сообщения . "Мне кажется, что выделенное курсивом утверждение противоречит первому утверждению («отправитель и получатель не должны быть доступны одновременно»).

Если подписчик должен продолжать оставаться активным для приема сообщений, это означает, что отправитель и получатель должны быть одновременно доступны , по крайней мере, в пабе / поддомене. Если они должны быть доступны, домен pub / sub только так хорош, как RMI. Это правда?

Answer 1

... отправитель и получатель не обязательно должны быть доступны одновременно для связи.

Насколько я могу судить, это общее утверждение о обмен сообщениями , а не подробное объяснение семантики, предоставляемой JMS API. Обратите внимание, что это под «Что такое обмен сообщениями?»перед началом конкретного обсуждения API JMS.

Для чего стоит, API JMS обеспечивает эту семантику, если вы используете стиль точка-точка обмен сообщениями (также обсуждается в руководстве). Он также предоставляет вариант этой семантики с использованием стиля сообщений pub-sub, но я вернусь к этому позже.

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

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

JMS API в некоторой степени ослабляет эту временную зависимость, позволяя подписчикам создавать долговременные подписки , которые получают сообщения, отправленные, когда подписчики не активны.

Итак, как я упоминал ранее, вы можете получить вариант неактивной семантики отправителя / получателя, используя стиль сообщений pub-sub через надежные подписки.

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