Целью разработки архитектуры RMI было создание распределенной объектной модели Java, которая свободно интегрируется в язык программирования Java и локальную объектную модель. Разработчики RMI достигли этой цели; была создана система, которая переносит безопасность и устойчивость архитектуры Java в мир распределенных вычислений.
Архитектура RMI основана на одном важном принципе: RMI дает возможность разделить и выполнить на разных JVM код, определяющий поведение, и код, реализующий поведение.
Конкретно в RMI определение удаленной службы кодируется при помощи интерфейса Java. Реализация удаленной службы кодируется в классе. Таким образом, ключ к пониманию RMI - помнить, что интерфейсы определяют поведение, а классы определяют реализацию.
RMI поддерживает два класса, реализующих один и тот же интерфейс. Первый класс является реализацией поведения и исполняется на сервере. Второй класс работает как промежуточный интерфейс для удаленной службы и исполняется на клиентской машине. Это показано на следующей диаграмме:
Клиентская программа вызывает методы прокси-объекта, RMI передает запрос на удаленную JVM и направляет его в реализацию объекта. Любые возвращаемые из реализации значения передаются назад в прокси-объект и затем в клиентскую программу.
Первый - это уровень заглушки и скелета, расположенный непосредственно перед разработчиком. Этот уровень перехватывает вызовы методов, произведенные клиентом при помощи переменной-ссылки на интерфейс, и переадресует их в удаленную службу RMI.
Второй - уровень удаленной ссылки. Этот уровень понимает, как интерпретировать и управлять ссылками на удаленные объекты служб. В JDK 1.1 этот уровень соединяет клиентов с удаленными объектами служб, которые исполняются на сервере. Это соединение является связью типа один к одному (однонаправленное соединение). В Java 2 SDK этот уровень был расширен поддержкой активации пассивных удаленных объектов при помощи технологии Remote Object Activation.
Третий(Транспортный уровень) - основан на соединениях TCP/IP между сетевыми машинами. Он обеспечивает основные возможности соединения и некоторые стратегии защиты от несанкционированного доступа.
При использовании уровневой архитектуры каждый из уровней может быть изменен или заменен без воздействия на остальную систему. Например, транспортный уровень может быть заменен протоколом UDP/IP без изменения остальных уровней.
Уровень заглушки и скелета RMI расположен непосредственно перед разработчиком Java. На этом уровне RMI использует прокси-модель проектирования. В прокси-модель объект одного контекста представляется другим (прокси-объектом) в отдельном контексте. Прокси-объект знает, как направлять вызовы методов между этими объектами.
Заглушка – это Java объект, который постоянно находится на машине клиента Функции заглушки – представление тех же интерфейсов, что и на удаленном сервере. Заглушка работает с другими частями RMI- системы для формулировки запроса, который посылается удалённой машине.
Скелет является вспомогательным классом, который создается для использования 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 соединения между разными JVM.
Как вы знаете, протокол TCP/IP обеспечивает постоянное, основанное на потоках, соединение между двумя машинами. Этот соединение основано на адресе IP и номере порта. В текущей реализации RMI соединения TCP/IP используются как основа для всех межмашинных соединений.
На вершине TCP/IP RMI использует протокол уровня соединения, называемый Java Remote Method Protocol (JRMP). JRMP является частным, основанным на потоках, протоколом, который только частично специфицирован в настоящее время в двух версиях. Первая версия была выпущена в реализации RMI в JDK 1.1 и требовала использования классов скелетов на сервере. Вторая версия была выпущена с Java 2 SDK. Она была оптимизирована по производительности и не требовала использования скелетных классов
Транспортный уровень RMI был разработан для осуществления соединения между клиентами и сервером даже с учетом сетевых помех. Хотя транспортный уровень предпочитает использовать несколько TCP/IP соединений, некоторые сетевые конфигурации разрешают только одно TCP/IP-соединение между клиентом и сервером (некоторые броузеры ограничивают апплеты одним сетевым соединением с их сервером). В этом случае, транспортный уровень распределяет несколько виртуальных соединений внутри одного TCP/IP-соединения.
При рассмотрении архитектуры RMI постоянно возникает вопрос: "Как клиент находит удаленную службу RMI?". Клиенты находят удаленные службы, используя службу имен или каталогов. Это может показаться хождением по кругу. Как клиент может найти службу, используя службу? И это действительно так. Служба имен или каталогов исполняется на хорошо известном хосте и имеет известный номер порта. (Хорошо известный означает, что все в организации знают об этом).
Основная деталь - rmiregistry rmiregistry (реестр RMI) (реестр RMI).
Реестр RMI работает на каждой машине, содержащей объекты удаленных служб и
принимающей запросы на обслуживание, по умолчанию используя порт 1099.
- Сервер на хосте создаёт удалённую службу, создавая локальный объект, который реализует эту службу.
- Сервер экспортирует объект в RMI.
- Сервер экспортирует объект в RMI.
- RMI создает службу прослушивания, ожидающую соединения с клиентом и - запроса службы
- Сервер регистрирует объект в rmiregistry используя общедоступное имя.
- Доступ к реестру RMI осуществляется статическим классом java.rmi.Naming, методом lookup
- lookup() принимает URL, указывающий на имя хоста и имя требуемой службы
Необходимо только указать name_service_port, если служба имен исполняется на порте, отличном от принимаемого по умолчанию 1099.
Приложение с распределёнными Приложение объектами должно:
- Найти удалённый объект
- Соединиться с ним
- Загрузить байткод этого объекта
Сервер вызывает реестр чтобы ассоциировать (или связать) имя с удалённым объектом. Клиент ищет удалённый объект по имени в реестре сервера и затем вызывает метод на нём. Иллюстрация также показывает, что RMI система использует существующий Web сервер чтобы загрузить байткоды классов (от сервера к клиенту и от клиента к серверу) для объектов когда это необходимо.