Файл: Технология построения распределенных информационных систем (Принципы организации распределенной обработки информации).pdf
Добавлен: 04.07.2023
Просмотров: 360
Скачиваний: 2
надежная доставка сообщений (reliable message delivery) — система гарантирует, что в процессе обмена сообщениями ни один сетевой пакет не будет потерян;
гарантированная доставка сообщений (guaranteed message delivery) — сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);
застрахованная доставка сообщений (assured message delivery) — каждое сообщение доставляется только один раз.
Промежуточные системы на базе очередей сообщений могут поддерживать обработку транзакций, разбивая большие синхронные транзакции, которые модифицируют несколько распределенных, разнородных баз данных, на меньшие асинхронные транзакции, взаимодействующие друг с другом посредством очередей. Таким образом МОМ-системы могут использоваться как более производительный асинхронный коммуникационный уровень для мониторов обработки транзакций ТРM. Очереди сообщений представляют собой мощный, гибкий и в то же время простой механизм межпрограммного взаимодействия. По существу, этот механизм близок к другой парадигме разработки приложений — созданию программ, управляемых событиями. Событие одного приложения (представленное сообщением) вызывает определенное действие в другом. И такая модель наиболее близка к реальному взаимодействию процессов в бизнесе реальных компаний.
Представителями программных продуктов, построенных на базе очередей сообщений, являются системы MQSeries компании IBM, MSMQ (Microsoft Message Queuing Server) компании Microsoft, MessageQ компании BEA, dbQ компании Sybase.
Еще одна модель обмена сообщениями — модель публикации/подписки (publlsh&subscribe) — имеет определенные перспективы для создания гибких, управляемых событиями приложений. Одно приложение публикует информацию в сети, а другое подписывается для получения данных по интересующей его теме. Взаимодействующие таким способом приложения полностью независимы друг от друга и могут ничего не знать о существовании, физическом размещении и состоянии друг друга. Это открывает путь к динамической реконфигурации всей распределенной системы, добавлению и произвольному изменению любых клиентов и серверов без прерывания их работы и полной изоляции прикладных компонентов от любых аспектов реализации других частей системы. В конечном итоге, это означает возможность эффективной интеграции различных бизнес-приложений в единое корпоративное решение.
Характерным примером распределенной системы на основе модели публикации/подписки является система TIB/Rendezvous компании TIBCO. Ключевой механизм, лежащий в основе системы TIB/Rendezvous, — это адресация по теме (subject-based addressing). При таком подходе процесс, который собирается посылать сообщение, не может определить точное место назначения. Вместо этого он именует сообщение названием темы (subject name), после чего посылает его в коммуникационную систему для пересылки по сети. Получатели, в свою очередь, не выясняют, от каких процессов они собираются получать сообщения. Вместо этого они сообщают коммуникационной системе, какие темы их интересуют. Коммуникационная система гарантирует, что получателю будут доставлены только те сообщения, которые несут данные по теме, интересующей получателя. Отправка сообщения методом адресации по теме также называется публикацией (publishing). Чтобы получить сообщение по определенной теме, процесс должен подписаться на эту тему. Принципиальная схема организации системы публикации/подписки, реализованная в TIB/Rendezvous, показана на рисунок 2.6.
Основой архитектуры системы TIB/Rendezvous является сеть с поддержкой групповой рассылки, хотя по возможности допускается использование более эффективных средств связи (так, например, если известно точное местонахождение подписчика, обычно выполняется сквозная передача сообщений). На каждом узле этой сети работает демон контактов (rendezvous daemon), который отвечает за то, чтобы сообщения отсылались и получались в соответствии с темой. Когда сообщение публикуется, демон контактов осуществляет его групповую рассылку всем узлам сети. Обычно групповая рассылка реализуется средствами базовой сети, такими как групповая рассылка по IP-адресам или аппаратная широковещательная рассылка.
Процессы, подписываясь на определенную тему, передают свою подписку локальному демону. Демон создает таблицу пар (процесс, тема) и при доставке сообщения с определенной темой просто просматривает эту таблицу в поисках локальных подписчиков, пересылая его каждому из процессов. Если на эту тему на данном узле никто не подписался, сообщение немедленно уничтожается.
машина 1 машина 2 машина 3 машина 4 машина 5
сеть
Публикация
на тему А
Подписка
на тему А
Подписка
на тему А
Публикация
на тему В
Подписка
на тему А
Подписка
на тему В
Подписка
на тему В
Тема
А
Тема
В
Демон
контак-
тов
Демон
контак-
тов
Демон
контак-
тов
Демон
контак-
тов
Демон
контак-
тов
Рисунок 2.6- Принципиальная схема организации системы публикации/подписки
Чтобы система могла вырасти до размера больших сетей, таких как глобальные сети, используются также маршрутизирующие демоны контактов (rendezvous router daemons). Обычно каждая локальная сеть имеет одного маршрутизирующего демона контактов. Этот демон связывается с маршрутизирующим демоном другой удаленной сети. Маршрутизирующие демоны образуют сквозную оверлейную сеть (overlay network), в которой маршрутизаторы соединены между собой попарно соединениями TCP. Вторичная сеть — это сеть маршрутизаторов прикладного уровня. Каждый маршрутизатор знает топологию вторичной сети и вычисляет дерево групповой рассылки для публикации сообщений в других сетях. Маршрутизаторы рассылают только те сообщения, которые публикуются в их локальной сети. Сообщения из других сетей пересылаются по дереву групповой рассылки той сети, из которой они первоначально исходили.
В целях повышения производительности всякий раз при публикации сообщения оно доставляется только в те удаленные сети, которые были сконфигурированы на прием подобных сообщений и имеют текущих подписчиков этих сообщений.
Технологической основой для всех сред обмена сообщениями нового поколения стала спецификация JMS (Java Message Service — служба сообщений Java), в деталях определяющая, как взаимодействуют клиенты и серверы в среде асинхронных сообщений. К числу достоинств JMS относится то, что она соответствует современным представлениям о взаимодействии приложений и не требует специальных знаний и доступна для любого программиста, работающего на языке Java. Этими качествами она заметно отличается от инструментария MQSeries, где необходима специальная подготовка. Еще один стимул для рождения нового поколения MOM — появление расширяемого языка разметки данных XML (eXtensible Markup Language — «расширяемый язык разметки») для Internet-приложений, позволяющего одним приложениям «понимать» другие.
Спецификация JMS построена на основе топологии «ступицы и колеса» (hub-and-spoke), в которой все приложения подключаются к центральному процессу, называемому сервером сообщений (message server). Он отвечает за корректность маршрутизации сообщений, аутентификацию и авторизацию пользователей. Сами приложения рассматриваются как клиенты — они могут быть передатчиками и/или приемниками. При этом обеспечивается такой API-интерфейс на базе Java, который позволяет разработчикам писать клиентские приложения, не заботясь о том, какое конкретно программное обеспечение MOM будет использоваться. Спецификация только определяет доступ к корпоративной системе обмена сообщениями, а каждый производитель ПО, опирающийся на JMS, самостоятельно разрабатывает инструменты для администрирования среды обмена сообщениями. JMS стала основой целого направления программных продуктов категории MOM, таких как MQ Express компании Talarian, SonicMQ компании Progress Software, Bus компании Softwired, FioranoMQ компании Fiorano Software и других.
-
-
Распределенная обработка информации на основе моделей согласования
-
Основным подходом, который используется в распределенных системах на основе моделей согласования, является отделение собственно вычислительных процессов от механизмов их согласования. Если рассматривать распределенную систему как набор процессов (возможно, многопоточных), то вычислительная часть распределенной системы образована группой процессов, каждый из которых осуществляет конкретные вычислительные операции, причем эти операции в принципе могут выполняться независимо от других процессов. В этой модели согласующая часть распределенной системы поддерживает все взаимодействие между процессами и организует их взаимную кооперацию. Она образует тот «клей», который связывает воедино деятельность, выполняемую разными процессами. В распределенных системах согласования основное внимание уделяется согласованию процессов.
В том случае, если процессы обладают связностью ссылок и времени, согласование осуществляется напрямую и имеет название прямого согласования (direct coordination). Связность ссылок обычно имеет вид явной идентификации собеседника в процессе взаимодействия. Так, например, процесс может взаимодействовать с другим процессом только в том случае, если он знает идентификатор процесса, с которым хочет обменяться информацией. Временная связность означает, что оба взаимодействующих друг с другом процесса активны одновременно. Такая связность имеет место при нерезидентной связи на основе сообщений.
Другой тип согласования наблюдается в том случае, если процессы не связаны по времени, но связаны по ссылкам. Такой тип согласования называют согласованием через почтовый ящик (mailbox coordination). В этом случае для взаимодействия не нужно, чтобы два взаимодействующих друг с другом процесса выполнялись одновременно. Вместо этого взаимодействие происходит путем посылки сообщений в почтовый ящик, может быть, используемый совместно. При этом необходимо явно указать адрес почтового ящика, в котором должны храниться сообщения. Это и есть ссылочная связность.
Комбинация связности по времени и несвязности по ссылкам образует группу моделей согласования на встрече (meeting-oriented coordination). В несвязной по ссылкам системе процессы не имеют полной информации друг о друге. Другими словами, когда процесс хочет согласовать свою деятельность с другими процессами, он не может обратиться к ним напрямую. Взамен используется метафора встречи, на которой собираются процессы, чтобы скоординировать свою деятельность. Модель предполагает, что процессы, участвующие во встрече, выполняются одновременно.
Наиболее распространенный вариант согласования — это сочетание несвязных по времени и по ссылкам процессов. Этот вариант представлен генеративной связью (generative communication), которая впервые была реализована в программной системе Linda. Основная идея генеративной связи состоит в том, что набор независимых процессов может использовать разделяемое сохранное пространство данных, организуемое с помощью кортежей. Кортежи — это именованные записи, содержащие несколько (но, возможно, и ни одного) типизованных полей. Процесс может помещать в разделяемое пространство данных записи любого типа (то есть генерировать связующие записи). Для разделения кортежей в соответствии с информацией, которая в них содержится, достаточно их имен. Разделяемые пространства имен реализуют механизмы ассоциативного поиска кортежей. Другими словами, когда процесс хочет извлечь кортеж из пространства данных, ему достаточно определить значения полей, которые его интересуют. Любой кортеж, удовлетворяющий описанию, будет извлечен из пространства данных и передан процессу. Если ничего найдено не будет, процесс может заблокироваться до прихода очередного кортежа.
Примером системы согласования является система Jini («джини») компании Sun Microsystems. Отнесение Jini к системам согласования основано в первую очередь на том, что эта система способна поддерживать генеративную связь при помощи Linda-подобной службы под названием JavaSpace. Однако существует множество служб и средств, которые делают Jini больше, чем просто системой согласования.
Jini — это распределенная система, состоящая из разных, но взаимосвязанных элементов. Она жестко привязана к языку программирования Java, хотя многие из ее принципов равно могут быть реализованы и при помощи других языков. Важной частью системы является модель согласования генеративной связи. Jini обеспечивает как временную, так и ссылочную несвязность процессов при помощи системы согласования JavaSpace. JavaSpace — это разделяемое пространство данных, в котором хранятся кортежи. Кортежи представляют собой типизованные наборы ссылок на объекты Java. В одной системе Jini могут сосуществовать несколько пространств JavaSpace.
Архитектура системы Jini может быть представлена в виде трех уровней. Самый нижний уровень образует инфраструктура. На этом уровне располагаются базовые механизмы Jini, в том числе и те, которые поддерживают взаимодействие посредством обращений RMI языка Java. Службы предоставляются как обычными процессами, так и устройствами, на которых программное обеспечение Jini (в том числе и виртуальная машина Java) выполняться не может. Поэтому регистрирующие и поисковые службы также относятся к инфраструктуре Jini. Второй уровень образуют средства общего назначения, которые дополняют базовую инфраструктуру и могут быть использованы для более эффективной реализации служб. В число этих средств входят подсистемы событий и уведомлений, средства аренды ресурсов и описания стандартных интерфейсов транзакций. Самый верхний уровень состоит из клиентов и служб. В противоположность остальным двум уровням Jini не определяет состав этого уровня однозначным образом. Актуальная реализация системы поддерживает несколько служб верхнего уровня, среди которых сервер JavaSpace и менеджер транзакций, реализующий интерфейсы транзакций Jini. Программам верхнего уровня, кроме того, нередко разрешается напрямую использовать механизмы инфраструктуры Jini.
Кроме генеративной связи, присущей модели JavaSpace, в число механизмов взаимодействия Jini входит простая подсистема событий и уведомлений. Модель событий Jini относительно проста. Если в рамках объекта происходит событие, которое может быть интересно клиенту, клиенту разрешается зарегистрировать себя на этом объекте. Когда факт наступления события будет зафиксирован, то есть когда событие произойдет, объект уведомит об этом зарегистрированного клиента. С другой стороны, клиент может потребовать от объекта, чтобы тот послал уведомление о наступлении события в другой процесс. В этом случае объекту пересылается удаленная ссылка на объект-слушатель (listener object), обратный вызов которого можно выполнить при наступлении события (путем обращения RMI языка Java). Регистрация клиента на объекте всегда арендуется. Когда срок аренды истекает, зарегистрированный клиент (или процесс, которому уведомления отправлялись по поручению клиента) перестает получать уведомления. Благодаря аренде регистрация не может сохраниться вечно, например, в результате отказа зарегистрированного клиента.