Пример 20

Перепад команд.

Рис. 4.4.

Перепад команд: Англия – Германия. Команды дописать самим.

Пример 21. Составное имя: (“UEFA”, “England”, “Prmier”).

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

-адреса

-идентификаторы

-имена, которые для восприятия человеком

В целях реализации пространства имен удобно разбить на 3 уровня:

1. глобальные

2. административные

3. управленческие

Имена 1 и 2 изменяются не часто, то есть их содержимое относительно постоянно, то можно воспользоваться кэшированием путей. Это добавляет эффективности. А в 3 есть динамика смены имен, связей, перемещение объектов и кэширование уже не эффективно. И здесь имена связывают с идентификаторами. А идентификаторы привязаны к ресурсу. А второй механизм – связь идентификатор: адрес. Это служба локализации.

Место службы локализации.

Рис. 4.5.

Лекция 7.12.04

Есть объект в каком-то адресном пространстве. Он может перемещаться по адресным пространствам: оставляет заместитель, а в новом АП формируется ссылка на объект. Такая схема в общем-то прозрачна для клиента: он не знает, что происходили перемещения. При получении запроса ответ может пойти по прямой схеме, так как известен путь и кто запросил сервис этого удаленного объекта.

Перемещение сущности.

Рис. 4.6.

Есть «Но» в этой схеме. Завис процесс в цепочке – цепочка оборвалась: добраться к удаленному объекту больше невозможно. Бороться с этим можно с помощью базовой точки.

Та машина, на которой сначала создавался объект, назовем базовой точкой. Обеспечим, чтобы эта машина всегда имела информацию о текущем местоположении созданного ею объекта. Тогда прослеживается следующая схема: если не удается по цепочке указателей добраться до объекта, то есть какой-то промежуточный процесс завис, то происходит обращение к базовой точке. Нужно только позаботится о том, чтобы БТ этот адрес не утеряла.