Целью разработки архитектуры RMI было создание распределенной объектной модели Java, которая свободно интегрируется в язык программирования Java и локальную объектную модель.
На основе использования интерфейсов было достигнуто разделения описания поведения (интерфейс) и реализации этого поведения (класс реализации, включающий реализацию созданного интерфейса и RMI позволяет разнести на разные ЭВМ JVM-коды , определяющие поведение (интерфейс пользователя) , и код , реализующий поведение (интерфейс реализующей программы). Такое разделение соответствую принятой практике, в которой клиенты знают об определениях служб, а серверы предоставляют эти службы. В RMI интерфейсы определяют поведение , а классы - реализацию(Рис. 2.).
RMI поддерживает два класса, реализующих один и тот же интерфейс:
первый реализует поведения и исполняется на сервере;
второй класс работает как промежуточный интерфейс для удаленной службы и исполняется на клиентской машине.
Реализация RMI, по существу, состоит из трех абстрактных уровней.
Первый –уровень заглушки и скелета, обслуживающий пользователя. Этот уровень перехватывает вызовы методов, произведенные клиентом при помощи переменной - ссылки на интерфейс, и переадресует их в удаленную службу RMI.
Второй уровень – уровень удаленной ссылки. Этот уровень понимает , как интерпретировать и управлять ссылками на удаленные объекты служб . В JDK 1.1 этот уровень соединяет клиентов с удаленными объектами служб , которые исполняются на сервере . Это соединение является связью типа один к одному (однонаправленное соединение ). В Java 2 SDK этот уровень был расширен поддержкой активации пассивных удаленных объектов при помощи технологии Remote Object Activation.
Третий - Транспортный уровень, основанный на соединениях TCP/IP между сетевыми машинами. Он обеспечивает основные возможности соединения и некоторые стратегии защиты от несанкционированного доступа. При использовании уровневой архитектуры каждый из уровней может быть изменен или заменен без воздействия на остальную систему. Например, транспортный уровень может быть заменен протоколом UDP/IP без изменения остальных уровней.
Реализуется прокси1 - модель проектирования, в которой модели объект одного контекста представляется другим (прокси - объектом ) в отдельном контексте . Прокси-объект знает , как организовать взаимодействия между этими объектами.
В прокси -модели , используемой в RMI, роль прокси выполняет класс заглушки, а роль RealSubject выполняет класс , реализующий удаленную службу . Скелет является вспомогательным классом , который создается для использования RMI. Скелет понимает, как взаимодействовать с заглушкой при RMI-соединении. Он читает параметры для вызова метода из соединения, производит вызов объекта, реализующего удаленную службу , принимает возвращаемое значение и записывает его обратно в заглушку .
В реализации RMI Java 2 SDK новый протокол связи сделал классы скелетов не нужными . RMI использует отражение для установления соединения с объектом удаленной службы. Вы должны использовать классы и объекты скелетов только в JDK 1.1 и совместимых с ним реализациях систем.
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.
