Опубликован: 11.05.2007 | Доступ: свободный | Студентов: 1698 / 235 | Оценка: 4.36 / 4.25 | Длительность: 16:06:00
Лекция 2:

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

< Лекция 1 || Лекция 2: 12345 || Лекция 3 >

2.5. Распределенные события

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

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

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

Подписчики и издатели слабосвязанных событий

Рис. 2.8. Подписчики и издатели слабосвязанных событий

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

2.6. Распределенные транзакции

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

  • Атомарность. Транзакция выполняется по принципу "все или ничего".
  • Согласованность. После успешного завершения или отката транзакции все данные находятся в согласованном состоянии, их логическая целостность не нарушена.
  • Изоляция. Для объектов вне транзакции не видны промежуточные состояния, которые могут принимать изменяемые в транзакции данные. С точки зрения "внешних" объектов, до успешного завершения транзакции они должны иметь то же состояние, в котором находились до ее начала.
  • Постоянство. В случае успешности транзакции сделанные изменения должны иметь постоянный характер (т.е. сохранены в энергонезависимой памяти).
Распределенная транзакция

Рис. 2.9. Распределенная транзакция

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

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

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

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

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

2.7. Безопасность в распределенных системах

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

  1. Проверка подлинности пользователя сервисов компоненты распределенной системы ( аутентификация1Аутентификация является стандартным термином в русской литераторе, хотя данный термин является "склейкой" английских authentication и identification . ). Проверка подлинности может быть односторонней, когда только сервер убеждается в подлинности клиента, или двухсторонней, когда клиент так же убеждается в подлинности сервера.
  2. Ограничение доступа к сервисам компоненты в зависимости от результатов аутентификации (авторизация). Для решения данной задачи промежуточная среда должна поддерживать ограничение доступа, основанное на так называемых ролях ( role based security ). Поскольку разработчики компоненты не могут обозначить уровни доступа через конкретных пользователей или групп пользователей системы, то они должны использовать некоторые абстрактные роли, которые при развертывании компоненты будут связаны администратором системы с учетными записями пользователей системы.
  3. Защита данных, передаваемых между компонентами системы, от просмотра и изменения третьими сторонами. Для этого передаваемые между компонентами сообщения должны подписываться электронной подписью и шифроваться как клиентом, так и сервером.

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

2.8. Промежуточные среды в Microsoft .NET Framework

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

В настоящий момент в .NET Framework Class Library присутствует поддержка четырех промежуточных сред для построения распределенных систем. Далее они перечислены в порядке даты выпуска промежуточной среды.

  • Среда Microsoft Message Queuing (MSMQ) поддерживает обмен сообщениями между программными компонентами на основе очередей.
  • Среда Microsoft Enterprise Services основана на разработанной ранее фирмой Microsoft среде COM+, которая позволяет использовать удаленные объекты и распределенные транзакции в локальной сети.
  • Среда ASP .NET Web Services позволяет организовать удаленный вызов на основе общепринятых стандартов, базирующихся на языке XML.
  • Среда .NET Remoting была разработана как универсальная промежуточная среда для использования удаленных объектов.

В версии .NET Framework 3.0 предполагается ввести технологию WCF ( Windows Communication Foundation ), объединяющую все упомянутые технологии построения распределенных систем. Кроме указанных технологий, приложения на .NET Framework могут использовать, например, удаленные вызовы на основе стандарта XML-RPC при подключении дополнительных библиотек.

< Лекция 1 || Лекция 2: 12345 || Лекция 3 >