В данном разделе рассматриваются системные сервисы Е1, расширяющие модель распределенных объектов до полноценной компонентной модели. К ним относятся Реестр Объектов, Сервер Контроля Доступа, Сервер Глобального Именования, а также система сборки мусора.

Центральным сервисом компонентной модели Е1 является Реестр Объектов. Реестр хранит информацию о всех репликах распределенных объектов, существующих в локальном узле, в том числе, адреса объектов и их интерфейсов, размещение объектов в доменах, информацию о ссылках между объектами. Реестр играет координирующую роль при выполнении таких операций как создание и удаление распределенных объектов и их реплик, междоменные вызовы, сборка мусора.

Рассмотрим каждую из указанных функций Реестра Объектов подробнее

Создание и удаление объектов

Распределенные объекты в Е1 создаются при помощи метода CreateObject Реестра. Аргументами метода являются идентификатор класса и домен, в котором должен быть создан объект. Кроме того, может указываться стратегия репликации, которая будет для него применяться. Метод CreateObject выполняет следующую последовательность действий:

1. Если в целевом домене отсутствует требуемый объект класса, Реестр обращается к Репозиторию Классов, который загружает данный объект класса в домен.
2. Реестр вызывает объект класса для создания объекта семантики. Поскольку на данный момент новый распределенный объект представлен только в одном узле, то объект репликации для него не нужен.
3. Информация об объекте сохраняется в структурах данных Реестра. В частности, объект, вызвавший метод CreateObject, регистрируется как владелец единственной сильной ссылки на новый объект.
4. Объект регистрируется в сервисе глобального именования.
5. Метод CreateObject возвращает указатель на один из интерфейсов нового распределенного объекта.

Как правило, распределенный объект удаляется, когда все его реплики обращаются в мусор. Кроме того, Реестр предоставляет метод DeleteObject для принудительного удаления объектов.

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

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

1. Обращается к сервису глобального именования за информацией об указанном объекте: класс, контактные точки, используемая стратегия репликации.
2. При необходимости, обращается к Репозиторию Классов для загрузки классов объекта семантики и объекта репликации в целевой домен.
3. Вызывает объекты классов для создания объекта семантики и связанного с ним объекта репликации.
4. Инициализирует объект репликации списком контактных точек, на основании которого будет запущен распределенный алгоритм вхождения новой реплики в состав распределенного объекта. Этот алгоритм является частью стратегии репликации.

Контроль междоменных вызовов

В системе междоменного взаимодействия Реестр Объектов отвечает за проверку корректности и правомерности вызовов. При выполнении междоменного вызова микроядро обращается к Реестру для того чтобы убедиться, что в локальном узле существует реплика вызываемого объекта и вызов является правомерным, т.е. вызывающий объект имеет право обращаться к указанному интерфейсу данного объекта. Кроме того, Реестр сообщает ядру, в каком домене находится вызываемый объект. Для взаимодействия с микроядром Реестр Объектов предоставляет интерфейс IAccessValidator (см. рисунок).

Реестр не реализует самостоятельно политику контроля доступа. Вместо этого, для прорверки правомерности вызова Реестр обращается к другому системному объекту - Серверу Контроля Доступа, который обсуждается далее.

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

Взаимодействие микроядра и Реестра Объектов при выполнении междоменного вызова. Пунктиром показан нормальный и оптимизированный (красным) путь выполнения междоменного вызова.

Еще одна важная функция Реестра Объектов - управление ссылками и сборка мусора - будет рассмотрена ниже.

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

Выбор конкретной модели контроля доступа на этапе проектирования ОС - сложная задача. Ни одна из существующих на сегодняшний день моделей защиты не является универсальной и не может в общем случае считаться оптимальной. Поэтому архитектура Е1 не определяет конкретную политику контроля доступа, которую должен имплементировать СКД. Никакие ограничения не накладываются и на стратегию репликации СКД, а также на структуры данных, используемые для описания прав. Вместо этого, СКД должен реализовывать интерфейс IAccessControl, посредством которого Реестр Объектов проверяет правомерность междоменных вызовов. Главный метод ValidateAccess данного интерфейса разрешает или запрещает выполнение вызова на основании идентификатора потока, производящего вызов, объекта, в контексте которого инициируется вызов, а также, вызываемого объекта и метода.

СКД может также предоставлять дополнительные интерфейсы, которые определяются конкретной моделью контроля доступа и реализуют специфичный для нее протокол распространения прав. Так, например, для реализации модели полномочий Take/Grant [7,8], СКД может предоставлять интерфейс, содержащий методы Take, Grant и Revoke, а для эмуляции модели защиты UNIX необходимы методы Chmod и Chown.

Глобальное выполнение правил ограничения доступа в рамках распределенной системы обеспечивается репликацией Сервера Контроля Доступа. Так, например, при отзыве некоторого полномочия, стратегия репликации СКД доставляет соответствующую нотифицикацию всем узлам, в которых хранится устаревшая информация. Накладные расходы, связанные с репликацией СКД, - один из важных факторов, которые необходимо принимать во внимание при выборе модели ограничения доступа.

Описанная архитектура СКД позволяет имплементировать разнообразные модели защиты, в том числе, различные модели полномочий (capabilities) [56, 20, 24, 7] и списков контроля доступа (ACL) [42]. При этом, как объект, так и субъект защиты могут выбираться различным образом. Например, в роли объекта может выступать распределенный объект, интерфейс или метод, а в роли субъекта - распределенный объект, домен или пользователь. Обратим внимание на последнюю возможность. До сих пор абстракция пользователя в Е1 не вводилась. Тем не менее, модели, в которых права принадлежат пользователям или ролям имеют широкое применение [44, 42]. В такой модели каждый поток выполняется от имени и с полномочиями некоторого пользователя. Следовательно, хотя понятие пользователя не является основным для Е1, существует возможность реализовать данную абстракцию на уровне Сервера Контроля Доступа, отождествляя пользователей с группами потоков.

Сервер Глобального Именования (СГИ) Е1 реализует протокол локализации объектов, позволяющий по виртуальному 64-битному адресу объекта получить список его контактных точек, т.е. узлов сети, в которых находятся реплики данного объекта, а также класс объекта и используемую стратегию репликации. Реестр Объектов обращается к СГИ для того чтобы инициировать создание новой реплики распределенного объекта.

Конкретный протокол локализации объектов должен выбираться, исходя из масштаба распределенной системы и частоты удаления и добавления узлов. Для небольших систем может использоваться централизованный протокол с одним или несколькими серверами имен. Для крупномасштабных систем с постоянной структурой, как правило, используется иерархическая система доменных серверов [34], а для динамически изменяющихся систем наиболее эффективны децентрализованные протоколы именования[51].

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

В большинстве ОС нет необходимости выделять сборку мусора в отдельную подсистему. Вместо этого, каждый компонент операционной системы использует собственный механизм учета ресурсов, основанный, как правило, на простом подсчете ссылок. Такой механизм легко реализуется и не влечет значительных накладных расходов. Однако, в распределенной ОС ненадежность узлов и сетевых соединений, а также асинхронный характер взаимодействия существенно усложняют задачу управления ссылками [38]. Кроме того, в Е1 каждый объект может иметь несколько реплик в различных узлах, что также затрудняет определение момента, когда объект превращается в мусор. Для организации сборки мусора в такой системе необходимы достаточно сложные распределенные структуры данных и алгоритмы. Разрабатывать их отдельно для каждой подсистемы ОС нецелесообразно, поэтому Е1 реализует единый механизм для всех объектов.

Механизм сборки мусора Е1 основан на построении и анализе графа ссылок между репликами распределенных объектов. Две разновидности ссылок соответствуют двум видам взаимодействия объектов: локальное взаимодейтствие между репликами распределенных объектов, находящимися в одном узле, и удаленное взаимодействие между репликами одного распределенного объекта в рамках стратегии репликации. Соответственно, выделяются локальные ссылки между различными распределенными объектами и удаленные ссылки между репликами одного объекта. В обоих случаях, как владельцем, так и объектом ссылки является реплика распределенного объекта.

Будем также разделять сильные и слабые ссылки. Слабая ссылка - это адрес интерфейса объекта или RPC-указатель на удаленную реплику, посредством которых можно выполнять, соответственно, локальные или удаленные вызовы. Слабые ссылки не отслеживаются системой сборки мусора и не учитываются при обнаружении неиспользуемых объектов. Для того чтобы превратить слабую ссылку в сильную, необходимо выполнить над ней операцию создания сильной ссылки AddRef. Заметим, что в Е1 AddRef - это метод системы сборки мусора, а не объекта, на который создается ссылка, в отличие, например, от COM. В результате, в системе сборки мусора будет зарегистрирована новая сильная ссылка. Если в данном узле реплика объекта, на который указывает ссылка, еще не существует, то, как было описано выше, она будет создана Реестром Объектов. Система сборки мусора ассоциирует с каждой ссылкой счетчик, значение которого инкрементируется и декрементируется, соответственно, операциями AddRef и Release. Когда значение счетчика становится равным нулю, сильная ссылка уничтожается. После уничтожения последней сильной ссылки на реплику распределенного объекта, она обращается в мусор и автоматически удаляется.

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

В управлении ссылками участвует Реестр Объектов, а также расположенные в каждом домене локальные Мониторы Ссылок. Реестр хранит основную часть информации о ссылках и обрабатывает такие события как создание первой и уничтожение последней сильной ссылки на реплику распределенного объекта. Кроме того, при создании и удалении распределенных ссылок, Реестры в различных узлах взаимодействуют для внесения соответствующих изменений в свои структуры данных. Мониторы Ссылок осуществляют подсчет ссылок внутри доменов, что позволяет минимизировать количество обращений к Реестру, связанных с управлением ссылками. Монитор предоставляет интерфейс IRefMonitor, содержащий методы AddRef и Release. Таким образом, прикладные объекты взаимодействуют с Монитором Ссылок, который, при необходимости, вызывает методы управления ссылками Реестра.

Для сборки циклического мусора, в том числе, распределенного, в Е1 используется частичная трассировка графа ссылок. Данная процедура проверяет достижимость некоторой реплики из Корневого Набора Объектов (КНО)[58]. К корневому набору относятся основные системные объекты Е1, не являющиеся мусором по определению. Мусором также не являются все объекты, достижимые из КНО. Все остальные объекты считаются мусором. Для выполнения частичной трассировки при помощи некоторой эвристической процедуры выбирается ”подозрительная” реплика, которая становится исходной точкой обхода графа. В результате либо будет доказана достижимость исходной реплики из корневого набора, либо будет обнаружен набор реплик, образующих цикл мусора.

На рисунке изображен фрагмент графа ссылок. Cильные ссылки показаны cплошными стрелками, а слабые - пунктирными. Для распределенного объекта А используется стратегия репликации клиент-сервер с одним основным и одним вторичным сервером. Клиентская реплика А₂ владеет сильной ссылкой на серверную реплику А₄, которая хранит состояние объекта и выполняет операции над ним. В свою очередь, А₄ владеет сильной ссылкой на вторичный сервер А₁, хранящий резервную копию объекта. Реплика А₂ взаимодействует с А₄ для выполнения операций над объектом. А₄ взаимодейстует с вторичным сервером А₁ для своевременного обновления резервной копии.

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

Фрагмент графа ссылок.

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