Трейдинг
позволяет клиентам определять местонахождения объекта в сервере исходя из предоставляемых объектами-серверами функций и требуемого качества обслуживания, то есть клиенты могут находить объекты-серверы, имена которых им не известны, у них есть только желание, чтобы те объекты 0среверы обладали функциональностью с требуемым качеством.
Нужно связывать объект с определенным именем – некоторая последовательность идентификаторов и она может быть разрешена в ссылку на объект.
Продолжение проги с футбольными командами
Надо объект зарегистрировать на сервере именований с использованием официального названия команды. А дальше посылаем имя команды и получаем ссылку на эту команду.
Соответствие с между именем и ссылкой – связывание имен. Поиск конкретного связывания – потеря эффективности. Решение этой проблемы – декомпозиция: разбиение пространства на отдельные подпространства. Здесь используется иерархическое разбиение. Отдельное пространство имен – контекст именования.
Связывание имен.
Рис. 4.20.
Есть корневое пространство – в него входят все остальные контексты. Поиск именования, т. е. конкретной ссылки по имени – обход контекстов. И если эти контексты расположены на разных компах, это издержки при пересылке. Здесь нужен разумный (эффективный) алгоритм перемещения по контекстам.
С позиции обеспечения эффективности поиска по именам вводится понятие: составные имена. Использование составных имен уменьшает пространство поиска.
Составное имя – это последовательность простых имен, задающих путь к объекту через ряд контекстов именования. Каждый сервер именования должен поддерживать 3 базовые операции:
Операция связывания, которая создает новое связывание для объекта. То есть это эта операция обеспечивает связывание имени и объекта.
Операция разрешения: возвращает объектную ссылку для определенного имени, переданного службе в качестве параметра.
Операция просмотра: выводит список связываний, которые есть в службе в контексте.
Перепад команд.
Рис. 4.21.
Перепад команд: Англия – Германия. Команды дописать самим.
Составное имя: (“UEFA”, “England”, “Prmier”).
Теперь нас интересует размещение мобильной сущности, то есть, те которые гуляют по распределенной сети. Содержание контекста имен:
-адреса
-идентификаторы
-имена, которые для восприятия человеком
В целях реализации пространства имен удобно разбить на 3 уровня:
глобальные
административные
управленческие
Имена 1 и 2 изменяются не часто, то есть их содержимое относительно постоянно, то можно воспользоваться кэшированием путей. Это добавляет эффективности. А в 3 есть динамика смены имен, связей, перемещение объектов и кэширование уже не эффективно. И здесь имена связывают с идентификаторами. А идентификаторы привязаны к ресурсу. А второй механизм – связь идентификатор: адрес. Это служба локализации.
Место службы локализации.
Рис. 4.22.
Лекция 7.12.04
Есть объект в каком-то адресном пространстве. Он может перемещаться по адресным пространствам: оставляет заместитель, а в новом АП формируется ссылка на объект. Такая схема в общем-то прозрачна для клиента: он не знает, что происходили перемещения. При получении запроса ответ может пойти по прямой схеме, так как известен путь и кто запросил сервис этого удаленного объекта.
Перемещение сущности.
Рис. 4.23.
Есть «Но» в этой схеме. Завис процесс в цепочке – цепочка оборвалась: добраться к удаленному объекту больше невозможно. Бороться с этим можно с помощью базовой точки.
Та машина, на которой сначала создавался объект, назовем базовой точкой. Обеспечим, чтобы эта машина всегда имела информацию о текущем местоположении созданного ею объекта. Тогда прослеживается следующая схема: если не удается по цепочке указателей добраться до объекта, то есть какой-то промежуточный процесс завис, то происходит обращение к базовой точке. Нужно только позаботится о том, чтобы БТ этот адрес не утеряла.