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

Поскольку разница между локальными и удаленными объектами на уровне язы­ка слабо заметна, Java может в ходе обращений к удаленным методам скрывать большую часть различий между ними. Так, в ходе обращения RMI в качестве па­раметра может быть передан любой простой или объектный тип, что предполага­ет возможность маршалинга типов. В терминологии Java это означает, что типы сериализуемы (serializable). Хотя в принципе сериализации можно подвергнуть большинство объектов, она не всегда является допустимой или возможной. Обычно зависящие от платформы объекты, такие как дескрипторы файлов или сокеты, не сериализуются.

Единственное различие между локальными и удаленными объектами, наблю­даемое в процессе RMI, состоит в том, что локальные объекты передаются по значению (включая большие объекты, такие как массивы), в то время как удален­ные объекты передаются по ссылке. Другими словами, локальные объекты копи­руются, после чего копия используется в качестве параметра-значения. В случае удаленных объектов в качестве параметра используется ссылка на объект, без всякого копирования, как показано на рис. 2.17.

При обращении RMI в Java ссылка на удаленный объект реализуется именно так, как мы говорили в пункте 2.3.2. Эта ссылка содержит сетевой адрес и конеч­ную точку сервера, а также локальный идентификатор необходимого объекта в адресном пространстве сервера. Как мы обсуждали, в ссылке на удаленный объ­ект, кроме того, кодируется стек протоколов, используемых клиентом и серве­ром для взаимодействия. Чтобы понять, как при обращении RMI в Java кодиру­ется стек протоколов, необходимо учитывать, что каждый объект Java представ­ляет собой экземпляр класса. Класс же, в свою очередь, содержит реализацию одного или более интерфейсов.

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

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

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

шения вызова. Для этого, как уже говорилось, заместитель нуждается в сетевом адресе и конечной точке сервера.

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

Этот подход согласуется с методами интеграции локальных и распределен­ных приложений в Java. Напомним, что при обращении RMI локальный объект передается путем создания копии, а удаленный — через общесистемную ссылку на объект. Заместитель представляет собой просто-напросто локальный объект. Это означает, что сериализуемый заместитель можно передавать по сети как па­раметр RMI. В результате появляется возможность использовать заместитель как ссылку на удаленный объект.

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

Такой подход к ссылкам на удаленные объекты отличается высокой гиб­костью и представляет собой одну из отличительных особенностей RMI в Java [482]. В частности, это позволяет оптимизировать решение под конкретный объ­ект. Так, рассмотрим удаленный объект, состояние которого изменяется только один раз. Мы можем превратить этот объект в настоящий распределенный объ­ект путем копирования в процессе привязки всего его состояния на клиентскую машину. Каждый раз при обращении клиента к методу он работает с локальной копией. Чтобы гарантировать согласованность данных, каждое обращение про­веряет, не изменилось ли состояние объекта на сервере, и при необходимости об­новляет локальную копию. Таким же образом методы, изменяющие состояние объекта, передаются на сервер. Разработчик удаленного объекта должен разрабо­тать только код, необходимый для клиента, и сделать его динамически подгру­жаемым при присоединении клиента к объекту.

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

 

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

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

Связь посредством сообщений

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

Это «что-то другое» — обмен сообщениями. В этом разделе мы сосредото­чимся на использовании в распределенных системах взаимодействия на основе сообщений. Сначала мы кратко рассмотрим, что такое чисто синхронное поведе­ние и каковы его области применения. Затем обсудим системы обмена сообще­ниями, позволяющие сторонам в процессе взаимодействия продолжать работу. И наконец, исследуем системы очередей сообщений, позволяющие процессам обмениваться информацией, даже если вторая сторона в момент начала связи не работает.