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

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

Модель взаимодействия "публикация/подписка"

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





Рис.2.20.Модели"публикация/подписка"повышаютгибкостьсистемиих устойчивость к изменениям.

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

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

2. Распределенное администрирование брокера сообщений

В состав систем брокеров сообщений входит поддержка администратора, то есть выделенного пользователя, который имеет право определять:

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

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

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

3. Основные виды прикладных систем

   1. Комплексная интеграция приложений в рамках предприятия

Системыкомплекснойинтеграцииприкладныхсистемпредприятий

(enterprise applicationintegration, EAI) – это эволюционный шаг в развитии

системной поддержки, расширивший

ее возможности

по интеграции

приложений.

Современный

интеграционные

системы строятся с

выраженной

промежуточной платформой, что

позволяет отделить слой

прикладной

логики от слоя

управления ресурсами, добиться

большей

щ

ж
гибкости и органично интегрировать серверы.

Дельные Предложени

СУБД

Толковые Предсказания

1. 
   Высокоуровневаямодельархитектурытипичнойсистемыинтеграции приложений в рамках предприятия.
   

При комплексной интеграции прикладных

систем

особенно важно

автоматизировать взаимодействие цепочек поставок,

то есть

передач

информации

от одной прикладной системы

другой,

которые

обычно

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