Файл: Распределенная технология обработки информации (Архитектурное построение систем распределенной обработки информации).pdf

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

Рис. 3.1 Принципиальная схема организации механизма очередей сообщений

Очереди сообщений могут быть долговременными или нет. В случае если очередь сообщений окажется недолговременной, если произойдет сбой в работе менеджера очередей, такие сообщения в очереди будут потеряны. Если поддерживается долговременная очередь, они будут восстановлены после перезапуска менеджера. Данный вариант естественно считается предпочтительным для большинства ответственных приложений. Можно выделить еще одну отличительную черту промежуточных систем на основе очередей сообщений - обеспечение одного из трех уровней «качества обслуживания»:

– надежная доставка сообщений — это система гарантирует, что в процессе обмена сообщениями ни один сетевой пакет не будет потерян;

– застрахованная доставка сообщений — это каждое сообщение доставляется только один раз;

– гарантированная доставка сообщений — это сообщение доставляется адресату незамедлительно или через заданный промежуток времени, который не превышает определенного значения (такое бывает, если сеть в данный момент не доступна).

Промежуточные системы на базе очередей сообщений могут поддерживать обработку транзакций, разбивая большие синхронные транзакции, модифицирующие несколько распределенных, разнородных баз данных, на меньшие асинхронные транзакции, которые взаимодействуют друг с другом с помощью очередей. Делаем вывод, что МОМ-системы могут использоваться как более производительный асинхронный коммуникационный уровень для мониторов обработки транзакций ТРM. Очереди сообщений представляют собой мощный, гибкий и в то же время простой механизм межпрограммного взаимодействия. Данный механизм можно сравнить с другой парадигмой разработки приложений – создание программ, управляемых событиями. Событие одного приложения (представленное сообщением) вызывает определенное действие в другом. И такая модель наиболее близка к реальному взаимодействию процессов в бизнесе реальных компаний.

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

• MQSeries компании IBM
• MSMQ (Microsoft Message Queuing Server) компании Microsoft
• MessageQ компании BEA
• dbQ компании Sybase.

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

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

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

Это дает возможность эффективно интегрировать различные бизнес-приложения в единое корпоративное решение.

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

Основой архитектуры системы TIB/Rendezvous является сеть с поддержкой групповой рассылки, хотя по возможности допускается использование более эффективных средств связи (так, например, если известно точное местонахождение подписчика, обычно выполняется сквозная передача сообщений). На каждом узле этой сети работает демон контактов. Он отвечает за то, чтобы сообщения отсылались и получались в соответствии с темой. Демон контактов проделывает следующую работу: когда сообщение публикуется, он осуществляет его групповую рассылку всем узлам сети. Обычно такая групповая рассылка реализуется средствами базовой сети, такими как групповая рассылка по IP-адресам или аппаратная широковещательная рассылка.

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

Рис. 3.2 Принципиальная схема организации системы публикации или подписки

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

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

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

Появление расширяемого языка разметки данных XML (еXtensible Markup Lаnguаge – «расширяемый язык разметки») для Intеrnеt-приложений, который позволяет одним приложениям «понимать» другие, стало еще одним стимулом для появления нового поколения МОМ. Спецификация JМS построена на основе топологии «hub-аnd-spоke», в которой все приложения подключаются к центральному процессу, называемому сервером сообщений. Он отвечает за корректность маршрутизации сообщений, аутентификацию и авторизацию пользователей. Сами приложения рассматриваются как клиенты – они могут быть передатчиками либо приемниками. При этом обеспечивается такой API-интерфейс на базе Jаva, который позволяет разработчикам писать клиентские приложения, не заботясь о том, какое конкретно программное обеспечение MOM будет использоваться. Спецификация только определяет доступ к корпоративной системе обмена сообщениями, а каждый производитель ПО, опирающийся на JMS, самостоятельно разрабатывает инструменты для администрирования среды обмена сообщениями. JМS стала основой целого направления программных продуктов категории МOM, таких как МQ Еxpress компании Тalarian, SоnicMQ компании Progress Software, Bus компании Sоftwirеd, FiоrаnоМQ компании Fiоrаnо Sоftwаrе и других.

Глава 4. Распределенная обработка информации на основе моделей согласования.

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

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

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

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

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

Примером системы согласования считается система Jini компании Sun Micrоsystеms. Отнесение Jini к системам согласования основано в первую очередь на том, что эта система способна поддерживать генеративную связь при помощи Lindа-подобной службы под названием JаvаSpае. Но при этом существует множество служб и средств, которые делают Jini больше, чем просто системой согласования.

Jini – это распределенная система, состоящая из разных, но взаимосвязанных элементов. Она жестко привязана к языку программирования Jаvа, хотя многие из ее принципов равно могут быть реализованы и при помощи других языков. Важной частью системы можно назвать модель согласования генеративной связи. Jini обеспечивает как временную, так и ссылочную несвязность процессов при помощи системы согласования JаvаSpаcе. JаvаSpаcе – это разделяемое пространство данных, в котором хранятся кортежи. Кортежи представляют собой типизованные наборы ссылок на объекты Java. В одной системе Jini могут сосуществовать несколько пространств JаvаSpаcе.

Архитектура системы Jini может быть представлена в виде трех уровней. Самый нижний уровень образует инфраструктура. На этом уровне располагаются базовые механизмы Jini, в том числе и те, которые поддерживают взаимодействие посредством обращений RMI языка Jаvа. Службы предоставляются как обычными процессами, так и устройствами, на которых программное обеспечение Jini (в том числе и виртуальная машина Jаvа) выполняться не может. Поэтому регистрирующие и поисковые службы также относятся к инфраструктуре Jini. Второй уровень образуют средства общего назначения, которые дополняют базовую инфраструктуру и могут быть использованы для более эффективной реализации служб. В число этих средств входят подсистемы событий и уведомлений, средства аренды ресурсов и описания стандартных интерфейсов транзакций. Самый верхний уровень состоит из клиентов и служб. В противоположность остальным двум уровням Jini не определяет состав этого уровня однозначным образом. Актуальная реализация системы поддерживает несколько служб верхнего уровня, среди которых сервер JаvаSpаcе и менеджер транзакций, реализующий интерфейсы транзакций Jini. Программам верхнего уровня, кроме того, нередко разрешается напрямую использовать механизмы инфраструктуры Jini.