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

Тема 6. Идентификация компонентов

6.1. Задача идентификации

При взаимодействии распределенных компонентов клиент отправляет запрос серверу. При этом он должен однозначно идентифицировать сервер, указав его имя и адрес его местонахождения. В качестве адреса может выступать IP адрес, DNS имя, имя очереди, электронный адрес почты и т.п. Возможны два варианта определения адреса:

  • статический – клиент обращается по заранее известному адресу указанному еще на этапе его реализации;

  • динамический – адрес определяется по имени сервера, через вспомогательные службы.

Первый вариант, как правило не вызывает проблем при реализации. Однако он накладывает ограничения на сервер:

  • адрес сервера должен быть известен;

  • сервер не дожжен менять своего местоположения (адрес должен быть постоянен).

Второй вариант более сложен, так как требует реализации дополнительных служб, позволяющих клиентам по имени сервера определять его местоположения. Существуют различные подходы к реализации таких служб, можно выделить следующие распространенные подходы:

  • Централизованная служба наименования;

  • Децентрализованная служба наменования.

6.2.Централизованная служба имен

Для определения адреса сервера клиенты могут использовать службу имен или каталогов. Служба имен или каталогов устанавливается на хорошо известном хосте и имеет известный номер порта. (Хорошо известный означает, что все в распределенные компоненты знают об этом). Рассмотрим организацию службы имен на примере 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.

На рис 6.1. изображено распределенное приложение RMI, которое использует регистр для получения ссылки на удаленный объект. Сервер вызывает регистр для того, чтобы связать имя с удаленным объектом. Клиент ищет удаленный объект по его имени в регистре сервера, а затем вызывает его метод. Иллюстрация также показывает, что система RMI использует существующий Web-сервер для "скачивания" байткодов классов от сервера к клиенту и от клиента к серверу, когда в объекте возникает необходимость.

Рис 6.1. Использование реестра RMI