Изучаем Java EE 7 - [198]

На высоком уровне архитектура обмена сообщениями состоит из следующих компонентов (рис. 13.2).

• Поставщик. JMS — это только API, поэтому он нуждается в реализации способа обмена сообщениями, то есть в поставщике (также известном как брокер сообщений). Поставщик обрабатывает буферизацию и доставку сообщений.

• Клиенты. Клиентом является любое приложение Java или компонент, который производит или потребляет сообщение с помощью поставщика. «Клиент» — это общий термин для производителя, отправителя, издателя, потребителя, приемника и подписчика.

• Сообщения. Это объект, которые клиенты отправляют или получают от поставщика.

• Администрируемые объекты. Брокер сообщений должен предоставить клиенту администрируемые объекты (фабрики подключений и места назначения) с помощью поиска JNDI или внедрения (как вы увидите далее).

Поставщик сообщений позволяет выполнять асинхронную коммуникацию, предоставляя место назначения, где сообщения могут храниться, пока не будут доставлены клиенту (см. рис. 13.1). Существуют два типа мест назначения, каждый из которых применяется к конкретной модели обмена сообщениями.

Рис. 13.2. Архитектура обмена сообщениями

• От точки к точке (point-to-point, P2P). В этой модели место назначения, используемое для хранения сообщений, называется очередью. В этой модели один клиент помещает сообщение в очередь, а другой получает сообщение. Как только получение сообщения подтверждено, поставщик сообщений удаляет его из очереди.

• Публикация-подписка (publish-subscribe, pub-sub). Место назначения называется темой. При использовании данной модели клиент публикует сообщение в теме и все абоненты этой темы получают сообщение.

От точки к точке

В модели P2P сообщение проходит от одного производителя к одному потребителю. Модель построена вокруг концепции очередей сообщений, отправителей и получателей (рис. 13.3). Очередь хранит отправленные сообщения, пока они не будут потреблены, отправитель и получатель не имеют временной зависимости друг от друга. Это означает, что отправитель может производить сообщения и отправлять их в очередь, когда ему удобно, и получатель может использовать их в то время, когда удобно ему. После создания получателя он получит все сообщения, которые были отправлены в очередь, даже те, которые были отправлены до его создания.

Рис. 13.3. Модель P2P

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

Модель P2P используется, если существует только один получатель для каждого сообщения. Обратите внимание, что очередь может иметь несколько потребителей, но как только получатель потребляет сообщение из очереди, оно оттуда извлекается и никакой другой потребитель не может получить его. На рис. 13.4 можно увидеть, как один отправитель производит три сообщения.

Рис. 13.4. Несколько получателей

Обратите внимание, что модель P2P не гарантирует доставку сообщений в определенном порядке (то есть порядок не определен). Поставщик может выбирать их по мере прибытия, или случайным образом, или каким-то другим способом.

Публикация-подписка

В модели публикации-подписки одно сообщение отправляется нескольким потенциальным потребителям одним производителем. Модель построена вокруг концепции тем, отправителей и подписчиков (рис. 13.5). Потребители называются подписчиками, так как им в первую очередь следует подписаться на тему. Поставщик управляет механизмом подписки/отписки, это происходит динамически.

Рис. 13.5. Модель публикации/подписки

Тема сохраняет сообщения, пока они не распределятся между всеми абонентами. В отличие от модели P2P, временные зависимости между отправителями и подписчиками существуют — подписчики не получают сообщения, отправленные до того, как они подписались на тему, и если подписчик неактивен в течение определенного периода времени, он не получит прошлые сообщения, когда снова станет активным. Обратите внимание, что этого можно избежать, поскольку JMS API поддерживает концепцию стойких подписчиков, как вы увидите позже.

Несколько подписчиков могут потребить одно сообщение. Модель публикации/подписки может быть использована для широковещательных приложений, в которых одно сообщение доставляется нескольким потребителям. На рис. 13.6 отправляется три сообщения, которые получит каждый подписчик (в неопределенном порядке).

Рис. 13.6. Несколько подписчиков

Администрируемые объекты

Администрируемые объекты — это объекты, которые конфигурируются административно, а не программно. Поставщик сообщений настраивает эти объекты и делает их доступными в пространстве имен JNDI. Как и источники данных JDBC, администрируемые объекты создаются только один раз. Существует два типа администрируемых объектов:

• фабрики соединений — используются клиентами для создания подключения к пункту назначения;

• места назначения — точки распространения сообщений, которые получают, хранят и распространяют сообщения; места назначения могут быть очередями (P2P) или темами (pub-sub).

Клиенты получают доступ к этим объектам через портативные интерфейсы, выполнив их поиск в пространстве имен JNDI или посредством внедрения. В GlassFish есть несколько способов создания таких объектов, как вы увидите далее: с помощью консоли администрирования, командной строки с параметром asadmin или интерфейса REST. Начиная с версии JMS 2.0, вы даже можете использовать аннотации @JMSConnectionFactoryDefinition и @JMSDestinationDefinition, чтобы определить эти объекты программно.