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

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

9.3. Globe

601

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

ект, совместно используемый тремя процессами (рис. 9.26). Процессы Ви

име-

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

ектов семантики (Sem). Процесс А не имеет не только состояния, он не имеет

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

са А соответствует традиционной клиентской заглушке, или заместителю.

Процесс локального

объекта В

Процесс

локального

объекта А

Процесс А

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

семантики локального

объекта С

Траектория

ответа

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

обращения к В и С,

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

Рис. 9.26. Обращение к объекту

Globe с использованием активной репликации

Предположим, процесс А обращается к объекту. В соответствие с простым

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

и С, на что указывает траектория в виде сплошной линии. Когда запрос достиг-

нет подобъекта связи (Comm), скажем, процесса В, будет активизирован поток

выполнения для обработки запроса. В конце своей работы этот поток выполне-

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

ном сообщении. Аналогичная деятельность происходит и в процессе С.

Пока происходит обращение, поток выполнения процесса Л, который собст-

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

из других процессов в подобъект репликации (Repl) процесса А блокировка

пото-

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

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

приложению Л, от которого исходило обращение, в локальных объектах, соот-

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

ность прекращается.

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

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

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

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

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

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

но.

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

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

ния Globe.

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

9.3.3. Процессы

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

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

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

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

Клиент Globe

—

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

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

терфейс подобъекта управления (Ctrl), как показано на рис. 9.26. Процесс А

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

щего состояния, но соединенного с репликами, у которых состояние имеется.

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

даже не имеет подобъекта семантики. Все его обращения после маршалинга не-

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

очень похожа на заместители в CORBA и также может быть использована в ка-

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

мах, подобных CORBA

[214].

Однако в Globe возможна также настройка клиен-

тов в соответствии с подходом DOOM и RMI языка Java. Такая настройка может

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

таты обращений.

Стандартный способ придания клиентам CORBA новых свойств

—

использо-

вание перехватчиков. В DCOM подобная настройка, которая производится пу-

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

держке пользовательского маршалинга. В Globe распределенный разделяемый

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

реализации содержатся в хранилищах классов. Клиент сам решает, какую реали-

зацию ему использовать.

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

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

объектов, которые этот клиент может загрузить. Возможно также, что контакт-

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

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

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

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

веренном хранилище классов.

Такая гибкость достигается в Globe немалой ценой. Приходится создавать

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

систем и машинных архитектур. Некоторые из проблем, связанных с гетероген-

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

ных на интерпретируемых языках, таких как Java.

Сервер Globe

в противоположность клиенту сервер системы Globe

—

это процесс, который

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

9.3. Globe 603

сети. Другими словами (см. рис. 9.26), он не в состоянии вызывать методы через

интерфейс, предоставляемый подобъектом управления (Ctrl); процессы В и С

—

это примеры серверов Globe.

В Globe имеется также сервер объектов, поддерживающий распределенные

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

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

Процессы могут связаться с сервером объектов Globe через интерфейс, методы

которого перечислены в табл. 9.14. В сущности, каждый сервер объектов Globe

представляется для своих клиентов просто еще одним распределенным разде-

ляемым объектом.

Таблица 9.14. Операции с сервером объектов Globe

Метод Описание

В1 nd

Метод позволяет серверу выполнить привязку

к указанному объекту,

если привязка не была выполнена ранее

AddBi ndi ng Метод позволяет серверу выполнить привязку к указанному объекту,

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

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

распределенного объекта

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

данного объекта

Unbi

ndDSO

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

данного объекта

Li stAl

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

Li stDSO Метод возвращает список всех локальных объектов данного

распределенного объекта

StatLR Метод получает состояние указанного локального объекта

Одна из важных операций сервера

—

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

разделяемому объекту с помощью метода Bind. При этом серверу передается де-

скриптор объекта и критерии выбора контактного адреса (при наличии несколь-

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

адрес, обладающий определенными свойствами.

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

привязка уже выполнена, не происходит ничего. Если предполагается загрузка

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

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

AddBinding.

Сервер объектов Globe также содержит базовые средства создания распреде-

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

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

екта класса), которую может загрузить сервер. Когда объект класса загружен,

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

его.

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

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

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

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

Метод RemoveLR просто удаляет определенный локальный объект с сервера

объектов. Обычно эта операция не вызывается никогда. Вместо этого сервер, как

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

объекту методом

Unb1

ndDSO.

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

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

нимаемое им место.

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

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

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

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

зидентные, так и сохранные объекты.

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

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

В Globe существует два способа привязки сервера объектов к распределенно-

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

ние сохранного локального объекта.

Сохранный локальный объект {persistent local

object) — это локальный объект, для которого сервер объектов Globe будет вы-

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

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

частью процесса корректного отключения сервера. Когда впоследствии сервер

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

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

резидентный локальный

объект {transient local

object),

который никогда не запи-

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

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

уничтожаются.

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

соответствующего установленному локальному объекту. Такой адрес позволяет

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

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

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

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

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

Именование играет в Globe важнейшую роль и в значительной степени отличает-

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

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

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

строк и бессмысленных (с точки зрения человека) имен в виде битовых строк

требуются разные службы.

9.3. Globe 605

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

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

ный идентификатор (OID)

—

256-битную строку. OID в Globe

—

это, согласно

определению из главы 4, правильный (true) идентификатор. Другими словами,

OID в Globe относится самое большее к одному распределенному разделяемому

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

любой объект имеет максимум один идентификатор OID.

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

пример, предположим, что процессы Ли В привязаны к распределенному разде-

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

му они привязаны. Процессы А и В будут считаться привязанными к одному

тому же объекту в том и только в том случае, если одинаковы их идентифика-

торы OID.

Чтобы локализовать объект, необходимо разрешить контактный адрес этого

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

ством

дескриптора объекта {object

handle),

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

строку, содержащую OID и другую информацию, необходимую службе локали-

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

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

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

в службе локализации Globe, не несет какой-либо информации о текущем место-

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

Служба локализации Globe организована по принципу иерархической служ-

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

здесь этот материал. Детальные сведения по этой теме можно найти в [24, 469].

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

с соображениями о его производительности разбирается в [33].

Служба локализации Globe возвращает контактный адрес. Этот контактный

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

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

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

Первая

—

это

идентификатор адреса {address

identifier), по которому служба ло-

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

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

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

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

листового узла.

Вторая часть содержит реальную информацию об адресе, но эта информация

для службы локализации абсолютно недоступна. Для службы локализации ад-

рес

—

это просто массив байтов, который может в равной степени соответство-

вать реальному сетевому адресу, указателю на интерфейс (после маршалинга ука-

зателя) или даже полностью «упакованному» (путем маршалинга) заместителю.

В Globe в настоящее время поддерживаются два типа адресов. Упакованный

адрес {stacked address)

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

из уровней которого описывается записью с тремя полями (табл. 9.15).

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

Таблица 9.15. Представление уровня протоколов в упакованном

контактном адресе

Поле Описание

Идентификатор протокола Константа, соответствующая протоколу (известному)

Адрес протокола Адрес, определяемый протоколом

Дескриптор реализации Ссылка на файл в хранилище классов

Идентификатор протокола {protocol identifier) —

это константа, соответствую-

щая одному

из

известных протоколов. Обычно идентификаторы протоколов опи-

сывают такие протоколы,

как

TCP,

UDP и IP.

Поле адрес протокола {protocol

address) содержит определяемый протоколом адрес, такой

как

номер порта TCP

или сетевой адрес IPv4.

наконец,

дескриптор реализации {implementation

hand-

le) — поле (необязательное), идентифицирующее место,

котором может нахо-

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

ставлен

виде URL-адреса.

Второй

тип

контактного адреса

—

это

адрес экземпляра {instance address),

состоящий

из

двух полей (табл. 9.16). Этот адрес также содержит дескриптор

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

на

файл

хранилище классов,

со-

держащий реализацию локального объекта. Этот локальный объект может быть

загружен привязанным

объекту процессом.

Таблица 9.16. Представление контактного адреса экземпляра

Поле Описание

Дескриптор реализации Ссылка на файл в хранилище классов

Строка инициализации Строка, используемая для инициализации данной

реализации локального объекта

Загрузка протекает

соответствии

со

стандартным протоколом, похожим

на

протокол загрузки классов в Java. После загрузки реализации

создания локаль-

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

в передаче ему

строки

инициализации

{initialization

string).

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

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

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

на

базе DNS [32]. Служба именования позволяет произво-

дить поиск и авторизованные изменения имен. Осмысленное имя в Globe [44] пред-

ставлено

виде

унифицированного идентификатора

ресурса {Uniform Resource

Identifier, URI), например, hfn://org/globeworld/dns/globesite. Это имя разрешается

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

Для использования DNS

имя

Globe сначала локально преобразуется

пра-

вильное DNS-имя. Так, имя Globe hfn://org/globeworld/dns/globesite преобразует-

ся

DNS-имя globesite.dns.globeworld.org, которое затем передается локальному

преобразователю имен DNS, как показано на рис. 9.27 (для обозначения сервера,

9.3. Globe

607

именуемого

org,

используется запись #org). Если предполагать, что мы имеем де-

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

стью имени, которую не сможет разрешить.

DNS клиента/

Преобразователь

имен Globe

1 globesite.dns.gIobeworld.org

2 #org, globesite.dns.globeworld

globesite.dns.globeworld

Сервер

имен DNS

#giobeworld, globesite.dns

globesite.dns

Сервер

имен DNS

Дескриптор объекта

Преобразователь

имен Globe

hfn://org/globeworld/dns/globesite

Рис. 9.27. Итеративное разрешение имен

Globe

В нашем примере DNS-имя globeworld.org будет разрешено сервером имен

Globe, который выделит оставшуюся часть, globesite.dns. Сервер имен Globe реа-

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

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

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

9.3.5.

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

Globe не имеет каких-либо специальных механизмов синхронизации. При необ-

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

кации. Механизмов синхронизации между объектами не существует. Понятно,

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

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

Репликация в Globe имеет важнейшее значение. Всякий распределенный разде-

ляемый объект Globe реализует свою собственную стратегию репликации при по-

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

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

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

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

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

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

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

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

операции над состоя-

нием реализуются

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

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

по разным процессам.

Ключевая проблема состоит

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

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

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

а за

поддержание непротиворечивости

полностью отвечает набор подобъектов репликации. По этой причине подобъект

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

локальному методу

подобъекта семантики. При этом принимается

во

внимание различие между ме-

тодами чтения (read

methods),

которые

не

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

се-

мантики,

методами модификации

(modify

methods),

которые вносят

него

из-

менения.

Когда процесс, привязанный

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

гцается

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

—

информирует

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

объекта репликации (табл. 9.17). Единственная информацрш, которую передает

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

при

вызове Start,

—

указание

на

то, может

ли

соответст-

вующее обращение внести изменения

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

на

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

что

ему делать дальше.

Таблица 9.17. Интерфейс подобъекта репликации, доступный

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

Метод Описание

sta

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

новым обращением

методу

send Выполняет маршалинг обращения

передает запрос

обращением

подобъекту репликации

nvoked Указывает на завершение обращения

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

Существует два возможных результата вызова метода start, каждый

из

кото-

рых указывает

на

следующее действие, которое следует выполнить подобъекту

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

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

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

ожидать завершения операции.

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

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

подобъекту

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

invoked, сообщая подобъекту репликации

том,

что

работа окончена.

И в

этом

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

Метод send

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

его

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

кации получит ответ, может быть даже

от

нескольких реплик.

любом случае,

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

9.3. Globe 609

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

вращает эти ответы в исходящем параметре метода send.

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

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

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

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

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

шении этого обращения вызывает метод Invoked. После вызова метода invoked под-

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

щий процесс.

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

конечный автомат с четырьмя состояниями, как это показано на рис. 9.28. Пере-

ходы между состояниями жестко контролируются подобъектом репликации,

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

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

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

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

кальное обращение к методу, отвечает подобъект репликацрш. Рассмотрим две

стратегии репликации, иллюстрирующие этот подход.

Рис. 9.28. Работа подобъекта управления в качестве

конечного автомата

Примеры репликации в Globe

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

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

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

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

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

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

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

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

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

метода send. Обращение после маршалинга рассылается всем репликам, включая

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

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

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

зультаты будут возвращены вызывающему процессу (табл. 9.18).

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

Таблица 9.18. Переходы из состояния в состояние при активной репликации

Состояние

Метод чтения

START

INVOKE

RETURN

Производимое действие

Отсутствует

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

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

Метод модификации

START

SEND

INVOKE

RETURN

Отсутствует

Выполнить маршалинг и передать

обращение

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

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

Вызов метода

start

invoked

Нет

start

send

invoked

Нет

Следующее

состояние

INVOKE

RETURN

START

SEND

INVOKE

RETURN

START

Рассмотрим теперь репликацию на основе первичной копии. В этом случае

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

вызывающему процессу.

При вызове метода модификации резервной копии ее подобъект репликации

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

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

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

приказ вернуть управление вызывающему процессу.

При вызове метода модификации первичной копии подобъект репликации

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

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

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

лает его в резервную копию. После завершения обновления резервной копии под-

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

вызывающему процессу (табл. 9.19).

Таблица 9.19. Переходы из состояния в состояние при репликации

на основе первичной копии

Состояние

Производимое действие Вызов метода

Следующее

состояние

Метод чтения

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

INVOKE Обратиться

локальному методу

RETURN

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

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

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

SEND

Выполнить маршалинг и передать

RETURN

обращение

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

start

invoked

Нет

start

send

INVOKE

RETURN

START

SEND

RETURN

Нет

START