Неоднородность

В распределенных системах, компоненты должны объявлять о предлагаемых услугах. Заявки могут быть синхронными/асинхронными. Клиент и сервер могут быть неоднородными. Причины неоднородности:

· Компоненты могут приобретаться в готовом виде

· При создании нового компонента, на него могут накладываться требования взаимодействия с существующими компонентами

· Компоненты создаются разными разработчиками

· Используются различные технологии

Разделение ресурсов

Ресурс - аппаратура, ПО, данные. Требуется определить, кому будет разрешен доступ к ресурсу => требуется вести учет пользователей. Менеджер ресурсов - компонент, предоставляющий доступ к разделяемым ресурсам.

Модели взаимодействия:

· Клиент-серверная (сервер предоставляет доступ к ресурсам)

· Концепция распределенных объектов, предоставляющих доступ к имеющимся у них ресурсам при обращении других компонентов

Отказоустойчивость

Система может продолжать работу даже в случае неисправности => избыточность => применение репликации (при отказе компонента, начинает работать его копия и обслуживание не прекращается)

Имеет несколько различных аспектов:

1. Прозрачность масштабируемости (обеспечивается 4, 5) - программист не должен знать, как достигается масштабируемость распределенной системы.

2. Прозрачность производительности (обеспечивается 4, 5) - пользователь и программист не знают, как поддерживается хорошая производительность.

3. Прозрачность отказа (обеспечивается 5, 6) - пользователям и программистам не требуется знать, как ВС справляется с отказами.

4. Прозрачность миграции (обеспечивается 7, 8) - перемещение компонентов незаметно для пользователей и без специальных действий со стороны разработчиков этих компонентов

5. Прозрачность репликации (обеспечивается 7, 8) - пользователям и разработчика не требуется знать, кто предоставляет услугу - реплика или основной компонент. Разработчики компоненты не должны учитывать возможность его репликации

6. Реплика - копия, которая остается синхронизированной с оригиналом

7. Прозрачность одновременного выполнения. Означает, что пользователи программы не знают, что компоненты запрашивают услуги одновременно. Несколько компонентов могут запрашивать обслуживание одновременно с сохранением его услов-ти. Пользователи и разработчики не видят, как организуется одновременно обслуживание.

8. Прозрачность доступа - одинаковость интерфейсов для локальной и удаленной связи (интерфейс заявки на обслуживание должен быть одним и тем же для связи между компонентами одного хоста и разных хостов)

9. Прозрачность местонахождения - способ вызова операции не зависит от местонахождения компонента (запрашивающему обслуживание объекту не требуется знать о физическом расположении компонента). Клиент не должен знать о местонахождении компонента или его реплики.

Есть машины: A и B. A вызывает процедуру, которая выполняется на B.

Стек при вызове процедуры:

Передавать параметры по значению просто, а вот по ссылке - проблема. Вызов через клонирование восстановлением. Удаленный вызов выглядит как локальный, то есть RPC обеспечивает прозрачность для клиента. Сервер тоже не подозревает, что он выполняет удаленный вызов.

На сервере есть аналогичная заглушка; сервер выполняет запрос, возвращает результат. Проблема: передача по адресу. Решение: можно предавать копию буфера.

Последовательность передачи управления при RPC:

При удаленном вызове процедур процесс на 1 узле вызывает процедуру процесса на 2 узле. Сложность заключается в том, что процессы работают в разных адресных пространствах (АП). При передаче параметров по значению это неважно, т.к. значение не зависит от АП, а при передаче по ссылке возникает проблема. Здесь можно использовать другой вариант передачи параметров (отсутствует в С) - копирование-восстановление.

Передача параметров по значению.

· Формируется пакет, содержащий имя процедуры и ее параметры;

· Сообщение принимается заглушкой-сервером;

· Заглушка на сервере формирует вызов процедуры (как локальной).

Клиентский процесс приостанавливает свою работу и ждет возвращение результата. При получении результата он продолжает работу.

Передача параметров по ссылке (копирование-восстановление).

Пример: чтение удаленного файла в массив.

Передать копию ссылки не представляется возможным, так как ссылка - это указатель в АП клиента, бессмысленно передавать ее копию. Вариант решения: можно поступить так: взять массив, на который показывает указатель, и передать копию этого массива. Все это помещается в сообщение, передаваемое на сервер. На сервере выделяется место под массив, ссылка на массив в АП сервера. Заглушка передает параметры серверному процессу, и он по всем правилам обращается к ОС и помещает результат в массив в своем АП. Заглушка упаковывает массив в сообщение и передает его на клиентскую заглушку с помощью ОС. Клиентская заглушка распаковывает это сообщение и помещает значения в тот массив, который находится в АП клиента. Клиентский процесс получает результат, как будто он обратился локально. Эта удаленность прозрачна для обоих.

Заглушки должны использовать один протокол, по которому они будут представлять встроенные типы. Если заглушки работают по одному и тому же протоколу, они будут различаться только интерфейсами на машинах.

Чтобы облегчить работу по созданию заглушек, используется язык определения интерфейсов. IDL - Interface Definition Language.

Распределенный объект (РО) - такой объект, реализация которого располагается на сервере, а взаимодействие клиентов с ним происходит через определенный интерфейс.

В адресное пространство клиента загружается реализация этого интерфейса - заместитель (proxy). Клиент непосредственно взаимодействует именно с заместителем.

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

Неявная (автоматическая) - клиент прозрачно связывается с объектом в момент разрешения ссылки (это когда по имени объекта получаем ссылку на него).

Явная - клиент должен вызвать специальную функцию для привязки к объекту.

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

Скелетон - образ клиента на сервере (заглушка сервера).

Клиент через заместителя вызывает определенный метод объекта и задает параметры этого метода. Заместитель формирует и упаковывает сообщение (маршалинг) и отправляет его на сервер. В этом сообщении содержится ссылка на объект, метод и значения параметров. Сервер получает сообщение, и передает его соответствующему скелетону. Скелетон распаковывает сообщение (демаршалинг) и непосредственно вызывает определенный метод объекта с заданными клиентом параметрами. Если предполагается, что метод что-нибудь возвращает, то скелетон упаковывает результат и отправляет его заместителю.

Сохранные и нерезидентные объекты

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

Нерезидентный - существует, пока им управляет сервер. Когда сервер завершает работу, это объект прекращает существование.

Способы определения местонахождения РО

Именование - управление пространствами имен, представляющими собой наборы связей между именами объектов и ссылками на них.

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

Статическое удаленное обращение к методам (RMI).

При статическом обращении интерфейс удаленного объекта описывается с помощью IDL, т.е. интерфейс известен на этапе компиляции.

Пример: Описание интерфейса футболиста.

При использовании статического обращения интерфейсы должны быть уже известны и при изменении интерфейса нужна перекомпиляция.

Динамическое удаленное обращение к методам.

При динамическом обращении интерфейс удаленного объекта заранее не известен. Параметры обращения к методу собираются в процессе выполнения. Заранее неизвестно, к какому методу будет обращение.

Передача параметров.

Используются ссылки на объекты как параметры, которые передаются при обращении к удаленному объекту. Объект, ссылка на который передается:

· находится в адресном пространстве клиента;

· находится удаленно.

Они реализуются по-разному. Ссылка передается только для удаленных объектов. Если объект локальный, то передается копия самого объекта.

При удаленном вызове клиентом на машине А сервера на машине С осуществляется копирование объекта O1 и передача ссылки на объект O2.

Серверы объектов (СО) - серверы, ориентированные на поддержку распределенных объектов. СО (в отличие от традиционных серверов) НЕ предоставляет конкретные службы, т.к. конкретные службы реализуются объектами, расположенными на сервере. СО предоставляет только средства обращения к объектам, основанные на запросах от удаленных клиентов.

Активизация объекта - перемещение объекта в адресное пространство сервера (например, десериализация). Правила обращения к объектам - политика активизации. Требуется механизм группировки объектов в соответствии с политикой активизации каждого из них. Этим механизмом является адаптер объектов. Чаще всего он скрыт в наборе средств построения СО. Каждый адаптер объектов контролирует 1 или несколько объектов. При получении запроса к одному из контролируемых объектов адаптер проверяет его состояние и при необходимости активизирует в соответствии с политикой активизации. После этого запрос передается к заглушке (скелетону) объекта, которая производит демаршаллинг (распаковку параметров) и осуществляет вызов метода. Адаптер ничего не знает об интерфейсах объектов.

Перенос кода необходим для:

· перераспределения нагрузки между узлами для повышения производительности;

· снижения трафика клиент-серверного взаимодействия.

У задачи выделяют следующие сегменты:

· сегмент кода - команды;

· сегмент исполнения - контекст задачи;

· сегмент ресурсов - ресурсы.

Модели переноса кода:

Минимальные требования для переноса кода предъявляет модель слабой мобильности - перенос только сегмента кода. Поэтому программа всегда выполняется из своего исходного состояния. Пример: Java Applet.

В модели сильной мобильности переносится сегмент кода и сегмент исполнения. Процесс приостанавливается, переносится и запускается на другом узле. Пример: мультиагентная платформа.

Типы связи процесса с ресурсом:

Процесс передает в точности тот ресурс, на который ссылаются аргументы (наиболее сильная связь);

Более слабая связь - процессу нужно только значение;

Наиболее слабая форма связи - процесс указывает лишь на использование ресурса определенного типа.

Программный агент.

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

Серверы - процессы, реализующие службы и предоставляющие к ним доступ.

Клиенты - процессы, использующие эти службы.

Рассмотрим на примере доступа к БД:

При трехуровневой организации системы имеем следующие логические уровни:

· Пользовательский интерфейс (ПИ на рисунке).

· Обработки (О).

· Данных (непосредственная работа с БД).

Варианты физического разделения уровней между узлами:

На этом рисунке клиент «утолщается» слева направо.

Взаимодействие клиента с сервером происходит следующим образом:

2.12 Общие сведение об именовании объектов и службе именования

Именование - способ определения местонахождения распределенных объектов, при котором осуществляется управление пространствами имен, представляющими собой наборы связей между именами объектов и ссылками на них.

Контекст именования - последовательность простых имен, идентифицирующая объект. Например “UEFA”, “England”, “Premier”, “Chelsea”.

Операции:

Связывание - регистрация объекта-сервиса по имени и объектной ссылке. Используется при добавлении нового объекта в систему или при перемещении / копировании существующего объекта.

Разрешение - получение ссылки на объект по его имени. Используется клиентом для получения доступа к методам объекта.

Размещение мобильных сущностей.

Мобильные сущности - это те объекты, которые могут гулять по разным хостам. В этом случае пространство имен удобно разбить на 3 уровня:

· Глобальный

· Административный

· Управленческий

В 1 и 2 помещаются объекты, которые перемещаются относительно редко. Здесь эффективно кэширование путей.

В 3 объекты гуляют часто, и для них используется следующая система:

По имени объекта служба именования определяет его идентификатор, затем служба локализации по ид находит его физический адрес.

У каждого узла свой системный таймер. Возникает проблема синхронизации часов. Пусть у узла р время Ср(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 сообщения посланы почти одновременно, их метки различаются.

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

29

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

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

29

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

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

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

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

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

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

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

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

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

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

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

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

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

J2EE - набор спецификаций, устанавливающих правила, которых следует придерживаться поставщикам конкретных реализаций 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

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

Страницы: 1, 2, 3, 4