Факультет «Інформатика та системи управління»
Методичні вказівки до лабораторної роботи
за курсом «Розподілені системи обробки інформації»
"Віддалений виклик методів (RMI)"
Москва 2004
Мета роботи
Ознайомитися з RMI. Написати клієнт RMI і сервер RMI.
Що таке RMI?
Java RMI (Remote Method Invocation - віддалений виклик методів) представляє собою тип віддаленого виклику процедур, незалежний від мережі, полегшений і повністю стерпний, так як написаний на мові Java.
Основні кроки роботи з RMI:
1. Визначте (або знайдіть) віддалений інтерфейс, узгоджений з сервером.
2. Напишіть код сервера.
3. Запустіть програму rmic (Java RMI stub compiler - компілятор заглушок RMI) для генерації сполучного коду.
4. Напишіть код клієнта.
5. Переконайтеся, що на сервері запущено RMI реєстр (програма rmiregistry).
6. Запустіть сервер.
7. Запустіть одного або декількох клієнтів.
Процедури RMI визначають за допомогою відомого механізму Java - інтерфейсів. Дистанційні нтерфейси долдни бути підкласами java.rmi. Remote, при цьому і клієнт і сервер повинні знаходитися в одному пакеті Java. Всі параметри вилучених методів повинні відноситися або до примітивних типах (int, double і т.п.), або реалізовувати інтерфейс java.io. Serializable.
Введення в розподілені обчислення з використанням RMI
Технологія Remote Method Invocation (RMI), вперше представлена у JDK 1.1, просунула мережеве програмування на більш високий рівень. Хоча RMI відносно проста у використанні, вона є надзвичайно потужною технологією і розкриває перед звичайним Java-програмістом повністю нову парадигму - світ розподілених об'єктних обчислень.
Цей курс являє собою поглиблене введення в цю універсальну технологію. RMI отримала значний розвиток у JDK 1.1 і багато в чому була покращена в Java 2 SDK. При необхідності, відмінності між цими двома версіями будуть відзначені.
Цілі
Головною метою розробників RMI було надання можливості програмістам розробляти розподілені Java-програми, використовуючи такі ж синтаксис і семантику, як і при розробці звичайних нерозподілених програм. Для цього вони повинні були перетворити модель роботи класів і об'єктів в одній віртуальній машині Java ™ (JVM) у нову модель роботи класів і об'єктів в розподіленій (кілька JVM) обчислювальному середовищі.
Порівняння розподілених та нерозподілених Java-програм
Розробники RMI прагнули зробити використання розподілених Java-об'єктів таким же, як і використання локальних об'єктів. У наступній таблиці перераховані деякі важливі відмінності.
Не турбуйтеся про те, що не всі відмінності вам зрозумілі. Всі проясниться після розгляду архітектури RMI. Ви можете використовувати цю таблицю в якості посилання під час вивчення RMI.
Архітектура Java RMI
Метою розробки архітектури 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 цей рівень був розширений підтримкою активації пасивних віддалених об'єктів за допомогою технології Remote Object Activation.
Транспортний рівень заснований на з'єднаннях TCP / IP між мережевими машинами. Він забезпечує основні можливості з'єднання і деякі стратегії захисту від несанкціонованого доступу.
При використанні рівневої архітектури кожен з рівнів може бути змінений або замінений без впливу на решту системи. Наприклад, транспортний рівень може бути замінений протоколом UDP / IP без зміни інших рівнів.
Рівень заглушки і скелета
Рівень заглушки і скелета RMI розташований безпосередньо перед розробником Java. На цьому рівні RMI використовує проксі-модель проектування, яка описана в книзі Gamma, Helm, Johnson та Vlissides «Design Patterns». У проксі-моделі об'єкт одного контексту представляється іншим (проксі-об'єктом) в окремому контексті. Проксі-об'єкт знає, як направляти виклики методів між цими об'єктами. На наступній діаграмі класів показана проксі-модель.
У проксі-моделі, використовуваної в RMI, роль проксі виконує клас заглушки, а роль RealSub j ect виконує клас, який реалізує віддалену службу.
Скелет є допоміжним класом, який створюється для використання RMI. Скелет розуміє, як взаємодіяти з заглушкою при RMI-з'єднанні. Скелет підтримує спілкування з заглушкою; він читає параметри для виклику методу із з'єднання, виробляє виклик об'єкта, що реалізує віддалену службу, приймає значення, що повертається і записує його назад в заглушку.
У реалізації RMI Java 2 SDK новий протокол зв'язку зробив класи скелетів не потрібними. RMI використовує відображення для встановлення з'єднання з об'єктом віддаленої служби. Ви повинні використовувати класи та об'єкти скелетів тільки в JDK 1.1 і сумісних з ним реалізаціях систем.
Рівень віддалених посилань
Рівні віддалених посилань визначають і підтримують семантику викликів з'єднання RMI. Цей урове надає об'єкт RemoteRef, який забезпечує з'єднання з об'єктами, що реалізують видалені служби.
Об'єкти заглушки використовують метод invoke () в об'єкті RemoteRef для напрямку виклику методу. Об'єкт RemoteRef розуміє семантику виклику віддалених служб.
Реалізація RMI в JDK 1.1 забезпечує тільки один спосіб з'єднання клієнтів з реалізаціями віддалених служб: односпрямоване з'єднання типу точка-крапка. Перед тим, як клієнт зможе використовувати віддалену службу, екземпляр об'єкта, що реалізує її, повинен бути створений на сервері і експортований в систему RMI. (Якщо це основна служба, вона також повинна бути поіменована і зареєстрована в реєстрі RMI).
Реалізація RMI в Java 2 SDK додає нову семантику для з'єднання клієнт-сервер. У цій версії RMI підтримує здатні до активізації віддалені об'єкти. Коли здійснюється виклик методу проксі для такого об'єкта, RMI визначає, чи знаходиться об'єкт, який реалізує віддалену службу, в пасивному стані. Якщо так, то RMI створить екземпляр об'єкта і відновить його стан з дискового файлу. Як тільки об'єкт активізується в пам'яті, він починає вести себе так само, як і об'єкт, який реалізує віддалену службу JDK 1.1.
Доступні й інші типи семантики сполук. Наприклад, у випадку широкомовного з'єднання, один проксі-об'єкт може передати запит методу кільком реалізаціям одночасно і прийняти перший відповідь (це зменшує час відгуку і, можливо, підвищує доступність об'єкта). У майбутньому Sun можливо додасть додаткові типи семантики в RMI.
Транспортний рівень
Транспортний рівень здійснює з'єднання між різними JVM. Всі з'єднання представляють собою засновані на потоках мережеві з'єднання, що використовують TCP / IP.
Навіть якщо дві JVM працюють на одному і тому ж фізичному комп'ютері, вони з'єднуються через стек мережевих протоколів TCP / IP. (Ось чому ви повинні мати діючу конфігурацію TCP / IP на вашому
комп'ютері для виконання вправ цього курсу). На наступній діаграмі показані 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>
[: <name_service_port>] / <service_name>
де host_name - це ім'я, распознаваемое в локальній мережі (LAN), або DNS-ім'я в мережі Internet. Необхідно лише вказати name_service_port, якщо служба імен виповнюється на порту, відмінному від прийнятого за замовчуванням 1099.
Використання RMI
Зараз настав час створити робочу RMI-систему і отримати практичний досвід. Ви створите просту віддалену службу, що реалізовує калькулятор, і спробуєте використовувати її з клієнтської програми.
Робоча RMI-система складається з кількох частин.
• Визначення інтерфейсів для віддалених служб
• Реалізація віддалених служб
• Файли заглушки і скелета
• Сервер, що надає видалені служби
• Служба імен RMI, що дає можливість клієнтам знайти видалені служби
• Постачальник файлу класів (HTTP або FTP-сервер)
• Клієнтська програма, яка потребує віддалених службах
Для спрощення завдання ви будете використовувати один і той же каталог для коду як клієнта, так і сервера. При запуску клієнта і сервера з одного і того ж каталогу вам не доведеться налаштовувати HTTP або FTP сервери для доступу до файлів класів. (Використання серверів HTTP та FTP в якості постачальників файлів класів детально розглядається в розділі «Поширення та встановлення програмного забезпечення RMI»)
Якщо припустити, що RMI-система вже спроектована, для її створення необхідно виконати наступні кроки:
1. Написати і відкомпілювати Java-код для інтерфейсів
2. Написати і відкомпілювати Java-код для класів реалізації
3. Створити файли класів заглушки і скелета з класів реалізації
4. Написати Java-код програми хоста для віддаленого обслуговування
5. Розробити Java-код для клієнтської програми RMI
6. Встановити та запустити RMI-систему
1. Інтерфейси
Першим кроком є написання та компіляцію Java-коду для інтерфейсів служб.
Коли ви створюєте віддалений інтерфейс, ви повинні слідувати наступним правилам:
1. Віддалений інтерфейс повинен бути публічним - public (він не може мати «доступ на рівні пакету», так само він не може бути «дружнім»). В іншому випадку клієнти будуть отримувати помилку при спробі завантаження об'єкта, що реалізує віддалений інтерфейс.
2. Віддалений інтерфейс повинен розширювати інтерфейс java.rmi. Remote.
3. Кожен метод віддаленого інтерфейсу повинен оголошувати java.rmi. RemoteException у своїй пропозиції throws на додаток до будь-яких винятків, специфічним для програми.
4. Віддалений об'єкт, який передається як аргумент або повертається значення (або безпосередньо, або як до частини локального об'єкта), повинен бути оголошений як віддалений інтерфейс, а не реалізація класу.
Інтерфейс 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. Re bind (). Однак цей виклик вимагає, щоб реєстрація була запущена окремим процесом на вашому комп'ютері. Ім'я сервера реєстрації - це rmiregistry, і під 32-бітної Windows ви пишете:
Як і багато інших мережеві програми, 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));
}
catch (MalformedURLException murle) {
System.out.println ();
System.out.println (
«MalformedURLException»);
System.out.println (murle);
}
catch (RemoteException re) {
System.out.println ();
System.out.println (
«RemoteException»);
System.out.println (re);} catch (NotBoundException nbe) {
System.out.println ();
System.out.println (
«NotBoundException»); System.out.println (nbe);
} Catch (
java.lang. ArithmeticException
ae) {
System.out.println (); System.out.println (
«Java.lang. ArithmeticException »); System.out.println (ae);
6. Запуск RMI-системи
Тепер ви готові до запуску системи! Ви повинні запустити три консолі, одну для сервера, одну для клієнта і одну для реєстру RMI.
Почніть з реєстру. Ви повинні знаходитися в каталозі, в якому знаходяться написані вами класи. Напишіть наступне:
Rmiregistry
Якщо не спрацює, то в поточному каталозі наберіть повний шлях до файлу rmiregistry.exe, Він знаходиться в каталозі JAVA_HOME / bin /
Якщо все пройде добре, реєстр почне працювати, і ви можете перейти до наступної консолі.
У другій консолі запустіть сервер, що містить CalculatorService, і наберіть наступне:
> Java CalculatorServer
Програма запуститься, завантажить реалізацію в пам'ять і буде очікувати на з'єднання клієнта.
В останній консолі запустіть клієнтську програму.
> Java CalculatorClient
Якщо все пройде добре, ви побачите наступну інформацію:
1
9
18
3
Ось і все: ви створили працюючу систему RMI. Навіть якщо ви запустили три консолі на одному і тому ж комп'ютері, RMI використовує стек протоколів TCP / IP вашої мережі для взаємодії між трьома окремими JVM. Це цілком закінчена RMI-система.
2. Методичка з сайту JGURU.ru
3. Sun Java 2 SE API
Методичні вказівки до лабораторної роботи
за курсом «Розподілені системи обробки інформації»
"Віддалений виклик методів (RMI)"
Москва 2004
Мета роботи
Ознайомитися з RMI. Написати клієнт RMI і сервер RMI.
Що таке RMI?
Java RMI (Remote Method Invocation - віддалений виклик методів) представляє собою тип віддаленого виклику процедур, незалежний від мережі, полегшений і повністю стерпний, так як написаний на мові Java.
Основні кроки роботи з RMI:
1. Визначте (або знайдіть) віддалений інтерфейс, узгоджений з сервером.
2. Напишіть код сервера.
3. Запустіть програму rmic (Java RMI stub compiler - компілятор заглушок RMI) для генерації сполучного коду.
4. Напишіть код клієнта.
5. Переконайтеся, що на сервері запущено RMI реєстр (програма rmiregistry).
6. Запустіть сервер.
7. Запустіть одного або декількох клієнтів.
Процедури RMI визначають за допомогою відомого механізму Java - інтерфейсів. Дистанційні нтерфейси долдни бути підкласами java.rmi. Remote, при цьому і клієнт і сервер повинні знаходитися в одному пакеті Java. Всі параметри вилучених методів повинні відноситися або до примітивних типах (int, double і т.п.), або реалізовувати інтерфейс java.io. Serializable.
Введення в розподілені обчислення з використанням RMI
Технологія Remote Method Invocation (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, які можуть генеруватися. Це зроблено для гарантії стійкості розподілених додатків. |
Метою розробки архітектури 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 цей рівень був розширений підтримкою активації пасивних віддалених об'єктів за допомогою технології Remote Object Activation.
Транспортний рівень заснований на з'єднаннях TCP / IP між мережевими машинами. Він забезпечує основні можливості з'єднання і деякі стратегії захисту від несанкціонованого доступу.
При використанні рівневої архітектури кожен з рівнів може бути змінений або замінений без впливу на решту системи. Наприклад, транспортний рівень може бути замінений протоколом UDP / IP без зміни інших рівнів.
Рівень заглушки і скелета
Рівень заглушки і скелета RMI розташований безпосередньо перед розробником Java. На цьому рівні RMI використовує проксі-модель проектування, яка описана в книзі Gamma, Helm, Johnson та Vlissides «Design Patterns». У проксі-моделі об'єкт одного контексту представляється іншим (проксі-об'єктом) в окремому контексті. Проксі-об'єкт знає, як направляти виклики методів між цими об'єктами. На наступній діаграмі класів показана проксі-модель.
У проксі-моделі, використовуваної в RMI, роль проксі виконує клас заглушки, а роль RealSub j ect виконує клас, який реалізує віддалену службу.
Скелет є допоміжним класом, який створюється для використання RMI. Скелет розуміє, як взаємодіяти з заглушкою при RMI-з'єднанні. Скелет підтримує спілкування з заглушкою; він читає параметри для виклику методу із з'єднання, виробляє виклик об'єкта, що реалізує віддалену службу, приймає значення, що повертається і записує його назад в заглушку.
У реалізації RMI Java 2 SDK новий протокол зв'язку зробив класи скелетів не потрібними. RMI використовує відображення для встановлення з'єднання з об'єктом віддаленої служби. Ви повинні використовувати класи та об'єкти скелетів тільки в JDK 1.1 і сумісних з ним реалізаціях систем.
Рівень віддалених посилань
Рівні віддалених посилань визначають і підтримують семантику викликів з'єднання RMI. Цей урове надає об'єкт RemoteRef, який забезпечує з'єднання з об'єктами, що реалізують видалені служби.
Реалізація RMI в JDK 1.1 забезпечує тільки один спосіб з'єднання клієнтів з реалізаціями віддалених служб: односпрямоване з'єднання типу точка-крапка. Перед тим, як клієнт зможе використовувати віддалену службу, екземпляр об'єкта, що реалізує її, повинен бути створений на сервері і експортований в систему RMI. (Якщо це основна служба, вона також повинна бути поіменована і зареєстрована в реєстрі RMI).
Реалізація RMI в Java 2 SDK додає нову семантику для з'єднання клієнт-сервер. У цій версії RMI підтримує здатні до активізації віддалені об'єкти. Коли здійснюється виклик методу проксі для такого об'єкта, RMI визначає, чи знаходиться об'єкт, який реалізує віддалену службу, в пасивному стані. Якщо так, то RMI створить екземпляр об'єкта і відновить його стан з дискового файлу. Як тільки об'єкт активізується в пам'яті, він починає вести себе так само, як і об'єкт, який реалізує віддалену службу JDK 1.1.
Доступні й інші типи семантики сполук. Наприклад, у випадку широкомовного з'єднання, один проксі-об'єкт може передати запит методу кільком реалізаціям одночасно і прийняти перший відповідь (це зменшує час відгуку і, можливо, підвищує доступність об'єкта). У майбутньому Sun можливо додасть додаткові типи семантики в RMI.
Транспортний рівень
Транспортний рівень здійснює з'єднання між різними JVM. Всі з'єднання представляють собою засновані на потоках мережеві з'єднання, що використовують TCP / IP.
Навіть якщо дві JVM працюють на одному і тому ж фізичному комп'ютері, вони з'єднуються через стек мережевих протоколів TCP / IP. (Ось чому ви повинні мати діючу конфігурацію TCP / IP на вашому
комп'ютері для виконання вправ цього курсу). На наступній діаграмі показані 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>
[: <name_service_port>] / <service_name>
де host_name - це ім'я, распознаваемое в локальній мережі (LAN), або DNS-ім'я в мережі Internet. Необхідно лише вказати name_service_port, якщо служба імен виповнюється на порту, відмінному від прийнятого за замовчуванням 1099.
Використання RMI
Зараз настав час створити робочу RMI-систему і отримати практичний досвід. Ви створите просту віддалену службу, що реалізовує калькулятор, і спробуєте використовувати її з клієнтської програми.
Робоча RMI-система складається з кількох частин.
• Визначення інтерфейсів для віддалених служб
• Реалізація віддалених служб
• Файли заглушки і скелета
• Сервер, що надає видалені служби
• Служба імен RMI, що дає можливість клієнтам знайти видалені служби
• Постачальник файлу класів (HTTP або FTP-сервер)
• Клієнтська програма, яка потребує віддалених службах
Для спрощення завдання ви будете використовувати один і той же каталог для коду як клієнта, так і сервера. При запуску клієнта і сервера з одного і того ж каталогу вам не доведеться налаштовувати HTTP або FTP сервери для доступу до файлів класів. (Використання серверів HTTP та FTP в якості постачальників файлів класів детально розглядається в розділі «Поширення та встановлення програмного забезпечення RMI»)
Якщо припустити, що RMI-система вже спроектована, для її створення необхідно виконати наступні кроки:
1. Написати і відкомпілювати Java-код для інтерфейсів
2. Написати і відкомпілювати Java-код для класів реалізації
3. Створити файли класів заглушки і скелета з класів реалізації
4. Написати Java-код програми хоста для віддаленого обслуговування
5. Розробити Java-код для клієнтської програми RMI
6. Встановити та запустити RMI-систему
1. Інтерфейси
Першим кроком є написання та компіляцію Java-коду для інтерфейсів служб.
Коли ви створюєте віддалений інтерфейс, ви повинні слідувати наступним правилам:
1. Віддалений інтерфейс повинен бути публічним - public (він не може мати «доступ на рівні пакету», так само він не може бути «дружнім»). В іншому випадку клієнти будуть отримувати помилку при спробі завантаження об'єкта, що реалізує віддалений інтерфейс.
2. Віддалений інтерфейс повинен розширювати інтерфейс java.rmi. Remote.
3. Кожен метод віддаленого інтерфейсу повинен оголошувати java.rmi. RemoteException у своїй пропозиції throws на додаток до будь-яких винятків, специфічним для програми.
4. Віддалений об'єкт, який передається як аргумент або повертається значення (або безпосередньо, або як до частини локального об'єкта), повинен бути оголошений як віддалений інтерфейс, а не реалізація класу.
Інтерфейс 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. Re bind (). Однак цей виклик вимагає, щоб реєстрація була запущена окремим процесом на вашому комп'ютері. Ім'я сервера реєстрації - це 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));
}
catch (MalformedURLException murle) {
System.out.println ();
System.out.println (
«MalformedURLException»);
System.out.println (murle);
}
catch (RemoteException re) {
System.out.println ();
System.out.println (
«RemoteException»);
System.out.println (re);} catch (NotBoundException nbe) {
System.out.println ();
System.out.println (
«NotBoundException»); System.out.println (nbe);
} Catch (
java.lang. ArithmeticException
ae) {
System.out.println (); System.out.println (
«Java.lang. ArithmeticException »); System.out.println (ae);
6. Запуск RMI-системи
Тепер ви готові до запуску системи! Ви повинні запустити три консолі, одну для сервера, одну для клієнта і одну для реєстру RMI.
Почніть з реєстру. Ви повинні знаходитися в каталозі, в якому знаходяться написані вами класи. Напишіть наступне:
Rmiregistry
Якщо не спрацює, то в поточному каталозі наберіть повний шлях до файлу rmiregistry.exe, Він знаходиться в каталозі JAVA_HOME / bin /
Якщо все пройде добре, реєстр почне працювати, і ви можете перейти до наступної консолі.
У другій консолі запустіть сервер, що містить CalculatorService, і наберіть наступне:
> Java CalculatorServer
Програма запуститься, завантажить реалізацію в пам'ять і буде очікувати на з'єднання клієнта.
В останній консолі запустіть клієнтську програму.
> Java CalculatorClient
Якщо все пройде добре, ви побачите наступну інформацію:
1
9
18
3
Ось і все: ви створили працюючу систему RMI. Навіть якщо ви запустили три консолі на одному і тому ж комп'ютері, RMI використовує стек протоколів TCP / IP вашої мережі для взаємодії між трьома окремими JVM. Це цілком закінчена RMI-система.
Література
1. Серія «Бібліотека професіонала» К. Хорстманн Г. Корнелл «Java 2. том 2 «Тонкощі програмування» »« Видавництво Вільямс »2002 р.2. Методичка з сайту JGURU.ru
3. Sun Java 2 SE API