Статическое и динамическое удаленное обращение к методам

После того как клиент свяжется с объектом, он может через заместителя обра­титься к методам объекта. Подобное удаленное обращение к методам {Remote Method Invocation, RMI) в части маршалинга и передачи параметров очень напо­минает RPC. Основное различие между RMI и RPC состоит в том, что RMI, как говорилось ранее, в основном поддерживает внутрисистемные ссылки на объекты. Кроме того, отпадает необходимость в клиентских и серверных заглушках общего назначения. Вместо них мы можем использовать значительно более удобные в ра­боте и специфические для объектов заглушки, которые мы также обсуждали.

Стандартный способ поддержки RMI — описать интерфейсы объектов на языке определения интерфейсов, так же как в RPC. Однако с тем же успехом мы мо­жем использовать объектный язык, например Java, который обеспечивает авто­матическую генерацию заглушек. Такой подход к применению предопределен­ных определений интерфейсов часто называют статическим обращением {static invocation). Статическое обращение требует, чтобы интерфейсы объекта при раз­работке клиентского приложения были известны. Также оно предполагает, что при изменении интерфейса клиентское приложение перед использованием но­вых интерфейсов будет перекомпилировано.

В качестве альтернативы обращение к методам может осуществляться более динамичным образом. В частности, иногда удобнее собрать параметры обраще­ния к методу во время исполнения. Этот процесс известен под названием дина­мического обращения {dynamic invocation). Основное его отличие от статического обращения состоит в том, что во время выполнения приложение выбирает, ка­кой метод удаленного объекта будет вызван. Динамическое обращение обычно выглядит следующим образом:

invoke(object. method. input_parameters. output_parameters);

 

 

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

Здесь object идентифицирует распределенный объект; method — параметр, точ­но задающий вызываемый метод; input_parameters — структура данных, в кото­рой содержатся значения входных параметров метода; output_parameters — струк­тура данных, в которой хранятся возвращаемые значения.

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

В качестве примера рассмотрим добавление целого числа int к объекту fobject файла. Для этого действия объект предоставляет метод append. В этом слу­чае статическое обращение будет иметь вид:

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

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

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

Поскольку большинство систем RMI поддерживает ссылки на объекты в преде­лах системы, возможности по передаче параметров при обращениях к методам обычно не столь ограничены, как в случае RPC. Однако существуют определен­ные тонкости, которые могут усложнить обращения RMI по сравнению с перво­начальным представлением. Ниже мы кратко обсудим этот вопрос.

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

К сожалению, использование исключительно распределенных объектов обыч­но слишком неэффективно, особенно если эти объекты малы и просты, как, на-

 

 

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

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

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

Эти две ситуации показаны на рис. 2.17, на котором изображены клиентская программа, выполняемая на машине А, и программа-сервер, выполняемая на ма­шине С. Клиент обладает ссылкой на локальный объект 01, который использу­ется в качестве параметра при вызове серверной программы на машине С. Кроме того, он обладает ссылкой на находящийся на машине В удаленный объект 02, который также используется в качестве параметра. При вызове сервера на маши­ну С передается копия всего объекта 01 и копия ссылки на объект 02.

Отметим, что независимо от того, работаем ли мы со ссылкой на локальный или глобальный объект, эта работа может быть весьма прозрачна, как, например, в Java. В Java разница будет заметна только в том случае, если локальные объек­ты будут иметь типы данных, отличные от типов данных удаленных объектов. В противном случае оба типа ссылок будут трактоваться почти одинаково [494]. С другой стороны, в традиционных языках программирования, таких как С, ссыл­ками на локальные объекты могут быть простые указатели, использовать которые в качестве ссылок на удаленные объекты будет невозможно.

 

 

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

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

Пример 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. После создания динами-

 

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

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

В противоположность динамическим объектам, именованные распределенные объекты (distributed named objects) не предназначены для работы с единственным клиентом. Они создаются сервером для совместного использования нескольки­ми клиентами. Именованные объекты регистрируются службой каталогов, так что клиент может найти объект и выполнить привязку к нему. Регистрация означает сохранение уникального идентификатора объекта, а также информации о том, как соединиться с сервером объекта. Разницу между динамическими и име­нованными объектами иллюстрирует рис. 2.18.