Понятие очередей сообщений

2.1.5. Обмен сообщениями по принципу публикации-подписки

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

Предоставляемые инфраструктурой очередей сообщений в рамках модели межточечного обмена функции "отправил – забыл" и "запрос – ответ" служат решением при множестве обстоятельств. Однако в отношении данных, перечисленных ниже, модель межточечного обмена имеет ограничения.

• Информация о состоянии.

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

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

  Для поддержания актуальности данных об изменениях информации по принципу "запрос – ответ" узел должен посылать службе периодические запросы текущего состояния информации. Для этого он должен знать об узлах, где расположена служба предоставления информации. Такой подход называют опросом.

  Опрос службы – неэффективный способ получения уведомлений об изменениях состояния. Большое число запросов может вернуть одно и то же значение, а посылающий запрос узел не получает информации об изменениях до отправки следующего запроса. Меньшие интервалы опроса могут повысить точность известной узлу информации, но повышают и требования к ресурсам службы и инфраструктуре системы.
• Информация о событии.

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

  Информация с описанием события, которое наступило, называется информацией о событии. Например, при каждой продаже товара, находящегося на складе, служба управления складом может требовать обновления складской информации или отправки дополнительного заказа товара поставщику.

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

Модель публикации и подписки снимает эти ограничения.

В ней сообщения от одного или нескольких отправителей может получать произвольное число потребителей информации. При этом отправитель носит название издателя, а потребитель обозначается как подписчик.

Обмен по принципу публикации-подписки включает понятие темы, на которую, демонстрируя интерес, может подписаться любое количество потребителей информации. Такое положение дел аналогично тому, как если бы кто-то подписался лишь на журналы по интересным для него темам. Каждая тема предоставляет информацию о конкретном состоянии или событии.

Издатель может посылать сообщения с информацией по той или иной теме всем подписчикам этой темы, не зная, сколько таких подписчиков и на каких конкретно узлах они расположены. По этой причине обмен по принципу публикации-подписки полностью разрывает связь между поставщиком и потребителем информации.

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

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

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

По одной теме может иметься несколько издателей; подписчик по одной теме может являться источником публикуемых сведений по другим.

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

2.2. Упрощение

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

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

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

1. Передать инфраструктуре очередей сообщений информацию, необходимую для указания корректного места назначения или мест назначений данного сообщения.
2. Передать сообщение инфраструктуре очередей сообщений.
3. При успешном завершении шага 2 приложение способно определить, что сообщение успешно достигло места своего назначения.

2.2.1. Разработка с акцентом на бизнес-логике

Разработка бизнес-приложений, реализующих службы или запросы к ним, может оказаться дорогостоящим процессом, требующим значительного объема ресурсов. Инфраструктура очередей сообщений позволяет прикладным программистам больше времени уделить бизнес-логике реализации службы, а не проблемам коммуникации и непростому обслуживанию возникающих сбоев.

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

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

2.2.2. Сопровождение приложений и переносимость их кода

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

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

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

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

Процесс модификации приложения для выполнения на узле с новыми базовыми инфраструктурными компонентами именуется переносом, простота переноса приложения на другие компоненты инфраструктуры носит название переносимости.

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