
- •Конспект лекций модуля № 2 "Базовый курс" дисциплины "Распределенные программные системы и технологии" Тема 5. Организация взаимодействия распределенных компонент
- •5.1. Виды взаимодействия
- •5.2. Синхронное взаимодействие.
- •5.1.1. Организация синхронного взаимодействия.
- •5.1.2. Удаленный вызов процедур
- •5.1.3. Удаленным вызовом методов
- •5.3. Асинхронное взаимодействие.
- •5.3.1. Организация асинхронного взаимодействия
- •5.3.2. Очереди сообщений
- •Тема 6. Идентификация компонентов
- •6.1. Задача идентификации
- •6.2.Централизованная служба имен
- •6.3. Распределенная служба имен
- •Тема .7 Синхронизация
- •7.1. Задачи синхронизации
- •7.2. Синхронизация доступа к данным
- •7.2.1. Гонки
- •7.2.2 Семафоры
- •7.2.2.1. Простые семафоры
- •7.2.2.2 Семафоры со счетчиками
- •7.2.4 Мониторы
- •7.2.4.1 Простые мониторы
- •7.2.4.2 Мониторы с условными переменными
- •7.2.4.3. Реализация мониторов
- •7.3. Синхронизация взаимодействия
- •7.3.1. Ситуация тупика
- •7.3.2. Моделирование тупиков сетью Петри
- •7.3.2.1. Сеть Петри
- •7.3.2.2. Моделирование тупика
- •7.4 Синхронизация времени
- •7.4.1. Проблема синхронизации времени
- •7.4.2. Алгоритм синхронизации времени
- •Тема 8. Транзакции
- •8.1. Понятие транзакции
- •8.2.Модели обработки транзакций
- •8.2.1. Плоские транзакции
- •8.2.2. Контрольные точки
- •8.2.3. Многозвенные транзакции
- •8.2.4. Вложенные транзакции
- •8.3. Классификация транзакций
- •8.4. Распределенные транзакции
- •8.4.1. Монитры транзакций
- •8.4.2 Управление транзакциями
- •8.4.3 Реализация транзакций
- •Литература к теме 8
- •Документация по библиотекам j2se
Тема 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