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

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

9.3.

Globe

611

Состояние Производимое действие Вызов метода Следующее

состояние

Метод модификации первичной копии

START Отсутствует

INVOKE Обратиться к локальному методу

RETURN

Вернуть результаты

start

invoked

Нет

INVOKE

RETURN

START

9.3.7. Отказоустойчивость

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

счет репликации. Во многих случаях для обеспечения отказоустойчивости впол-

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

на нескольких машинах. Что действительно необходимо

—

так это механизмы

восстановления после отказа.

В плане восстановления после сбоев сервер объектов Globe гарантирует, что

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

ке.

Другрши словами, как мы говорили ранее, эти объекты превращаются в со-

хранные объекты. Однако помимо сохранности необходимо гарантировать, что

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

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

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

ки.

Подобные средства Globe пока не предоставляет.

9.3.8. Защита

Меры защиты в Globe сосредоточены на предотвращении хакерских атак на оди-

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

пользуемый для обеспечения подобной защиты,

—

создание дополнительного

под-

объекта защиты (security subobject)

как части каждого локального объекта. Место

подобъекта защиты в структуре локальных объектов иллюстрирует рис. 9.29.

Подобъект защиты обеспечивает защита на различных этапах обращения

методам.

Во-первых, необходимо гарантировать, что обращения удаленргых про-

цессов аутентифицированы. По этой причине подобъект связи должен переда-

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

аутентифицировать запрашивающий процесс.

После завершения аутентификации информацией с подобъектом защиты об-

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

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

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

пустимо или нет обращение к нему ранее аутентифицированного запрашиваю-

щего процесса.

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

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

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

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

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

шает определенное значение.

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

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

^ .

t t

Связь с другими Связь с локальными

локальными службами

объектами защиты

Рис. 9.29. Место подобъекта защиты в локальном объекте Globe

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

мер,

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

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

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

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

объект поддержки {principal

object).

Этот объект представляет пользователя распределенного разделяемого

объекта в конкретном защищенном домене. Объект поддержки отвечает за взаи-

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

фикации и сертификации.

В качестве примера рассмотрим, как можно использовать в распределенном

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

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

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

РА

РВ.

Рисунок 9.30

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

зации защищенного взаимодействрш между А\\ В при условии, что процессы

РА

и Рв относятся к разным защищенным доменам.

Сначала подобъект защиты вызывает объект поддержки (представляющий

процесс

РА),

чтобы получить сеансовый ключ (шаг 1). Объект поддержки запраши-

вает подсистему аутентификации Kerberos и ее службу выдачи талонов (шаг 2),

чтобы получить сеансовый ключ и талон для локального объекта В (шаг 3), кото-

рые передаются подобъекту защиты (шаг 4).

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

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

(шаг 5). Далее талон попадает к объекту поддержки, представляющему процесс

9.4. Сравнение систем CORBA, DCOM и Globe 613

Рв (шаг

6),

который берет

на

себя расшифровку талона

возвращает получен-

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

(шаг

7).

Защищенный домен

Объект поддержки

процесса

Локальный

объект

Процесс

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

—

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

Локальный

объект

Защищенный домен

Г|

Kerberos

Процесс А

Объект поддержки процесса

Рис. 9.30. Защита распределенных разделяемых объектов

помощью системы Kerberos

Дополнительную информацию о защите в Globe можно найти в [202, 261].

9.4. Сравнение систем CORBA, DCOM

и Globe

CORBA, DCOM

Globe

—

три разные системы объектов со своими преимущест-

вами

недостатками. После детального обсуждения принципов организации этих

трех систем давайте сравним их между

собой.

Начнем с целей, которые ставились

при разработке каждой системы.

9.4.1.

Философия

Системы CORBA, DCOM

Globe разрабатывались

разными целями. CORBA

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

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

ния от разных производителей. Сотни участников различных комитетов старались

прийти

соглашению

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

компонентов CORBA, и поразительно уже

то,

что они вообще о чем-то сумели до-

говориться.

Основной целью разработки DCOM было расширение функциональных воз-

можностей

при

сохранении совместимости

существующими версиями, вклю-

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

ченными в ранние системы Windows. Неплохо, что старые приложения по-преж-

нему работоспособны, гораздо хуже, что когда-то сделанные неудачные решение

теперь практически невозможно исправить. Модель DCOM чрезвычайно сложна,

и это удивительно, особенно учитывая тот факт, что она в отличие от CORBA не

является результатом работы многочисленных комитетов и комиссий.

Система Globe представляет собой типичный образец исследовательской ра-

боты. Она была разработана небольшим коллективом, предпочитавшим просто-

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

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

шинстве других исследовательских проектов, план Globe, в сущности, прост и по-

нятен. Однако Globe

—

незавершенная система и многие ее аспекты требуют до-

работки. Основная це.71ь разработки Globe

—

обеспечение масштабируемости.

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

ключаются в следующем. В CORBA и DOOM используется модель удаленных

объектов. CORBA предлагает гибкую и непротиворечивую объектную модель.

Сила подхода CORBA состоит в том, что подобная система обеспечивает высо-

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

к объектам. Клиенту нелегко заметить разницу между локальным и удаленным

объектами. Объекты обладают состоянием, могут быть глобально идентифици-

рованы, а ссылки легко передаются от клиента к клиенту и от машины к машине.

Кроме того, объекты могут быть как нерезидентными, так и сохранными.

Модель DCOM значительно проще модели CORBA, и мы могли бы даже по-

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

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

имеют состояния. Эта модель нарушает многие прршципы, лежащие в основе тех-

нологии распределенных объектов.

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

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

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

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

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

цию.

Кроме того, он может также инкапсулировать правила и реализации защи-

ты,

обработки ошибок и т. д.

Сравнивая службы этих систем, мы также видим серьезные различия. CORBA

содержит обширный набор служб, обширный настолько, что функциональность

отдельных служб нередко пересекается. С другой стороны, DCOM предлагает

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

ния и каталогов. В Globe реализован только абсолютный минимум служб

—

про-

стейшая служба именования и расширенная служба локализации. Это соответству-

ет философии построения Globe, однако совершенно ясно, что для превращения

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

чения ей необходимо иметь множество дополнительных служб.

Другое существенное отличие трех систем друг от друга состоит во взгляде на

интерфейсы. CORBA предоставляет стандартный язык IDL, на котором состав-

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

9.4. Сравнение систем CORBA, DCOM и Globe 615

выбранном языке программировагнш. С точки зрения переносимости и межопе-

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

ности, стандартизовано. Основное преимущество такого подхода состоит в том,

что CORBA не зависит от кода, генерируемого компиляторами. В сущности,

CORBA определяет межоперационное взаимодействие на уровне языка програм-

мирования.

В противоположность CORBA системы DCOM и Globe поддерживают би-

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

ся независимо от языка программирования. В DCOM достоинства бинарных ин-

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

на смеси таких языков, как С, Java и Visual Basic. В Globe используется анало-

гичный подход.

9.4.2. Связь

Рассмотрим теперь, как реализована связь в системах. CORBA изначально ис-

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

модель поддерживает и асинхронную связь

—

в форме односторонних и отложен-

ных синхронных запросов. В настоящее время модель взаимодействия CORBA

уже не так проста и обладает богатым набором возможностей. Это асинхронные

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

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

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

сообщений.

В этом аспекте модель DCOM похожа на CORBA. Она обеспечивает син-

хронное обращение к удаленным методам, но, кроме того, и разнообразные (при-

чем несовместимые) механизмы обратного вызова. Как и CORBA, она также под-

держивает работу с сообщениями.

Globe допускает только синхронные обращения к методам. В этой системе

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

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

Для того чтобы обойти проблемы, связанные с репликацией сообщений, о кото-

рых мы говорили в главе 6, необходимы специальные меры

[288].

Проблема под-

держки цепочек обращений не решена до сих пор. Отметим, что эта проблема не

ограничивается Globe; системы CORBA и DCOM также столкнутся с ней, как

только попытаются реплицировать объекты.

9.4.3. Процессы

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

шенно непохожий на другие. Сервер объектов CORBA наиболее гибкий и уни-

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

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

мощи адаптера объектов CORBA. Такое разделение помогает разрабатывать рас-

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

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

Серверы объектов DCOM

—

это ответ Microsoft на необходимость разработки

распределенных объектов. Они не такие гибкие, как серверы объектов CORBA

с их адаптером РОА, а управление объектами и обращением к методам в основ-

ном жестко закодировано в исполняющей системе. Кроме того, когда дело дохо-

дит до поддержки потоков выполнения, разработчики объектов до некоторой

степени уже не властны над

ними.

JIT-активизация, которую поддерживают сер-

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

объект не имеет информации о состоянии. Ценность этого подхода для любой

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

Сервер объектов Globe несколько примитивнее, но его функциональность

сравнима с адаптером РОА системы CORBA. Эта функциональность в основном

является следствием того факта, что объекты могут иметь свою собственную

реализацию подобъекта управления и подобъекта репликации. Сервер объектов

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

сутствует необходимость в конфигурировании сервера, как в случае РОА систе-

мы CORBA. Однако поскольку объекты в Globe в основном могут определять

лишь правила своего распространения, репликации и защиты, оставшиеся виды

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

стоящее время имеется лишь ограниченная поддержка сохранности объектов.

9.4.4. Именование

Основная разница между CORBA, DCOM и Globe проявляется при сравнении

служб именования этих систем. В CORBA имеется множество механизмов име-

нования и ссылок на объекты. В частности, в число этих механизмов входят вы-

деленная служба именования, службы свойств и обмена. В сущности, каждая из

этих служб возвращает одну или несколько ссылок на объекты. Ссылка на объект

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

интересующий нас объект. Кроме того, она может указывать на хранилище реа-

лизаций, которое отслеживает текущий сервер объекта, или даже непосредствен-

но активизировать объект в случае необходимости.

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

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

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

в которых относительно просто создать эффективную службу локализации. Од-

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

глобальных системах они неприменимы.

Модель DCOM сама по себе не имеет службы именования, а пользуется су-

ществующими службами своего окружения, такой как Active Directory. Если по-

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

можным.

Одна из форм ссылок на объекты в DCOM

—

это указатели на интерфейсы.

Маршалинг этих указателей обычно требует маршалинга и доставки в нужное

место клиентского заместителя. Если ограничиться стандартным маршалингом,

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

9.4. Сравнение систем CORBA, DCOM и Globe 617

терфейс в качестве ссылки на объект

—

это непростое занятие, особенно когда

требуется что-то необычное.

Ссылки на сохранные объекты имеют форму моникеров (в [333] вместо тер-

мина mo??z^er используют термин

kludge).

Моникеры

—

достаточно сложная тема.

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

ко это лекарство лучше болезни, остается открытым.

Подход, принятый в Globe, в корне отличается от подходов CORBA и DCOM

с жестким разделением между именованием и адресацией объектов. Использова-

ние в системе Globe независимых от местоположения долгоживущих идентифи-

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

ни на адрес, которое хранится в традиционной службе именования. Изменение

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

дали достоинства этого подхода в главе 4. Основной его недостаток состоит в не-

обходимости выделенной и хорошо масштабируемой службы локализации. Раз-

работка такой службы

—

дело далеко не простое.

Именование объектов в Globe при помощи строк символов относительно не-

сложно. К сожалению, отсутствует служба каталогов, которая позволила бы клиен-

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

ба нужна многим распределенным системам.

9.4.5. Синхронизация

Механизмы синхронизации, имеющие вид традиционных служб блокировки

и транзакций, реализованы только в CORBA и DCOM. Globe не имеет механиз-

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

ми,

которые реализуются подобъектами репликации.

9.4.6. Кэширование и репликация

в механизмах кэширования и репликации трех систем имеются серьезные разли-

чия.

Определение репликации в CORBA потребовало длительных усилий, связан-

ных в основном с трудностями интеграции самого понятия репликации в пред-

ставление об удаленном объекте. Подход к репликации в CORBA в настоящее

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

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

объектов. Другими словами, с точки зрения клиента нет в сущности никакой раз-

ницы, реплицируется объект или нет.

Сервер репликации определяет, как, где и когда происходит репликация.

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

можно ассоциировать с группами объектов. Все эти правила реализуют последо-

вательную непротиворечивость. Типичная реализация базируется на механизме

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

Не существует каких-то отдельных средств поддержания кэширования, но его

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

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

ков.

Реализация подсистемы кэширования, однако, полностью возлагается на раз-

работчртка приложений. Проблема такого подхода состоит в необходимости про-

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

В DCOM нет поддержки кэширования и репликации. Эти вопросы приложе-

ния должны решать для себя сами.

В Globe используется совершенно другой подход, нежели в CORBA. В Globe

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

объект репликации. Поскольку интерфейс подобъекта репликации стандартизо-

ван,

объекту могут быть с легкостью приписаны различные реализации разных

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

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

тегий репликации, принятый в CORBA. Тот же самый механизм можно исполь-

зовать и для создания механизмов кэширования.

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

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

зацир!

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

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

В этом смысле подобъекты репликации Globe можно сравнить с перехватчиками

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

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

ных объектов.

9.4.7. Отказоустойчивость

Отказоустойчивость в CORBA, как мы говорили ранее, в основном обеспечивает-

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

доступа также способствуют разработке отказоустойчивых служб CORBA.

DCOM обеспечивает отказоустойчивость системы сходным образом, при по-

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

динатором транзакций.

Globe не поддерживает транзакций, а обеспечение отказоустойчивости бази-

руется только на репликации. Существует не СЛР1ШКОМ МНОГО способов восста-

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

в локальном долговременном хранилище.

9.4.8. Защита

и, наконец, сравнивая защиту в CORBA, DCOM и Globe, мы снова обнаружива-

ем между этими системами серьезные различия.

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

тов.

Разбираясь в многочисленных механизмах защиты, следует позаботиться об

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

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

привязанных к приложению объектов правил. При обработке брокером ORB за-

проса или ответа он обращается к объектам правил. Объект правил можно скон-

9.4. Сравнение систем CORBA, DCOM и Globe 619

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

ты.

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

системе Kerberos.

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

хвате вызовов. Чтобы сделать это безопасным образом, CORBA поддерживает

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

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

Другой подход используется в DCOM. Защита поддерживается на деклара-

тивном уровне путем указания в реестре требованри1 объекта по активизации,

контролю доступа и аутентификацирх. Выполнение этих требований совместно

обеспечивают операционная система и DCOM. Альтернативный подход состоит

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

рать,

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

функций.

Защр1та в Globe частично реализована на базе выделенных подобъектов защрх-

ты.

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

Kerberos. Кроме того, они решают вопросы защиты, связанные с взаимодействи-

ем,

репликацией и обращениями к подобъектам семантики. Однако архитектура

защиты Globe остается незавершенной.

Результаты сравнения систем CORBA, DCOM и Globe представлены в

табл. 9.20.

Таблица 9.20. Сравнение CORBA, DCOM и Globe

Критерий

Цели разработки

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

Службы

Интерфейсы

Синхронная связь

Асинхронная связь

Обратные вызовы

События

Сообщения

Сервер объектов

Служба каталогов

Служба обмена

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

Служба локализации

Ссылки на объекты

CORBA

Межоперационная

совместимость

Удаленные объекты

В основном

собственные

На основе IDL

Да

Гибкий (PDA)

Да

Нет

По местоположению

объекта

DOOM

Функциональность

Удаленные объекты

Из окружения

Бинарные

Да

Жестко

кодированный

Да

Нет

Да

Нет

Указатель на

интерфейс

Globe

Масштабируемость

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

объекты

Несколько

Бинарные

Да

Нет

Определяемый

объектами

Нет

Да

Правильный

идентификатор

продолжение ё^

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

Таблица 9.20

(продолжение)

Критерий

Синхронизация

Поддержка

репликации

Транзакции

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

Поддержка

восстановления

Защита

CORBA

Транзакции

Выделенный сервер

Да

Посредством

репликации

Да

Различные

механизмы

DCOM

Транзакции

Отсутствует

Да

Посредством

транзакций

Посредством

транзакций

Различные

механизмы

Globe

Только между

объектами

Выделенный

подобъект

Нет

Посредством

репликации

Нет

Требует доработки

9.5. Итоги

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

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

для поддержки кэширования или репликации. В CORBA для изменения исходя-

щих и входящих запросов используются перехватчики. В DCOM пользователь-

ский маршалинг требует настройки клиентского заместителя. В Globe настройка

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

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

ный объект.

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

тов,

такие как CORBA или DCOM, поддерживают альтернативные средства обра-

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

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

Организация серверов объектов в различных системах, за исключением неко-

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

более одного объекта. Различия обнаруживаются в гибкой настройке сервера.

В CORBA гибкость обеспечивается при помощи адаптеров объектов. DCOM пре-

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

конкретное приложение. В Globe серверы объектов относительно просты, посколь-

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

пределенных объектов.

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

место на уровне ссылок на объекты. Поддержка осмысленных имен практически

одинакова. И в CORBA, и в DCOM внутрисистемные ссылки на объекты зависят

от их местоположения. Эти ссылки содержат информацию о местоположении

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

в Globe не зависят от местоположения, но для этой системы требуется глобаль-

ная служба локализации для разрешения ссылок в контактные адреса. Контакт-

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