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

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

9.2.

DCOM 581

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

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

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

рено.

MSMQ, как и большинство систем очередей сообщений (например, MQSe-

ries),

поддерживает транзащионные

очереди {transactional

queues).

В своей про-

стейшей форме транзакционная очередь состоит из коллекции сообщений, кото-

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

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

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

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

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

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

наторы, о которых мы говорили в главе 7.

9.2.3. Процессы

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

сложной. Однако углубившись в детали, мы обнаружим, что некоторые вещи не

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

DCOM.

Клиенты

Поддержка клиента в модели DCOM

—

это ее естественное предназначение. Для

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

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

зываются точно так же, как это делалось до появления DCOM, когда существова-

ла только модель СОМ.

Однако имеются некоторые моменты, требующие особого внимания. Один из

наиболее важных вопросов подобного рода

—

обработка ссылки на объект. На-

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

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

терфейса. Если сам объект располагается на удаленной машине, интерфейс на

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

обращения и пересылает запросы объекту.

Как процесс А может передать ссылку на объект другому процессу, скажем В?

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

цессу В нужен, в сущности, указатель на реализацию того же интерфейса, ко-

торый имеется у процесса А. Этот интерфейс имеет уникальный идентифика-

тор

—

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

деле необходимо передать HD этого интерфейса. Кроме того, процесс А может

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

ле.

Предполагая, что процесс В имеет локальную реализацию заместителя для

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

циировать вызов нужного метода.

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

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

маршалингу за-

просов на обращение. Такие заместители автоматически генерируются по специ-

фикации MIDL

или

могут быть созданы

по

информации, содержащейся

биб-

лиотеках типов. Однако бывают случаи, когда стандартный маршалинг —

не

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

мость кэширования

на

заместителе результатов предшествующих обращений.

Включение функции кэширования

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

разработчиком вручную.

Кроме стандартного маршалинга DCOM поддерживает пользовательский мар-

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

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

том, как организовать

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

маршалинге решение состоит

том, что весь код маршалинга содержит сторона,

выполняющая маршалинг, поэтому передача

IID

интерфейса требует лишь

за-

грузки этого кода

построения заместителя интерфейса.

По существу, передача ссылки

на

объект

случае пользовательского марша-

линга происходит путем маршалинга заместителя, принадлежащего отправителю,

передачи этого заместителя получателю

последующего демаршалинга полу-

ченного заместителя из сообщения. То есть заместитель отправителя

конечном

итоге оказывается

получателя. Отметим, что подобный подход очень похож

на

передачу ссылок

на

объекты

Java,

которой мы говорили

главе 2. Поскольку

маршалинг выполняется способом, специфичным

для

данного объекта, необхо-

димо,

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

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

маршалинга

(то

есть после своего рода упаковки). Предполагается, что этот код

доступен получателю

идентифицируется по его идентификатору CLSID. Пере-

дачу ссылки

на

объект

DCOM иллюстрирует рис. 9.21.

Процесс А

Клиентское приложение

Заместитель

клиента

Маршалинг/

Демаршалинг

заместителя

Передача

заместителя

клиента после

маршалинга

Процесс

Клиентское приложение

Маршалинг/

Демаршалинг

заместителя

Заместитель

клиента

Информация привязки

\ /

Заглушка

объекта

(

Объект

Та же самая

информация привязки

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

Рис. 9.21. Передача ссылки на объект

DCOM при пользовательском маршалинге

9.2.

DCOM 583

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

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

мим заместителем. В последнем случае маршалинг обращений к методам, содер-

жащимся в интерфейсе, выполняет заместитель. То есть заместитель отвечает за

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

но,

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

ния (демаршалинг). Маршалинг заместителя производится стандартным обра-

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

Серверы DCOM

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

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

переносимый адаптер объектов, жестко закодированы в каждом объекте DCOM.

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

мещенных на удаленном хосте.

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

минавшийся ранее

менеджер управле71ия службами (Service Control

Manager,

SCM).

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

разом. Предположим, что клиент владеет CLSID объекта класса. Чтобы создать

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

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

объектов. Затем CLSID передается менеджеру SCM, ассоциированному с най-

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

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

тор CLSID уже в своем локальном реестре.

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

объекта класса, после чего создает экземпляр объекта. В SCM регистрируется

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

просы, а также идентификатор нового объекта. Эта информация привязки воз-

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

екта напрямую, без вмешательства SCM.

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

объектами на сервере, разработчику. Чтобы немного облегчить ему жизнь, DCOM

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

звание активизации «на лету»' {«just-in-time» activation), или JIT-активизации

(JIT-activation). Под этим названием скрывается механизм, при помощи которо-

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

дующим образом.

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

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

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

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

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

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

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

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

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

объекта. Разумеется, такой подход допустим только при работе с объектами без

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

не хранят никакой информации о своем внутреннем состоянии. Все, что остается

для работы с таким объектом,

—

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

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

ориентированного программирования. Если же предполагается сохранять ин-

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

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

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

Модель DCOM сама по себе предоставляет объектам лишь относительно низко-

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

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

фейсы. Указатель на интерфейс имеет смысл только в тех процессах, в которых

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

добавление к

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

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

ссылки, известные под названием

моникеров

{monikers),

мы и обсудим. DCOM не

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

ной системы Windows 2000, объекты DCOM могут пользоваться службой Active

Directory Windows, которая является настоящей службой каталогов. Здесь мы

также рассмотрим и эту службу.

Моникеры

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

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

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

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

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

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

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

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

DCOM предоставляет различные варианты моникеров. Наиболее важным из

них является

файловый моникер

{file

moniker),

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

мый из файла локальной файловой системы. В этом случае моникер должен со-

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

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

екта этого класса.

Как и все моникеры, файловый моникер поддерживает операцию BlndToObject,

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

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

9.2. DCOM 585

Таблица 9.5. Привязка к объекту DCOM при помощи файлового моникера

Шаг Исполнитель Описание

1 Клиент Вызов метода

В1

ndToOb j ect моникера

2 Моникер Поиск соответствующего идентификатора CLSID и указание SCM

создать объект

3 SCM Загрузка объекта класса

4 Объект класса Создание объекта и возвращение моникеру указателя

на интерфейс

5 Моникер Указание объекту загрузить ранее сохраненное состояние

6 Объект Загрузка из файла своего состояния

7 Моникер Возвращение клиенту указателя на интерфейс объекта

Первое, что следует понимать, моникер

—

это сохранный объект, то есть объ-

ект длительного хранения. В терминологии DCOM это означает, что любой мо-

никер содержит методы для сохранения своего содержимого на диске. Во многих

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

виде части файла. Позже, прочитав этот файл, можно будет воссоздать по дан-

ным моникера настоящий объект. В этот момент клиент получит в свое распоря-

жение интерфейс IMoniker, содержащий операцию BindToObject.

Предположим, что клиент только что прочитал с диска файловый моникер и

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

рый является моникер. При обращении к методу BindToObject этого моникера его

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

ном реестре. Этот объект класса идентифицируется по идентификатору CLSID,

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

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

ся в локальном реестре клиента. После того как он найден, CLSID передается со-

ответствующему менеджеру SCM, который отвечает за создание объекта этого

класса.

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

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

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

операцию загрузки файла. Другими словами, сам объект знает, как восстановить

свое предшествующее состояние при помощи загружаемых из файла данных.

Отметим, что этот файл не имеет никакого отношения к файлу, в котором хра-

нится сам моникер.

И, наконец, клиенту возвращается указатель на изначально запрошенный им

интерфейс, что и завершает операцию привязки.

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

с ним объект в таблице

запущегшых объектов

(Running Object

Table,

ROT) кли-

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

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

ROT. Если он обнаруживает, что объект класса уже создан, он выполняет при-

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

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

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

шине.

Кроме файловых моникеров DCOM поддерживает несколько других типов

моникеров, некоторые из них представлены в табл. 9.6. Кроме этих заранее опре-

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

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

ти в

[132].

Таблица 9.6. Типы моникеров, определенные в DCOM

Тип моникера Описание

Файловый моникер Ссылка на объект, создаваемый из файла

Моникер URL Ссылка на объект, создаваемый из URL

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

Композитный моникер Ссылка на композицию моникеров

Моникер элемента Ссылка на моникер, входящий в композицию

Моникер указателя Ссылка на объект удаленного процесса

Active Directory

С появлением Windows 2000 приложения DCOM получили возможность ис-

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

ем Active

Directory.

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

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

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

тающих под UNIX.

этом смысле службу каталогов можно сравнить с «желтыми

страницами». В противоположность ей служба именования, способная выдать

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

книгой.

До появления Active Directory в различных компонентах DCOM и Windows

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

лиотеки типов, моникеры и т. д. Хотя служба Active Directory на самом деле не

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

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

По организации служба Active Directory в значительной степени соответству-

ет распределенной системе на базе Windows 2000. Как предполагается, такая

система разделена на

домены

{domains),

каждый из которых содержит некоторое

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

несколько

контроллеров домена {domain

controllers),

которые представляют собой

локальные серверы каталогов, контролирующие пользователей и ресурсы этого

домена. Домен имеет соответствующее имя DNS, например cs.vu.nl.

Контроллеры домена представляют собой серверы каталогов LDAP. Как мы

уже говорили в главе 4, протокол LDAP представляет собой Интернет-версию

протокола доступа к каталогам Х.500. В случае Active Directory каждый кон-

троллер домена содержит заранее определенную схему организации сущностей

9.2.

DCOM

587

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

ции пользователей, хостов, принтеров и т. п. При необходимости эта схема мо-

жет быть расширена.

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

ванием записей типа

SRV

системы DNS, описанных в главе 4. Так, сервер LDAP

домена cs.vu.nl может быть зарегистрирован при помощи записи

SRV

под именем

ldap.tcp.cs.vu.nl. Это имя может, в свою очередь, ссылаться на имя DNS хоста со-

ответствующего контроллера домена.

Теперь понятно, что найти в заданном домене контроллер домена очень лег-

ко.

Клиент должен просто запросить у DNS имя хоста сервера LDAP в этом до-

мене, после чего он сможет связаться с этим сервером и получить информацию о

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

Эта схема в общем виде приведена на рис. 9.22.

Запрос адреса

хоста

у контроллера

данного

домена

DNS

Клиент

Запрошенный

адрес

Запрос LDAP ^

•

Ответ LDAP

Контроллер

домена

Рис.

9.22. Обобщенная

организация

Active Directory

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

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

пример, если клиент хочет найти все web-серверы, работающие под UNIX, он

должен сначала связаться с контроллером некоего конкретного домена и ЛР1ШЬ

после этого посылать ему поисковый запрос. Если поиск распространяется на

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

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

Чтобы помочь справиться с этой проблемой. Active Directory позволяет груп-

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

Дерево доменов {domain

tree) представляет со-

бой поддерево пространства имен DNS, а лес

доменов {domain

forest)

—

это про-

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

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

индекс, именуемый

глобальным каталогом {global

catalog).

Записи каждого доме-

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

{атрибут,

значение) копируются

в каталог. Клиенту теперь значительно проще сделать поисковый запрос в ката-

лог группы доменов.

Дополнительную информацию о Active Directory, управлении этой системой,

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

[273].

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

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

Базовый механизм синхронизации

DCOM реализован

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

Этот механизм

мы

рассмотрим чуть позже

при

обсуждении вопросов отказо-

устойчивости

DCOM.

9.2.6. Репликация

Стандартной поддержки репликации в приложениях DCOM не существует. Реп-

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

как Active Directory. Что касается пользовательских приложений, разработчику

придется разрабатывать собственные решения.

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

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

DCOM обеспечивается при помощи автома-

тических транзакций {automatic

transactions),

которые представляют собой

не-

отъемлемую часть СОМ+. Автоматические транзакции позволяют разработчику

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

тов,

которые нужно объединить

транзакцию. Также можно представить

виде

транзакции

одиночное обращение

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

том

случае, когда реализация метода предполагает работу

базой данных.

Транзакции

объектной среде создаются автоматически,

зависимости

от

того,

как

сконфигурирован соответствующий объект класса. Каждый объект

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

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

табл. 9.7.

Таблица 9.7. Значения атрибута транзакции объектов DCOM

Значение Описание

REQUIRED_NEW

При

каждом обращении всегда начинается новая транзакция

REQUIRED Новая транзакция начинается, если она еще

не

начата

SUPPORTED Включается

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

ее

NOT_SUPPORTED Никогда

не

включается

транзакции

DISABLED Никогда

не

включается

транзакции, даже если клиент пытается

это сделать

Если атрибут транзакции имеет значение REQUIRES_NEW,

то

всякий раз при об-

ращении

объекту

он

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

независимую от всех прочих. Более того, если вызвавшая сторона уже участвует

в транзакции, объект, требующий новой транзакции, начинает другую транзак-

цию параллельно

существующей.

Если атрибут транзакции имеет значение REQUIRED, наблюдается другая

си-

туация.

этом случае объект пррп1имает участие

транзакции вызвавшей

его

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

9.2.

DCOM

589

закцию. В любом случае обращение

нему всегда осуществляется

как

часть тран-

закции.

Если транзакции лишь поддерживаются (SUPPORTED), объект никогда

не

начи-

нает новой транзакции,

лишь включается

транзакцию вызвавшей

его

сторо-

ны.

Если вызвавший объект

или

клиент

не

участвует

транзакции!, обращение

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

Если транзакции

не

поддерживаются, обращение

объекту может происхо-

дить

вне

всяких транзакций,

которых могла

бы

принимать участие вызываю-

щая сторона. Другими словами,

этом случае

нет

никаких гарантий сохранения

атомарности. Значение атрибута транзакции объекта класса

этом случае уста-

навливается равно NOT_SUPPORTED.

И, наконец, если объект показывает,

что

поддержка транзакций отключена

(DISABLED),

то вне

зависимости

от

пожеланий клиента объект

не

будет участво-

вать

транзакциях. Отключение транзакций

~ это

более жесткий вариант,

чем

просто отсутствие поддержки.

последнем случае клиент,

от

которого исходит

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

транзакцию объект,

которому

это

обращение направлено. Если поддержка транзакций отключена, это невозможно.

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

при

помо-

щи отдельного менеджера транзакций.

Во

многих случаях используется менед-

жер транзакций Windows, известный

как

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

транзак-

ций {Distributed

Transaction

Coordinator,

DTC)

корпорации Microsoft.

DTC

—

это

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

фазного подтверждения, описанный

главе

9.2.8. Защита

Как

и в

CORBA, система защиты DCOM

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

щений

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

аб-

солютно иной. Хотя DCOM чаще всего входит

одну

из

операционных систем

семейства Windows, разработчики DCOM совершенно оправданно решили

по

возможности отделить защиту DCOM

от

служб защиты Windows. Таким обра-

зом

они

сохранили возможность реализации DCOM

на

других операционных

системах

сохранением защиты обращений.

В DCOM существует два направления реализации защиты. Важная роль

в за-

щите DCOM отводится реестру,

при

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

ративная защита. Кроме того, защита может быть реализована

программным

путем,

в том

смысле,

что

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

до-

ступа

аутентификации. Далее

мы

рассмотрим

оба

подхода.

Декларативная защита

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

что в

реестре описываются

потребности компонента

(то

есть объекта)

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

па и аутентификации. Модель защиты DCOM основана

на

механизме ролей.

Как

случае мандатов,

для

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

о них

присутствовали

реестре.

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

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

каждого зарегистрированного класса записи в реестре определяют, какие пользо-

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

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

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

групп.

DCOM поддерживает несколько уровней аутентификации

{authentication

le-

vels),

представленных в табл. 9.8. По умолчанию большинство систем считают

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

сервером (уровень

CONNECT).

Однако можно также требовать идентификации при

каждом обращении к серверу (CALL) или даже при каждом получении данных от

клиента (PACKET). Уровни PACKET_INTEGRITY и PACKET_PRIVACY - это уже не просто

уровни аутентификации, а скорее добавление к уровню

PACKET

проверки целост-

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

Таблица 9.8. Уровни аутентификации в DCOM

Уровень Определение

NONE

Аутентификация не требуется

CONNECT

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

сервером

CALL Аутентификация клиента при каждом обращении

PACKET Аутентификация всех пакетов данных

РАСКЕТ_1

NTEGRITY Аутентификация пакетов данных

проверка

их

целостности

PACKET_PRIVACY Аутентификация пакетов данных, проверка

их

целостности

и шифрование пакетов данных

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

лить,

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

та, обращающегося к объекту (табл. 9.9). Для этого используются так называе-

мые уровни обезличивания (impersonation levels). Если уровень обезличивания

имеет значение

ANONYMOUS,

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

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

Таблица 9.9. Уровни обезличивания в DCOM

Уровень Описание

ANONYMOUS

Клиент абсолютно анонимен

IDENTIFY Сервер знает клиента

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

IMPERSONATE Сервер может

по

поручению клиента обращаться

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

DELEGATE Сервер может

по

поручению клиента обращаться

удаленным объектам

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

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

Этот уровень позволяет серверу идентифицировать клиента, однако эта иденти-

фикация может использоваться только на этом сервере и только для проверки

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