Факультет «Информатика и системы управления»
Методические указания к лабораторной работе
по курсу «Распределенные системы обработки информации»
"Удаленный вызов методов(RMI)"
Москва 2004 г.
Цель работы
Ознакомиться с RMI. Написать клиент RMI и сервер RMI.
Что такое RMI?
JavaRMI (RemoteMethodInvocation – удаленный вызов методов) представляет собой тип удаленного вызова процедур, независимый от сети, облегченный и полностью переносимый, так как написан на языке Java.
Основные шаги работы с RMI:
1. Определите (или найдите) удаленный интерфейс, согласованный с сервером.
2. Напишите код сервера.
3. Запустите программу rmic (JavaRMIstubcompiler – компилятор заглушек RMI) для генерации связующего кода.
4. Напишите код клиента.
5. Убедитесь, что на сервере запущен RMI реестр (программа rmiregistry).
6. Запустите сервер.
7. Запустите одного или нескольких клиентов.
Процедуры RMI определяют с помощью известного механизма Java – интерфейсов. Удаленные нтерфейсы долдны быть подклассами java.rmi. Remote, при этом и клиент и сервер должны находиться в одном пакете Java. Все параметры удаленных методов должны относиться или к примитивным типам (int, doubleи т.п.), либо реализовывать интерфейс java.io. Serializable.
Введение в распределенные вычисления с использованием RMI
Технология RemoteMethodInvocation (RMI), впервые представленная в JDK 1.1, продвинула сетевое программирование на более высокий уровень. Хотя RMI относительно проста в использовании, она является необыкновенно мощной технологией и раскрывает перед обычным Java‑программистом полностью новую парадигму – мир распределенных объектных вычислений.
Этот курс представляет собой углубленное введение в эту универсальную технологию. RMI получила значительное развитие в JDK 1.1 и во многом была улучшена в Java 2 SDK. При необходимости, различия между этими двумя версиями будут отмечены.
Цели
Главной целью разработчиков RMI было предоставление возможности программистам разрабатывать распределенные Java‑программы, используя такие же синтаксис и семантику, как и при разработке обычных нераспределенных программ. Для этого они должны были преобразовать модель работы классов и объектов в одной виртуальной машине Java™ (JVM) в новую модель работы классов и объектов в распределенной (несколько JVM) вычислительной среде.
Сравнение распределенных и нераспределенных Java‑программ
Разработчики RMI стремились сделать использование распределенных Java‑объектов таким же, как и использование локальных объектов. В следующей таблице перечислены некоторые важные отличия.
Не беспокойтесь о том, что не все отличия вам понятны. Все прояснится после рассмотрения архитектуры RMI. Вы можете использовать эту таблицу в качестве ссылки во время изучения RMI.
| Локальный объект Удаленный объект | ||
| Определение объекта | Локальный объект определяется при помощи класса Java. | Экспортируемое поведение удаленного объекта определяется при помощи интерфейса, который должен быть расширен из интерфейса Remote. |
| Реализация объекта | Локальный объект реализуется своим классом Java. | Поведение удаленного объекта определяется классом Java, который реализует удаленный интерфейс. |
| Создание объекта | Новый экземпляр локального объекта создается оператором new. | Новый экземпляр удаленного объекта создается на компьютере хоста оператором new. Клиент не может непосредственно создать новый удаленный объект (если не использует технологию Java 2 Remote Object Activation). |
| Доступ к объекту | Доступ к локальному объекту осуществляется непосредственно через переменную-ссылку на объект. | Доступ к удаленному объекту осуществляется через переменную-ссылку на объект, указывающую на реализацию замещающей заглушки удаленного интерфейса. |
| Ссылки | В одной JVM, ссылка на объект указывает непосредственно на объект в динамической памяти. | «Удаленная ссылка» представляет собой указатель на замещающий объект («заглушку») в локальной динамической памяти. Заглушка содержит информацию, которая дает возможность соединиться с удаленным объектом, содержащим реализацию методов. |
| Активные ссылки | В одной JVM, объект считается «живым», если существует хотя бы одна ссылка на него. | В распределенной среде удаленная JVM может разрушиться, и сетевое соединение может быть потеряно. Считается, что удаленный объект имеет активную удаленную ссылку на него, если к нему производился доступ в течение определенного периода времени (срока аренды). Если все удаленные ссылки были удалены явно, или если у всех удаленных ссылок закончился срок аренды, тогда удаленный объект становится доступен для удаленной сборки мусора. |
| Финализация | Если объект реализует метод finalize(), он вызывается перед тем, как объект утилизируется сборщиком мусора. | Если удаленный объект реализует интерфейс Unreferenced, при удалении всех удаленных ссылок вызывается метод unreferenced этого интерфейса. |
| Сборка мусора | При удалении всех локальных ссылок на объект, он становится кандидатом на удаление сборщиком мусора. | Удаленный сборщик мусора работает совместно с локальным. Если нет удаленных ссылок и удалены все локальные ссылки на объект, он становится кандидатом для сборщика мусора в обычном значении этого понятия. |
| Исключительные ситуации | Исключительные ситуации являются либо исключительными ситуациями времени исполнения, либо классом Exceptions. Компилятор Java заставляет программу обрабатывать все Exceptions. | RMI заставляет программу иметь дело с любыми возможными объектами RemoteException, которые могут генерироваться. Это сделано для гарантии устойчивости распределенных приложений. |
Архитектура JavaRMI
Целью разработки архитектуры RMI было создание распределенной объектной модели Java, которая свободно интегрируется в язык программирования Java и локальную объектную модель. Разработчики RMI достигли этой цели; была создана система, которая переносит безопасность и устойчивость архитектуры Java в мир распределенных вычислений.
Интерфейсы: основа RMI
Архитектура RMI основана на одном важном принципе: определение поведения и реализация этого поведения считаются разными понятиями. RMI дает возможность разделить и выполнить на разных JVM код, определяющий поведение, и код, реализующий поведение.
Это прекрасно соответствует требованиям распределенных систем, в которых клиенты знают об определениях служб, а серверы предоставляют эти службы.
Конкретно в RMI определение удаленной службы кодируется при помощи интерфейса Java. Реализация удаленной службы кодируется в классе. Таким образом, ключ к пониманию RMI– помнить, что интерфейсы определяют поведение, а классы определяют реализацию.
Следующий рисунок иллюстрирует это разделение:
Помните, что интерфейсы Java не содержат исполняемого кода. RMI поддерживает два класса, реализующих один и тот же интерфейс. Первый класс является реализацией поведения и исполняется на сервере. Второй класс работает как промежуточный интерфейс для удаленной службы и исполняется на клиентской машине. Это показано на следующей диаграмме. Клиентская программа вызывает методы прокси-объекта, RMI передает запрос на удаленную JVM и направляет его в реализацию объекта. Любые возвращаемые из реализации значения передаются назад в прокси-объект и затем в клиентскую программу.
Уровни архитектуры RMI
Рассмотрев высокоуровневую архитектуру RMI, взглянем на ее реализацию. Реализация RMI, по существу, состоит из трех абстрактных уровней. Первый – это уровень заглушки и скелета, расположенный непосредственно перед разработчиком. Этот уровень перехватывает вызовы методов, произведенные клиентом при помощи переменной-ссылки на интерфейс, и переадресует их в удаленную службу RMI.
Следующий уровень – уровень удаленной ссылки. Этот уровень понимает, как интерпретировать и управлять ссылками на удаленные объекты служб. В JDK 1.1 этот уровень соединяет клиентов с удаленными объектами служб, которые исполняются на сервере. Это соединение является связью типа один к одному (однонаправленное соединение). В Java 2 SDK этот уровень был расширен поддержкой активации пассивных удаленных объектов при помощи технологии RemoteObjectActivation.
Транспортный уровень основан на соединениях ТСР/IР между сетевыми машинами. Он обеспечивает основные возможности соединения и некоторые стратегии защиты от несанкционированного доступа.
При использовании уровневой архитектуры каждый из уровней может быть изменен или заменен без воздействия на остальную систему. Например, транспортный уровень может быть заменен протоколом UDP/IP без изменения остальных уровней.
Уровень заглушки и скелета
Уровень заглушки и скелета RMI расположен непосредственно перед разработчиком Java. На этом уровне RMI использует прокси-модель проектирования, которая описана в книге Gamma, Helm, Johnson и Vlissides «DesignPatterns». В прокси-модели объект одного контекста представляется другим (прокси-объектом) в отдельном контексте. Прокси-объект знает, как направлять вызовы методов между этими объектами. На следующей диаграмме классов показана прокси-модель.
В прокси-модели, используемой в RMI, роль прокси выполняет класс заглушки, а роль RealSubject выполняет класс, реализующий удаленную службу.
Скелет является вспомогательным классом, который создается для использования RMI. Скелет понимает, как взаимодействовать с заглушкой при RMI‑соединении. Скелет поддерживает общение с заглушкой; он читает параметры для вызова метода из соединения, производит вызов объекта, реализующего удаленную службу, принимает возвращаемое значение и записывает его обратно в заглушку.
В реализации RMIJava 2 SDK новый протокол связи сделал классы скелетов не нужными. RMI использует отражение для установления соединения с объектом удаленной службы. Вы должны использовать классы и объекты скелетов только в JDK 1.1 и совместимых с ним реализациях систем.