Распределенные системы обработки информации

где с - максимальная скорость дрейфа времени, 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, а также разработчикам приложений.

3.2 Архитектура J2EE

Поддерживаются разные типы клиентов: HTML - браузеры, апплеты, автономные java-приложения.

Уровень представления - часто реализуется в виде веб-уровня.

Уровень бизнес-логики - в виде уровня EJB (Enterprise Java Beans).

Уровень интеграции - уровень сервера БД - EIS (Enterprise Information Server). Это адаптеры ресурсов J2EE.

Сервер приложений - содержит контейнеры компонентов EJB.

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

· Доступ к инфраструктуре J2EE.

· Управление жизненным циклом компонентов EJB.

· Доступ к БД с использованием JDBC.

· Контейнер изолирует компонент от клиента. Все запросы перехватываются контейнером.

· У каждого компонента есть объект EJBContext, который является ссылкой на контейнер.

· Контейнер автоматически создает набор соединений с БД.

· Контейнер позволяет объединять несколько компонент внутри одной транзакции.

Аббревиатуры:

JMS - Java Messaging Service

JSP - Java Server Page

JTA - Java Transaction API

JAF - Java Beans Activation Framework

JAXP - Java API for XML Parser

JAAS - Java Authentication and Authorization Service

3.3 EJB - Enterprise Java Beans

EJB - серверная java технология, основанная на транзакциях. Позволяет быстро и относительно просто разрабатывать распределенные, транзакционные, безопасные и портируемые Java приложения.

Компонент EJB представляет собой:

Remote - Расширенный интерфейс. Определяет методы компонента.

Remote Home - определяет методы жизненного цикла для создания, удаления, поиска компонент(интерфейс фабрики классов)

Local - этот интерфейс используется другими компонентами находящимися в этом же контейнере.

Вызов происходит следующим образом

Модули EJB - объединенные в группу компоненты EJB, которые могут взаимодействовать.

Типы компонентов EJB:

Session - связаны с бизнес процессами приложения; имеют доступ к бд, но не предоставляют доступа к ней; жизненный цикл - до перезагрузки сервера. ( вызов сессионных компонентов: сервлетты, страницы JSP, java приложения). Разделяется на 2 типа:

Stateless - не сохраняет информации о своем состоянии

Statefull - могут сохранять инф о своем состоянии

(У них сильно различаются жизненные циклы.)

Entity - моделируют бизнесс данные приложения; предоставляют доступ к БД; часто 1 обращается к 2; t жизни = t жизни бд(при перезагр сервера автоматически восстанавливаются); вызов из 1 и компонентов WEB;

MessageDriven - прдставляют действия. Их можно вызвать только послав сообщение этому компоненту; С помощью 3 организуют доступ к 1. t жизни как у 1

Так цепочку обращений в J2EE можно представить следующим образом:

Java Beans

JB это не EJB, EJB более обширное понятие.

JB - для создания пользовательского интерфейса, для взаимодействия между страницами.

EJB - для создания серв приложений, только не визуальные компоненты.