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

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

2.3.

Обращение к удаленным объектам 111

имя серверу службы каталогов. Последний возвращает сетевой адрес маши-

ны,

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

к DCE-демону этой машины (имеющему общеизвестную конечную точку) и про-

сит его найти в его таблице конечных точек конечную точку сервера видеоин-

формации. Теперь, вооружившись полученными данными, мы можем выполнить

вызов RPC. В ходе последующих вызовов RPC нам нет нужды проделывать всю

процедуру поиска заново.

При необходимости система DCE дает клиенту возможность усложненного

поиска необходимого сервера. Безопасность RFC также входит в ее задачи.

Выполнение вызова RPC

Реальный вызов RPC происходит прозрачно и обычным образом. Клиентская за-

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

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

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

оно передается нужному серверу в соответствии с содержащейся в сообщении ко-

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

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

отправляется назад по тому же маршруту.

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

По умолчанию поддерживается

одноразовая

операция (at-most-once

operation),

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

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

де вызова RPC «рухнул», а затем был быстро восстановлен, клиент не должен

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

С другой стороны, можно пометить (в файле IDL) удаленную процедуру как

идемпотентпую

(idempotent),

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

торы запросов. Так, например, чтение некоторого блока из файла можно повто-

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

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

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

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

вызовов RPC всем машинам текущей локальной сети. Мы вернемся к семантике

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

2.3.

Обращение к удаленным объектам

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

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

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

вом строго определенного интерфейса. Такой подход позволяет легко заменять

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

По мере того как механизм RPC постепенно становился фактическим стан-

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

112 Глава 2. Связь

понимать, что принципы RPC могут быть равно применены и к объектам. В этом

разделе мы распространим идею RFC на обращения к удаленным объектам

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

по сравнению с вызовами RPC. Мы сосредоточимся на относительно простых

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

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

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

сматривать сейчас.

2.3.1.

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

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

зываемые

состоянием

{state), и операции над этими данными, называемые л/^шо-

дами {methods). Доступ к методам можно получить через интерфейс. Важно

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

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

вляется через интерфейс этого объекта. Объект может реализовывать множество

интерфейсов. Точно так же для данного описания интерфейса может существо-

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

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

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

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

показанная на рис. 2.16, обычно и

m^hiBdieTC^

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

{distribu-

ted object).

Машина клиента

Машина сервера

Клиент

обращается .

к методу

Операционная

система

клиента

Сеть

Тот же интерфейс,

что и у объекта

Скелетон

вызывает

для объекта

тот же метод

Операционная

система

сервера

Параметры вызова после

маршалинга передаются по сети

Рис. 2.16. Обобщенная организация удаленных объектов

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

Объект

•

Состояние

•

Метод

Интерфейс

2.3.

Обращение к удаленным объектам 113

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

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

заместителем {рюху). Заместитель клиента аналогичен клиентской заглушке

в системах RPC. Единственное, что он делает,

—

выполняет маршалинг парамет-

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

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

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

ской машине интерфейсы. Входящий запрос на обращение к методу сначала по-

падает на серверную заглушку, часто именуемую

скелетоном

{skeleton).

Скелетон

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

ходящегося на сервере. Серверная заглушка также отвечает за маршалинг пара-

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

Характерной, но немного противоречащей интуитивному представлению осо-

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

(данные) не распределяется

—

оно локализовано на одной машине. С других ма-

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

называют удаленными

{remote

object).

Как мы увидим в последующих главах при

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

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

вается от клиентов за интерфейсами объектов.

Объекты времени компиляции против

объектов времени выполнения

Объекты в распределенных системах существуют в различных формах. В наибо-

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

программирования, например Java, C++ или другого объектно-ориентированного

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

ект является экземпляром класса.

Класс —

это описание абстрактного типа в виде

модуля, содержащего элементы данных и операций над этими данными

[291].

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

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

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

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

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

Java.

Интерфейсы

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

щаться к объектам Java с удаленных машин. Разработчик программы на Java ча-

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

ется только текстом программы на языке Java.

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

состоит в зависимости от конкретного языка программирования. Существует

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

—

непосредственно

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

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

ветствии с ним, не зависят от конкретного языка программирования. В част-

114 Глава 2. Связь

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

языках программирования.

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

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

шить написать на С библиотеку, содержащую набор функций, которые смогут

работать с общим файлом данных. Главный вопрос состоит в том, как превра-

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

шины. Традиционный способ состоит в том, чтобы использовать

адаптер объектов

{object

adapter), который послужит

оболочкой {wrapper)

реализации с единствен-

ной задачей

—

придать реализации видимость объекта. Сам термин «адаптер»

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

[157],

который предоставляет ин-

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

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

библиотеке на С и открывающая файл данных, соответствующий текущему со-

стоянию объекта.

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

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

чительно в понятиях интерфейсов, которые они реализуют. Реализация интер-

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

для удаленных обращений. Адаптер будет принимать приходящие обращения

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

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

Сохранные и нерезидентные объекты

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

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

объекты.

Сохранный объект {persistent object) —

это объект, который продолжает

существовать, даже не находясь постоянно в адресном пространстве серверного

процесса. Другими словами, сохранный объект не зависит от своего текущего серве-

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

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

стве и завершить свою работу. Позже вновь запущенный сервер может считать

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

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

дентный объект {transient object) —

это объект, который существует, только пока

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

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

—

это спорный вопрос.

Некоторые полагают, что нерезидентных объектов вполне достаточно. Сейчас мы

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

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

2.3.2.

Привязка клиента к объекту

Интересная разница между традиционными системами RPC и системами, под-

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

2.3.

Обращение к удаленным объектам 115

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

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

машинах, например как параметры обращения к методу. Путем сокрытия истин-

ной реализации ссылок на объекты (то есть обеспечения их непрозрачности)

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

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

ханизмом RPC повышается.

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

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

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

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

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

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

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

клиента.

При неявной привязке

{implicit binding)

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

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

на объект. Так, например, в C++ можно переопределить унарный оператор выбо-

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

как с простыми указателями (листинг 2.1). В случае неявной привязки клиент

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

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

{explicit

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

функцию для привязки к объекту. При явной привязке обычно возвращается ука-

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

Листинг

2.1.

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

переменных

// Определить внутрисистемную ссылку на объект

D1str_object* obj_ref;

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

obj_ref = ... :

Неявно провести привязку

обратиться

методу

obj_ref->clo_someth1ng():

Листинг 2.2. Пример явной привязки с использованием как глобальных,

так и локальных переменных

/7 Определить внутрисистемную ссылку на объект

D1str_object obj_ref;

// Определить указатель на локальные объекты

Local_object* obj_ptr:

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

obj_ref = ... ;

Явно провести привязку

получить указатель

на локальный заместитель

obj_ptr

b1ncl(obj_ref):

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

obj_ptr->clo_something();

116 Глава 2. Связь

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

Очевидно, что ссылки на объекты должны содержать достаточно информации,

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

содержать сетевой адрес машины, на которой paзмeп^eн реальный объект, вместе

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

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

пример, в форме 16-битного числа. Конечная точка в данном случае абсолютно

такая же, как и та, что обсуждалась при рассмотрении системы DCE RPC. На

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

локальной операционной системой сервера. Однако эта схема имеет мрюжество

недостатков.

Во-первых, если в сервере произойдет сбой и после восстановления сервер

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

Эту проблему можно решить так же, как это сделано в DCE: создать на машине

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

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

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

конечную точку сервера. Такой подход требует, чтобы мы кодировали идентр!-

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

индекса в таблице конечных точек. Сервер, в свою очередь, всегда должен реги-

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

Однако кодирование сетевого адреса машины сервера в ссылке на объект

—

вообще говоря, плохая идея. Проблема подобного подхода — в том, что сервер

невозможно будет перенести на другую машину, не объявив недеР1Ствительными

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

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

щих таблицы конечных точек, на сервер локализации {location server)^ следящрш

за постоянной работой серверов, на которых расположены объекты. Ссылка на

объект в результате должна содержать сетевой адрес сервера локализации, а так-

же действующий в системе идентификатор сервера. Как мы увидим в главе 4, это

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

мости.

До настоящего момента мы в тактических \1елях предполагали, что клиент

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

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

портный протокол, такой как TCP, но также и общий протокол маршалинга и де-

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

протоколом для установки исходного соединения, обработки ошибок, контроля

потока и пр.

Мы можем осторожно отбросить это допущение, если предположим, что к

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

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

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

может одновременно поддерживать прием данных по протоколу TCP и дейта-

2.3.

Обращение к удаленным объектам 117

граммы и

DP.

При этом на клиенте лежит ответственность за реализацию замес-

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

Мы можем пойти еще дальше, включив в ссылку на объект

дескриптор

реали-

зации

{implementation

handle), указывающий на полную реализацию заместителя.

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

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

щего на файл архива, типа ftp://ftp.clientware.org/proxies/java/proxy-v1.1a.zip. Про-

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

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

вии создать экземпляр. Плюс такого подхода состоит в том, что клиент не дол-

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

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

объекта заместителей. Однако, как мы увидим в главе 8, чтобы гарантировать

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

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

2.3.3. Статическое и динамическое удаленное

обращение к методам

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

титься к методам объекта. Подобное удаленное

обраще7ше

к методам (Remote

Method

Invocation,

RMI) в части маршалинга и передачи параметров очень напо-

минает RPC. Основное различие между RMI и RPC состоит в том, что RMI, как

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

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

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

боте и специфические для объектов заглушки, которые мы также обсуждали.

Стандартный способ поддержки RMI

—

описать интерфейсы объектов на языке

определения интерфейсов, так же как в RPC. Однако с тем же успехом мы мо-

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

матическую генерацию заглушек. Такой подход к примененргю предопределен-

ных определений интерфейсов часто называют

статическим обращением

{static

invocation).

Статическое обращение требует, чтобы интерфейсы объекта при раз-

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

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

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

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

динамичным образом. В частности, иногда удобнее собрать параметры обраще-

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

мического обращения

{dynamic

invocation).

Основное его отличие от статического

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

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

выглядит следующим образом:

1nvoke(object. method. 1nput_parameters. output_parameters):

118 Глава 2. Связь

Здесь object идентифицирует распределенный объект; method

—

параметр, точ-

но задающий вызываемый метод; 1nput_parameters

—

структура данных, в кото-

рой содержатся значения входных параметров метода; output_parameters

—

струк-

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

В качестве примера рассмотрим добавление целого числа 1nt к объекту

fobject файла. Для этого действия объект предоставляет метод append. В этом слу-

чае статическое обращение будет иметь вид:

fobject.append (int)

Динамическое обращение будет выглядеть так:

1nvoke(fobject. 1d(append). 1nt)

Здесь операция 1d(append) возвращает идентификатор метода append. Для ил-

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

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

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

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

интерфейс с объектом. Пользователю после этого может быть предложено вы-

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

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

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

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

го создания обращений к методам.

Другая область применения динамических обращений

—

службы пакетной об-

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

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

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

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

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

2.3.4. Передача параметров

Поскольку большинство систем RMI поддерживает ссылки на объекты в преде-

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

обычно не столь ограничены, как в случае RPC. Однако существуют определен-

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

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

Сперва рассмотрим ситуацию, когда все объекты

—

распределенные. Другими

словами, все объекты в системе доступны с удаленных машин. В этом случае при

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

метры. Ссылки передаются по значению и копируются с одной машины на дру-

гую.

Если процесс получает ссылку на объект в качестве результата обращения

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

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

К сожалению, использование исключительно распределенР1ых объектов обыч-

но слишком неэффективно, особенно если эти объекты малы и просты, как, на-

2.3.

Обращение к удаленным объектам 119

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

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

ными адресными пространствами или, что еще хуже, между различными маши-

нами. Поэтому работа со ссылками на удаленные и локальные объекты обычно

происходит по-разному.

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

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

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

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

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

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

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

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

программа, выполняемая на машине А, и программа-сервер, выполняемая на ма-

шине С. Клиент обладает ссылкой на локальный объект 01, который использу-

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

С.

Кроме

того,

он обладает ссылкой на находящийся на машине В удаленный объект 02,

который также используется в качестве параметра. При вызове сервера на маши-

ну С передается копия всего объекта 01 и копия ссылки на объект 02.

Машина А Машина В

Локальная

ссылка L1.

Локальный

объект 01

Удаленная

ссылка R1

Код клиента с кодом

заместителя, то есть с кодом

обращения RMI к серверу,

находящемуся

на машине С

Удаленное обращение^

с передачей в качестве

параметров ссылок

и R1

Удаленный

объект 02

Г Копирование ]

объекта 01

Пм

''X

Копирование ссылки R1

на объект 02

Машина С

Код сервера

(реализация методов)

Рис. 2.17. Передача объекта по ссылке и по значению

Отметим, что независимо от того, работаем ли мы со ссылкой на локальный

или глобальный объект, эта работа может быть весьма прозрачна, как, например,

Java.

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

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

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

[494].

С другой

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

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

качестве ссылок на удаленные объекты будет невозможно.

120 Глава 2. Связь

Дополнительный эффект обращения к методам с использованием в качестве

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

Скрыть это невозможно, и в результате мы вынуждены явно указывать на разли-

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

разлР1-

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

—

оно также затрудняет

написание распределенных приложений.

2.3.5. Пример 1

—

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

DCE

—

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

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

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

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

стоятельность. К сожалению, время доказательств совпало с «рождением» уда-

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

среда DCE была традиционной, основанной на RPC системой, для нее наступили

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

успели установрггь достаточное число копий. Нет объектов

—

нет и разговора, а сре-

да DCE их никогда не имела.

Команда, создававшая среду DCE, долго убеждала адвокатов объектных тех-

нологий, что в ней реализована поддержка объектов. Так, они утверждали, что

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

реализации и распределения скрыты за интерфейсами. Однако эти аргументы не

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

нологию. В этом пункте мы рассмотрим, как DCE поддерживает распределенные

объекты. Объекты DCE интересны для нас тем, что они являются прямым про-

должением модели клиент-сервер, основанной на RPC, и представляют собой

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

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

Распределенные объекты были добавлены в DCE в форме расширений языка оп-

ределения интерфейсов (IDL) вместе с привязками на языке C++. Другими сло-

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

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

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

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

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

Поддерживаются два типа распределенных

объектов.

Динамические

распреде-

ленные

объекты

{distributed dynamic

objects)

— это объекты, которые создаются

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

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

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

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

можно вызвать, используя стандартный механизм RPC. После создания динами-