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

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Принципы организации распределенной обработки информации

1.1 Требования, предъявляемые к свойствам систем распределенной обработки информации

1.2 Логические слои прикладного программного обеспечения вычислительных систем

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

2. Механизмы реализации распределенной обработки информации

2.1 механизм удаленного вызова процедур

2.2 Объектно-ориентированный подход к организации распределенной обработки информации

2.3 Распределенная обработка информации на основе транзакционного взаимодействия

2.4 Распределенная обработка информации с применением технологий обмена сообщениями

2.5 Распределенная обработка информации на основе моделей согласования

Заключение

Глоссарий

Список использованных источников

Список сокращений

Приложение А

Введение

система информация программный обеспечение

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

Под распределенной обработкой информации понимается комплекс операций с информацией (традиционно описываемый термином «обработка информации»), проводимый на независимых, но связанных между собой вычислительных машинах, предназначенных для выполнения общих задач.

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

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

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

- обмен (программы различных систем посылают друг другу сообщения, как правило, файлы);

- разделение (имеется непосредственный доступ к ресурсам нескольких машин, например, совместное использование файлов);

- совместная работа (машины играют в реализации программы взаимодополняющие роли).

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

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

Достоинствами распределенной обработки информации является:

- большое число взаимодействующих между собой пользователей;

- устранение пиковых нагрузок с централизованной базы данных за счет распределения обработки и хранения локальных баз данных на разных ЭВМ;

- возможность доступа пользователя к вычислительным ресурсам сети ЭВМ;

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

1 Принципы организации распределенной обработки информации

1.1 Требования, предъявляемые к свойствам систем распределенной обработки информации

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

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

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

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

Гибкость характеризует легкость конфигурирования системы при изменении состава компонентов.

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

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

* никто не обладает полной информацией о системе;

* решения принимаются на основе локальной информации;

* сбой в одном месте не вызывает нарушения работы алгоритма;

* существования единого времени не требуется.

Требование масштабируемости является существенным препятствием на пути распространения систем, реализованных на базе локальных сетей, на уровень сетей глобальных.

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

1.2 Логические слои прикладного программного обеспечения вычислительных систем

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

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

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

3) слой (уровень) логики доступа к данным, или слой управления ресурсами.

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

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

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

Алгоритмы доступа к данным исторически рассматривались как специфический для конкретного приложения интерфейс к механизму постоянного хранения данных наподобие файловой системы или системы управления базами данных (СУБД). При помощи этой части приложение управляет соединениями с базой данных и запросами к ней (перевод специфических для конкретного приложения запросов на язык базы данных, получение результатов и перевод этих результатов обратно в специфические для конкретного приложения структуры данных). К этой части относят только специфический для приложения интерфейс к СУБД, но не ее саму.

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

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

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

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

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

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

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

На уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. Так в рассмотренных выше архитектурных построениях при размещении процессов клиента и сервера на одной машине (обычно принято называть эту машину звеном, или ярусом - от англ. «tier») говорят об однозвенной реализации архитектуры клиент/сервер, а при размещении процессов клиента и сервера соответственно на двух разных машинах говорят о двухзвенной реализации такой архитектуры. Таким образом под общим концептуальным названием модели «клиент/сервер» скрывается несколько вариантов архитектурного построения вычислительных систем, а именно архитектуры однозвенные, двухзвенные, трехзвенные и т. д. (обычно при числе звеньев более трех архитектуру называют многозвенной).

Однозвенная архитектура вырождается в классическую архитектуру с централизованной обработкой информации. В двухзвенной архитектуре приложение разделено на две части: клиентскую и серверную. Возможные варианты распределения слоев прикладного программного обеспечения в двухзвенной архитектуре представлены на рисунке 1.1. Обычно сторона клиента содержит логику представления, а логика доступа к данным (как правило СУБД) и сама база данных находятся на стороне сервера. Алгоритмы бизнес-логики могут быть размещены либо полностью на стороне сервера (конфигурация так называемого «тонкого» клиента, рисунок 1.1б), либо частично или полностью на машине клиента вместе с логикой представления (конфигурация так называемого «толстого» клиента, рисунок 1.1в,1.1г). В случае размещения на стороне клиента лишь части логики представления, минимально достаточной для функционирования клиента (что характерно для современных архитектур так называемых «терминальных», или «бездисковых», рабочих станций), конфигурация обычно носит наименование «сверхтонкого» клиента (рисунок 1.1а).

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

Размещено на http://www.allbest.ru/

Рисунок 1.1- Варианты построения двухзвенных архитектур клиент/сервер (конфигурации: а - «сверхтонкий» клиент; б - «тонкий» клиент; в, г - «толстый» клиент)

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

Размещено на http://www.allbest.ru/

Рисунок 1.2- Вариант построения трехзвенной архитектуры клиент/сервер

Характерным примером использования трехзвенной архитектуры являются веб-приложения, которые реализуются посредством трех компонентов: веб-браузера клиента, веб-сервера и реляционной базы данных. Именно выделение бизнес-логики в отдельное звено позволяет преодолеть фундаментальные ограничения двухзвенной архитектуры. Клиенты в этом случае не поддерживают постоянного соединения с базой данных, а обмениваются информацией со средним звеном только тогда, когда это необходимо. В то же время процесс среднего звена поддерживает всего несколько активных соединений с базой данных, но использует их многократно. Поэтому процессы в среднем звене могут предоставлять обслуживание теоретически неограниченному числу клиентов.

Дальнейшее увеличение гибкости и масштабируемости распределенных систем достигается переходом к многозвенным архитектурам, включающим более чем три звена, и соответствующим распределением слоев прикладного программного обеспечения (и их частей) по разным машинам. Например, слой логики доступа к данным может быть разделен на СУБД и собственно базу данных, хранимую на отдельном устройстве (или группе устройств). Такая конфигурация отражает реализацию распределенной СУБД (рисунок 1.3.).

Размещено на http://www.allbest.ru/

Рисунок 1.3- Вариант построения четырехзвенной архитектуры клиент/сервер

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

2 Механизмы реализации распределенной обработки информации

2.1 Механизм удаленного вызова процедур

Синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером) поддерживает спецификация удаленного вызова процедур (remote procedure call - RPC). Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам - клиентскому и серверному переходникам, или заглушкам (от англ. stub - заглушка, переходник). Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой процесс.

При вызове клиентом удаленной процедуры вначале выполняется локальный вызов процедуры, являющейся частью клиентского переходника. Локальный вызов вместе с параметрами передается клиентскому переходнику. При этом с помощью специального языка описания интерфейсов (Interface Definition Language - IDL) производится определение интерфейса процедуры, то есть описание параметров процедуры, передаваемых ей до выполнения RPC и возвращаемых после завершения RPC. Затем это описание транслируется и производится упаковка данных в формат сообщения - маршалинг (marshaling). Клиентский переходник вызывает локальную операционную систему, которая пересылает сообщение удаленной операционной системе сервера. Удаленная операционная система передает сообщение серверному переходнику, реализующему серверную часть вызова и состоящему из программ получения запроса от клиента, форматирования данных (демаршалинг), вызова реальной процедуры (реализованной на сервере) и возврата результатов клиенту. Клиент блокируется и ждет ответа, а на сервере запускается серверный переходник, преобразующий сообщение в параметры локальной процедуры. Сервер видит вызов как прямое обращение к его локальной процедуре с нужными параметрами, выполняет вызов и передает результаты серверному переходнику. Серверный переходник форматирует результаты работы процедуры в сообщение для клиента и вызывает локальную операционную систему сервера. Операционная система сервера пересылает сообщение операционной системе клиента. Клиент выводится из состояния ожидания, его операционная система принимает сообщение и направляет его клиентскому переходнику, который извлекает результаты из сообщения, передает их клиенту и возвращает клиенту управление.

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

Размещено на http://www.allbest.ru/

Рисунок 2.1- Принципиальная схема организации удаленного вызова процедур

2.2 Объектно-ориентированный подход к организации распределенной обработки информации

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

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

Для распределенных систем разделение на интерфейсы и объекты позволяет помещать интерфейсы на одну вычислительную машину, а сами объекты - на другую. Принципиальная схема организации механизма удаленных объектов представлена на рисунок 2.2. При выполнении клиентом «привязки» к распределенному объекту в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем (proxy). Заместитель клиента аналогичен клиентскому переходнику в механизме RPC. Он выполняет маршалинг параметров в сообщения при обращении к методам, демаршалинг данных из ответных сообщений с результатами обращения к методам, передачу результатов клиенту. Сами же объекты находятся на сервере и предоставляют необходимые клиентской системе интерфейсы. Входящий запрос на обращение к методу сначала попадают в так называемый серверный каркас, или скелетон (skeleton), аналогичный серверному переходнику в RPC. Cерверный каркас преобразует входящий запрос в обращение к методу через интерфейс объекта, находящегося на сервере. Каркас также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента. Если объект физически распределен по нескольким вычислительным машинам, то это скрывается от клиентов за интерфейсами объектов.

Размещено на http://www.allbest.ru/

Рисунок 2.2- Принципиальная схема организации механизма удаленных объектов

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

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

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

Клиент, осуществив связь с объектом, может через заместителя объекта обратиться к методам объекта. Таким образом при объектно-ориентированном подходе к распределенной обработке информации реализуется механизм так называемого удаленного обращения к методам (Remote Method Invocation - RMI).

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

На основе механизма RMI разработано множество стандартов и программных реализаций объектно-ориентированных платформ промежуточного ПО, поддерживающих эффективную распределенную обработку информации.

2.3 Распределенная обработка информации на основе транзакционного взаимодействия

Для реализации транзакционного взаимодействия применяются мониторы обработки транзакций TPM (Transaction Processing Monitor), или транзакционные мониторы, разработанные для обеспечения надежного мультиплексного доступа к большому количеству ресурсов для большого количества параллельных пользователей. Механизм TPM - наиболее старая технология реализации распределенных систем, которая появилась в 1970-х годах в среде больших универсальных вычислительных машин для выполнения банковских, страховых и других высококритичных вычислений.

Транзакционные мониторы представляют одну из самых сложных и многофункциональных технологий в мире промежуточного ПО. Они предназначены для автоматизированной поддержки приложений, оформленных в виде последовательности транзакций. Каждая транзакция представляет собой законченный блок обращений к ресурсу (чаще всего - к базе данных) и некоторых действий над ним. Корректное выполнение транзакции должно гарантировать выполнение четырех условий - так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability):

* Atomicity (атомарность) - операции транзакции образуют неразделимый, атомарный блок («unit of work» - «единица работы») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;

* Consistency (согласованность) - по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;

* Isolation (изолированность) - одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;

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

В системе без TPM обеспечение свойств ACID берут на себя серверы распределенной базы данных на основе протокола 2РС - (two-Phase Commit - двухфазное подтверждение). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции. Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, требуется использование механизма монитора обработки транзакций. Транзакционные мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру общего стандарта распределенной обработки транзакций DTP (Distributed Transaction Processing) для данной категории промежуточного программного обеспечения MW (middleware). Архитектура DTP поддерживает совместное использование ресурсов (файлов или баз данных) множеством программ, обеспечивая управление доступом, гарантирующее согласованность системы в целом. Транзакционный монитор поддерживает выполнение распределенных транзакций на основе транзакционного RPC. Традиционные вызовы удаленных процедур независимы. Если вызывается сервер, который, выполняя удаленную процедуру, вызывает другой сервер, нет способа отличить, где произошла ошибка - в первом или втором сервере. Семантика же транзакционного вызова такова: если группа вызовов процедур внутри транзакции подтверждается (успешно завершается), имеются гарантии, что каждый из вызовов завершился успешно. Если возникло прерывание выполнения группы вызовов, общий эффект будет таким, как если бы ни один из вызовов не выполнялся. Процедурные вызовы, заключенные в транзакционные скобки, рассматриваются как единое целое, а инфраструктура RPC гарантирует их атомарность.

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

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

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

Системы ОТМ отличаются от других средств интеграции разных категорий MW тем, что все необходимые свойства ТРM и ORB предоставляются в одном продукте. Многие представители категории ОТМ базируются на компонентной модели CORBA/Java (эти две технологии построения распределенных компонентных сред все более тесно интегрируются друг с другом) и стандартной транзакционной архитектуре DTP, поддерживая при необходимости работу с объектами компонентной объектной модели DCOM (Distributed Component Object Model)

Так, консорциумом OMG была разработана спецификация объектного сервера транзакций OTS (Object Transaction Server), цель которой - унифицировать объединенную функциональность мониторов транзакций и брокеров объектных запросов. Это расширение CORBA нашло свое отражение в спецификации JTS для Java (Java Transaction Service - служба транзакций Java).

2.4  Распределенная обработка информации на основе технологий обмена сообщениями

Промежуточное ПО, ориентированное на обмен сообщениями (Message Oriented Middleware - MOM), относительно молодая и динамично развивающаяся категория систем промежуточного слоя. Согласно этой модели приложения обмениваются байтовыми строками - сообщениями, обращаясь к API-интерфейсу системы MOM, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от ранее рассмотренных моделей промежуточного ПО, MOM реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложений. MOM можно считать и наиболее гибкой категорией MW, поскольку системы этого типа поддерживают как синхронные, так и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения. По способу обмена сообщениями все продукты MOM могут быть разделены на три подгруппы систем:

1) с передачей сообщений,

2) c очередями сообщений,

3) типа публикация/подписка.

Системы с передачей сообщений (Message Passing - MP) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Отсюда следует, что данное решение не подходит для слабо связанных программ, работающих в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей. Обмен сообщениями может происходить в синхронном и асинхронном режиме. Кроме средства непосредственных коммуникаций, системы этого типа могут обеспечивать дополнительные службы промежуточного слоя, например, службу каталогов.

Многочисленная часть МОМ-систем реализует асинхронный механизм очередей сообщений (Message Queuing - MQ). В отличие от передачи сообщений, эта модель межпрограммного взаимодействия не требует поддержки непосредственного соединения одного прикладного модуля с другим, но гарантирует доставку сообщения даже в том случае, если программа-адресат в данный момент не доступна. Программа-отправитель передает сообщение MQ-системе и продолжает выполнение. Сообщение помещается в локальное промежуточное хранилище - очередь сообщений, размещенную в оперативной памяти или на диске, откуда оно может быть немедленно или через какое-то время передано программе-получателю. Таким образом, приложения, которые используют эту модель связи, могут работать практически независимо друг от друга без временной синхронизации. Поэтому механизм очередей сообщений является удачным решением для приложений, предназначенных мобильным пользователям, для реализации потоков работ и поддержки приложений в глобальных сетях с медленными и не очень надежными соединениями.

Большинство MQ-систем включает менеджер очереди (Queue Manager), который управляет локальными очередями, гарантирует передачу сообщений нужному адресату и, взаимодействуя с менеджерами на других узлах, следит за сетевым маршрутом передачи сообщения, выбирая альтернативный путь, если по тем или иным причинам основной оказывается недоступен.

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



Размещено на http://www.allbest.ru/

Рисунок 2.5- Принципиальная схема организации механизмаочередей сообщений

Очереди сообщений могут быть долговременными (persistent) или нет. В последнем случае, если произойдет сбой в работе менеджера очередей, то сообщения в очереди будут потеряны. Если поддерживается долговременная очередь, сообщения будут восстановлены после перезапуска менеджера. Этот вариант безусловно является предпочтительным для большинства ответственных приложений. Еще одной отличительной чертой промежуточных систем на основе очередей сообщений является обеспечение одного из трех уровней «качества обслуживания»:

* надежная доставка сообщений (reliable message delivery) - система гарантирует, что в процессе обмена сообщениями ни один сетевой пакет не будет потерян;

* гарантированная доставка сообщений (guaranteed message delivery) - сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);

* застрахованная доставка сообщений (assured message delivery) - каждое сообщение доставляется только один раз.

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

Представителями программных продуктов, построенных на базе очередей сообщений, являются системы MQSeries компании IBM, MSMQ (Microsoft Message Queuing Server) компании Microsoft, MessageQ компании BEA, dbQ компании Sybase.

Еще одна модель обмена сообщениями - модель публикации/подписки (publlsh&subscribe) - имеет определенные перспективы для создания гибких, управляемых событиями приложений. Одно приложение публикует информацию в сети, а другое подписывается для получения данных по интересующей его теме. Взаимодействующие таким способом приложения полностью независимы друг от друга и могут ничего не знать о существовании, физическом размещении и состоянии друг друга. Это открывает путь к динамической реконфигурации всей распределенной системы, добавлению и произвольному изменению любых клиентов и серверов без прерывания их работы и полной изоляции прикладных компонентов от любых аспектов реализации других частей системы. В конечном итоге, это означает возможность эффективной интеграции различных бизнес-приложений в единое корпоративное решение.

Характерным примером распределенной системы на основе модели публикации/подписки является система TIB/Rendezvous компании TIBCO. Ключевой механизм, лежащий в основе системы TIB/Rendezvous, - это адресация по теме (subject-based addressing). При таком подходе процесс, который собирается посылать сообщение, не может определить точное место назначения. Вместо этого он именует сообщение названием темы (subject name), после чего посылает его в коммуникационную систему для пересылки по сети. Получатели, в свою очередь, не выясняют, от каких процессов они собираются получать сообщения. Вместо этого они сообщают коммуникационной системе, какие темы их интересуют. Коммуникационная система гарантирует, что получателю будут доставлены только те сообщения, которые несут данные по теме, интересующей получателя. Отправка сообщения методом адресации по теме также называется публикацией (publishing). Чтобы получить сообщение по определенной теме, процесс должен подписаться на эту тему. Принципиальная схема организации системы публикации/подписки, реализованная в TIB/Rendezvous, показана на рисунок 2.6.

Основой архитектуры системы TIB/Rendezvous является сеть с поддержкой групповой рассылки, хотя по возможности допускается использование более эффективных средств связи (так, например, если известно точное местонахождение подписчика, обычно выполняется сквозная передача сообщений). На каждом узле этой сети работает демон контактов (rendezvous daemon), который отвечает за то, чтобы сообщения отсылались и получались в соответствии с темой. Когда сообщение публикуется, демон контактов осуществляет его групповую рассылку всем узлам сети. Обычно групповая рассылка реализуется средствами базовой сети, такими как групповая рассылка по IP-адресам или аппаратная широковещательная рассылка.

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

Размещено на http://www.allbest.ru/

Рисунок 2.6- Принципиальная схема организации системы публикации/подписки

Чтобы система могла вырасти до размера больших сетей, таких как глобальные сети, используются также маршрутизирующие демоны контактов (rendezvous router daemons). Обычно каждая локальная сеть имеет одного маршрутизирующего демона контактов. Этот демон связывается с маршрутизирующим демоном другой удаленной сети. Маршрутизирующие демоны образуют сквозную оверлейную сеть (overlay network), в которой маршрутизаторы соединены между собой попарно соединениями TCP. Вторичная сеть - это сеть маршрутизаторов прикладного уровня. Каждый маршрутизатор знает топологию вторичной сети и вычисляет дерево групповой рассылки для публикации сообщений в других сетях. Маршрутизаторы рассылают только те сообщения, которые публикуются в их локальной сети. Сообщения из других сетей пересылаются по дереву групповой рассылки той сети, из которой они первоначально исходили.

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

Технологической основой для всех сред обмена сообщениями нового поколения стала спецификация JMS (Java Message Service - служба сообщений Java), в деталях определяющая, как взаимодействуют клиенты и серверы в среде асинхронных сообщений. К числу достоинств JMS относится то, что она соответствует современным представлениям о взаимодействии приложений и не требует специальных знаний и доступна для любого программиста, работающего на языке Java. Этими качествами она заметно отличается от инструментария MQSeries, где необходима специальная подготовка. Еще один стимул для рождения нового поколения MOM - появление расширяемого языка разметки данных XML (eXtensible Markup Language - «расширяемый язык разметки») для Internet-приложений, позволяющего одним приложениям «понимать» другие.

Спецификация JMS построена на основе топологии «ступицы и колеса» (hub-and-spoke), в которой все приложения подключаются к центральному процессу, называемому сервером сообщений (message server). Он отвечает за корректность маршрутизации сообщений, аутентификацию и авторизацию пользователей. Сами приложения рассматриваются как клиенты - они могут быть передатчиками и/или приемниками. При этом обеспечивается такой API-интерфейс на базе Java, который позволяет разработчикам писать клиентские приложения, не заботясь о том, какое конкретно программное обеспечение MOM будет использоваться. Спецификация только определяет доступ к корпоративной системе обмена сообщениями, а каждый производитель ПО, опирающийся на JMS, самостоятельно разрабатывает инструменты для администрирования среды обмена сообщениями. JMS стала основой целого направления программных продуктов категории MOM, таких как MQ Express компании Talarian, SonicMQ компании Progress Software, Bus компании Softwired, FioranoMQ компании Fiorano Software и других.

2.5 Распределенная обработка информации на основе моделей согласования

Основным подходом, который используется в распределенных системах на основе моделей согласования, является отделение собственно вычислительных процессов от механизмов их согласования. Если рассматривать распределенную систему как набор процессов (возможно, многопоточных), то вычислительная часть распределенной системы образована группой процессов, каждый из которых осуществляет конкретные вычислительные операции, причем эти операции в принципе могут выполняться независимо от других процессов. В этой модели согласующая часть распределенной системы поддерживает все взаимодействие между процессами и организует их взаимную кооперацию. Она образует тот «клей», который связывает воедино деятельность, выполняемую разными процессами. В распределенных системах согласования основное внимание уделяется согласованию процессов.

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

Другой тип согласования наблюдается в том случае, если процессы не связаны по времени, но связаны по ссылкам. Такой тип согласования называют согласованием через почтовый ящик (mailbox coordination). В этом случае для взаимодействия не нужно, чтобы два взаимодействующих друг с другом процесса выполнялись одновременно. Вместо этого взаимодействие происходит путем посылки сообщений в почтовый ящик, может быть, используемый совместно. При этом необходимо явно указать адрес почтового ящика, в котором должны храниться сообщения. Это и есть ссылочная связность.

Комбинация связности по времени и несвязности по ссылкам образует группу моделей согласования на встрече (meeting-oriented coordination). В несвязной по ссылкам системе процессы не имеют полной информации друг о друге. Другими словами, когда процесс хочет согласовать свою деятельность с другими процессами, он не может обратиться к ним напрямую. Взамен используется метафора встречи, на которой собираются процессы, чтобы скоординировать свою деятельность. Модель предполагает, что процессы, участвующие во встрече, выполняются одновременно.

Наиболее распространенный вариант согласования - это сочетание несвязных по времени и по ссылкам процессов. Этот вариант представлен генеративной связью (generative communication), которая впервые была реализована в программной системе Linda. Основная идея генеративной связи состоит в том, что набор независимых процессов может использовать разделяемое сохранное пространство данных, организуемое с помощью кортежей. Кортежи - это именованные записи, содержащие несколько (но, возможно, и ни одного) типизованных полей. Процесс может помещать в разделяемое пространство данных записи любого типа (то есть генерировать связующие записи). Для разделения кортежей в соответствии с информацией, которая в них содержится, достаточно их имен. Разделяемые пространства имен реализуют механизмы ассоциативного поиска кортежей. Другими словами, когда процесс хочет извлечь кортеж из пространства данных, ему достаточно определить значения полей, которые его интересуют. Любой кортеж, удовлетворяющий описанию, будет извлечен из пространства данных и передан процессу. Если ничего найдено не будет, процесс может заблокироваться до прихода очередного кортежа.