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

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

9.1.C0RBA 561

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

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

цесс Л хотел, как описывалось выше, послать ссылку процессу J5, это успешно

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

го же брокера ORB. В противном случае версия ссылки после маршалинга, кото-

рую посылал процесс А, была непонятна брокеру ORB, обслуживающему про-

цесс В.

Все современные системы CORBA поддерживают одинаковое, не зависящее

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

ется

межоперационной

ссылкой на

объект

(Interoperable Object Reference, lOR).

He так уж важно, использует или нет ORB формат IOR для своих внутренних

нужд. Однако при передаче ссылки на объект другому брокеру ORB он делает

это в формате IOR. Ссылка IOR содержит всю информацию, необходимую для

идентификации объекта. Общий вид IOR представлен на рис. 9.10 вместе со спе-

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

деталях.

Теговый профиль

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

ссылка на объект (10R)

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

хранилища

1 '^

профиля

профиль

Версия

МОР

Хост Порт

Ключ

объекта

Компоненты

^,-'-""'' " """"--^

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

РОА

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

объекта

Другая информация

сервера

Рис. 9.10. Организация IOR со специфической информацией для ПОР

Каждая ссылка IOR начинается с идентификатора хранилища. Как мы гово-

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

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

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

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

ря этому идентификатору и клиент, и сервер получают доступ в одно и то же

хранилище интерфейсов или как минимум идентифицируют интерфейсы по од-

ному и тому же идентификатору.

Наиболее важная часть каждой ссылки IOR

—

так называемый

теговый

про-

филь (tagged profile). Каждый теговый профиль содержит всю информацию,

необходимую для обращения к объекту. Если сервер объектов поддерживает

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

дельном теговом профиле. Детали профиля для ПОР также представлены на

рис.

9.10.

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

Профиль для ПОР идентифицируется соответствующим полем тегового про-

филя и состоит, в свою очередь, из пяти полей.

> Поле версии ПОР определяет версию протокола ПОР, использованную в дан-

ном профиле.

"¥ Поле хоста

—

это строка, идентифицирующая хост, на котором находится

объект. Хост может быть задан либо в виде полного доменного DNS-име-

ни (например, soling.csvu.nl), либо в виде IP-адреса хоста (например,

130.37.24.11).

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

дящих сообщений.

Поле ключа объекта содержит информацию, необходимую серверу для

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

мер,

частью этого ключа, как правило, является созданный РОА идентифи-

катор объекта. Этот ключ будет также идентифицировать РОА.

'f И, наконец, поле компонентов может содержать дополнительную инфор-

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

относится ссылка. Это может быть, например, информация по защите, пока-

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

ный в ссылке сервер временно недоступен. Ниже мы еще вернемся к этим

вопросам.

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

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

дов.

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

—

это

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

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

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

Предваряя обсуждение службы именования CORBA, предположим, что кли-

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

имя. В ответ служба именования вернет хранимую ею и зависящую от языка

программирования реализацию ссылки IOR. Подобная реализация может быть

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

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

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

и для проверки идентификатора хранилища, содержащегося в IOR, может по-

местить заместитель на клиента и вернуть указатель р на этот заместитель. Внут-

ри себя ORB сохраняет сведения о том, что р соответствует IOR объекта.

Разные брокеры ORB имеют разную реализацию, но одинаковый сценарий

работы. До передачи р клиенту клиентский брокер ORB проверяет теговые про-

фили, входящие в IOR. Предположим, что объект вызывается по протоколу

ПОР.

В этом случае клиентский брокер ORB может, используя адрес хоста и но-

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

токолу TCP. В этот момент он и передает р клиенту.

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

няет маршалинг запроса в сообщение Request протокола ПОР. Это сообщение

содержит ключ объекта для данного сервера, который также хранится в IOR.

9.1.C0RBA

563

Сообщение через соединение TCP передается на сервер, где пересылается адап-

теру РОА, ассоциированному с ключом объекта. Далее РОА передаст запрос

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

зов метода.

Согласно этому сценарию IOR непосредственно ссылается на объект, что

приводит к так называемой прямой привязке

{direct

binding).

Альтернативой пря-

мой привязке является непрямая привязка

{indirect

binding),

при которой постро-

енный запрос сначала пересылается в хранилище реализаций. Хранилище реа-

лизаций

—

это еще один процесс, идентифицируемый в IOR объекта. Он служит

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

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

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

дающих правила, обязательные для объектов длительного хранения.

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

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

ций. Хранилище уведомляет, что запрос на самом деле предназначен для другого

сервера, и просматривает свои таблицы в поисках работающего сервера и его ме-

стоположения. Если соответствующий сервер в данный момент не запущен, хра-

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

томатического запуска.

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

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

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

ресылается соответствующему серверу.

iOR ссылается на хранилище реализаций

Клиент

IOR

5. Реальное обращение

Перенаправленное

сообщение

^ 3. Выяснение

^ активности объекта

Сервер

объекта

Первое обращение^

или запрос на привязку

Хранилище

реализаций

Активизировать или

запустить объект

Рис. 9.11. Непрямая привязка в CORBA

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

Как и другие распределенные системы, CORBA имеет службу именования, кото-

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

Формально имя в CORBA

—

это последовательность компонентов имени, каж-

дый из которых имеет вид пары

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

сорт), где

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

сорт

— строки. Обычно

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

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

строкой символов, например «steen» или «elke». Атрибут

сорт —

это просто ин-

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

дикатор именованного объекта, похожий на расширение в именах файлов. Так,

например, объект, названный «steen», может иметь сорт «dir», указывающий на

то,

что это объект каталога.

Не существует способа представить путь и имя в виде одной строки. Другими

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

сто этого имена можно передавать просто как последовательность компонентов

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

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

оно остается непрозрачным.

На структуру графа именования не существует ограничений. Каждый из уз-

лов графа именования трактуется как объект. Контекст именования (naming

context) — это объект, хранящий таблицу отображения компонентов имен в

ссылки на объекты. Контекст именования, таким образом, это то, что в главе 4

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

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

Граф именования не имеет корневого контекста. Однако каждый брокер ORB

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

собой корень графа именования. Имена всегда разрешаются в соответствии с

данным контекстом именования. Другими словами, если клиент хочет разре-

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

Если разрешение имени произошло успешно, он всегда возвращает ссылку либо

на контекст именования, либо на именованный объект. В этом смысле разреше-

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

дем повторно приводить всю эту информацию.

9.1.5.

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

Две наиболее важные службы, облегчающие синхронизацию в CORBA,

—

это

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

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

блокировки.

В основе транзакций в CORBA лежит следующая модель. Транзакция ини-

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

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

вится частью транзакции. При этом сервер объекта уведомляется о том, что

теперь он участвует в транзакции. Эта информация неявно передается серверу

при обращении к объекту.

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

мый

объект {recoverable

object) — это объект, выполняемый сервером объектов,

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

ности, серверы восстановимых объектов в состоянии обработать прерывание

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

ному из восстановимых объектов. Однако в ходе транзакции может осуществ-

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

шествующее началу транзакции. Конкретно

—

это

транзащионные объекты

(trans-

actional

objects)^

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

9.1.

CORBA 565

кол двухфазного подтверждения транзакций. Транзакционные объекты обычно

предназначены только для чтения.

Таким образом, понятно, что транзакции в CORBA подобны распределенным

транзакциям и их протоколам, которые мы обсуждали в главах 5 и 7.

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

го доступа,

—

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

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

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

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

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

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

си.

Информацию о степенях блокировки можно получить в [160, 177]

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

CORBA не поддерживает обобщенных кэширования и репликации. В третью

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

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

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

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

шинстве случаев эти меры основаны на ргспользовании перехватчиков.

Давайте рассмотрим один из примеров того, как для повышения произво-

дительности в CORBA можно включить возможность репликации. Эта задача

решается в системе CASCADE. В CASCADE цель состоит в предоставлении

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

CORBA

[102].

CASCADE поддерживает службу кэширования, реализуемую с по-

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

ссылается на так называемый доменный сервер кэширования {Domain Caching

Server,

DCS). Каждый сервер DCS

—

это сервер объектов, работающий в ORB

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

бальной сети, такой как Интернет.

Кэшируемые копии одного и того же объекта образуют иерархртю. Подразу-

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

ровать свой объект на локальном сервере DCS. Этот DCS становится корнем

иерархии. Другие клиенты также могут потребовать у своих локальных серверов

DCS кэшировать копию этого объекта. Для этого DCS сначала присоединяется

к текущей иерархии тех DCS, которые уже кэшируют этот объект.

CASCADE поддерживает клиентскую модель непротиворечивости данных,

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

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

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

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

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

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

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

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

ной степени зависит от шаблонов обращения и доступа к объекту. CASCADE

удовлетворяет этим требованиям.

В качестве службы CORBA система CASCADE тесно связана с перехватчи-

ками. Со стороны клиента система CASCADE фактически невидима, все вопросы,

связанные с непротиворечивостью, скрыты за интерфейсами, которые предо-

ставляют объекты. Единственный случай, когда клиент получает явный доступ

к CASCADE,

—

обращение к своему локальному серверу DCS с запросом о нача-

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

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

лаются DCS.

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

к запросу перед его отправкой в DCS добавляется дополнительная информация.

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

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

видел клиент.

Обобщенную организацию DCS ршлюстрирует рис. 9.12. DCS управляет не-

сколькими копиями объекта. Копия объекта состоит из состояния и реализаций

операций, производимых в этом состоянии. В терминологии CORBA, DCS име-

ет того же слугу, что и исходная копия объекта. Перехватчик, стоящий за DCS,

перехватывает входящие обращения и выделяет из них определенную инфор-

мацию, например, добавленную перехватчиком клиента. Запрос после этого пе-

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

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

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

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

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

дельно.

Кэшированный

объект

Кэшированный

объект

Кэшированный

объект

Кэшированный

объект

CASCADE RTS

ORB сервера

Перехватчики

Локальная ОС

Обращение

Объект

Управление

обращениями

к методам

Объект

правил

Обращение

Рис. 9.12. Упрощенная организация DCS

Хотя CASCADE и позволяет более или менее прозрачно кэшировать серверы

объектов, однако похоже, что для реализации службы кэширования в CORBA

необходимы дополнительные усилия. Хотя при необходимости изменять обра-

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

кой другой поддержки кэширования CORBA не предоставляет.

9.1.C0RBA 567

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

Системы CORBA длительное время почти не имели средств поддержания отка-

зоустойчивости. В большинстве случаев о факте ошибки просто сообщалось кли-

енту, никаких других действий система не предпринимала. Так, например, при

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

(временной) клиент просто ждал. В CORBA версии 3 отказоустойчивостью за-

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

[328].

Группы объектов

Базовый подход к обработке ошибок в CORBA состоит в репликации объектов и

создании из них групп

объектов {object

groups).

Такая группа содержит одну или

несколько абсолютно идентичных копий одного и того же объекта. Адресация

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

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

ликация прозрачна. Поддерживаются различные стратегии репликации, включая

репликацию на основе первичной копии, активную репликацию и репликацию на

основе кворума. Все эти стратегии мы обсуждали в главе 6. Существуют также

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

ти в

[328].

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

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

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

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

использовании особого типа ссылки IOR, именуемой

межоперационпой ссылкой

на группу

объектов {Interoperable Object Group

Reference,

IOGR). Основное ее от-

личие от обычной ссылки IOR состоит в том, что каждая ссылка IOGR содержит

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

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

жать несколько ссылок, но все они будут относиться к

одному

и тому

же

объек-

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

Когда клиент передает своему брокеру ORB ссылку IOGR, этот брокер пыта-

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

ПОР брокер ORB может использовать дополнительную информацию, обнару-

женную в одном из профилей ПОР в ссылке IOGR. Эта информация, как мы

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

рис.

9.13, конкретный профиль ПОР может ссылаться на первичный экземпляр

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

TAG^BACKUP

соответственно.

Если привязка к одной из реплик невозможна, ORB клиента может продол-

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

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

ента процесс привязки абсолютно прозрачен, для него это выглядит так, как

будто он связывается с обыкновенным объектом CORBA.

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

Межоперационная ссылка на группу объектов (lOGR)

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

хранилища профиля

Профиль-1

профиля

Профиль-N

Версия|

ПОР

Хост-1 Порт-1

Ключ

объекта-1

Компоненты

Версия

ПОР

XocT-N Порт-N

Ключ

объекта-N

Компоненты

TAG

PRIMARY

Другая информация

группы

TAG

BACKUP

Другая информация

группы

Рис. 9.13. Возможная организация IOGR для группы объектов с первичным экземпляром

и резервными копиями

Пример архитектуры

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

ку отказов, к CORBA необходимо добавить определенные компоненты. Одна из

возможных архитектур отказоустойчивой версии CORBA приведена на

рис.

9.14.

Эта архитектура была применена в системе Eternal [305, 310], которая имеет от-

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

повых коммуникаций Totem

[304].

Менеджер

репликации

Протоколирование

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

Менеджер

групп

объектов

Менеджер

свойств

группы

Объект

ORB

Перехватчик

Репликация

Надежная групповая

рассылка

Клиент или сервер

объектов

К другим репликам

•

Рис. 9.14. Пример архитектуры отказоустойчивой системы CORBA

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

менеджер репликации (replication

manager),

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

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

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

лицировать.

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

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

9.1.

CORBA 569

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

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

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

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

чением по умолчанию. Менеджер репликации, кроме того, отвечает за замену

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

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

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

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

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

вость групп объектов и гарантирует протоколирование сообщений на случай,

если потребуется восстановление системы.

Обращения затем рассылаются остальным членам группы с использованием

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

репликации запрос передается каждой из реплик объекта для обработки его каж-

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

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

серверы просто протоколируют этот запрос на случай, если потребуется восста-

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

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

9.1.8. Защита

Защита в CORBA имеет долгую историю. Исходные версии спецификаций CORBA

вряд ли стоит принимать во внимание, по той простой причине, что отдельные

попытки описать службу защиты провалились. В CORBA версии 2.4 описание

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

системы CORBA вносится защита. Рассмотрим защиту системы CORBA побли-

же.

Обзор по этой теме, написанный одним из авторов исходной спецификации

защиты CORBA, можно найти в [66].

Важный момент спецификации защиты CORBA состоит в том, что службы

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

пользоваться для реализации разного рода правил защиты. Положение осложня-

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

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

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

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

эти механизмы (на уровне приложения, внутри ORB или в ходе передачи сооб-

щения).

Ядро защиты в CORBA формируется путем поддержания защищенных обра-

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

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

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

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

ние.

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

ращение. Подобный подход ведет к ситуации, представленной на рис. 9.15.

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

Набор объектов

правил для объекта

Набор объектов--^

правил для клиента

Набор

соответствующих

служб

защиты ORB

Реализация объекта

(Объект)!

правил

[Объект]

правил]

Служба

защиты

Служба

защиты

ORB сервера

Локальная ОС

Обращение

Рис. 9.15. Обобщенная организация защищенного обращения

объекту в CORBA

Когда клиент выполняет привязку

объекту, чтобы потом иметь возможность

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

со

стороны

клиента понадобятся

для

защищенного обращения. Выбор служб определяется

правилами защиты, ассоциированными

административным доменом,

котором

выполняется клиент,

особо

—

правилами данного клиента.

Правила защиты задаются

объектами

правил {policy

objects)^

ассоциирован-

ными

клиентом. На практике домен,

котором исполняется клиент, открывает

свои правила защиты

для ORB

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

объектов правил. С клиентом автоматически ассоциируются правила по умолча-

нию.

Примерами объектов правил могут быть

те

объекты, которые определяют

тип применяемой защиты сообщений

или

хранят списки доверенных сторон.

Другие примеры

детали можно найти

[66].

Схожая структура поддерживается

и на

стороне сервера. Точно так же адми-

нистративный домен,

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

определенный набор служб защиты. Точно

так же

вызванный объект имеет до-

полнительно собственный набор объектов правил,

которых хранится специфи-

ческая для данного объекта информация.

Для поддержания защиты

CORBA могут применяться различные подходы.

В частности, чтобы сделать брокер

ORB по

возможности более общим, жела-

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

которые скроют реализацию этих служб. Службы, которые можно определить

подобным образом,

CORBA именуются

взаимозаменяемыми

(replaceable).

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

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

Перехватчик

контро-

ля доступа

(access control interceptor) —

это

перехватчик уровня запросов, кото-

рый проверяет права доступа, связанные

обращением. Кроме него имеется

перехватчик защищенных

обращений

(secure

invocation interceptor)

уровня сооб-

щений, отвечающий

за

реализацию защиты сообщений. Другими словами, этот

перехватчик занимается шифрованием запросов

ответов, поддерживая

их це-

лостность

конфиденциальность.