Архитектуры распределенных информационных систем

Содержание

Слайд 2

ПОНЯТИЕ АРХИТЕКТУРЫ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ Организация РС определяется тем каким образом программное

ПОНЯТИЕ АРХИТЕКТУРЫ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ

Организация РС определяется тем каким образом программное обеспечение

РС распределяется между вычислительными узлами этой системы.
В организации систем часто выделяют:
Логическую организацию совокупности программных компонент системы;
Физическую организацию размещение этих компонент на узлах системы.
Слайд 3

ПРОГРАММНАЯ АРХИТЕКТУРА Организация РС определяется составом программных компонент входящих в состав

ПРОГРАММНАЯ АРХИТЕКТУРА

Организация РС определяется составом программных компонент входящих в состав системы.
Программная

архитектура показывает помимо того как организована система, также и то как взаимодействуют между собой программные компоненты этой системы.
Слайд 4

ПРОЗHАЧНОСТЬ РС И ЕЕ АРХИТЕКТУРА Исходя из требования обеспечения прозрачности в

ПРОЗHАЧНОСТЬ РС И ЕЕ АРХИТЕКТУРА

Исходя из требования обеспечения прозрачности в распределенных

системах требуется четко разделять приложения и лежащие в их основе платформы.
Такое разделение в РС выполняется с помощью промежуточного уровня системы.
Слайд 5

ВЫБОР ВАРИАНТА ПРОГРАММНОЙ АРХИТЕКТУРЫ Важнейшим решением при разработке архитектуры системы является:

ВЫБОР ВАРИАНТА ПРОГРАММНОЙ АРХИТЕКТУРЫ

Важнейшим решением при разработке архитектуры системы является:
выбор варианта

размещения ПО промежуточного уровня (ППУ) системы.
Имеется различные методики определение состава и размещения ППУ приложений, что и определяет множество вариантов программных архитектур.
Слайд 6

СИСТЕМНАЯ АРХИТЕКТУРА Фактическая (реально разворачиваемая) реализация РС, требует однозначного определения размещения

СИСТЕМНАЯ АРХИТЕКТУРА

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

компонент системы на реальных машинах.
Практически всегда имеется множество вариантов такого размещения.
Размещение программных компонент системы (программная архитектура) на физических машинах называется системной архитектурой.
Слайд 7

ВИДЫ СИСТЕМНОЙ АРХИТЕКТУРЫ Различают три вида системной архитектуры: централизованная; децентрализованная (peer-to-peer);

ВИДЫ СИСТЕМНОЙ АРХИТЕКТУРЫ

Различают три вида системной архитектуры:
централизованная;
децентрализованная (peer-to-peer);
гибридная – комбинация элементов

централизованной и децентрализованной архитектур.
Слайд 8

ПОНЯТИЕ АРХИТЕКТУРНОГО СТИЛЯ В настоящее время исследования в области программного обеспечения

ПОНЯТИЕ АРХИТЕКТУРНОГО СТИЛЯ

В настоящее время исследования в области программного обеспечения достигли

достаточной зрелости, что позволило однозначно определить понятие архитектурного стиля (архитектуры) РИС.
При проектировании и создании РС выбор архитектуры является ключевым техническим решением, определяющим успех создания больших программных систем.
При обсуждении архитектурных аспектов РС важным понятием является архитектурный стиль, который описывается в терминологии компонент и определяет:
способ коммуникаций между компонентами;
порядок обмена данными между компонентами;
как элементы системы совместно формируют распределенную систему.
Слайд 9

ПОНЯТИЕ ПРОГРАММНОГО КОМПОНЕНТА Компонент – модульная единица ПО снабженная полностью определенным

ПОНЯТИЕ ПРОГРАММНОГО КОМПОНЕНТА

Компонент – модульная единица ПО снабженная полностью определенным и

предоставляемым по запросу интерфейсом.
Компонент должен обладать свойством – заменяемости (replaceable) в рамках системного окружения. Замена компонента может быть выполнена в любой момент, даже в условиях работы системы. Последний аспект определяет, что в РС может отсутствовать опция
Интерфейс - описывает состав параметров необходимых для обращению к компоненту. Замена компонента может быть выполнена только при условии неизменности его интерфейса.
Конектор – это механизм который обеспечивает коммуникации, и способствует координации (или кооперации) компонент друг с другом.
Конектор может быть сформирован на основе средств реализующих способ связи между компонентами. :
удаленный вызов процедур (RPC);
обмен сообщениями (message passing);
потока данных (streaming data) и д.р.
Использование понятий компонент и конектор позволяет описывать различные варианты конфигураций, которые в свою очередь могут быть квалифицированы как архитектурные стили.
Слайд 10

ОСНОВНЫЕ ВИДЫ АРХИТЕКТУР РИС В настоящее время общепризнанными архитектурными стилями считаются:

ОСНОВНЫЕ ВИДЫ АРХИТЕКТУР РИС

В настоящее время общепризнанными архитектурными стилями считаются:
многоуровневые архитектукры

(layered);
объектные архитектуры (object-based);
ресурсо-центрированные архитектуры (resource-centerd) ;
архитектуры основанные на событиях (event-based).
Эти стили могут одновременно применяться в одних и тех же системах в различных сочетаниях.
Слайд 11

МНОГОУРОВНЕВАЯ АРХИТЕКТУРА Базовая идея проста: компоненты распределяются по уровням, при этом

МНОГОУРОВНЕВАЯ АРХИТЕКТУРА

Базовая идея проста: компоненты распределяются по уровням, при этом компонент

уровня j Lj может вызывать компонент находящийся на нижележащем уровне i (Li), от которого он получает ответ.
Как правило вызов компонента выше стоящего уровня нижележащим запрещен.

Простая многоуровневая архитектура

Слайд 12

ДРУГИЕ ВИДЫ МНОГОУРОВНЕВЫХ АРХИТЕКТУР Смешанная многоуровневая архитектура – допускает вызов не

ДРУГИЕ ВИДЫ МНОГОУРОВНЕВЫХ АРХИТЕКТУР

Смешанная многоуровневая архитектура – допускает вызов не только

смежных нижележащих уровней, но и более глубоколежащих уровней.

Смешанная
Многоур. архитектура

Архитектура с обратными
связями

Многоуровневая архитектура с обратными связями

Слайд 13

МНОГОУРОВНЕВАЯ ОРГАНИЗАЦИЯ СТЕКА СЕТЕВЫХ ПРОТОКОЛОВ Примером такой организации может служить стек

МНОГОУРОВНЕВАЯ ОРГАНИЗАЦИЯ СТЕКА СЕТЕВЫХ ПРОТОКОЛОВ

Примером такой организации может служить стек сетевых

протоколов, например : TCP/IP

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

Слайд 14

АРХИТЕКТУРА ПРИЛОЖЕНИЯ (РАССЛОЕНИЕ ПРИЛОЖЕНИЯ)

АРХИТЕКТУРА ПРИЛОЖЕНИЯ (РАССЛОЕНИЕ ПРИЛОЖЕНИЯ)

Слайд 15

МНОГОУРОВНЕВАЯ ОРГАНИЗАЦИЯ ПРИЛОЖЕНИЙ

МНОГОУРОВНЕВАЯ ОРГАНИЗАЦИЯ ПРИЛОЖЕНИЙ

Слайд 16

АРХИТЕКТУРА ОСНОВАННАЯ НА ОБЪЕКТАХ (OBJECT-BASED ARCHITECTURE) В этой архитектуре понятие объект

АРХИТЕКТУРА ОСНОВАННАЯ НА ОБЪЕКТАХ (OBJECT-BASED ARCHITECTURE)

В этой архитектуре понятие объект однозначно соответствует

понятию компонент.
Объекты взаимодействуют между собой с помощью механизма RPC.
Эта архитектура предоставляет естественный способ инкапсуляции данных (состояние объекта) и операций которые могут выполняться над этими данными (методы объекта) объектом.
Интерфейс предоставляемый объектом скрывает детали реализации объекта, что делает объект полностью независимым от его окружения.
Разделение интерфейсов и реализации объектом этого интерфейса позволяет разместить интерфейс объекта на одной машине, а сам объект на другой машине. Такой объект называется распределенным.
Слайд 17

РАСПРЕДЕЛЕННЫЕ ОБЪЕКТЫ Когда клиент связывается с распределенным объектом, реализация интерфейса этого

РАСПРЕДЕЛЕННЫЕ ОБЪЕКТЫ

Когда клиент связывается с распределенным объектом, реализация интерфейса этого объекта,

называемая proxy, загружается в адресное пространство клиента.
Посредник (proxy) это аналог заглушки (stub) клиента в RPC. Он выполняет маршалинг вызова метода в сообщение и извлечение результата из ответного сообщения получаемого от сервера.
Реальный объект располагается на удаленной машине, где имеется такой же интерфейс как и на клиентской машине. Входящий вызов метода принимает серверная заглушка (stub, также часто называемая skeleton), которая извлекает вызов из сообщения и передает его интерфейсу объекта сервера. Заглушка сервера размещает ответ в сообщение и отправляет его proxy клиента.
Слайд 18

СЕРВИС Архитектура распределенных объектов ее основе сформировать сервис как независимую программную

СЕРВИС

Архитектура распределенных объектов ее основе сформировать сервис как независимую программную единицу.


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

ОСНОВНЫЕ ПОНЯТИЯ СОА (1) СOA – это способ описания требований и

ОСНОВНЫЕ ПОНЯТИЯ СОА (1)

СOA – это способ описания требований и методология

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

ОСНОВНЫЕ ПОНЯТИЯ СОА (2) SOA описывается как совокупность сервисов, реализуемых в

ОСНОВНЫЕ ПОНЯТИЯ СОА (2)

SOA описывается как совокупность сервисов, реализуемых в виде

компонентных объектов, систематизированных на основе обмена сообщениями (message-passing taxonomy).
Общим примером сообщений, которыми обмениваются сервисы является XML сообщение.
Для каждого сервиса принято определять:
поставщика сервиса (компонент сервис),
потребителя сервиса (компонент клиент);
брокера - компонент, обеспечивающий взаимодействие поставщика и потребителя.
Слайд 21

ВЗАИМОДЕЙСТВИЕ МЕЖДУ ПОСТАВЩИКОМ И ПОТРЕБИТЕЛЕМ СЕРВИСА Клиент обращается к поставщику посылая

ВЗАИМОДЕЙСТВИЕ МЕЖДУ ПОСТАВЩИКОМ И ПОТРЕБИТЕЛЕМ СЕРВИСА

Клиент обращается к поставщику посылая ему

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

АРХИТЕКТУРА ИС ПРЕДПРИЯТИЯ НА ОСНОВЕ SOA Уровень бизнес-логики предприятия Уровень логики приложения Уровень приложения

АРХИТЕКТУРА ИС ПРЕДПРИЯТИЯ НА ОСНОВЕ SOA

Уровень бизнес-логики предприятия
Уровень логики приложения
Уровень приложения

Слайд 23

ВЕБ СЕРВИС Веб-служба, веб-сервис (англ. web service) — идентифицируемая программная система со стандартизированными интерфейсами.

ВЕБ СЕРВИС

Веб-служба, веб-сервис (англ. web service) — идентифицируемая программная система со стандартизированными интерфейсами.

Слайд 24

МОДЕЛЬ РАБОТЫ WEB-СЕРВИСА

МОДЕЛЬ РАБОТЫ WEB-СЕРВИСА

Слайд 25

СТЕК ПРОТОКОЛОВ WEB-СЕРВИСА

СТЕК ПРОТОКОЛОВ WEB-СЕРВИСА

Слайд 26

АРХИТЕКТУРА ОСНОВАННАЯ НА РЕСУРСАХ Рост числа сервисов доступных через Web и

АРХИТЕКТУРА ОСНОВАННАЯ НА РЕСУРСАХ

Рост числа сервисов доступных через Web и создание

распределенных систем на основе композиций сервисов привели к необходимости переосмысления архитектуры РС построенных на базе Web.
Одной из проблем построения РС на основанных на Web сервисах явилась высокая сложность обеспечения связи между большим числом различных компонент.
В качестве альтернативы было предложено рассматривать РС как коллекцию ресурсов каждый из которых индивидуально управляется своим компонентом.
Слайд 27

РЕСУРСО-ЦЕНТРИЧЕСКАЯ АРХИТЕКТУРА Ресурсы могут добавляться либо удаляться с помощь приложения (удаленного).

РЕСУРСО-ЦЕНТРИЧЕСКАЯ АРХИТЕКТУРА

Ресурсы могут добавляться либо удаляться с помощь приложения (удаленного).
Такой подход

привел формированию понятия ресурсо-центрической архитектуры РИС
Ресурсный подход получил широкое распространение в WEB в виде Web-сервисов RESTful (Representational State Transfer)

Удаленное приложение

Ресурс 1

Ресурс 2

Ресурс M

Ресурс N

Слайд 28

ПРИНЦИПЫ АРХИТЕКТУРЫ RESTFUL Архитектура REST (Representational State Transfer) основана на четырех

ПРИНЦИПЫ АРХИТЕКТУРЫ RESTFUL

Архитектура REST (Representational State Transfer) основана на четырех принципах

[Fielding, 2000]:
Использование единой схемы именования. Идентификация ресурса выполняется посредством URI, который предоставляет глобальное адресное пространство для поиска ресурсов и сервисов.
Унифицированный интерфейс – GET извлекает текущее состояние ресурса в некотором представлении. POST передает новое состояние ресурса. Поддерживается всего 4 операции:
PUT – создать новый ресурс;
GET – получить состояние ресурса в некоторое представление;
DELETE – Удалить ресурс;
POST – Модифицировать ресурс с помощью изменения его состояния.
Информативные сообщения – являются самодостаточными. Ресурсы отделены от их представления таким образом, что их содержимое может быть доступно в различных форматах (например, HTML, XML, текст, RDF, JPEG).
Отсутствие сессии. После формирования ответа сервер забывает о клиенте. Взаимодействия через гиперссылки – Для обмена существуют различные технологии (например, переименование URI, cookies и скрытые поля формы). Состояние может быть вставлено в ответное сообщение, чтобы указать допустимое будущее состояние взаимодействия.
Слайд 29

СРАВНЕНИЕ REST И SOAP/XML WEB-СЕРВИСОВ RESTful архитектура стала популярна благодаря своей

СРАВНЕНИЕ REST И SOAP/XML WEB-СЕРВИСОВ

RESTful архитектура стала популярна благодаря своей простоте.
SOAP

поддерживает 16 операций, RESTful всего 4.
В случае RESTful приложение должно предоставить все параметры запроса с помощью одной операции, а в случае SOAP число передаваемых параметров за одну операцию ограничено, поэтому для передачи всех параметров требуется выполнение нескольких операций.
Например, для создания bucket в AWS S3 (SOAP/XML) надо выполнить:
import bucket
bucket.create (“mybucket”)
В случае RESTful:
PUT “http://mybucket.s3.amazonsws.com/”

Вызов SOAP может порождать синтаксические ошибки, обнаруживаемые во время компиляции, в то время как в случае REST проверка вызова откладывается на время исполнения

Слайд 30

АРХИТЕКТУРЫ ОСНОВАННЫЕ НА ПУБЛИКАЦИИ И ПОДПИСКЕ По мере роста размеров РС

АРХИТЕКТУРЫ ОСНОВАННЫЕ НА ПУБЛИКАЦИИ И ПОДПИСКЕ

По мере роста размеров РС стало

важным иметь архитектуру в которой зависимость между процессами стала бы как можно меньше.
В качестве таковой была предложена архитектура в которой было введено строгое разграничение между процессами передачи и обработки сообщений и координацией этих процессов.
Идея состояла в том, что бы взглянуть на РС как на совокупность процессов обработки информации взаимодействующих между собой.
В этой модели координация заключается в коммуникации и координации между процессами. Координация играет роль клея связывающего активность процессов в единое целое.
Слайд 31

СПОСОБЫ КООРДИНАЦИИ В зависимости то вида координации используемой в системе можно

СПОСОБЫ КООРДИНАЦИИ

В зависимости то вида координации используемой в системе можно определить

несколько моделей архитектуры подписка/публикация.
В качестве способов координации используются:
Временная координация;
Ссылочная (адресная) координация.
Слайд 32

ВАРИАНТЫ АРХИТЕКТУР ПУБЛИКАЦИЯ/ПОДПИСКА В зависимости от комбинации двух факторов координации различают

ВАРИАНТЫ АРХИТЕКТУР ПУБЛИКАЦИЯ/ПОДПИСКА

В зависимости от комбинации двух факторов координации различают следующие

модели архитектуры публикация/подписка:
архитектура П/П с прямой координацией;
архитектура П/П с координацией через почтовый ящик;
архитектура П/П с координацией на основе событий;
архитектура П/П с координацией на основе разделяемых данных.
Слайд 33

АРХИТЕКТУРА П/П С ПРЯМОЙ КООРДИНАЦИЕЙ В этой модели одновременно используются оба

АРХИТЕКТУРА П/П С ПРЯМОЙ КООРДИНАЦИЕЙ

В этой модели одновременно используются оба вида

координации:
Координация по времени существует, когда оба процесса запущены и работают).
Координация по ссылке (адресная) существует, когда имеется явная ссылка на процесс с которым требуется взаимодействие, либо в виде имени либо в виде его идентификатора.

коммуникации

Слайд 34

АРХИТЕКТУРА П/П С КООРДИНАЦИЕЙ ЧЕРЕЗ ПОЧТОВЫЙ ЯЩИК В этой модели: Отсутствует

АРХИТЕКТУРА П/П С КООРДИНАЦИЕЙ ЧЕРЕЗ ПОЧТОВЫЙ ЯЩИК

В этой модели:
Отсутствует координация по

времени, оба процесса запускаются и работают не синхронизируясь друг с другом.
Подписчик периодически проверяет наличие сообщений в своем почтовом ящике.
Отправитель (издатель) периодически активизируется для отправки сообщения в почтовый ящик другого процесса.
Координация по ссылке (адресная) существует, в виде адреса почтового ящика.
Слайд 35

АРХИТЕКТУРА НА ОСНОВЕ ОБЩЕГО ПРОСТРАНСТВА ДАННЫХ Пример: Linda - программная модель,

АРХИТЕКТУРА НА ОСНОВЕ ОБЩЕГО ПРОСТРАНСТВА ДАННЫХ

Пример: Linda - программная модель, разработанная

в 1980 году. Разделяемое пространство данных в модели Linda называется пространство записей (кортежей). Это пространство поддерживает три операции:
in(t): извлечь (с удалением) запись, соответствующую шаблону t;
out(t): занести запись по шаблону t.
* Операции in(t) и out(t) взаимно блокируют друг друга.
zd (t): получить копию записи по шаблону t;

В случае отсутствия обоих видов координации получается модель с общей шиной данных.

Слайд 36

АРХИТЕКТУРА П/П НА ОСНОВЕ СОБЫТИЙ Для получения уведомления процесс подписчик должен

АРХИТЕКТУРА П/П НА ОСНОВЕ СОБЫТИЙ

Для получения уведомления процесс подписчик должен всегда

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

В этой модели ссылочная координация отсутствует, но поддерживается во времени.

Слайд 37

ВАРИАНТЫ АРХИТЕКТУРЫ П/П НА ОСНОВЕ СОБЫТИЙ В зависимости от способа описания

ВАРИАНТЫ АРХИТЕКТУРЫ П/П НА ОСНОВЕ СОБЫТИЙ

В зависимости от способа описания события

различают два варианта систем с архитектурой публикации/подписке на основе событий:
системы публикации/подписки основанные на теме (topic-based public-subscribe systems);
системы публикации/подписки основанные на содержимом (контенте) (content-based public-subscribe systems)
Слайд 38

СИСТЕМА ПУБЛИКАЦИИ/ПОДПИСКИ ОСНОВАННАЯ НА ТЕМЕ Событие описывается набором атрибутов – списком

СИСТЕМА ПУБЛИКАЦИИ/ПОДПИСКИ ОСНОВАННАЯ НА ТЕМЕ

Событие описывается набором атрибутов – списком пар

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

СИСТЕМЫ ПУБЛИКАЦИИ/ПОДПИСКИ ОСНОВАННЫЕ НА СОДЕРЖИМОМ (КОНТЕНТЕ) В этом случае событие также

СИСТЕМЫ ПУБЛИКАЦИИ/ПОДПИСКИ ОСНОВАННЫЕ НА СОДЕРЖИМОМ (КОНТЕНТЕ)

В этом случае событие также

описывается набором атрибутов, которые представляются парами: имя_атрибута, диапазон_значений.
Допускается использовать все виды предикатов на основе множества атрибутов (подобно запросам SQL).
Уведомление описывает опубликованное событие, когда оно становится доступным другим процессам для чтения.
Подписка должна быть направлена к промежуточному ПО с описанием события, в котором заинтересован подписчик.
Очевидно, что чем более сложным является описание события, тем более трудно проверить событие на соответствие этого описания.
Слайд 40

ПРИНЦИП ОБМЕНА ДАННЫМИ МЕЖДУ ИЗДАТЕЛЕМ И ПОДПИСЧИКОМ В СИСТЕМАХ С ШИНОЙ

ПРИНЦИП ОБМЕНА ДАННЫМИ МЕЖДУ ИЗДАТЕЛЕМ И ПОДПИСЧИКОМ В СИСТЕМАХ С ШИНОЙ

СОБЫТИЙ

Условием обмена данными является совпадение подписки на событие и уведомление о событии.
Во многих случаях событие на самом деле соответствует данным, ставшим доступными. В этом случае при совпадении имеется два сценария:
Программное обеспечение промежуточного уровня может решить направить подписчикам уведомления вместе с ассоциированными с этим событием данными. Это называется процессом с совпадением подписки.
Программное ПУ передает только уведомление. При этом подписчики смогут самостоятельно считать требуемые данные. ПО ПУ не предоставляет услуг по хранению данных. Услуги хранения оказываются отдельным сервисом.

Слайд 41

ОСНОВНАЯ ПРОБЛЕМА СИСТЕМ ПУБЛИКАЦИИ/ПОДПИСКИ События могут легко запутать работу подписчиков. В

ОСНОВНАЯ ПРОБЛЕМА СИСТЕМ ПУБЛИКАЦИИ/ПОДПИСКИ

События могут легко запутать работу подписчиков. В

качестве примера рассмотрим такую подписку: "Уведомить, когда номер 1060 будет освобожден и дверь в номер будет не заперта".
Обычно распределенная система, поддерживающая такие подписки, может быть реализована путем установки независимых сенсоров (датчиков) для мониторинга занятости номера (например, датчики движения) и регистрации состояния дверного замка.
Для обеспечения надежной работы такой системы, необходимо сформировать (скомпоновать) такие примитивные события в публикуемые данные, на которые можно было бы подписать процессы получатели данных.
Компоновка событий оказывается сложной задачей, особенно когда простейшие (примитивные) события генерируются источниками, распределенными по всей системе.
Очевидно, что в системах публикации/подписки подобным этой, основная проблема кроется в эффективности и масштабируемости реализации сравнения подписок и уведомлений.
Слайд 42

ОРГАНИЗАЦИЯ ПРОМЕЖУТОЧНОГО ПО (MIDLEWARE) При организации ПО промежуточного уровня в системах

ОРГАНИЗАЦИЯ ПРОМЕЖУТОЧНОГО ПО (MIDLEWARE)

При организации ПО промежуточного уровня в системах основанных

на объектных компонентах, часто используются два шаблона проектирования:
Оболочки (Wrappers).
Перехватчики (Interceptors).
Их применение направлено на достижение открытости системы.
Слайд 43

WRAPPERS ИЛИ ADAPTERS При создании распределенных проблем на основе уже существующих

WRAPPERS ИЛИ ADAPTERS

При создании распределенных проблем на основе уже существующих компонент

мы сразу же сталкиваемся с фундаментальной проблемой:
Интерфейсы предлагаемые унаследованными компонентами, не поддерживаются всеми компонентами.
Оболочка или адаптер – это специальные компоненты которые обеспечивают приемлемый интерфейс для клиента приложения. Функциями адаптера является преобразование интерфейса компонента-сервер в вид удобный для компонента –клиента.
Wrapper реализуется как компонент посредник, обеспечивающий приложению возможность вызова удаленного объекта.
При необходимости обеспечить взаимодействие между N компонентами потребуется создать N(N-1)=O(N2) адаптеров.
Слайд 44

БРОКЕР СООБЩЕНИЙ Уменьшить число адаптеров можно создав промежуточное ПО, которое обеспечит

БРОКЕР СООБЩЕНИЙ

Уменьшить число адаптеров можно создав промежуточное ПО, которое обеспечит централизованное

управление доступом между различными приложениями.
Часто роль такого ПО выполняет брокер сообщений.
Приложения просто посылают брокеру запросы, содержащие всю необходимую информацию для доступа к другому приложению.
В свою очередь брокер, зная как подключиться к требуемому приложению, обращается к нему и получив ответ переправляет его к приложению инициировавшему запрос. В этом случае необходимо реализовать только 2N=O(N) адаптеров, вместо O(N2) .
Слайд 45

ПЕРЕХВАТЧИКИ ОБРАЩЕНИЙ (INTERCEPTORS) Концептуально перехватчик обращений, прерывает нормальный процесс вызова компонент

ПЕРЕХВАТЧИКИ ОБРАЩЕНИЙ (INTERCEPTORS)

Концептуально перехватчик обращений, прерывает нормальный процесс вызова компонент и

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

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

Слайд 46

ОБРАЩЕНИЕ К РЕПЛИКАМ ОБЪЕКТА В Представим, что объект В имеет несколько

ОБРАЩЕНИЕ К РЕПЛИКАМ ОБЪЕКТА В

Представим, что объект В имеет несколько реплик.

В этом случае мы должны обратиться к каждой реплике. В этом может помочь перехватчик – запроса (request-level interceptor).
Хотя объект А ничего не знает о других экземплярах В, но о них знает ПО промежуточного слоя объекта В, выполняющее роль перехватчика обращений уровня запроса.
В конце концов вызов удаленного объекта должен быть передан по сети, для этого необходимо обратиться к интерфейсу локальной ОС А.
На этом уровне используется перехватчик уровня сообщения (message-level interceptor) для передачи вызова удаленному объекту на машине В.
Слайд 47

АДАПТИРУЕМОЕ ПО ПРОМЕЖУТОЧНОГО СЛОЯ Необходимость в адаптируемом промежуточном ПО возникает из-за

АДАПТИРУЕМОЕ ПО ПРОМЕЖУТОЧНОГО СЛОЯ

Необходимость в адаптируемом промежуточном ПО возникает из-за того,

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

ЗАМЕНА КОМПОНЕНТ ВО ВРЕМЯ ИСПОЛНЕНИЯ Примером такого подхода является замена программных

ЗАМЕНА КОМПОНЕНТ ВО ВРЕМЯ ИСПОЛНЕНИЯ

Примером такого подхода является замена программных компонент

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

Исполнение

Слайд 49

СИСТЕМНАЯ АРХИТЕКТУРА

СИСТЕМНАЯ АРХИТЕКТУРА

Слайд 50

ЦЕНТРАЛИЗОВАННАЯ ОРГАНИЗАЦИЯ РС

ЦЕНТРАЛИЗОВАННАЯ ОРГАНИЗАЦИЯ РС

Слайд 51

ВАРИАНТЫ АРХИТЕКТУРЫ КЛИЕНТ-СЕРВЕР Простейшая организация предполагает наличие всего двух типов машин.

ВАРИАНТЫ АРХИТЕКТУРЫ КЛИЕНТ-СЕРВЕР

Простейшая организация предполагает наличие всего двух типов машин.
Клиентские машины,

на которых имеются программы, реализующие только пользовательский интерфейс или его часть.
Серверы, реализующие все остальное, то есть уровни обработки и данных.
На самом деле такая система не является распределенной: все происходит на сервере, а клиент представляет собой не что иное, как простой терминал.
Слайд 52

ФИЗИЧЕСКИ ДВУХЗВЕННЫЕ АРХИТЕКТУРЫ Один из подходов к организации клиентов и серверов

ФИЗИЧЕСКИ ДВУХЗВЕННЫЕ АРХИТЕКТУРЫ

Один из подходов к организации клиентов и серверов —

это распределение программ, находящихся на уровне приложений, по различным машинам.

Первые три варианта соответствуют модели с тонким клиентом.
Варианты 4,5 называются моделью клиент-сервер с толстым клиентом.

Слайд 53

РАЗНОВИДНОСТИ МОДЕЛИ КЛИЕНТ-СЕРВЕР Обычно ПО хранения данных располагается на сервере (например,

РАЗНОВИДНОСТИ МОДЕЛИ КЛИЕНТ-СЕРВЕР

Обычно ПО хранения данных располагается на сервере (например, сервер базы

данных), интерфейс с пользователем на стороне клиента, а обработку данных распределять между клиентской и серверной частями.
Толстый клиент. Такая модель подразумевает объединение в клиентском приложении интерфейса пользователя и обработки данных. Серверная часть в этом случае представляет собой сервер баз данных.
Тонкий клиент. В этом случае клиентское приложение обеспечивает интерфейс с пользователем, а сервер объединяет модули хранения и обработки (толстый сервер).
Многоуровневые системы клиент-сервер. В этих системах некоторая часть функций, связанных с обработкой данных, либо с доступом к модулям хранения, либо с обеспечением многопользовательского доступа, выделяется в отдельный модуль (mieddlware), называемый ПО промежуточного слоя.
Слайд 54

ТОЛСТЫЙ КЛИЕНТ Основным недостатком толстого клиента является сложность администрирования и трудности

ТОЛСТЫЙ КЛИЕНТ

Основным недостатком толстого клиента является сложность администрирования и трудности с

обновлением ПО, поскольку его замену нужно производить одновременно на всех рабочих местах всей информационной системы.
Слайд 55

ТОНКИЙ КЛИЕНТ В тонком клиенте этот недостаток устраняется, однако появляются большие

ТОНКИЙ КЛИЕНТ

В тонком клиенте этот недостаток устраняется, однако появляются большие сложности

в создании ПО серверной части, появляются трудности в объединении модулей обработки и хранения данных.
Слайд 56

ВЗАИМОДЕЙСТВИЕ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ Взаимодействие между клиентом и сервером расположенными

ВЗАИМОДЕЙСТВИЕ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ

Взаимодействие между клиентом и сервером расположенными на

разных машинах часто называют «поведением запрос – ответ»
Слайд 57

МНОГОУРОВНЕВЫЕ СИСТЕМЫ КЛИЕНТ-СЕРВЕР Многоуровневая архитектура клиент-сервер позволяет более разумно распределить модули

МНОГОУРОВНЕВЫЕ СИСТЕМЫ КЛИЕНТ-СЕРВЕР

Многоуровневая архитектура клиент-сервер позволяет более разумно распределить модули обработки

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

ПОВЕДЕНИЕ СЕРВЕРА КАК КЛИЕНТА В СЛОЖНЫХ ПРИЛОЖЕНИЯХ В классической модели клиент-сервер

ПОВЕДЕНИЕ СЕРВЕРА КАК КЛИЕНТА В СЛОЖНЫХ ПРИЛОЖЕНИЯХ

В классической модели клиент-сервер не

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

ПРИМЕР РАБОТЫ СЕРВЕРА В КАЧЕСТВЕ КЛИЕНТА В WEB ПРИЛОЖЕНИИ Другой пример

ПРИМЕР РАБОТЫ СЕРВЕРА В КАЧЕСТВЕ КЛИЕНТА В WEB ПРИЛОЖЕНИИ

Другой пример работа

серверов приложений в среде WEB
Такая архитектура Web приложения, также является В этом физической трехзвенной (three-tiered)
Слайд 60

HTTP Request CFML HTML HTML Database Messaging Directory Services File Server

HTTP Request

CFML

HTML

HTML

Database

Messaging

Directory Services

File Server

Distributed Objects

ТРЕХЗВЕННАЯ АРХИТЕКТУРА СЕРВЕРА ПРИЛОЖЕНИЙ COLD FUSION

Cold Fusion Server

HTTP Server

Слайд 61

ДЕЦЕНТРАЛИЗОВАННАЯ ОРГАНИЗАЦИЯ РС: СИСТЕМЫ PEER-TO-PEER (ОДНОРАНГОВЫЕ СИСТЕМЫ)

ДЕЦЕНТРАЛИЗОВАННАЯ ОРГАНИЗАЦИЯ РС: СИСТЕМЫ PEER-TO-PEER (ОДНОРАНГОВЫЕ СИСТЕМЫ)

Слайд 62

СРАВНЕНИЕ СИСТЕМ P2P И КЛИЕНТ-СЕРВЕР В отличие от классической клиент серверной

СРАВНЕНИЕ СИСТЕМ P2P И КЛИЕНТ-СЕРВЕР

В отличие от классической клиент серверной

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

СРАВНЕНИЕ ПРИНЦИПОВ ПОСТРОЕНИЯ СИСТЕМ P2P И КЛИЕНТ-СЕРВЕР Сравниваемые принципы организации систем:

СРАВНЕНИЕ ПРИНЦИПОВ ПОСТРОЕНИЯ СИСТЕМ P2P И КЛИЕНТ-СЕРВЕР

Сравниваемые принципы организации систем:

управление;
доступность ресурсов;
структура;
мобильность ресурсов;
время жизни;
именование;
синхронизация процессов.

Четкой границы между централизованной и децентрализованной архитектурами не существует.

Слайд 64

СПОСОБЫ РЕАЛИЗАЦИИ РАСПРЕДЕЛЕННОСТИ В СИСТЕМЕ Различают два способа реализации распределенности: Вертикальная распределенность. Горизонтальная распределенность.

СПОСОБЫ РЕАЛИЗАЦИИ РАСПРЕДЕЛЕННОСТИ В СИСТЕМЕ

Различают два способа реализации распределенности:
Вертикальная распределенность.
Горизонтальная распределенность.

Слайд 65

ВЕРТИКАЛЬНАЯ РАСПРЕДЕЛЕННОСТЬ Реализуется путем разбиения приложения на логические уровни связанные иерархически.

ВЕРТИКАЛЬНАЯ РАСПРЕДЕЛЕННОСТЬ

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

характерна для клиент серверных архитектур.
Каждый логический уровень размещается на отдельном узле РС
Слайд 66

ГОРИЗОНТАЛЬНАЯ РАСПРЕДЕЛЕННОСТЬ В этом случае клиент или сервер могут одновременно исполняться

ГОРИЗОНТАЛЬНАЯ РАСПРЕДЕЛЕННОСТЬ

В этом случае клиент или сервер могут одновременно исполняться на

одном и том же узле, разделяя между собой его ресурсы.
Системы поддерживающие горизонтальную распределенность получили название пиринговых систем (peer-to-peer systems)
Слайд 67

ЗАДАЧИ РЕШАЕМЫЕ С ПОМОЩЬЮ Р2Р СИСТЕМ (1) Уменьшение/распределение затрат. Серверы централизованных

ЗАДАЧИ РЕШАЕМЫЕ С ПОМОЩЬЮ Р2Р СИСТЕМ (1)

Уменьшение/распределение затрат. Серверы централизованных систем,

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

ЗАДАЧИ РЕШАЕМЫЕ С ПОМОЩЬЮ Р2Р СИСТЕМ (2) Надежность сети определяется такими

ЗАДАЧИ РЕШАЕМЫЕ С ПОМОЩЬЮ Р2Р СИСТЕМ (2)

Надежность сети определяется такими параметрами

как количество сбоев в работе сети, отношение времени простоя к общему времени работы, до- ступностью ресурсов и т.д. Таким образом, основной проблемой становит- ся разработка новых алгоритмов обнаружения ресурсов, на которых бази- руются новые P2P платформы
Анонимность. Бывает, пользователь не желает, чтобы другие пользователи или поставщики услуг знали о его нахождении в сети. При использовании центрального сервера трудно обеспечить анонимность, так как серверу, как правило, необходимо идентифицировать клиента, по крайней мере через интернет адрес. При использования P2P-сети пользователи могут избежать предоставления любой информацию о себе
Слайд 69

ПРИНЦИПЫ ПОСТРОЕНИЯ РС Р2Р В распределенной системе Р2Р каждый узел участник

ПРИНЦИПЫ ПОСТРОЕНИЯ РС Р2Р

В распределенной системе Р2Р каждый узел участник знает

некоторое число логических соседей с которыми он может поддерживать обмен напрямую, без посредников, посылая и получая в ответ сообщения по сети.
Этот набор соседей формирует логический граф связности для всех узлов системы. Это граф часто называют наложенной сетью Р2Р (overlay network).
Системы Р2Р должны соответствовать следующим критериям:
Самооганизация: система самостоятельно адаптируется к подключению или отключению узла к системе. Пиры используют локальную информацию получаемую от своих соседей для организации взаимодействия друг с другом.
Распределенность: отсутствует централизованное управление поведением узла в системе.
Масштабируемость: система может масштабироваться неограниченно избегая таким образом проблем «бутылочного горла», отказов отдельных узлов и проблем перегрузки узлов.
Слайд 70

КЛАССИФИКАЦИЯ СИСТЕМ Р2Р Системы Р2Р можно классифицировать по двум признакам: По

КЛАССИФИКАЦИЯ СИСТЕМ Р2Р

Системы Р2Р можно классифицировать по двум признакам:
По степени централизации.
По

наличию или отсутствию структуры.
Слайд 71

КЛАССИФИКАЦИЯ Р2Р СИСТЕМ ПО СТЕПЕНИ ИХ ЦЕНТРАЛИЗАЦИИ

КЛАССИФИКАЦИЯ Р2Р СИСТЕМ ПО СТЕПЕНИ ИХ ЦЕНТРАЛИЗАЦИИ

Слайд 72

ЦЕНТРАЛИЗОВАННЫЕ Р2Р СИСТЕМЫ В этом случае некоторая группа узлов отвечает за

ЦЕНТРАЛИЗОВАННЫЕ Р2Р СИСТЕМЫ

В этом случае некоторая группа узлов отвечает за выполнение

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

Пример: Napster
Узел S посылает запрос на определение места размещения некоторых данных к
управляющим узлам (core nodes).
На основе имеющегося у них глобального индекса управляющий узел форвардирует запрос к узлам А и В.
Узлы А и В отвечают напрямую S.
При отправке запроса S устанавливает таймер, по истечение которого, он выбирает узел из числа ответивших ему.

Слайд 73

НЕДОСТАТКИ ЦЕНТРАЛИЗОВАННЫХ P2P СИСТЕМ Управляющие сервера являются потенциальными точками отказа. Такое

НЕДОСТАТКИ ЦЕНТРАЛИЗОВАННЫХ P2P СИСТЕМ

Управляющие сервера являются потенциальными точками отказа.
Такое решение является

плохо масштабируемым.
Эти недостатки отсутствуют в частично централизованных системах.
Слайд 74

ДЕЦЕНТРАЛИЗОВАННЫЕ АРХИТЕКТУРЫ Р2Р СИСТЕМ При очень большом числе пиров гибридные системы

ДЕЦЕНТРАЛИЗОВАННЫЕ АРХИТЕКТУРЫ Р2Р СИСТЕМ

При очень большом числе пиров гибридные системы не

способны обеспечить корректную обработку всех запросов. Они перегружены запросами и не способны их обработать за приемлемое время.
В децентрализованных системах каждый пир принадлежащий к наложенной сети обеспечивает обзор ресурсов только у своих логических соседей.
Для обеспечения устойчивости к отказам отдельных узлов информация о ресурсах принадлежащих каждому пиру реплицируется всем его соседям по наложенной сети.
Децентрализованная система не имеет точек единственного отказа, однако она менее эффективна чем соответствующая централизованная система.
Слайд 75

ПРИМЕР ДЕЦЕНТРАЛИЗОВАННОЙ P2P GNUTELLA В системе Gnutella поиск и предоставление сервисов

ПРИМЕР ДЕЦЕНТРАЛИЗОВАННОЙ P2P GNUTELLA

В системе Gnutella поиск и предоставление сервисов производится

путем процедуры пошагового поиска, в которой могут участвовать все узлы, входящие в сеть.
Каждый узел содержит таблицу соседей, содержащую IP адрес и порт известного узла Gnutella.
При запуске новый узел Gnutella переходит в режим начальной загрузки, в котором посредством одного из доступных источников (список узлов на одном из узлов интернет; внутренний предустановленный список узлов и др.) формирует начальный список соседей.
После чего, соседям высылается сообщение обнаружения, пересылаемое далее по цепочке систем. Таким образом обеспечивается обнаружение ресурсов, предоставляемых всеми узлами подключенными к сети.
Слайд 76

КЛАССИФИКАЦИЯ Р2Р СИСТЕМ ПО ИХ СТРУКТУРЕ

КЛАССИФИКАЦИЯ Р2Р СИСТЕМ ПО ИХ СТРУКТУРЕ

Слайд 77

СТРУКТУРИРОВАННЫЕ Р2Р СИСТЕМЫ Структура Р2р системы определяется структурой наложенной сети, которая

СТРУКТУРИРОВАННЫЕ Р2Р СИСТЕМЫ

Структура Р2р системы определяется структурой наложенной сети, которая может

иметь одну из известных топологий:
кольцо;
Двоичное дерево;
Решетка;
И т.п.
Эта топология используется для эффективного поиска данных (ресурсов).
Слайд 78

ИНДЕКС РЕСУРСА СТРУКТУРИРОВАННОЙ P2P СИСТЕМЫ Характеристикой структурированной Р2Р системы является так

ИНДЕКС РЕСУРСА СТРУКТУРИРОВАННОЙ P2P СИСТЕМЫ

Характеристикой структурированной Р2Р системы является так называемый

индекс, который однозначно определяет каждый экземпляр данных поддерживаемый в системе и соответственно каждый узел располагающий каким-либо ресурсом.
Соседство в системе определяется по близости значений индексов у узлов.
В качестве такого индекса используется ключ хэш функции:
Key(data item) = hash(data item's Value).
Слайд 79

РАСПРЕДЕЛЕННАЯ ХЭШ ТАБЛИЦА (DISTRIBUTED HASH TABLE) Каждому узлу структурированной P2P системы

РАСПРЕДЕЛЕННАЯ ХЭШ ТАБЛИЦА (DISTRIBUTED HASH TABLE)

Каждому узлу структурированной P2P системы назначается

идентификатор из одного того же набора значений хэша. И каждый узел становится ответственным за хранение данных, связанных (ассоциированных) с определенным набором ключей.
По сути, система описывается с помощью таблицы хэшей - распределений хэш таблицы (DHT - Distributed Hash Table).
Слайд 80

ПОИСК УЗЛА СТРУКТУРИРОВАННОЙ P2P СИСТЕМЫ Для того чтобы найти узел, ассоциируемый

ПОИСК УЗЛА СТРУКТУРИРОВАННОЙ P2P СИСТЕМЫ

Для того чтобы найти узел, ассоциируемый с

ключом, необходимо выполнить операцию поиска узла по ключу:
node = lookup (key).
В задаче поиска топология наложенной сети играет ключевую роль.
Любой узел однозначно связан с некоторым ключом, что позволяет организовать эффективную маршрутизацию для поиска узла, ответственного за хранение ресурса.
Слайд 81

ПРИМЕР СТРУКТУРИРОВАННОЙ P2P СИСТЕМЫ - ГИПЕРКУБ Примером простой P2P системы с

ПРИМЕР СТРУКТУРИРОВАННОЙ P2P СИСТЕМЫ - ГИПЕРКУБ

Примером простой P2P системы с ограниченным

числом узлов может служить гиперкуб.
Гиперкуб - это n-размерный куб. Топология гиперкуба при n=4 следующая.
Экземпляры данных связаны с узлами, которые в гиперкубе представляются вершинами.
Каждой вершине (узлу) устанавливается идентификатор от 0 до 24-1.
Слайд 82

ПОИСК ПО ГИПЕРКУБУ Предположим, узел 0111(7) ищет данные, имеющие идентификатор 1110(14).

ПОИСК ПО ГИПЕРКУБУ

Предположим, узел 0111(7) ищет данные, имеющие идентификатор 1110(14).

Слайд 83

ПОИСК В СИСТЕМЕ С ТОПОЛОГИЕЙ КОЛЬЦО (СИСТЕМА ХОРД) Узлы образуют наложенную

ПОИСК В СИСТЕМЕ С ТОПОЛОГИЕЙ КОЛЬЦО (СИСТЕМА ХОРД)

Узлы образуют наложенную сеть логическое

кольцо. В которой каждый экземпляр данных имеет ключ к состоящий из m-бит.
Key(data item) = hash(data item's Value).
Ключ данных отображается на узел id= map(key), имеющий наименьший идентификатор id ≥ key
Этот узел называется приемник (successor)
suc(keyi)=id
Слайд 84

ПОИСК УЗЛА В СИСТЕМЕ ХОРД Предположим, узел 9 ищет узел отвечающий

ПОИСК УЗЛА В СИСТЕМЕ ХОРД

Предположим, узел 9 ищет узел отвечающий

за экземпляр данных с ключем 3 (это будет узел 4).
Узел 9 имеет дуги с узлами 11,14, 18 и 28. Так как самым дальним является узел 28, то к нему и обращается узел 9.
Узел 28 имеет дуги с 1, 4 и 14, и он не знает о существовании узла между узлами 1 и 4. Поэтому он форвардирует запрос к узлу 1.
Узел 1 знает, что он предшествует узлу 4, а значит узел 4 отвечает за ключ 3, поэтому он направляет запрос к узлу 4.
Узел 4 ответит узлу 9 напрямую.

В показанной сети m=5 (25) ключи экземпляров данных key = {0-31} и
девять узлов id = {1,4,9,11,14,18,20,21,28}.
Каждый узел связан “кратчайшими”дугами с другими узлами (как это делается
пока не важно).
Для поиска ключа узел посылает запрос к узлам с которыми он связан дугами.

Слайд 85

ПОИСК С ПОМОЩЬЮ МАРШРУТИЗАЦИИ ДОКУМЕНТОВ (1) Данный метод обеспечивает поиск документов

ПОИСК С ПОМОЩЬЮ МАРШРУТИЗАЦИИ ДОКУМЕНТОВ (1)

Данный метод обеспечивает поиск документов без

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

Когда какой-либо пир (на рисунке – узел 7008) производит публика- цию ресурса в сети, каким-либо образом вычисляется идентификатор данного ресурса (на рисунке – документ 0110). При этом, идентификаторы узлов сети и ресурсов имеют единую область возможных значений.
Далее, копия данного ресурса (или ссылка на него) связывается с узлуом, который имеет наиболее похожий идентификатор, на рисунке показана трасса документа 0110:
узлы 7008 – 0459 – 0009 – 0040.
Данная процедура производится следующим образом:
Производится сравнение идентификатора ресурса с идентификаторами всех соседних узлов.
Если идентификатор текущего узла ближе всего (по некоторой метрике) к идентификатору документа, то процесс трассировки завершается.

Если один из идентификаторов соседних узлов ближе к идентификатору документа, чем идентификатор текущего узла, то ссылка на данный ресурс копируется на узел с более близким идентификатором и процесс повторяется с п. 1. (узел 0040 на рисунке).

Слайд 86

ПОИСК С ПОМОЩЬЮ МАРШРУТИЗАЦИИ ДОКУМЕНТОВ (2) Поиск ресурса производится по аналогичному

ПОИСК С ПОМОЩЬЮ МАРШРУТИЗАЦИИ ДОКУМЕНТОВ (2)

Поиск ресурса производится по аналогичному алгоритму,

но вместо копирования документа происходит трансляция запроса (в запросе содержится идентификатор запрашиваемого ресурса, например 0110 на рисунке 57) от узла, инициировавшего запрос (на рисунке – узел 5203) к узлу, идентификатор которого ближе всего соответствует идентификатору запрашиваемого документа.
Соответственно, в процессе трансляции данного запроса должен появиться такой узел, который хранит информацию об интересуемом документе, если данный документ находится в соответствующей части сети.
К недостаткам такого подхода можно отнести необходимость знания точного идентификатора документа, который необходимо найти в сети (невозможность поиска по отдельным атрибутам документа), а также возможность образования «островов», затрудняющих алгоритм поиска.
Слайд 87

НЕСТРУКТУРИРОВАННЫЕ P2P СИСТЕМЫ Они не имеют определенной топологии. Каждый узел в

НЕСТРУКТУРИРОВАННЫЕ P2P СИСТЕМЫ

Они не имеют определенной топологии.
Каждый узел в такой системе

поддерживает список соседних узлов, а об остальных он ничего не знает.
В результате наложенная сеть такой системы представляет собой случайный граф: - граф в котором дуга между вершинами существует с некоторой вероятностью P[]. В идеале эта вероятность имеет одно и тоже значение, для всех пар вершин.
При присоединении узла к Р2Р системе, он контактирует с общеизвестными в системе узлами и получает от них список других пиров от которых он может узнать о еще большем числе пиров.
В таких системах, если пир хочет найти какой-либо ресурс, то он не может следовать какой-то определенной процедуре маршрутизации. Он должен прибегнуть к специальной процедуре поиска установленной в этой системе.
Имеется два предельных метода поиска в таких системах:
Метод затопления (flooding).
Метод случайного блуждания (random walk).
Слайд 88

МЕТОД ЗАТОПЛЕНИЯ Узел u посылает запросы ко всем известным ему соседям.

МЕТОД ЗАТОПЛЕНИЯ

Узел u посылает запросы ко всем известным ему соседям.
Если

узел v имеет требуемые данные, то он либо посылает их напрямую узлу породившему запрос, либо отсылает их к узлу форвардеру от которого он получил запрос.
Если узел не имеет данных, то он форвардирует запрос ко всем своим соседям.
Если узел уже получал такой запрос, то он не будет повторно на него отвечать.
Для того, чтобы избежать избежать сильного затопления системы, для запросов устанавливается время жизни (TTL-Time to live). Каждый промежуточный узел обрабатывающий запрос уменьшает TTL на 1. Когда TTL станет равным 0 запрос удаляется из системы.
От выбора значения TTL сильно зависит эффективность поиска и степень затопления системы запросами.
Слайд 89

МЕТОД СЛУЧАЙНОГО БЛУЖДАНИЯ Узел u просто опрашивает соседей выбирая их случайным

МЕТОД СЛУЧАЙНОГО БЛУЖДАНИЯ

Узел u просто опрашивает соседей выбирая их случайным образом.

Например, пусть u выберет для опроса узел v.
Если v имеет требуемые данные, то он напрямую ответит u, если нет, то v форвардирует запрос своему соседу, выбранному случайным образом.
Очевидно, что этот метод порождает значительно меньший трафик, но для поиска нужного ресурса может потребоваться значительно больше времени.
Для уменьшения времени ожидания узел источник процедуры поиска может одновременно стартовать n процедур случайного блуждания. В этом случае в этом случае время поиска снижается в n раз.
Случайное блуждание также требует своей принудительной остановки. Для этого можно также использовать TTL, либо можно установить условия при которых узел принявший запрос сам определит нужно форвардировать запрос случайным образом далее или нет.
Для неструктурированных систем также необходимо определить порядок сравнения для определения признака нахождения искомых данных. Это могут быть те же методы, которые применяются в структурированных системах Р2Р.
Слайд 90

МЕТОД ПОИСКА ОСНОВАННЫЙ НА ПОЛИТИКЕ Этот метод занимает промежуточное положение между

МЕТОД ПОИСКА ОСНОВАННЫЙ НА ПОЛИТИКЕ

Этот метод занимает промежуточное положение между методами

затопления и случайного блуждания.
В этом методе для выбора узлов в качестве соседей используется некоторая установленная политика.
Например:
в качестве узлов к которым перенаправляются запросы выбираются узлы, которые ранее более успешно выполняли поиск, по сравнению с другими узлами.
в качестве узлов к которым направляются запросу выбираются узлы, имеющие наибольшее число соседей.
и т.п.
Слайд 91

ИЕРАРХИЧЕСКИ ОРГАНИЗОВАННЫЕ Р2Р СИСТЕМЫ В не структурированных системах по мере их

ИЕРАРХИЧЕСКИ ОРГАНИЗОВАННЫЕ Р2Р СИСТЕМЫ

В не структурированных системах по мере их роста

поиск данных может стать невозможен. Источник этой проблемы масштабируемости очевиден – отсутствие детерминированой процедуры маршрутизации запросов поиска ресурсов.
В качестве альтернативы во многих неструктурированных системах создаются специальные узлы хранящие индекс экземпляров данных имеющихся в системе.
Имеются и другие ситуации в которых отказ от симметричной природы р2р систем имеет смысл. Например, сети доставки контента (CDN – Content Delivery Network).
В CDN сетях узлы системы хранят копии Web документов отдельных сайтов Интернет к которым пользователям требуется быстрый доступ. Для поиска узлов используются брокеры, которые хранят сведения о степени используемости ресурсов и доступности узлов, что позволяет выбирать наиболее подходящий из узлов для получения ресурсов.
Слайд 92

ИЕРАРХИЧЕСКАЯ ОРГАНИЗАЦИЯ СЕТИ Р2Р Узлы играющие роль брокеров, а также узлы

ИЕРАРХИЧЕСКАЯ ОРГАНИЗАЦИЯ СЕТИ Р2Р

Узлы играющие роль брокеров, а также узлы поддерживающие

индекс ресурсов называются супер-узлами. Супер-узлы часто образуют сеть р2р. Обычные узлы выполняющие роль клиентов супер-узлов называют слабыми (weak nodes).
В этих сетях супер-узлы должны всегда оставаться доступными в сети. Это создает проблемы надежности, которые можно компенсировать, путем развертывания системы копирования восстановления между парами супер-узлов, и обеспечением подключения рядовых узлов к обеим супер-серверам.
В сетях с супер-узлами, возникают и другие проблемы, например как отбирать узлы для роли супер-узлов.
Слайд 93

ИЕРАРХИЧЕСКАЯ Р2Р СИСТЕМА. ПРИМЕР: SKYPE Самой популярной на сегодняшний день службой

ИЕРАРХИЧЕСКАЯ Р2Р СИСТЕМА. ПРИМЕР: SKYPE

Самой популярной на сегодняшний день службой Интернет-телефонии

является Skype, созданная в 2003 году шведом Никласом Зеннстромом и датчанином Янусом Фриисом, авторами известной пиринговой сети KaZaA.
В настоящее время Skype принадлежит корпорации Microsoft, которая приобрела ее за $8,5 млрд. в мае 2011 года.
В состав системы входят следующие элементы:
Skype-login сервер – единственный централизованный элемент Skype-сети, обеспечивающий авторизацию Skype-клиентов.
Обычный узел (Skype Client) – обычный конечный узел в сети.
Супер-узел (Super node) – узлы, играющие роль роутеров в сети Skype.
Выделенные узлы для установки связи со стационарными телефонными линиями.
Каждый узел Skype-сети хранит перечень IP-адресов и портов известным ему super-узлов в динамически обновляемых кэш-таблицах (Host Cache Tables, HC-tables). Начиная с версии Skype 1.0, кэш-таблицы представляют собой простой XML-файл, в незашифрованном виде записанный на диске в домашней директории пользователя.
Любой узел, имеющий публичный IP-адрес (т.е. тот, который маршрутизируется в Ин- тернет) и обладающий достаточно широким каналом, автоматически становится super-узлом и пропускает через себя трафик обычных узлов, помогая им преодолеть защиты типа брандмауэров или трансляторов сетевых адресов (NAT) и равномерно распределяя нагрузку между хостами.
Единственным централизованным элементом является Skype-login сервер, отвечающий за процедуру авторизации Skype-клиентов и гарантирующий уникальность «позывных» для всей распределенной сети.
Слайд 94

ГИБРИДНЫЕ АРХИТЕКТУРЫ Р2Р СИСТЕМ

ГИБРИДНЫЕ АРХИТЕКТУРЫ Р2Р СИСТЕМ

Слайд 95

ГИБРИДНЫЕ АРХИТЕКТУРЫ Р2Р Существует множество архитектур РС в которых успешно сочетаются

ГИБРИДНЫЕ АРХИТЕКТУРЫ Р2Р

Существует множество архитектур РС в которых успешно сочетаются архитектуры

клиент сервер и децентрализованные архитектуры Р2Р систем.
Слайд 96

ЧАСТИЧНО ЦЕНТРАЛИЗОВАННЫЕ (ГИБРИДНЫЕ) СИСТЕМЫ Р2Р В этих системах все узлы делятся

ЧАСТИЧНО ЦЕНТРАЛИЗОВАННЫЕ (ГИБРИДНЫЕ) СИСТЕМЫ Р2Р

В этих системах все узлы делятся на

несколько типов в зависимости от иерархической организации. В двухуровневой системе имеется два вида узлов:
суперузлы (supernodes); мощные узлы связанные между собой хорошими каналами связи. Хранят метаданные о расположении ресурсов и
рядовые пиры (peers); связаны с одним или несколькими суперузлами.

Пример Kazaa:
Узел S к ближайшему суперузлу запрос на поиск ресурса. Суперузел
форвардирует это запрос ко всем подключенным узлам.
Узел А отвечает на запрос напрямую к S.
Так как запрос форвардируется и к другим суперузлам, то него отвечает и узел С.
S выбирает сам к какому из ответивших узлов обраться для получения ресурса.

Слайд 97

СИСТЕМЫ С ГРАНИЧНЫМИ СЕРВЕРАМИ Эти системы разворачиваются в Интернет, при этом

СИСТЕМЫ С ГРАНИЧНЫМИ СЕРВЕРАМИ

Эти системы разворачиваются в Интернет, при этом на

границах сетей сервис провайдеров (ISP – Internet Service Provider) размещаются сервера этих систем.
Конечные пользователи этих систем располагаются в сетях сервис провайдеров и подключаются к распределенной системе через граничные сервера.
Основное назначение граничных серверов предоставлять контент для пользователей, возможно после предварительной фильтрации и перекодировки.
Базовая модель состоит в том, что для организации граничный сервер является источником всего контента, получаемого из Интернет. Этот сервер может использовать другие граничные сервера, например для репликации Web страниц. страниц.
Слайд 98

СИСТЕМЫ НА ОСНОВЕ ВЗАИМНОГО СОТРУДНИЧЕСТВА (COLLABORATIVE SYSTEMS) Гибридная архитектура особенно широко

СИСТЕМЫ НА ОСНОВЕ ВЗАИМНОГО СОТРУДНИЧЕСТВА (COLLABORATIVE SYSTEMS)

Гибридная архитектура особенно широко используется

в системах на основе взаимного сотрудничества. В качестве примера рассмотрим BitTorent.
Основная идея состоит в том, что пользователь загружает файл не из одного места, а из множества источников по частям. Такими источниками являются машины других пользователей, которые тоже ищут в системе файлы для закачки, но должны предоставлять доступ к уже закаченным файлам. Данное условие обеспечивает поддержку сотрудничества между пользователями.
Протокол BitTorrent был разработан в 2001 Брэмом Коэном.
Слайд 99

BITTORRENT Если узел хочет опубликовать файл или набор файлов, то программа-

BITTORRENT

Если узел хочет опубликовать файл или набор файлов, то программа- клиент

BitTorrent сети разделяет передаваемые файлы на части и создает файл метаданных (идентификатор раздачи), который содержит следующую информацию:
URL трекера (супер-сервера, который хранит актуальную информацию об активных узлах которые имеют отдельные части файла);
Общая информация о файлах (имя, длина и пр.);
Хеш-суммы SHA1 сегментов раздаваемых файлов;
Passkey пользователя – ключ, который однозначно определяет пользователя загрузившего файл;
Хеш-суммы файлов целиком (не обязательно);
Альтернативные источники – адреса альтернативных трекеров, на которых можно найти информацию по данному файлу (не обязательно).
Алгоритм загрузки документа производится следующим образом:
клиент подключается к трекеру по URL из файла метаданных;
сообщает хеш-идентификатор требуемого файла;
получает адреса пиров скачивающих и раздающих данный файл;
клиенты соединяются между собой и обмениваются информацией без участия трекера.
В последнее время стала распространяться альтернативная технология поиска и загрузки документов на основе «магнитных ссылок» (magnet links) и подхода распределенных хеш-таблиц (Distributed Hash Table — DHT) по сути дела представляющих собой реализацию алгоритма маршрутизации документов.
Причина возникновения этой технологии – дальнейшее развитие деперсонализации и попытка торрент-трекеров защититься от юридического преследования правообладателей. Торрент-файл для такой раздачи создаётся без адреса трекера и клиенты находят друг друга через распределенные хеш-таблицы.
Слайд 100

ПРИМЕНЕНИЕ СИСТЕМ P2P Наибольшее распространение пиринговые системы получили при реализации сиситем

ПРИМЕНЕНИЕ СИСТЕМ P2P

Наибольшее распространение пиринговые системы получили при реализации сиситем предназначенных

для обработки больших объемов данных и обеспечивающих индивидуальный обмен информацией между пользователями.
В настоящий момент, технологии P2P наиболее ярко представлены в 3-х направлениях:
Распределенные вычисления: разбиение общей задачи на большое число независимых в обработке подзадач (проекты на платформе BOINC ); Файлообменные сети: P2P выступают альтернативой FTP-архивам, которые утрачивают перспективу ввиду значительных информационных перегрузок (однако требуются эффективные механизмы поиска) (Gnutella, eDonkey, BitTorrent );
Приложения для совместной работы: требуют обеспечения прозрачных механизмов для совместной работы. (Skype, Groove ).
Слайд 101

ДОСТОИНСТВА P2P СИСТЕМ Можно выделить следующие основные преимущества пиринговых систем: высокая

ДОСТОИНСТВА P2P СИСТЕМ

Можно выделить следующие основные преимущества пиринговых систем:
высокая масштабируемость, связанная

с равномерным распределением вычислительной нагрузки на всех участников сети;
стабильность работы сети, обусловленная отсутствием таких «узких мест» как выделенный сервер, обрабатывающий все сетевые запросы;
возможность объединения ресурсов отдельных участников сети, и их предоставление другим участникам;
распределение совокупных затрат на предоставление ресурсов между участниками сети.
- Предыдущая
Наш дружный класс. Фотоальбом
Следующая -
testovoe_zadanie_po_10_teme

Похожие презентации

Тестирование. По урок 15. Интеграционное тестирование
Особенности оформления письма-запроса как вида информационно-справочной документации
Система электронного документооборота
Исключения. Методы обработки исключений
Нормальная форма БД
Виды компьютерных вирусов Подготовила: Жигалова Катя Проверила: Выпрева Вера Владимировна
Моделирование и оптимизация процессов и систем сервиса
Методы оптимальных решений
Организация сети NGN/IMS микрорайона г. Новогрудок
Конкурентная разведка. Разведывательный цикл (тема 2.1)
Основные понятия Баз данных. Система управления базами данных Mіcrosoft Access и ее основные возможности
Принцип работы сред программирования. Интерпретаторы и компиляторы
Тест по информатике (3 класс)
Массивы
Знакомство со средой программирования Раsсаl. Стандартные математические функции
Тестирование программного обеспечения (Часть 1)
Киберспорт, как массовая культура
Презентация "Базы данных 7" - скачать презентации по Информатике
Компьютерная графика 08/09/15
Hegel and dialectics doing in software engineering
Алгоритм это выполнения команд последовательность
АНГЛОЯЗЫЧНЫЙ ИНТЕРНЕТ Халина Евгения, Фасолько Светлана МОУ СОШ №12 Им. Сметанкина В. Н. 9 «А» класс г. Находка 2009г. Руководител
Понятие Интернет
Обеспечение безопасности информации в современных информационных системах (тема № 9)
Информационные системы и основы баз данных. Лекция 5
тема 1.1 - информационные системы
Вирусы
Урок №3. Формы представления данных (таблицы, формы, запросы, отчеты)
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть