2.4. Связь посредством сообщений 131
рые подходят для синхронных процессов. Ограничиваться исключительно этими
средствами во многих случаях нереально, особенно если принять во внимание
географическую масштабируемость.
Необходимость в службах сохранной связи стала очевидной, когда разработчикам
программного обеспечения промежуточного уровня потребовалось интегрировать
приложения в крупные и сильно разветвленные взаимосвязанные сети.
Подобные сети часто разбросаны по различным подразделениям и административным
зонам, части которых не всегда могут быть доступны немедленно. Например,
доступ может быть ограничен по причине сбоев в сети или процессах.
Для решения подобных проблем были разработаны частные решения на базе сохранной
связи, но подобные решения, как легко понять, не вполне удовлетворяли
требованиям переносимости и работоспособности в разных условиях.
Другам недостатком нерезидентной связи можно считать тот факт, что в случае
возникновения ошибки необходимо немедленно замаскировать ее и запустить
процедуру восстановления. Невозможность отложить восстановление в данном
случае означает нарушение прозрачности по отказам. В случае же сохранной связи
приложение разрабатывается в расчете на длительные задержки между посылкой
сообщения и получением ответа на него. Соответственно, мы можем прибегнуть
к несложным, хотя возможно и медленным способам маскировки ошибок
и восстановления.
Должно быть понятно, что выбор исключительно между нерезидентным и сохранным
типами связи во многих случаях неприемлем. Аналогично, только синхронный
и асинхронный типы связи — это еще не все. В зависимости от задач
распределенной системы ей могут потребоваться все возможные типы связи. Ранее
мы говорили в основном о нерезидентной синхронной связи — RPC и RMI.
Другие формы взаимодействия, как правило, представлены системами, работающими
на основе передачи сообщений. Эти системы мы обсудим в следующих
пунктах. Мы проясним разницу между нерезидентной и сохранной связью.__
Базовый интерфейс очереди
Put – добавить сообщение в соответствующую очередь
Следовательно, маршрутизаторы могут помочь в создании масштабируемых
систем очередей сообщений. Однако по мере роста сети очередей сообщений
становится ясно, что ручное конфигурирование этой сети скоро станет невозможным.
Единственным решением будет использование динамической схемы
маршрутизации, такой же как в компьютерных сетях. В этом отношении легкое
удивление вызывает тот факт, что подобные решения до сих пор не встроены
в какие-нибудь популярные системы очередей сообщений.
Другой причиной использования ретрансляторов является их способность
производить вторичную обработку сообщений. Так, например, в целях безопасности
или защиты от сбоев может быть необходимо ведение журнала сообщений.
Специальный тип ретрансляторов, о котором мы поговорим в следующем
пункте, в состоянии работать как шлюз, преобразуя сообщения в удобный для
получателя вид.
И, наконец, ретрансляторы могут использоваться для групповой рассылки.
В этом случае входящее сообщение просто помещается в каждую из исходящих
очередей.
Брокер сообщений:
- они конвертируют сообщения из одного формата в другой. Для самих приложений, которые отправляю / получают сообщения об этом даже не догадываются.
Потоки данных
Поток данных – последотельность элементов данных.
-асинхронные потоки данных (в них не накладываются какие то лимиты ограничений)
- синхронные потоки данных (накладываются ограничения на времядоставки сообщений и интервал между сообщениями)
Характеристики сенхронных потоков данных:
- Максимальный размер элемента данных (в случае с видио – размер одного кадра)
- Размер корзины элементарных данных (в случае с “какимто” кодированием звука – 2 байта)
- Максимальная скорость передачи данных
- Скорость передачи корзины элементарных кадров
Характеристики качества обслуживания:
Чувствительность к потерям (байт)
Чувствительность к интервалам (мс)
Чувствительность к групповым потерям (элементов данных)
Минимальная фиксируемая задержка (мс)
Максимальная фиксируемая задержка (мс)
Максимальное отклонение задержки (мс)
Показатель собдения (единиц)
Синхронизация потоков данных
Чем производится синхронизация
Пользоатльским приложением
Промежуточной средой
Где производится синхронизация
На отправителе
На получателе
Синхронизация приложением
Синхронизация промежуточным ПО
(159 страница)
(Задание на практику: JSP - она используется для генерации …структурированных документов (как правило HTML) , ДЗ – JSP, индивидуальные задания)
28.03.2013
Сервис - ориентированная архитектура - это парадигма организации, сервисно ... ресурсов, таких как приложения и данных, находящихся в разных административных доменах для получения желаемого результата конечных пользовтелей. Конечным потребителем этих ресурсов может выступать как пользователь, так и другая программа, а сам сервис - это логическая единица. Сервис - ор архитектура - развитие клиент серверной архитектуры.
Цели создание СО архитектуры (чего хотели достич) :
1) Расширение повторного использования обхода
2) Независимость от используемых платформ, инструментов и языков разработки.
3) Повышение масштабируемости создаваемых систем
4) Улучшение управляемости создаваемых систем
5) Сокращение издержек при разработке приложений за счёт упорядочевания процесса разработки и за счёт всего перечисленного
Общие принципы SOA:
Архитектура не привязана к определённой ретхнологии
Независиость от конкретных платформ
Независимость от ЯП
Независимость от конкретных пиложений
Организация сервиса как слабосвязанных компонентов
Принципы проектирования сервисов (что надо учитывать, при проектировании конкретного сервиса):
Стандартизированность
Слабая связность сервисов с другими сервисами
Максимальная абстрагиврованность сервисов
Максимальное переиспдользование кода
Автономность
Минимизация информации о кнутреннем состоянии
Обнаруживаемость сервисов
Конструируемость
Виды сервисов:
- Сервис - задача – для решения какой либо задачи (например разложить число на множители)
- Сервис –сущность (соответствует какому то объекту, например очереди)
- Сервис – утилита (системные сервисы, они общие для разных прикладных задач (например сервис логирования))
Веб - сервисы
- программная система, идентифицируемая строкой URI, чьи общедоступные интефейся определены на языке XML. Описание жто программной системы может быть найдено другими программными системами, которые могут взаимодействовать… … …
Используемые технологии:
- XML – расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных
- SOAP – протокол общмена сообщениями на базе XML
- WSDL – язык описания внешних интерфейсов веб – сервисов, основанных на XML.
- UDDI – интегральный интерфейс распознавания, описания и интеграции (каталог веб сервисов)
(*Картинка схемы взаимодействия (У серёги есть))
Достоинства и недостатки Вуб Сервисов:
+ обеспечивают взаимодействие программных систем независимо от платформы
+ позволяют вести разработку на большом количестве разных языков программирования
+основаны на открытых стандартах и протоколах
+ простоты в разработкее и отладке, благодаря использванию XML
+ использование HTTP притокола позволяет вазимодействовать программам через межсетевые экраны
- меньшая производительность и большой трафик из-за использвания текстовых XML-сообщений
Облачные вычисления
это модель, которая по запросу через сеть, предоставляет удобный доступ, ко множеству настраеваемых, разделяеваемых ресурсов, таких как: сети, сервера, хранилища данных, программы, сервисы и т.д. Которые могут быть быстро предоставлены и освабождены с минимальными усилиями со стороны их провайдера.
Ключевые характеристики:
- Быстрота развертывания (ресурсы могут быть быстро предоставлены)
- API (облака предоставляют интерфейс для прикладных программ)
- Низкая стоимость
- Независимость от устройства и местоположения (к ресурсам в облаке можно обратиться с любой точки земного шара через интернет и с любой платформы)
- Многопользовательность
- Расположение инфраструктуры в местах с низкими издержками
- Пиковая нагрузка
- Эффективность использования ресурсов (за счёт того, что пиковая нагрузка в относительном выражении к средней нагрузке – маленькая)
- Надёжность
- Масшатбируемость (динамическая, быстра – как только потребуютс ресурсы, они тут же могут быть выделены, если стали не нужны- тут же могут быть освабождены)
- Безопасность
- Поддержка
- Измеримость потребленных ресурсов
Виды облаков:
Общее облако
Частное облако (облако, организованное внутри какой то организации, доступ к которому из вне – запрещён)
Community cloud (облако сообщества, несколько организаций работающих в общем направлении)
Облако облаков (совокупность всех облаков)
Общее облако:
- гомогенная инфраструктура
- Общае политики
- Разделяемые ресурсы, много арендаторов
- Арендованная инфраструктуа, операционные издержки
- Масштабируемость и экономия на масштабе
Частное облако:
- Гетерогенная инфраструктура
- Собственные политики
- Выделенные ресурсы
- Собственная инфраструктура, капитальные издержки
- Полный контроль
Виды сервисов в облаках:
- Infrastructure-as-a-Service (IaaS)- инграструктура как сервис.
- Platform-as-a-Service (PaaS) – платформа как сервис
- Software-as-a-Service (SaaS) – программное обеспечение как сервис
и д.р.
Недостатки облаков:
- Требуется постоянное соединение с Интернет
- Плохо работакет с медленным доступом в Интернет
- Программы могут работать медленнее, чем при локальной установке
- Контроль над инфраструктурой
- Конфиденциальность данных и алгоритмов.
(Практическое задание: с помощью джава RMI организовать распределённое вычисление в нашем индивидуальном задании. Сделать несколько RMI серверов, котрые будут производить вычисления. RMI сервер будет решать подзадачу. Должен быть один клиент, который обращается к этим серверам, передаёт им параметры подзадач, … клиент их агригирует и возвращает результаты браузеру. Для того, чтобы реализовать RMI программу на джава, надо сделать следующее:
Описать интерфейс для удалённого класса:
import java.rmi.Remote;
import java.rmi.RemoteExceptin
public interface TestRmiInt extends Remote
{
public int Addition (int a, int b) throws RemoteException;
}
после описания интерфейса, надо написать медот класса (есть фото у сергея), и метод main, чтобы зарегистрировать. Внутри объекта, создаётся метод класса, которому он принадлежит. В последующем, при обращении к реестру, по имени можно получить ссылку на объект. После реализации сервера, надо будет сделать клиента, который сервер использует, для того, чтобы…………………………….
04.04.13
Грид – географически распределённая инфроструктура, объединяющая множество ресурсов разных типов (процессоры, ОП, хранилища и баз данных, сети, приложения и т.д.) доступ к которым пользвователь может получить из любой точки земного шара не зависимо от расположения этих ресурсов.
Доступ к грид осуществляется через виртуальную оргаизацию:
- множество географических удалённых ресурсов и людей
- из разных административных доменов, об\ъединённых сетью
- совместно использующие ресурсы и имеющие общие цели
- с динамически меняющемся составом
- отказоустойчевые
Грид близки к Облачным вычислениям. Грид появился раньше облаков.
Критерий ГРИД (Ян Фостер):
ГРИД это система, которая:
- соординирует использование ресурсов при отсутствии централизованного управления этими ресурсами
- использует стандартные, открытые, уиверсальные и т.д. протоколы и интерфейсы
-Нетривиальным образом обеспечивает высококачественное обслуживание (целое бьольше, чем просто сумма)
ГРИД ли это?? (По Яну Фостеру)
Web – no
Internet – no
CORBA
BitTorrent – yes
BOINC (SETI@home)
????????????
Предопосылки:
-Грид возник, Когда появилась потребность в больших мозностях и больших вычислительных данынх.
- Необходимость в совместной работе географически удалённых пользователей
- Необходимость в больших хранилищах данных
- Развитие технологии высокоскоростной передачи данных
ГРИД без ипользования Middleware
ГРИД с использованием Globus Toolkit
Архитектура ГРИД:
Уровни грид:
Базовый
Коммуникационный
Ресурсный
Коллективный
Прикладной
Модель песочных часов:
Прикладной->Коллективный->РЕсурсный->Коммуникационный->Базовый
Базовый уровень (Fabric Layer):
-описывает службы непосредственно работающие с ресурсами
- Вычислительные ресурсы (комптютер, кластер, суперкомпьютер,…)
- ресурсы хранения данных
- сенсоры
Уровень связи (Connectivity Layer):
-определяет коммуникационные протоколы и протоколы аутентификации
- Коммуникационные протоколы обеспечивают обмен данными между компонентами базового уровня
- Протоколы аутентификации предоставляют криптографические механизмы для идентификации и проверки подленности пользователй и ресурсов.
Ресурсный уровень (Куыщгксу Дфнук):
-согласование политик безопасности использования ресурса
- процедура инициации ресурса
- Мониторинг состояния ресурса
- Учёт использования ресурсва
Протоклы относящиеся к ресурсному уровню состоят из 2х классов:
- информационные протоколы
- протоколы управления
Коллективный уровень (Collectuve Layer)|:
отвечает за глобальную интеграцию различных наборов ресурсов
_сервисы для определения, планирования, распределения
…
Прикладной уровень:
- описывает пользовательские приложения которые описаны в ГРИД.
BOINC:
Berkeley Open Infrastructure for Network Computing
SETI@home — анализ радиосигналов с радиотелескопа Аресибо, а также ряда других радиотелескопов мира, для поиска внеземных цивилизаций. Для определения сигнал делили на части и рассылалаи на компы добровольцев.
BOINC – добровольцы предоставляют вычислительные мощности. Любой желающий может подключить свой компьютер к проекту и на его компьютер будут выполняться подзадачи, выполнятся и результаты будут возвращаться обратно.
Есть один или несколько центральных серверов, которые выполняют некоторые задачи:
Генератор подзалдач (разбивает 1 задачу на большое количество маленьких подзадач и высылает эти кусочки к подключённым вычислительным узлам). После вычислений – результаты посылаются обратно на сервер, сервер проводит ВАЛИДАЦИЮ (валидация – проверка корректности). Боинк предоставляет валидаторы по умолчанию (или, способ проверки сравниваются результаты с разных точек, каких результатов больше всего – тот и правильный. После валидации происходит ассимилация задачи – объединение решения подзадач в решение всей задачи.
Клиентская часть:
Представлена менеджером проекта. Менеджер проекта позовляет подключаться к множеству проектов, реализованных на системе боинк (т.е. к серверам которые генерируют задачи). Позволяет определить квоты по дисковому пространству, по процессному времени. После того, как квоты определены он обеспечивает загрузку программы решающей подзадачу с сервера выбранного проекта и загрузку входных данных под неё, которые сгенерировал сервер и производятся вычисления. Вычсиления производятся тогда, Когда самому пользователю не требуются вычислительные мощноси (напмер – во время запуска экранной заставки). Результаты вычислений сохраняются в файл и отправляются обратно на сервер. Менеджер проектов позволяет получать статистику о выполнении поздач (скольок % выполнено, сколько процессорного времени заняло и т.д.), для этого осуществляется взаимодействие с клиентской программой через разделяемую память.
(Надо будет написать 4 компонента: генератор задач, валидатор, ассимилятор, вычислитель).
Сегодняшнее задание:
надо реализовать вычисление для индивидуального задания с использованием технологии JMS (джава меседжин серсисес).JMS поддерживает 2 вида сообщений (очереди – отправляет сообщения в очередь, темы – отличие в том, что получателей у тем много (одно сообщение отправляется и пересылается всем подписчикам) )
18.04.13