2.12 Общие сведения о синхронизации в рсои

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

где с - максимальная скорость дрейфа времени, t - UTC. Если требуется рассинхронизация не более д, то через каждые

необходима синхронизация часов.

Алгоритм Кристиана.

Есть узел, принимающий сигналы точного времени - сервер времени. Остальные узлы через каждые

обращаются к серверу и получают значение времени. Здесь есть 2 момента:

Необходимо время на запрос и возврат результата. Решение: если время запрошено в момент Т0, а получено в момент Т1, то установить часы на полученное время + (Т1-Т0)/2.

Если часы отстают, то мы их доставляем. А если часы спешат, то мы их должны ставить назад. А это не допустимо. Тогда мы не одномоментно подстраиваем часы, а растягиваем это во времени, просто замедляя их ход.

Алгоритм Беркли.

Один узел - демон - периодически собирает времена остальных узлов, получает среднее и рассылает обратно.

Логические часы. Алгоритм Лампорта.

Есть ситуации, когда важно не точное время выполнения процесса, а точная последовательность выполнения. Для таких случаев используют достаточно часто алгоритм Лампорта синхронизации логических часов.

Лампорт определил отношение: «Происходит раньше». Оно обозначается: a b. Это значит, что все процессы согласны с тем, что событие а происходит раньше b.

· Для одного процесса, если а раньше b, то отношение выполняется.

· Если а - посылка сообщения, а b - получение того же сообщения, то отношение тоже выполняется.

· Отношение транзитивно.

В алгоритме каждому событию a ставится метка времени C(a). Эта метка должна быть принята как достоверно правильная всеми процессами. То есть если действительно a b, то C(a) < C(b). Каждому сообщению прикрепляется временная метка. Получатель сравнивает ее со своим временем. Если его время меньше метки, то оно устанавливается равным метка+1. Даже если 2 сообщения посланы почти одновременно, их метки различаются.

2.13 Жизненный цикл распределенных объектов

2.13.1 Cоздание объектов

Требуется создать объект в адресном пространстве (АП) сервера (конструктор создал бы в АП клиента). Для этого необходима фабрика. Чтобы найти фабрику, необходим искатель фабрик. Чтобы найти искатель фабрик, используется сервер именования или трейдинг.

29

2.13.2 Миграция объектов.

Объектная миграция - копирование или перемещение объекта сервера с 1 машины на другую. Чтобы объект позволял миграцию, необходим интерфейс, реализующий операции copy и move с параметром - искателем фабрик. Через фабрику создается объект на новом месте, в него копируется состояние исходного объекта. Далее в случае перемещения исходный объект удаляется. При копировании создается новая ссылка на объект (т.к. исходный объект остается).

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

29

Если цепочка оборвалась (разрыв связи, зависание…), добраться до удаленного объекта больше невозможно. Бороться с этим можно с помощью базовой точки.

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

2.13.3 Копирование объектов

Чтобы объект позволял копирование, необходим интерфейс, реализующий операцию copy с параметром - искателем фабрик. Через фабрику создается объект на новом месте, в него копируется состояние исходного объекта. Создается новая ссылка на объект (т.к. исходный объект остается).

3. Технология J2EE

3.1 Общие сведения

Платформа J2EE - комплекс взаимодействующих технологий, базирующихся на спецификациях фирмы Sun и представляющих стандарт разработки серверных приложений (уровня предприятия).

Особенности:

· Независимость от платформы.

· Простота разработки приложений на основе компонентной технологии.

· Переносимость и расширяемость.

· Возможность разработки распределенных приложений.

· Возможность интеграции с другими платформами.

· Возможность интеграции с существующими информационными системами.

· Обеспечение надежной защиты информации.

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