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

• Название: Учебное пособие издано при поддержке образовательной программы Формирование
• Анкор: Архитектура распределенных систем программного обеспечения
• Дата: 13.01.2023
• Размер: 1 Mb.
• Имя файла: mdwrbook.docx
• Тип: Учебное пособие; #885216
• страница: 15 из 36

Взаимодействие с системой очередей сообщений

Подход, применяемый в системах очередей, принципиально асинхронный. Обычно системы очередей предоставляют пользователям прикладной программный интерфейс, который удобен для использования в некотором конкретном программном окружении. Например, программисты, использующие язык Java, могут использовать стандартный интерфейс Java Message Service (JMS): отправители (получатели) сначала привязываются к очереди, то есть идентифицируют очередь, в которую они хотят послать (из которой хотят получить) сообщение, указывая имя очереди, а затем могут приступать к отправке (получению) сообщений.

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

4. Транзакционные очереди

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

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

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

6. Брокеры сообщений

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

работа с заказчиками и поставщиками

подготовка предложений

обработка _{закупки}

управление отгрузкой

заявок

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

новое сообщение

новое сообщение

новое сообщение

новое сообщение

Рис. 2.18. Приложения, использующие для взаимодействия модель "точка/точка", должныбытьизменены,еслиимпотребуетсяначатьвзаимодействоватьсновой системой (пунктир).

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

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

Традиционные системы на базе RPC и системы очередей создают между приложениями соединения типа "точка-точка" (Рис.2.18). Часто возникающая при их использовании проблема заключается в том, что при таком взаимодействии ответственность за определение получателя сообщения ложится на отправителя. В определенных случаях эта схема адресации становится трудно управляемой, поскольку число отправителей и получателей постоянно растет, а окружение, в котором работает система, становится более динамичным. Если отправителю потребуется начать взаимодействовать с новой системой, его приложение должно быть изменено. Снять подобные ограничения удается с помощью брокеров сообщений, которые действуют как посредники между системными сущностями. Брокеры сообщений обеспечивают гибкую маршрутизацию и другие необходимые для интеграции приложений качества. В сочетании с асинхронным обменом информацией – это наиболее пригодный подход к решению проблемы комплексной интеграции приложений отдельных предприятий. Брокеры сообщений забирают задачу определения пути доставки сообщения у отправителя и передают ее ядру системы (Рис.2.19). Имея брокер сообщений, пользователи могут выбрать такую прикладную логику, которая для каждого сообщения идентифицирует очередь, в которую сообщение должно быть доставлено. Это позволяет отправителям не указывать, кто будет получателем сообщения. Брокер сообщений, выполняя правила, заданные пользователем, сам определит получателя, что значительно упрощает схему взаимодействия прикладных компонентов системы и их внутреннюю структуру. Правила определения единственного из потенциальных получателей сообщения конкретного вида и содержания от конкретного отправителя сосредотачиваются в единственном месте системы, что облегчает процесс их модификации,

если она потребуется.

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

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

в обычных системах обмена сообщениями именно отправитель определяет получателя сообщения

отправитель получатель


ядро брокера сообщений




брокер сообщений

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

Рис.2.19.Брокерсообщенийдаетвозможностьопределятьпроизвольнуюлогику маршрутизации сообщений.

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

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

совместно извлекать сообщения из очередей и обрабатывать их

(балансировка нагрузки).

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