Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПОКС.doc
Скачиваний:
13
Добавлен:
04.12.2018
Размер:
536.58 Кб
Скачать

28. Схема работы по протоколу rmi.

RMI

1. Вызов статического метода grid::bind() дает задание брокеру запросов найти нужный объект в системе. 2. Брокер находит объект в репозитории и получает оттуда путь к исполняемому файлу. В Orbix может быть также использован сервис локации, позволяющий узнать, на каком хосте сети расположен нужный объект. По полученному имени файла ORB запускает сервер. 3. Сервер при старте создает экземпляры всех объектов, включая объект grid из класса grid_i. Как показывалось, класса grid_i косвенно наследует класс CORBA::Object, чей конструктор вызывает метод BOA::create(), давая на вход уникальный идентификатор, и получая объектную ссылку. Затем объектная ссылка регистрируется в брокере запросов вызовом obj_is_ready(). 4. Конструктор класса grid_i создает экземпляр объекта суррогата. 5. Брокер запросов возвращает объектную ссылку клиенту, где создается клиентский суррогат объекта и регистрируется в таблице объектов суррогатов с соответствующей объектной ссылкой. 6. Клиент получает объектную ссылку как указатель на объект суррогат - gridVar.

1.Клиент вызывает метод сервиса имен lookup() для получения ссылки на удаленный объект. Сервис имен обращается к процессу registry. По заданному имени объекта registry находит ссылку, если объект не активен, запускает соответствующий сервер. 2. При старте сервера создается экземпляр объекта RMISecurityManager, позволяющий загрузку нелокальных Java классов. 3. Создается объект класса gridImpl, реализующего интерфейсы grid, grid2. Поскольку этот объект наследует класс UnicastRemoteObject, вызывается конструктор класса родителя, который и создает и экспортирует в сеть удаленный объект. Он создает экземпляр объекта-суррогата. 4. Объект может быть перерегистрирован в сервисе имен (registry) - вызовом метода rebind(). 5. Процесс registry возвращает в метод lookup ссылку на зарегистрированный объект. 6. В адресное пространство клиента передаются классы клиентского суррогата и создается экземпляр вспомогательного объекта. 7. Клиентский суррогат имеет то же множество методов, что и реальный объект. Вызов этих методов осуществляет маршализацию запроса. Клиент получает объектную ссылку obj на объект-суррогат в результате работы метода lookup().

7. При вызове метода gridVar->get() вызываеся соответствующий метод объекта-суррогата. Суррогат создает псевдо-объект Request, упаковывает параметры в этот объект и вызывает метод Request::invoke(). Этот метод передает запрос в коммуникационный канал посредством вызова метода CORBA::Request::send(). Далее объект вызывает метод CORBA::Request::get_response() и ждет ответа от сервера. 8. При получении сервером сообщения с запросом, управление передается базовому объектному адаптеру (БОА). БОА находит нужный суррогат серверного объекта и передает ему запрос. 9. Суррогат распаковывает параметры из полученного объекта Request, по имени метода находит нужный метод реального объекта и вызывает его. Затем суррогат получает возвращаемое значение, упаковывает его и завершает работу. БОА формирует сообщение и кладет его передаваемый буфер. 10. Буфер передается клиенту и считывается методом CORBA::Request::get_response(), ожидающим ответа. Сообщение считывается из буфера и обрабатывается суррогатом, распаковывающим возвращаемые значения, исключительные ситуации. Результат передается в метод gridVar->get(). 11. Вызов метода gridVar->reset() производится по аналогичной схеме.

1.Вызов метода obj.get() есть вызов метода клиентского объекта-суррогата. Суррогат содержит ссылку на интерфейс RemoreRef, который отвечает за обработку запроса к удаленному объекту. Вызывается метод newCall, описанный в этом интерфейсе, с указанием номера вызываемой операции, и хэш кода, идентифицирующего удаленный объект. Метод newCall упаковывает параметры запроса в объект, реализующий интерфейс RemoteCall. 2. Вызывается метод invoke(), передающий RemoteCall на транспортный уровень. invoke() ожидает отработки удаленного метода и возвращаемых параметров. Из сообщения запроса формируется поток. 3. Поток передается серверу, где из сообщения формируется тот же объект RemoteCall. Он передается в суррогат объекта, где обрабатывается методом dispatch(). 4. Суррогат находит по хэш-коду нужный реальный объект, по номеру - вызываемый метод, распаковывает параметры из RemoteCall и вызывает реальный метод get() объекта. dispatch() ожидает завершения работы метода. 5. Возвращаемые параметры упаковываются обратно в RemoteCall, который передается на транспортный уровень и затем клиенту. 6. Потоковое сообщение, полученное транспортным уровнем клиента, расшифровывается и возвращается в ожидающий ответа метод invoke(). Суррогат объекта, получив возвращаемые параметры в RemoteCall, распаковывает их и передает в метод get(). 7. Создается ссылка на интерфейс grid2 явным преобразованием типов из ссылки на grid. Ссылка остается на тот же реальный объект-суррогат, но видимые методы теперь те, которые определены в интерфейсе grid2. 8. Вызов метода obj2.reset() производится по аналогичной технологии.

Таблица 9.

CORBA

RMI

1. Вызов метода bind() обращается к брокеру запросов для получения объектной ссылки. Управление передается сначала брокеру, работающему на стороне клиента. Он запрашивает сервис локации (конфигурационный файл), по которому определяется местонахождение удаленного объекта. Соответствующий запрос отправляется серверному брокеру запросов по TCP/IP. 2. В момент старта сервера создается объект grid и, как показывалось, вызываются конструктор CORBA::Object, а затем метод BOA::create(). BOA создает сетевой сокет, объекту grid присваивается идентификатор, создается объектная ссылка. Если взаимодействие происходит по протоколу IIOP, то объектная ссылка имеет вид Interoperable Object Reference (IOR). Эта ссылка содержит имя хоста, TCP/IP-порт, код объекта в сервере. BOA регистрирует ссылку для брокера запросов. 3. Когда ссылка передается клиенту (в результате работы метода bind()), суррогат объекта получает адрес получателя и устанавливает сетевое соединение на основе сокетов.

1.Вызовом метода lookup() клиент обращается к службе имен, через которую получает зарегистрированную объектную ссылку. 2. Для соединения с серверным объектом создается объект типа RMISocketFactory и вызывается метод createSocket() для заданного порта и хоста. 3. Во время старта сервера вновь созданный объект регистрируется в сервисе имен registry. Создается объект типа UnicastRemoteObject - экспортирующий объект. При регистрации формируется его объектная ссылка. Объектная ссылка состоит из идентификатора виртуальной Java-машины (endpoint) и, в ее пределах, идентификатора конкретного объекта. Такая ссылка в терминах RMI называется "живая" (live reference). Экспортируется объект присваиванием ему анонимного порта. 4. На стороне сервера также создается объект RMISocketFactory и вызывается метод createServerSocket() на заданном порту. Серверный сокет автоматически определяет, если пришедшее к нему сообщение есть пакет протокола HTTP POST.

1. Вызов метода bind() обращается к брокеру запросов для получения объектной ссылки. Управление передается сначала брокеру, работающему на стороне клиента. Он запрашивает сервис локации (конфигурационный файл), по которому определяется местонахождение удаленного объекта. Соответствующий запрос отправляется серверному брокеру запросов по TCP/IP. 2. В момент старта сервера создается объект grid и, как показывалось, вызываются конструктор CORBA::Object, а затем метод BOA::create(). BOA создает сетевой сокет, объекту grid присваивается идентификатор, создается объектная ссылка. Если взаимодействие происходит по протоколу IIOP, то объектная ссылка имеет вид Interoperable Object Reference (IOR). Эта ссылка содержит имя хоста, TCP/IP-порт, код объекта в сервере. BOA регистрирует ссылку для брокера запросов. 3. Когда ссылка передается клиенту (в результате работы метода bind()), суррогат объекта получает адрес получателя и устанавливает сетевое соединение на основе сокетов.

1.При вызове метода obj.get() суррогат упаковывает параметры в формат сериализованного объекта (Object Serialization). 2. По установленному соединению, через сокеты, созданные объектом RMISocketFactory, сообщение передается серверу. Клиентское приложение обеспечивает три типа пересылки сообщения. Первая попытка делается отправить сообщение непосредственно в удаленный сокет. Если наложены некоторые ограничения - установлен firewall, сообщение передается по протоколу HTTP протоколу и автоматически распознается сервером. В том случае если объект недоступен по HTTP напрямую, клиент пытается подсоединиться к CGI скрипту, перенаправляющему клиента к новому сетевому порту. 3. Возвращаемые значения метода также кодируются форматом прокола сериализации объектов.