Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 29
Текст из файла (страница 29)
СвязьРеализация ссылок на объектыОчевидно, что ссылки на объекты должны содержать достаточно информации,чтобы обеспечить клиентам привязку к объекту. Простая ссылка на объект должнасодержать сетевой адрес машины, на которой 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ше к методам (RemoteMethod Invocation, RMI) в части маршалинга и передачи параметров очень напоминает RPC. Основное различие между RMI и RPC состоит в том, что RMI, какговорилось ранее, в основном поддерживает внутрисистемные ссылки на объекты.Кроме того, отпадает необходимость в клиентских и серверных заглушках общегоназначения. Вместо них мы можем использовать значительно более удобные в работе и специфические для объектов заглушки, которые мы также обсуждали.Стандартный способ поддержки RMI — описать интерфейсы объектов на языкеопределения интерфейсов, так же как в RPC. Однако с тем же успехом мы можем использовать объектный язык, например Java, который обеспечивает автоматическую генерацию заглушек.
Такой подход к примененргю предопределенных определений интерфейсов часто называют статическим обращением {staticinvocation). Статическое обращение требует, чтобы интерфейсы объекта при разработке клиентского приложения были известны. Также оно предполагает, чтопри изменении интерфейса клиентское приложение перед использованием новых интерфейсов будет перекомпилировано.В качестве альтернативы обращение к методам может осуществляться болеединамичным образом. В частности, иногда удобнее собрать параметры обращения к методу во время исполнения.
Этот процесс известен под названием динамического обращения {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пример, целые числа и логические значения. Каждое обращение клиента, если онне находится на том же сервере, что и объект, порождает запрос между различными адресными пространствами или, что еще хуже, между различными машинами. Поэтому работа со ссылками на удаленные и локальные объекты обычнопроисходит по-разному.При обращении к методу с использованием ссылки на объект в качестве параметра эта ссылка копируется и передается как параметр-значение только тогда, когда она относится к удаленному объекту. Именно в этом случае происходит передача объекта по ссылке.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
