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

У распределенных объектов в DCE имеется одна проблема, связанная с их чрезвычайной близостью с RPC: не существует механизма прозрачных ссылок на объекты. Клиент имеет в лучшем случае дескриптор привязки (binding handle), ассоциированный с именованным объектом. Дескриптор привязки содержит идентификатор интерфейса, транспортный протокол, используемый для связи с сервером объектов, а также адрес и конечную точку хоста сервера. Дескриптор привязки может быть преобразован в строку и в таком виде передан другому процессу.

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

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

Дополнительную информацию по объектному программированию в DCE мож­но найти в [335, 476].

2.3.6. Пример 2 — Java rmi

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

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

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

Язык Java также поддерживает распределенные объекты исключительно в форме удаленных объектов. Напомним, что удаленный объект — это распределенный

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

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

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

Более существенное различие между локальными и удаленными объектами в Java заключается в семантике блокировки объектов. Java позволяет построить любой объект в виде монитора. Для этого достаточно объявить один из методов синхронизируемым (synchronized). Если два процесса одновременно вызовут син­хронизируемый метод, работать будет только один из них, в то время как второй окажется заблокированным. Таким образом, мы можем гарантировать, что дос­туп к внутренним данным объекта будет осуществляться только последовательно. Как и в мониторе, процесс может быть заблокирован и изнутри объекта в ожида­нии выполнения некоторого условия, как мы описывали в главе 1.

Рассуждая логически, блокировка в удаленных объектах — дело несложное. Предположим, что клиент А вызвал синхронизируемый метод удаленного объек­та. Чтобы получить доступ к удаленному объекту, который всегда выглядит так же, как локальный, необходимо блокировать А на уровне клиентской заглушки, которая реализует интерфейс объекта и к которой А имеет прямой доступ. Точно так же и другой клиент на другой машине должен быть блокирован до пересылки запроса на сервер. Это означает, что нам необходимо блокировать разных клиен­тов на различных машинах. Как мы увидим в главе 5, распределенная синхрони­зация может оказаться довольно сложным делом.

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

Поэтому разработчики Java RMI ограничили блокировку удаленных объек­тов блокировкой заместителей [494]. На практике это означает, что просто путем