49294 (566572), страница 2
Текст из файла (страница 2)
компьютере для выполнения упражнений этого курса). На следующей диаграмме показаны TCP/IP соединения между разными JVM. Транспортный уровень RMI был разработан для осуществления соединения между клиентами и сервером даже с учетом сетевых помех.
Хотя транспортный уровень предпочитает использовать несколько ТСР/IР соединений, некоторые сетевые конфигурации разрешают только одно TCP/IP‑соединение между клиентом и сервером (некоторые броузеры ограничивают апплеты одним сетевым соединением с их сервером).
В этом случае, транспортный уровень распределяет несколько виртуальных соединений внутри одного TCP/IP‑соединения.
Именование удаленных объектов
При рассмотрении архитектуры RMI постоянно откладывался один вопрос: «Как клиент находит удаленную службу RMI?» Сейчас вы получите ответ на этот вопрос. Клиенты находят удаленные службы, используя службу имен или каталогов. Это может показаться хождением по кругу. Как клиент может найти службу, используя службу? И это действительно так. Служба имен или каталогов исполняется на хорошо известном хосте и имеет известный номер порта. (Хорошо известный означает, что все в организации знают об этом).
RMI может использовать много различных служб каталогов, включая Java Naming and Directory Interface (JNDI). RMI и сама включает в себя простую службу, называемую реестром RMI, rmiregistry. Реестр RMI работает на каждой машине, содержащей объекты удаленных служб и принимающей запросы на обслуживание, по умолчанию используя порт 1099.
На хосте программа сервера создает удаленную службу, предварительно создавая локальный объект, реализующий эту службу. Затем она экспортирует этот объект в RMI. Как только объект экспортирован, RMI создает службу прослушивания, ожидающую соединения с клиентом и запроса службы. После экспорта, сервер регистрирует объект в реестре RMI, используя общедоступное имя.
На стороне клиента к реестру RMI доступ обеспечивается через статический класс Naming. Он предоставляет метод lookup(), который клиент использует для запросов к реестру. Метод lookup() принимает URL, указывающий на имя хоста и имя требуемой службы. Метод возвращает удаленную ссылку на обслуживающий объект. URL принимает следующий вид:
rmi://
[:] /
где host_name – это имя, распознаваемое в локальной сети (LAN), или DNS‑имя в сети Internet. Необходимо только указать name_service_port, если служба имен исполняется на порте, отличном от принимаемого по умолчанию 1099.
Использование RMI
Сейчас наступило время создать рабочую RMI‑систему и получить практический опыт. Вы создадите простую удаленную службу, реализующую калькулятор, и попробуете использовать ее из клиентской программы.
Рабочая RMI‑система состоит из нескольких частей.
-
Определение интерфейсов для удаленных служб
-
Реализация удаленных служб
-
Файлы заглушки и скелета
-
Сервер, предоставляющий удаленные службы
-
Служба имен RMI, дающая возможность клиентам найти удаленные службы
-
Поставщик файла классов (HTTP или FTP‑сервер)
-
Клиентская программа, которая нуждается в удаленных службах
Для упрощения задачи вы будете использовать один и тот же каталог для кода как клиента, так и сервера. При запуске клиента и сервера из одного и того же каталога вам не придется настраивать HTTP или FTP серверы для доступа к файлам классов. (Использование серверов HTTP и FTP в качестве поставщиков файлов классов детально рассматривается в разделе «Распространение и установка программного обеспечения RMI »)
Если предположить, что RMI‑система уже спроектирована, для ее создания необходимо выполнить следующие шаги:
-
Написать и откомпилировать Java‑код для интерфейсов
-
Написать и откомпилировать Java‑код для классов реализации
-
Создать файлы классов заглушки и скелета из классов реализации
-
Написать Java‑код программы хоста для удаленного обслуживания
-
Разработать Java‑код для клиентской программы RMI
-
Установить и запустить RMI‑систему
1. Интерфейсы
Первым шагом является написание и компилирование Java‑кода для интерфейсов служб.
Когда вы создаете удаленный интерфейс, вы должны следовать следующим правилам:
-
Удаленный интерфейс должен быть публичным – public (он не может иметь «доступ на уровне пакета», так же он не может быть «дружественным»). В противном случае клиенты будут получать ошибку при попытке загрузки объекта, реализующего удаленный интерфейс.
-
Удаленный интерфейс должен расширять интерфейс java.rmi. Remote.
-
Каждый метод удаленного интерфейса должен объявлять java.rmi. RemoteException в своем предложении throws в добавок к любым исключениям, специфичным для приложения.
-
Удаленный объект, передаваемый как аргумент или возвращаемое значение (либо напрямую, либо как к части локального объекта), должен быть объявлен как удаленный интерфейс, а не реализация класса.
Интерфейс Calculator определяет все удаленные возможности, предлагаемые службой:
public interface Calculator
extends java.rmi. Remote {public long add (long a, long b)
throws j ava.rmi. RemoteException;
public long sub (long a, long b)
throws j ava.rmi. RemoteException;
public long mul (long a, long b)
throws j ava.rmi. RemoteException;
public long div (long a, long b)
throws j ava.rmi. RemoteException;
Скопируйте этот файл в ваш каталог и откомпилируйте его при помощи компилятора Java:
>javac Calculator.java
2. Реализация
Теперь вы пишете реализацию удаленной службы. Ниже приведен класс CalculatorImpl:
public class CalculatorImpl extends
java.rmi.server. UnicastRemoteObj ect implements Calculator {
// Реализации должны иметь
// явный конструктор для
// того, чтобы объявить
// исключительную ситуацию RemoteException
public CalculatorImpl()
throws java.rmi. RemoteException {
super ();
public long add (long a, long b)
throws java.rmi. RemoteException {return a + b;
public long sub (long a, long b)
throws java.rmi. RemoteException {return a – b;
public long mul (long a, long b)
throws java.rmi. RemoteException {return a * b;
public long div (long a, long b)
throws java.rmi. RemoteException {
return a / b;
}
И опять, скопируйте этот код в ваш каталог и откомпилируйте его.
Класс реализации использует UnicastRemoteOb j ect для присоединения к системе RMI. В данном примере класс реализации непосредственно расширяет UnicastRemoteOb j ect. Это не является обязательным требованием. Класс, не расширяющий UnicastRemoteObj ect, может использовать свой метод exportOb j ect () для присоединения к RMI.
Если класс расширяет UnicastRemoteObj ect, он должен обеспечить конструктор, объявляющий, что он может сгенерировать объект RemoteException. Если этот конструктор вызывает метод super (), он активизирует код в UnicastRemoteObj ect, который выполняет RMI‑соединение и инициализацию удаленного объекта.
3. Заглушки и скелеты
Дальше вы используете компилятор RMI, rmic, для генерации файлов заглушки и скелета. Компилятор запускается с указанием файла класса, реализующего удаленную службу.
>rmic CalculatorImpl
Попробуйте выполнить это в вашем каталоге. После запуска rmic вы должны найти файл Calculator_Stub. class.
4. Хост-сервер
Удаленные службы RMI должны быть помещены в процесс сервера. Класс CalculatorServer является очень простым сервером, предоставляющим простые элементы для размещения.
import java.rmi. Naming;
public class CalculatorServer {
public CalculatorServer () {try {
Calculator c = new CalculatorImpl();
Naming.rebind (»
rmi://localhost:1099/
CalculatorService», c);} catch (Exception e) {
System.out.println («Trouble:» + e);
public static void main (String args[]) {new CalculatorServer();
В этом примере вы видите вызов статического метода Naming.rebind(). Однако этот вызов требует, чтобы регистрация была запущена отдельным процессом на вашем компьютере. Имя сервера регистрации – это rmiregistry, и под 32‑битной Windows вы пишете:
start rmiregistry
для запуска в фоновом режиме.
Как и многие другие сетевые программы, rmiregistry обращается по IP адресу машины, на которой она установлена, но она также слушает порт. Если вы вызовите rmiregistry как показано выше, без аргументов, будет использован порт по умолчанию 1099. Если вы хотите использовать другой порт, вы добавляете аргумент в командную строку, указывающий порт. Следующий пример устанавливает порт 2005, так что rmiregistry под управлением 32-битной Windows должна запускаться так:
start rmiregistry 2005
Информация о порте также должна передаваться в команде bind(), наряду с IP адресом машины, где располагается регистрация. Но это может выявить проблему, если вы хотите проверять RMI программы локально. В выпуске JDK 1.1.1, есть целая связка проблем:
1) localhost не работает с RMI. Поэтому для экспериментов с RMI на одной машине вы должны использовать имя машины. Чтобы найти имя вашей машины под управлением 32‑битной Windows, перейдите в панель управления и выберите «Network». Выберите закладку «Identification», и посмотрите имя вашего компьютера. Регистр в имени игнорируется. (Пример имени: «peppy»)
2) RMI не работает, пока ваш компьютер имеет активные TCP/IP соединения, даже если все ваши компоненты просто общаются друг с другом на локальной машине. Это значит, что вы должны соединятся с вашим провайдером Internet до того, как попробуете запустить программу или будете огорчены неким сообщением об ошибке.
Если учесть все это, команда bind() принимает вид:
Naming.bind (« //peppy:2005/CalculatorService», с);
Если вы используете порт по умолчанию 1099, вам не нужно указывать порт, так что вы можете просто сказать:
Naming.bind (« //peppy/CalculatorService», с);
Вы можете выполнить локальную проверку, оставив в покое IP адрес, а использовать только идентификатор:
Naming.bind («CalculatorService», с);
Имя сервиса здесь произвольно. В данном случае CalculatorService выбрано просто как имя класса, но вы можете назвать так, как захотите. Важно, чтобы это было уникальное имя регистрации, чтобы клиент знал, когда будет искать, что производит удаленные объекты. Если имя уже зарегистрировано, вы получите AlreadyBoundException. Чтобы предотвратить это, вы всегда можете использовать rebind() вместо bind(), так как rebind() либо добавляет новый элемент, либо заменяет уже существующий.
Даже после завершения работы main(), ваш объект будет оставаться созданным и зарегистрированным, ожидая, что придет клиент и выполнит запрос. Пока rmiregistry остается запущенным, и вы не вызовите Naming.unbind() на вашей машине, объект будет оставаться там. По этой причине, когда вы разрабатываете ваш код, вам необходимо выгружать rmiregistry и перезапускать его, когда скомпилируете новую версию вашего удаленного объекта.
Вам не обязательно запускать rmiregistry как внешний процесс. Если вы знаете, что только ваше приложение использует регистрацию, вы можете загрузить ее внутри вашей программы с помощью строки:
LocateRegistry.createRegistry(2005);
Как и раньше, 2005 – это номер порта, который мы использовали в этом примере. Это эквивалентно запуску rmiregistry 2005 из командной строки, но часто этот способ является более подходящим при разработке RMI кода, так как это снжает число необходимых действий при запуске и остановке регистрации После того, как вы выполните этот код, вы можете вызвать bind(), используя Naming, как и ранее.
5. Клиент
Исходный код клиента следующий:
import java.rmi. Naming;•
import java.rmi. RemoteException;
import java.net. MalformedURLException;
import java.rmi. NotBoundException;
public class CalculatorClient {
public static void main (String[] args) {try {
Calculator c = (Calculator)
Naming.lookup («rmi://remotehost
/CalculatorService»); System.out.println (c.sub (4, 3)); System.out.println (c.add (4, 5)); System.out.println (c.mul (3, 6)); System.out.println (c.div (9, 3));
}











