Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

9.2. DCOM 591

Если разрешить серверу выдавать себя

за

клиента (уровень IMPERSONATE),

по-

является возможность обращений

локальным объектам этого сервера,

ходе

которых сервер будет использовать мандат клиента. Если необходимо обраще-

ние

за

пределы одной машины, уровень должен быть установлен

DELEGATE,

что

позволит клиенту делегировать права доступа серверу.

Программная защи1^а

Кроме декларативной защиты можно также позволять приложениям самим

вы-

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

защиты общего назначения. Возможность установки уровня защиты может пона-

добиться приложениям

для

временного повышения уровня защиты

по

сравне-

нию

заявленным

реестре.

Настройка параметров защиты производится

при

инициализации процесса

путем вызова из процесса функции Colnitial izeSecurity DCOM. Процесс должен

идентифицировать компонент (то есть объект класса или объект), для которого он

хотел бы изменить описанные выше уровни аутентификации

обезличивания.

У программной защиты имеется интересная черта: процесс может также ука-

зать

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

Обычно

эта

служба относится

той операционной системе, поверх которой

ра-

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

в табл. 9.10,

также три службы авторизации, перечисленные

табл. 9.11. Число

служб

обоих случаях легко увеличить. Наличие

или

отсутствие конкретной

службы зависит не

от

DCOM,

от операционной системы. Так, например,

Win-

dows 2000 обычно доступны такие службы, как SSL и версия Kerberos с асиммет-

ричной криптосистемой.

Таблица 9.10. Стандартные службы аутентификации, поддерживаемые DOOM

Служба Описание

NONE

Аутентификация отсутствует

DCE_PRI VATE

Аутентификация DCE

на

основе общих ключей

DCE_PUBL

IС Аутентификация DCE

на

основе открытых ключей

WINNT Аутентификация службой защиты Windows

GSS_KERBEROS Аутентификация при помощи Kerberos

Таблица 9.11. Стандартные службы авторизации, поддерживаемые DCOM

Служба Описание

NONE

Авторизация отсутствует

NAME

Авторизация путем идентификации клиента

DCE

Авторизация

помощью сертификатов атрибутов привилегий (РАС)

Так настроить параметры активизации, чтобы клиент получил возможность

создавать экземпляры объекта, невозможно.

Эту

информацию можно только

декларировать, поскольку

SCM

машины,

на

которой создается объект, всегда

592 Глава 9. Распределенные системы объектов

проверяет реестр, чтобы убедиться, что привилегии клиента соответствуют акти-

визации. Однако можно делегировать право на активизацию другому процессу.

Детали можно найти в

[132].

9.3. Globe

Последний пример распределенной системы объектов, который мы рассмот-

рим,

—

это система Globe.

Globe

{Global

Object-Based Environment —

глобальная

объектная

среда)

—

это экспериментальная распределенная система, разработан-

ная авторами и их коллегами в университете Vrije (Амстердам). Основная цель

разработки системы, которая отличает Globe от CORBA и DOOM,

—

предостав-

ление возможности поддерживать очень большое число пользователей и объек-

тов,

разбросанных по всему Интернету, при сохранении полной прозрачности

распределения. Большинство других распределенных систем объектов, как из-

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

Обзор системы можно найти в

[471];

детальное описание архитектуры имеет-

ся в

[202].

9.3.1.

Обзор

Globe

—

это распределенная система объектов, в которой особую роль играет масш-

табируемость. Структура Globe определялась задачами построения крупных гло-

бальных систем, способных поддерживать огромное число пользователей и объ-

ектов. Основным при таком подходе является метод просмотра объектов. Как и в

случае других систем объектов, объекты в Globe рассматриваются как инкапсу-

ляция сущностей и операций над ними.

Важное отличие Globe от других систем объектов, особенно от других масш-

табируемых систем, таких как Legion [181, 182] состоит в том, что объекты могут

также инкапсулировать реализацию правил распределения состояния объектов

по нескольким машинам. Другими словами, каждый объект определяет, каким

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

ляет также и другими своими правилами.

Вообще говоря, объекты в Globe отвечают за все, что только можно. Так, на-

пример, объект определяет, как, когда и куда может переместиться его состоя-

ние.

Кроме того, объект решает, следует ли делать реплики его состояния и, если

да, как именно должна происходить репликация. Объект может также опре-

делять свои правила защиты и реализацию. Ниже мы опишем, каким образом

достигается такая инкапсуляция.

Объектная модель

в отличие от большинства других распределенных систем объектов. Globe не

поддерживает модель удаленных объектов. Объекты в Globe обладают способно-

стью храниться в физически раздробленном состоянии, то есть состояние объек-

тов может быть распределено и реплицировано между несколькими процессами.

9.3. Globe

593

Эту организацию иллюстрирует рис. 9.23, на котором показан объект, распреде-

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

дельной машине. Объекты в Globe являются распределенными

разделяемыми

объ-

ектами {distributed shared

objects).

Это название отражает тот факт, что объекты

обычно используются несколькими процессами одновременно. Объектная мо-

дель Globe восходит своими корнями к распределенным объектам Огса, описан-

ным в [27]. Схожая объектная модель используется также в операционной систе-

ме SOS [282, 409].

Распределенный

разделяемый

объект

Локальный

объект

Процесс

Интерфейс

Рис.

9.23. Организация распределенного разделяемого объекта

Процесс, связанный с распределенным разделяемым объектом, получает ло-

кальную реализацию интерфейсов этого объекта. Эта локальная реализация на-

зывается

локальным представлением {local

representative),

или просто локальным

объектом {local

object).

В принципе, так или иначе, локальный объект имеет со-

стояние, полностью прозрачное для содержащего его процесса. Вся реализация

объекта скрыта за предлагаемыми процессу интерфейсами.

Всякий локальный объект реализует стандартный интерфейс SOInf объекта,

подобный интерфейсу lUnknown в DCOM. В частности, подобно Querylnterface

BDCOM, SOInf имеет метод

getinf,

который получает в качестве исходных дан-

ных идентификатор интерфейса и возвращает указатель на этот интерфейс,

позволяя другим процессам получить доступ к его реализации в объекте. Име-

ются и другие примеры сходства между локальными объектами Globe и объекта-

ми DCOM. Так, например, предполагается, что каждый локальный объект имеет

соответствующий объект класса, который может создавать новые локальные

объекты.

Локальные объекты реализуют бинарные интерфейсы, которые состоят в ос-

новном из таблиц указателей на функции. Интерфейсы описываются на языке

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

используемые в CORBA и DCOM, но имеет некоторые частные отличия.

Существует две разновидности локальных объектов Globe. Примитивный

локальный объект {primitive local object) — это локальный объект, который не

содержит других локальных объектов. В противоположность ему, составной

594

Глава 9. Распределенные системы объектов

локальный

объект {composite local object) —

это объект, составленный из несколь-

ких (возможно также составных) локальных объектов. Для поддержания состав-

ных объектов таблица интерфейсов локальных объектов Globe состоит из пар

указателей

(состояние,

метод). Каждый указатель на состояние соответствует

данным, принадлежащим одному конкретному локальному объекту. В случае

интерфейса примитивного локального объекта все указатели на состояние опре-

деляют одни и те же данные, относящиеся к состоянию самого объекта. В случае

составных объектов указатели на состояние определяют состояния разных объ-

ектов, входящих в этот составной объект.

Составные объекты используются для построения локальных объектов, необ-

ходимых для реализации распределенных разделяемых объектов. Подобный ло-

кальный объект содержит как минимум четыре подобъекта (рис. 9.24).

Интерфейс, реализуемый

подобъектом семантики

Подобъект ^

управления

с.

Подобъект

репликации

Подобъект

связи

Подобъект

семантики

Связь с другими

локальными объектами

Рис. 9.24. Обобщенная структура локального объекта для распределенных

разделяемых объектов Globe

Подобъект семантики {semantics subobject)

реализует функциональность рас-

пределенного разделяемого объекта. Так, например, с помощью Globe были раз-

работаны распределенные web-сайты, в которых коллекция логически связанных

web-страниц, значков, изображений и т. п. была объединена в один документ. Та-

кой документ, называемый

GlobeDoc

[472],

реализуется локально при помощи

подобъекта семантики, предоставляющего интерфейсы, перечисленные в табл. 9.12.

Каждый файл, используемый как часть web-документа, считается элементом

объекта GlobeDoc. При помощи интерфейса документа можно добавлять или

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

щий список всех элементов. Предполагается, что web-документы организованы в

виде графа с корнем. При помощи отдельных методов можно определить и най-

ти корневой элемент, которым во многих web-приложениях является стандарт-

ный файл index.htm.

9.3. Globe 595

Таблица 9.12. Интерфейсы, реализованные в подобъекте семантики

объекта GlobeDoc

Метод Описание

Интерфейс документа

AddEl

ement Добавление элемента к текущему набору элементов

Del

eteEl ement Удаление элемента из web-документа

А11Е1 ements

Возвращение списка входящих в документ элементов

SetRoot Установка корневого элемента

GetRoot Возвращение ссылки на корневой элемент

Интерфейс содержимого

GetContent Возвращение содержимого элемента в виде массива байтов

PutContent Замена содержимого элемента заданным массивом байтов

PutAl

Content Замена содержимого всего документа

Интерфейс свойств

GetProperti

Получение списка пар

{атрибут,

значение) из элемента

SetProperties Установка списка пар

(атрибут,

значение) для элемента

Интерфейс блокировок

CheckoutЕ1

ements Захват группы модифицируемых элементов

Check I пЕ1

ements Освобождение группы модифицированных элементов

GetCheckedEl ements Получение списка захваченных элементов

Каждый элемент представляется просто массивом байтов. Интерфейс содер-

жимого включает в себя методы получения текущего содержимого документа

и его замены заданным массивом байтов. Интерфейс свойств представляет мето-

ды для манипулирования с метаданными, связанными с элементом. Метаданные

элемента представлены в виде пар (атрибут,

371аче7ше).

Так, например, каждый

из элементов GlobeDoc имеет свой МШЕ-тип (МШЕ-типы мы обсудим в гла-

ве И).

И, наконец, для того чтобы иметь возможность вносить изменения в элементы

параллельно, каждый объект GlobeDoc реализует интерфейс блокировок. Этот

интерфейс иллюстрирует принятый в Globe подход к управлению параллельным

доступом. Поскольку мы предполагаем, что большинство web-документов исполь-

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

но сделать достаточно простым. Когда элемент необходимо изменить, то первым

делом он захватывается. Захватить

(check

out) элемент

—

это, в сущности, то же

самое, что блокировать его на время модификации. Возможность чтения при этом

сохраняется. После проведения модификации элемент

освобождается (check

in),

при этом изменения вступают в силу.

Вернемся к локальному объекту для распределенных разделяемых объектов,

показанному на рис. 9.24. Его

подобъект

связи

(communication subobject)

исполь-

зуется для получения стандартного интерфейса с базовой сетью. Этот подобъект

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

с установлением соединения и без установления соединения. Существуют также

596 Глава 9. Распределенные системы объектов

и более совершенные подобъекты связи, реализующие интерфейсы групповой

рассылки. Некоторые подобъекты связи могут использоваться для организации

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

ную связь.

Очень важным практически для всех распределенных разделяемых объектов

является

подобъект

репликации

{replication

subobject).

Этот подобъект реализует

принятую стратегию распределения объекта. Как и в случае подобъекта связи,

его интерфейс стандартизован. Подобъект репликации отвечает за то, как имен-

но будет выполняться метод, представленный подобъектом семантики. Так, на-

пример, подобъект репликации, реализующий активную репликацию, должен быть

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

и том же порядке. В этом случае этот подобъект сможет работать в связке с под-

объектом репликации другого локального объекта, представляющего тот же са-

мый распределенный разделяемый объект.

Подобъект

управления

{control subobject)

играет роль прослойки между поль-

зовательским интерфейсом подобъекта семантики и стандартизованным интер-

фейсом подобъекта репликации. Кроме того, он отвечает за экспорт интерфейсов

подобъекта семантики в процессы, работающие с распределенным разделяемым

объектом. Перед передачей подобъекту репликации подобъект управления вы-

полняет маршалинг всех обращений к методам, отправляемых такими процессами.

Подобъект репликации в принципе может позволить подобъекту управления

самому обработать запрос и вернуть результат процессу, обратившемуся к объ-

екту. Точно так же можно передавать подобъекту управления запросы удален-

ных процессов. Будет выполнен демаршалинг такого запроса, после чего подобъект

управления выполнит его и передаст результаты обратно подобъекту реплика-

ции. Рассмотрение деталей мы отложим до обсуждения вопросов репликации

в системе Globe.

Привязка процесса к объекту

в противоположность CORBA и DCOM, система Globe не имеет ни хранилища

интерфейсов, ни аналога хранилища реализаций. Отсутствие этих двух служб

частично связано с той моделью объектов, которая используется в Globe. Так,

в частности, когда происходит привязка процесса к объекту, процесс должен за-

грузить в свое адресное пространство конкретный локальный объект, соответ-

ствующий распределенному разделяемому объекту, к которому выполняется при-

вязка. Рассмотрим, как в Globe происходит привязка процесса к объекту.

Как показано на рис. 9.25, привязка выполняется за пять шагов. Каждый шаг,

за исключением последнего, возвращает информацию, необходимую для сле-

дующего шага. Таким образом, если мы получили информацию для очередного

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

фективность привязки в целом.

Привязка начинается с осмысленного (с позиций человека) имени службе

именования. Это действие обозначено на рисунке как шаг 1. В Globe входит

служба именования на основе DNS, которую мы обсудим чуть ниже. Эта служба

возвращает глобально уникальное имя и не зависящий от местоположения деск-

9.3. Globe

597

риптор объекта (object handle). Это действие обозначено на рисунке как шаг 2.

Дескриптор объекта используется в Globe в качестве глобальной ссылки на объ-

ект, которая позволяет выполнять поиск объекта при помощи службы локализа-

ции Globe. Отметим, что Globe отделяет службу именования от службы локали-

зации (см. главу 4). Достоинство подобного разделения заключается в том, что

мы можем изменять имена и адреса, без какого бы то ни было влияния на ото-

бражение имен в адреса.

Клиент

3. Выбор

адреса

Объект

класса Локальный

объект

i 1

Передача имени

Дескриптор объекта

Передача дескриптора

объекта ^

Служба именования

Адреса и протоколы

5. Инициализация

контакта

Загрузки и создание

экземпляра класса

(Доверенное)

хранилище классов

Распределенный

разделяемый объект

Рис. 9.25. Привязка процесса к объекту в Globe

Служба локализации Globe возвращает набор контактных адресов данного

объекта.

Контактный адрес (contact address)

точно определяет, где и каким обра-

зом можно найти объект. Объект может иметь несколько контактных адресов,

например, в связи с репликацией или поддержкой нескольких коммуникацион-

ных протоколов. Далее мы увидим, что контактный адрес напоминает межопера-

ционную ссылку на объект (IOR) в CORBA. После получения контактного адре-

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

информация.

Поскольку служба локализации может вернуть набор контактных адресов

для одного объекта, процесс должен прежде всего выбрать один из них (шаг 3).

Выбор может быть произвольным или опираться на те или иные критерии, такие

как расстояние до адреса или предполагаемое качество обслуживания в случае

привязки к данному адресу.

Любой контактный адрес содержит информацию о том, что необходимо для

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

частности, он точно определяет локальный объект, который процессу следует

загрузить. Так, например, контактный адрес может содержать URL-адрес файла,

598 Глава 9. Распределенные системы объектов

содержащего объекты класса, которые должен загрузить процесс. Подобный

подход напоминает загрузку классов

Java.

Загрузку локального объекта из хра-

нилища (доверенного) классов и создание экземпляра иллюстрирует шаг 4.

Отметим, что хранилище классов может быть просто файловой системой, воз-

можно, удаленного сайта с доступом по FTP или по другому протоколу обмена

файлами.

Отметим, что хранилище классов напоминает хранилище реализаций CORBA

в том смысле, что оба они содержат реализации объектов. В Globe, однако, хра-

нилище классов больше соответствует трад^щионной схеме хранения, в которой

выбирается код. В CORBA это процесс, которому можно отправить запрос на

создание объекта на сервере объекта.

И, наконец, последний шаг состоит в инициализации локального объекта

и организации через этот локальный объект работы с другими локальными объек-

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

Службы Globe

в противоположность CORBA и DCOM, Globe содержит относительно немного

служб. На самом деле реализованы только те службы, которые не предоставляют-

ся самим объектом. Это проще всего объяснить, рассматривая некоторые службы,

имеющиеся в CORBA и DCOM, и их реализацию в Globe (табл. 9.13).

Таблица 9.13. Возможные реализации в Globe обычных служб

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

Служба Возможная реализация в Globe Доступность

Служба коллекций Выделенный объект, содержащий ссылки Нет

на другие объекты

Служба параллельного Каждый объект реализует собственную Нет

доступа стратегию управления параллельным

доступом

Служба транзакций Выделенный объект, представляющий собой Нет

менеджер транзакций

Служба Выделенный объект на каждую группу Нет

событий/уведомлений событий (как в DCOM)

Служба внешних связей Каждый объект реализует собственные Да

процедуры маршалинга

Служба жизненного цикла Выделенные объекты класса реализуются Да

внутри объекта

Служба лицензирования Реализуется каждым объектом Нет

в отдельности

Служба именования Выделенная служба, реализованная в виде Да

коллекции именующих объектов

Служба свойств/обмена Выделенная служба, реализованная в виде Нет

коллекции направляющих объектов

Служба сохранности Реализуется внутри объекта Да

Служба защиты Реализуется внутри объекта в комбинации Да

со службами (локальными) защиты

Служба

Служба репликации

Служба

отказоустойчивости

9.3. Globe 599

Возможная реализация в Globe Доступность

Реализуется внутри объекта Да

Реализуется внутри объекта в комбинации Да

с серверами обеспечения отказоустойчивости

Служба коллекций CORBA используется для объединения объектов в спи-

ски,

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

объекта, состояние которого представляет собой набор ссылок на объекты. В Globe

подобная служба реализована именно так.

Служба параллельного доступа в CORBA определена в понятиях коллекции

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

[327].

В DCOM управление параллельным доступом осуществляется частично служ-

бой транзакций, а частично так же, как серверы объектов обслуживают потоки

выполнения. В Globe управление параллельным доступом обычно производится

каждым объектом самостоятельно. Другими словами, разделяемый объект, кото-

рому необходимо предотвратить параллельный доступ к своему состоянию, дол-

жен предоставить необходимый специальный интерфейс для блокировки. Ника-

кого стандартного интерфейса для управления параллельным доступом в Globe

не существует.

Как и в коллекциях, в транзакциях также происходит объединение объектов.

В Globe транзакции обычно реализуются при помощи выделенного объекта, иг-

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

стандартизованы.

В Globe нет службы событий. Как мы увидим, объекты в Globe всегда пассив-

ны в том смысле, что у них отсутствует собственный поток выполнения. Таким

образом, объект не в состоянии уведомить клиента о произошедшем событии.

Для реализации службы событий в Globe подошла бы модель извлечения (pull)

CORBA. В этом случае события можно было бы объединить в один объект, как

в классе событий DCOM. До настоящего времени события в Globe не использо-

вались.

Служба внешних связей, или служба маршалинга, обычно реализуется для

каждого объекта в отдельности. В Globe большинство объектов должны реализо-

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

возможность передавать свое состояние на другие машины. Мы вернемся к во-

просам маршалинга чуть позже, когда будем обсуждать объектную модель Globe.

Служба жизненного цикла предоставляет средства создания, удаления, копи-

рования и перемещения объектов. Понятно, что в Globe объект создать сам себя

не может. Все прочие операции реализуются самим объектом; специальные сред-

ства для удаления, копирования или перемещения объектов в Globe отсутству-

ют. Создание объектов обычно выполняется путем прямого обращения к серверу

объекта с требованием создать экземпляр объекта. Подобный подход немного на-

поминает способ, применяемый в DCOM.

Лицензирование в Globe не поддерживается, но может быть реализовано

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

600 Глава 9. Распределенные системы объектов

Служба именования

—

это хороший пример службы, которую невозможно

реализовать при помощи именованного объекта, поскольку она используется для

поиска этого объекта. Другими словами, доступ к службе именования по опреде-

лению требуется раньше, чем доступ к именованным объектам. Разумеется, сама

по себе служба именования может быть реализована с использованием объектов,

как это сделано, например, в CORBA. В Globe имеется выделенная служба име-

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

свойств и торговли также должны быть реализованы отдельно от объектов, ссыл-

ками на которые они манипулируют.

Множество распределенных систем имеют выделенную службу сохранности

(длительного хранения) в форме файловой системы или базы данных. В Globe

такой службы нет. Вместо этого сохранность рассматривается как свойство объ-

екта, а потому должна реализовываться самим объектом. Как добиться сохран-

ности, в основном решает объект. Однако объекту для длительного хранения его

состояния необходима определенная поддержка. В Globe эта поддержка обеспе-

чивается в первую очередь серверами объектов, хотя многие реализации объек-

тов используют также локальную файловую систему.

Защита в Globe частично реализуется каждым объектом в отдельности, а час-

тично локальными и глобальными службами защиты. Так, например, хотя объ-

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

ем к методам, вопросы получения и сертификации ключей обычно выделяют

в отдельную службу. Ниже мы еще вернемся к вопросам защиты в Globe.

Основная разница между Globe и другими распределенными системами объ-

ектов становится очевидной при рассмотрении вопросов репликации. Как мы

говорили, объекты в Globe сами определяют, как нужно реплицировать их со-

стояние. Другими словами, репликация осуществляется исключительно силами

самих объектов. В противоположность этому, в таких системах, как CORBA, обыч-

но применяются специальные серверы репликации, которые управляют репли-

кацией групп объектов. Детали реализации репликации в Globe будут рассмот-

рены позже.

И, наконец, отказоустойчивость в Globe также поддерживается каждым из

объектов, хотя для успешной маскировки ошибок необходима определенная под-

держка со стороны серверов отказоустойчивых объектов. И снова мы обещаем

вернуться к обсуждению отказоустойчивости чуть позже.

9.3.2. Связь

в отличие от CORBA и DCOM Globe не предоставляет никаких других методов

связи кроме синхронных обращений к методам. Когда обращение завершается, то

есть когда происходит возвращение результата обращения (обращение при этом

выглядит как вызов метода через локальный интерфейс), всякая деятельность

внутри распределенного разделяемого объекта прекращается, не считая деятель-

ности, связанной с другими вызовами. В этом смысле объекты Globe считаются

пассивными

(passive).