В этом примере вы видите вызов статического метода Naming.bind( ). Однако, этот вызов требует, чтобы репозиторий был запущен как отдельный процесс на компьютере. Имя сервера репозитория rmiregistry, в 32-х системе Windows вы используете команду:

для запуска его в фоновом режиме. Для системы Unix используется команда:

Как и многие сетевые программы, rmiregestry получает IP адрес той машины, на которой она запущена, но она также должна слушать порт. Если вы вызовите rmiregestry как это показано выше, без аргументов, для репозитория будет использован порт по умолчанию 1099. Если вы хотите, чтобы репозиторий был на другом порту, вы добавляете аргумент в командную строку, который указывает порт. Например, интересующий порт 2005, так что rmiregestry должна быть запущена следующей командой под 32-х битной Windows:

или для Unix:

Информация о номере порта также должна быть передана в команду bind( ), точно так же, как и IP адрес машины, где расположен репозиторий. Но таким образом мы получаем препятствие, если вы хотите запустить RMI программу локально, способ тестирования сетевых программ был указан в этой главе. В JDK 1.1.1 существует пара проблем:[2]

Учитывая все вышесказанное, команда bind( ) принимает вид:

Если вы используете порт по умолчанию 1099, вам не нужно указывать порт, так что вы можете написать:

Вы должны быть способны выполнить локальное тестирование оставив в покое IP адрес и используя только идентификатор:

Имя службы произвольно, в данном случае это PerfectTime, что совпадает с именем класса, но вы можете использовать любое название, какое хотите. Важно то, что оно должно быть уникальным в известном клиенту репозитории, к которому он обращается для производства удаленного объекта. Если имя уже есть в репозитории, вы получите AlreadyBoundException. Чтобы предотвратить это, вы можете всегда использовать rebind( ) вместе bind( ), так как rebind( ) либо добавляет новую запись, либо заменяет уже существующую.

Даже после того, как main( ) завершит работу, ваш объект будет создан и зарегистрирован, так что он останентся жить в репозитории, ожидая прихода клиентов и запросов от них. До тех пор, пока работает rmiregistry и вы не вызвали метод Naming.unbind( ) с вашим именем, объект будет существовать. По этой причине, когда вы разрабатываете ваш код, вам необходимо выгружать rmiregistry и перезапускать его, когда вы скомпилировали новую версию вашего удаленного объекта.

Вам не нужно принудительно запускать rmiregistry, как внешний процесс. Если вы знаете, что ваше приложение является единственным, использующим репозиторий, вы можете запускать его внутри программы с помощью строки:

Как и прежде, 2005 - это номер порта, который мы будем использовать в этом примере. Это эквивалентно запуску rmiregistry 2005 из командной строки, но такой запуск часто будет более последовательным, когда вы разрабатываете RMI код, так как при этом пропускаются дополнительные шаги запуска и остановки репозитория. Как только вы выполните этот код, вы можете вызвать bind( ), используя Naming, как и прежде.

Создание заглушек и скелетов

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

То, что происходит за сценой достаточно сложно. Любые объекты, котоые вы передаете при вызове или получаете от удаленного объекта должны реализовывать Serializable (если вы хотите передавать удаленную ссылку вместо самого объекта, объектные аргументы могут реализовывать Remote), так что вы можете представить, что заглушки и скелеты автоматически выполняют сериализацию и десериализацию, как будтно они "руководят" всеми аргументами через сеть и возвращают результат. К счастью, вам не нужно знать ничего этого, но вы должны создать заглушки и скелеты. Это простой процесс: вы вызываете инструмент rmic для вашего скомпилированного кода и создаете необходимые файлы. Таким образом требуется просто добавить еще один шаг в процесс компиляции.

Однако, инструмент rmic привередлив к пакетам и classpaths. PerfectTime.java расположен в пакете c15.rmi, и если вы вызовите rmic в том же директории, в котором расположен PerfectTime.class, rmic не найдет файл, так как он ищет в переменной classpath. Таким образом вы должны указать расположение в переменной classpath, например так:

Вам не нужно находиться в директории, содержащем PerfectTime.class, когда вы запускаете эту команду, а результат будет помещено в текущий каталог.

Когда запуск rmic завершится успешно, вы получите два новых класс в директории:

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

Использование удаленного объекта

Главная цель RMI состоит в упрощении использования удаленных объектов. Есть только одна дополнительная вещь, которую вы должны выполнить в клиентской программе, это найти и получить удаленный интерфейс с сервера. Все остальное - это обычное Java программирование: посылка сообщений объекту. Вот программа, которая использует PerfectTime:

Строка идентификатора точно такая же, как и используемая для регистрации объекта с помощью Naming, а первая часть представляет URL и номер порта. Так как вы используете URL, вы можете также указать машину в Internet'е.

То, что приходит от Naming.lookup( ) должно быть приведено к удаленному интерфейсу, а не к классу. Если вместо этого вы будете использовать класс, вы получите исключение.

Вы можете видеть вызов метода

так как то, что вы имеете - это ссылка на удаленный объект, программирование с которой не отличается от программирования с локальным объектом (с одним отличием: удаленные методы выбрасывают RemoteException).

←

Удаленный вызов методов (RMI)

Соединение с базой данных

→