9.3. Globe

Последний пример распределенной системы объектов, который мы рассмот­рим, — это система Globe. Globe (GLobal Object-Based Environment — глобальная объектная среда) — это экспериментальная распределенная система, разработан­ная авторами и их коллегами в университете Vrije (Амстердам). Основная цель разработки системы, которая отличает Globe от CORBA и DCOM, — предостав­ление возможности поддерживать очень большое число пользователей и объек­тов, разбросанных по всему Интернету, при сохранении полной прозрачности распределения. Большинство других распределенных систем объектов, как из­вестно, создавались в первую очередь для работы в локальных сетях.

Обзор системы можно найти в [471]; детальное описание архитектуры имеет­ся в [202].

9.3.1. Обзор

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

Важное отличие Globe от других систем объектов, особенно от других масш­табируемых систем, таких как Legion [181, 182] состоит в том, что объекты могут также инкапсулировать реализацию правил распределения состояния объектов по нескольким машинам. Другими словами, каждый объект определяет, каким образом его состояние можно рассредоточить по репликам. Каждый объект управ­ляет также и другими своими правилами.

Вообще говоря, объекты в Globe отвечают за все, что только можно. Так, на­пример, объект определяет, как, когда и куда может переместиться его состоя­ние. Кроме того, объект решает, следует ли делать реплики его состояния и, если да, как именно должна происходить репликация. Объект может также опре­делять свои правила защиты и реализацию. Ниже мы опишем, каким образом достигается такая инкапсуляция.

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

В отличие от большинства других распределенных систем объектов, Globe не поддерживает модель удаленных объектов. Объекты в Globe обладают способно­стью храниться в физически раздробленном состоянии, то есть состояние объек­тов может быть распределено и реплицировано между несколькими процессами.

Эту организацию иллюстрирует рис. 9.23, на котором показан объект, распреде­ленный между четырьмя процессами, каждый из которых выполняется на от­дельной машине. Объекты в Globe являются распределенными разделяемыми объ­ектами (distributed shared objects). Это название отражает тот факт, что объекты обычно используются несколькими процессами одновременно. Объектная мо­дель Globe восходит своими корнями к распределенным объектам Огса, описан­ным в [27]. Схожая объектная модель используется также в операционной систе­ме SOS [282, 409].

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

Всякий локальный объект реализует стандартный интерфейс SOInf объекта, подобный интерфейсу IUnknown в DCOM. В частности, подобно Querylnterface в DCOM, SOInf имеет метод getlnf, который получает в качестве исходных дан­ных идентификатор интерфейса и возвращает указатель на этот интерфейс, позволяя другим процессам получить доступ к его реализации в объекте. Име­ются и другие примеры сходства между локальными объектами Globe и объекта­ми DCOM. Так, например, предполагается, что каждый локальный объект имеет соответствующий объект класса, который может создавать новые локальные объекты.

Локальные объекты реализуют бинарные интерфейсы, которые состоят в ос­новном из таблиц указателей на функции. Интерфейсы описываются на языке определения интерфейсов, который в основном похож на аналогичные языки, используемые в CORBA и DCOM, но имеет некоторые частные отличия.

Существует две разновидности локальных объектов Globe. Примитивный локальный объект (primitive local object) — это локальный объект, который не содержит других локальных объектов. В противоположность ему, составной локальный объект (composite local object) — это объект, составленный из несколь­ких (возможно также составных) локальных объектов. Для поддержания состав­ных объектов таблица интерфейсов локальных объектов Globe состоит из пар указателей (состояние, метод). Каждый указатель на состояние соответствует данным, принадлежащим одному конкретному локальному объекту. В случае интерфейса примитивного локального объекта все указатели на состояние опре­деляют одни и те же данные, относящиеся к состоянию самого объекта. В случае составных объектов указатели на состояние определяют состояния разных объ­ектов, входящих в этот составной объект.

Составные объекты используются для построения локальных объектов, необ­ходимых для реализации распределенных разделяемых объектов. Подобный ло­кальный объект содержит как минимум четыре подобъекта (рис. 9.24).

Подобъект семантики (semantics subobject) реализует функциональность рас­пределенного разделяемого объекта. Так, например, с помощью Globe были раз­работаны распределенные web-сайты, в которых коллекция логически связанных web-страниц, значков, изображений и т. п. была объединена в один документ. Та­кой документ, называемый GlobeDoc [472], реализуется локально при помощи подобъекта семантики, предоставляющего интерфейсы, перечисленные в табл. 9.12. Каждый файл, используемый как часть web-документа, считается элементом объекта GlobeDoc. При помощи интерфейса документа можно добавлять или удалять подобные элементы. Этот интерфейс содержит также метод, возвращаю­щий список всех элементов. Предполагается, что web-документы организованы в виде графа с корнем. При помощи отдельных методов можно определить и най­ти корневой элемент, которым во многих web-приложениях является стандарт­ный файл jndex.htm.

Каждый элемент представляется просто массивом байтов. Интерфейс содер­жимого включает в себя методы получения текущего содержимого документа и его замены заданным массивом байтов. Интерфейс свойств представляет мето­ды для манипулирования с метаданными, связанными с элементом. Метаданные элемента представлены в виде пар (атрибут, значение). Так, например, каждый из элементов GlobeDoc имеет свой МШЕ-тип (MIME-типы мы обсудим в гла­ве 11).

И, наконец, для того чтобы иметь возможность вносить изменения в элементы параллельно, каждый объект GlobeDoc реализует интерфейс блокировок. Этот интерфейс иллюстрирует принятый в Globe подход к управлению параллельным доступом. Поскольку мы предполагаем, что большинство web-документов исполь­зуется относительно небольшим количеством людей, механизм блокировки мож­но сделать достаточно простым. Когда элемент необходимо изменить, то первым делом он захватывается. Захватить {check out) элемент — это, в сущности, то же самое, что блокировать его на время модификации. Возможность чтения при этом сохраняется. После проведения модификации элемент освобождается (check in), при этом изменения вступают в силу.

Вернемся к локальному объекту для распределенных разделяемых объектов, показанному на рис. 9.24. Его подобъект связи (communication subobject) исполь­зуется для получения стандартного интерфейса с базовой сетью. Этот подобъект содержит несколько простых методов передачи сообщений для взаимодействия с установлением соединения и без установления соединения. Существуют также и более совершенные подобъекты связи, реализующие интерфейсы групповой рассылки. Некоторые подобъекты связи могут использоваться для организации надежной связи, в то время как другие в состоянии обеспечить лишь ненадеж­ную связь.

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

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

Подобъект репликации в принципе может позволить подобъекту управления самому обработать запрос и вернуть результат процессу, обратившемуся к объ­екту. Точно так же можно передавать подобъекту управления запросы удален­ных процессов. Будет выполнен демаршалинг такого запроса, после чего подобъект управления выполнит его и передаст результаты обратно подобъекту реплика­ции. Рассмотрение деталей мы отложим до обсуждения вопросов репликации в системе Globe.

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

В противоположность CORBA и DCOM, система Globe не имеет ни хранилища интерфейсов, ни аналога хранилища реализаций. Отсутствие этих двух служб частично связано с той моделью объектов, которая используется в Globe. Так, в частности, когда происходит привязка процесса к объекту, процесс должен за­грузить в свое адресное пространство конкретный локальный объект, соответ­ствующий распределенному разделяемому объекту, к которому выполняется при­вязка. Рассмотрим, как в Globe происходит привязка процесса к объекту.

Как показано на рис. 9.25, привязка выполняется за пять шагов. Каждый шаг, за исключением последнего, возвращает информацию, необходимую для сле­дующего шага. Таким образом, если мы получили информацию для очередного шага привязки, то этот шаг можно начинать осуществлять. Это повышает эф­фективность привязки в целом.

Привязка начинается с осмысленного (с позиций человека) имени службе именования. Это действие обозначено на рисунке как шаг 1. В Globe входит служба именования на основе DNS, которую мы обсудим чуть ниже. Эта служба возвращает глобально уникальное имя и не зависящий от местоположения деск­

риптор объекта (object handle). Это действие обозначено на рисунке как шаг 2. Дескриптор объекта используется в Globe в качестве глобальной ссылки на объ­ект, которая позволяет выполнять поиск объекта при помощи службы локализа­ции Globe. Отметим, что Globe отделяет службу именования от службы локали­зации (см. главу 4). Достоинство подобного разделения заключается в том, что мы можем изменять имена и адреса, без какого бы то ни было влияния на ото­бражение имен в адреса.

Служба локализации Globe возвращает набор контактных адресов данного объекта. Контактный адрес (contact address) точно определяет, где и каким обра­зом можно найти объект. Объект может иметь несколько контактных адресов, например, в связи с репликацией или поддержкой нескольких коммуникацион­ных протоколов. Далее мы увидим, что контактный адрес напоминает межопера­ционную ссылку на объект (IOR) в CORBA. После получения контактного адре­са можно считать, что у процесса есть вся необходимая для привязки к объекту информация.

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

Любой контактный адрес содержит информацию о том, что необходимо для создания локальной реализации процесса, чтобы он мог работать с объектом. В частности, он точно определяет локальный объект, который процессу следует загрузить. Так, например, контактный адрес может содержать URL-адрес файла, содержащего объекты класса, которые должен загрузить процесс. Подобный подход напоминает загрузку классов в Java. Загрузку локального объекта из хра­нилища (доверенного) классов и создание экземпляра иллюстрирует шаг 4. Отметим, что хранилище классов может быть просто файловой системой, воз­можно, удаленного сайта с доступом по FTP или по другому протоколу обмена файлами.

Отметим, что хранилище классов напоминает хранилище реализаций CORBA в том смысле, что оба они содержат реализации объектов. В Globe, однако, хра­нилище классов больше соответствует традиционной схеме хранения, в которой выбирается код. В CORBA это процесс, которому можно отправить запрос на создание объекта на сервере объекта.

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

Службы Globe

В противоположность CORBA и DCOM, Globe содержит относительно немного служб. На самом деле реализованы только те службы, которые не предоставляют­ся самим объектом. Это проще всего объяснить, рассматривая некоторые службы, имеющиеся в CORBA и DCOM, и их реализацию в Globe (табл. 9.13).

Служба коллекций CORBA используется для объединения объектов в спи­ски, очереди и т. д. Обычно такая служба может быть реализована при помощи объекта, состояние которого представляет собой набор ссылок на объекты. В Globe подобная служба реализована именно так.

Служба параллельного доступа в CORBA определена в понятиях коллекции интерфейсов, использующих для доступа различные типы блокировок [327]. В DCOM управление параллельным доступом осуществляется частично служ­бой транзакций, а частично так же, как серверы объектов обслуживают потоки выполнения. В Globe управление параллельным доступом обычно производится каждым объектом самостоятельно. Другими словами, разделяемый объект, кото­рому необходимо предотвратить параллельный доступ к своему состоянию, дол­жен предоставить необходимый специальный интерфейс для блокировки. Ника­кого стандартного интерфейса для управления параллельным доступом в Globe не существует.

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

В Globe нет службы событий. Как мы увидим, объекты в Globe всегда пассив­ны в том смысле, что у них отсутствует собственный поток выполнения. Таким образом, объект не в состоянии уведомить клиента о произошедшем событии. Для реализации службы событий в Globe подошла бы модель извлечения (pull) CORBA. В этом случае события можно было бы объединить в один объект, как в классе событий DCOM. До настоящего времени события в Globe не использо­вались.

Служба внешних связей, или служба маршалинга, обычно реализуется для каждого объекта в отдельности. В Globe большинство объектов должны реализо-вывать собственные процедуры маршалинга, при помощи которых они получают возможность передавать свое состояние на другие машины. Мы вернемся к во­просам маршалинга чуть позже, когда будем обсуждать объектную модель Globe.

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

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

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

Множество распределенных систем имеют выделенную службу сохранности (длительного хранения) в форме файловой системы или базы данных. В Globe такой службы нет. Вместо этого сохранность рассматривается как свойство объ­екта, а потому должна реализовываться самим объектом. Как добиться сохран­ности, в основном решает объект. Однако объекту для длительного хранения его состояния необходима определенная поддержка. В Globe эта поддержка обеспе­чивается в первую очередь серверами объектов, хотя многие реализации объек­тов используют также локальную файловую систему.

Защита в Globe частично реализуется каждым объектом в отдельности, а час­тично локальными и глобальными службами защиты. Так, например, хотя объ­ект сам может контролировать большую часть аспектов, связанных с обращени­ем к методам, вопросы получения и сертификации ключей обычно выделяют в отдельную службу. Ниже мы еще вернемся к вопросам защиты в Globe.

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

И, наконец, отказоустойчивость в Globe также поддерживается каждым из объектов, хотя для успешной маскировки ошибок необходима определенная под­держка со стороны серверов отказоустойчивых объектов. И снова мы обещаем вернуться к обсуждению отказоустойчивости чуть позже.