Добавлен: 27.06.2023
Просмотров: 90
Скачиваний: 2
СОДЕРЖАНИЕ
Глава 1 Архитектурное построение и свойства систем распределённой обработки информации
1.1 Свойства систем распределённой обработки информации как среды реализации обработки информации
1.2 Требования к архитектурному построению систем распределённой обработки информации
Глава 2 Механизмы реализации технологии распределенной обработки информации
2.1 Механизм удаленного вызова процедур
2.2 Объектно-ориентированный подход к организации распределенной обработки информации
Atomicity (атомарность) - операции транзакции образуют неразделимый, атомарный блок ("unitofwork" - "единица работы") с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;
Consistency (согласованность) - по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;
Isolation (изолированность) - одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;
Durability (долговременность) - все модификации ресурсов в процессе выполнения транзакции будут долговременными.
В системе без TPM обеспечение свойств ACID берут на себя серверы распределенной базы данных на основе протокола 2РС - (two-PhaseCommit - двухфазное подтверждение). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы обработки информации опрашиваются о готовности выполнить необходимые действия.
Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции. Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику.
Поэтому для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, требуется использование механизма монитора обработки транзакций. Транзакционные мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру общего стандарта распределенной обработки транзакций DTP (DistributedTransactionProcessing) для данной категории промежуточного программного обеспечения MW (middleware).
Архитектура DTP поддерживает совместное использование ресурсов (файлов или баз данных) множеством программ, обеспечивая управление доступом, гарантирующее согласованность системы обработки информациив целом. Транзакционный монитор поддерживает выполнение распределенных транзакций на основе транзакционного RPC. Традиционные вызовы удаленных процедур независимы. Если вызывается сервер, который, выполняя удаленную процедуру, вызывает другой сервер, нет способа отличить, где произошла ошибка - в первом или втором сервере. [11]
Семантика же транзакционного вызова такова: если группа вызовов процедур внутри транзакции подтверждается (успешно завершается), имеются гарантии, что каждый из вызовов завершился успешно. Если возникло прерывание выполнения группы вызовов, общий эффект будет таким, как если бы ни один из вызовов не выполнялся. Процедурные вызовы, заключенные в транзакционные скобки, рассматриваются как единое целое, а инфраструктура RPC гарантирует их атомарность. Функциональность транзакционных мониторов достаточна для разработки, выполнения, управления и сопровождения транзакционных информационных распределенных систем.
Эта функциональность включает в себя язык IDL, именование, безопасность и аутентификацию, компиляторы переходников, поддержку работы с транзакционными вызовами (транзакционные скобки, обратные вызовы), ведение журнальных записей, восстановление, блокировку, управление процессами и приоритетами, балансировку нагрузки, репликацию, управление ресурсами.
Промежуточное ПО, ориентированное на обмен сообщениями (Message Oriented Middleware - MOM), относительно молодая и динамично развивающаяся категория систем промежуточного слоя. Согласно этой модели приложения обмениваются байтовыми строками - сообщениями, обращаясь к API-интерфейсу системы MOM, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами.
В отличие от ранее рассмотренных моделей промежуточного ПО, MOM реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложений. MOM можно считать и наиболее гибкой категорией MW, поскольку системы обработки информации этого типа поддерживают как синхронные, так и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения.
По способу обмена сообщениями все продукты MOM могут быть разделены на три подгруппы систем:
1) с передачей сообщений,
2) c очередями сообщений,
3) типа публикация/подписка.
Системы обработки информациис передачей сообщений (MessagePassing - MP) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Отсюда следует, что данное решение не подходит для слабо связанных программ, работающих в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей.
Обмен сообщениями может происходить в синхронном и асинхронном режиме. Кроме средства непосредственных коммуникаций, системы обработки информации этого типа могут обеспечивать дополнительные службы промежуточного слоя, например, службу каталогов.
Принципиальная схема организации механизма очередей сообщений представлена на рисунке 6.
машина 1 машина 2
сеть
Приложение
A
Менеджер очередей
Приложение
D
Очередь 1
Очередь 4
Приложение
C
Менеджер очередей
Приложение
В
Очередь 3
Очередь 2
Рисунок 6 - Принципиальная схема организации механизма очередей сообщений
Основным подходом, который используется в распределенных системах на основе моделей согласования, является отделение собственно вычислительных процессов от механизмов их согласования. Если рассматривать распределенную систему как набор процессов (возможно, многопоточных), то вычислительная часть распределенной системы обработки информацииобразована группой процессов, каждый из которых осуществляет конкретные вычислительные операции, причем эти операции в принципе могут выполняться независимо от других процессов.
В этой модели согласующая часть распределенной системы обработки информацииподдерживает все взаимодействие между процессами и организует их взаимную кооперацию. Она образует тот "клей", который связывает воедино деятельность, выполняемую разными процессами. В распределенных системах обработки информации согласования основное внимание уделяется согласованию процессов.
В том случае, если процессы обладают связностью ссылок и времени, согласование осуществляется напрямую и имеет название прямого согласования (direct coordination). Связность ссылок обычно имеет вид явной идентификации собеседника в процессе взаимодействия. Так, например, процесс может взаимодействовать с другим процессом только в том случае, если он знает идентификатор процесса, с которым хочет обменяться информацией. Временная связность означает, что оба взаимодействующих друг с другом процесса активны одновременно. Такая связность имеет место при нерезидентной связи на основе сообщений.
Другой тип согласования наблюдается в том случае, если процессы не связаны по времени, но связаны по ссылкам. Такой тип согласования называют согласованием через почтовый ящик (mailboxcoordination). В этом случае для взаимодействия не нужно, чтобы два взаимодействующих друг с другом процесса выполнялись одновременно. Вместо этого взаимодействие происходит путем посылки сообщений в почтовый ящик, может быть, используемый совместно. При этом необходимо явно указать адрес почтового ящика, в котором должны храниться сообщения. Это и есть ссылочная связность.
Комбинация связности по времени и несвязности по ссылкам образует группу моделей согласования на встрече (meeting-orientedcoordination). В несвязной по ссылкам системе процессы не имеют полной информации друг о друге. Другими словами, когда процесс хочет согласовать свою деятельность с другими процессами, он не может обратиться к ним напрямую.
Взамен используется метафора встречи, на которой собираются процессы, чтобы скоординировать свою деятельность. Модель предполагает, что процессы, участвующие во встрече, выполняются одновременно.
Наиболее распространенный вариант согласования - это сочетание несвязных по времени и по ссылкам процессов. Этот вариант представлен генеративной связью (generative communication), которая впервые была реализована в программной системе Linda. Основная идея генеративной связи состоит в том, что набор независимых процессов может использовать разделяемое сохранное пространство данных, организуемое с помощью кортежей. Кортежи - это именованные записи, содержащие несколько (но, возможно, и ни одного) типизованных полей.
Процесс может помещать в разделяемое пространство данных записи любого типа (то есть генерировать связующие записи). Для разделения кортежей в соответствии с информацией, которая в них содержится, достаточно их имен. Разделяемые пространства имен реализуют механизмы ассоциативного поиска кортежей. Другими словами, когда процесс хочет извлечь кортеж из пространства данных, ему достаточно определить значения полей, которые его интересуют. Любой кортеж, удовлетворяющий описанию, будет извлечен из пространства данных и передан процессу. Если ничего найдено не будет, процесс может заблокироваться до прихода очередного кортежа.
Примером системысогласования является система Jini ("джини") компании SunMicrosystems. Отнесение Jini к системам согласования основано в первую очередь на том, что эта система способна поддерживать генеративную связь при помощи Linda-подобной службы под названием JavaSpace. Однако существует множество служб и средств, которые делают Jini больше, чем просто системой согласования. Jini - это распределенная система, состоящая из разных, но взаимосвязанных элементов.
Она жестко привязана к языку программирования Java, хотя многие из ее принципов равно могут быть реализованы и при помощи других языков.
Важной частью системы является модель согласования генеративной связи. Jini обеспечивает как временную, так и ссылочную несвязность процессов при помощи системы согласования JavaSpace. JavaSpace - это разделяемое пространство данных, в котором хранятся кортежи. Кортежи представляют собой типизованные наборы ссылок на объекты Java. В одной системе Jini могут сосуществовать несколько пространств JavaSpace.
Заключение
Системы распределенной обработки информации в виде многомашинных вычислительных комплексов и компьютерных сетей представляют собой одну из наиболее прогрессивных форм организации средств вычислительной техники. Возможность взаимодействия вычислительных систем при реализации распределенной обработки информации определяют как их способность к совместному использованию данных или к совместной работе с использованием стандартных интерфейсов. Целью распределенной обработки информации является оптимизация использования ресурсов и упрощение работы пользователя.
Распределенная система позволяет скрыть от пользователя аспекты своей внутренней организации, физические места размещения ресурсов, вопросы реализации и взаимодействия процессов, обслуживающих запросы пользователя. Распределенная система способна увеличиваться в масштабах путем подключения к системе дополнительных компонентов без принципиального влияния на работу существующих приложений и пользователей.
Прикладное программное обеспечение в общем случае может быть представлено в виде композиции трех логических слоев: слоя логики представления, слоя бизнес-логики и слоя логики доступа к данным. Послойное разделение прикладного программного обеспечения минимизирует взаимодействие между составными элементами и служит основой для выделения компонентов, которые могут быть распределены для работы на нескольких вычислительных машинах.
Децентрализованная обработка информации основывается на архитектурной модели клиент/сервер, где клиентами считаются вычислительные машины, нуждающиеся в получении тех или иных услуг, а серверами - вычислительные машины, которые эти услуги предоставляют. Под общим концептуальным названием модели клиент/сервер скрывается несколько вариантов архитектурного построения вычислительных систем, а именно архитектуры однозвенные, двухзвенные, трехзвенные и многозвенные.
Промежуточное программное обеспечение позволяет осуществить связь и взаимодействие между разнородными компонентами распределенных систем, предоставляет стандартные интерфейсы программирования, реализует переносимость программ и прозрачность функционирования систем распределенной обработки информации.
Наибольшее практическое распространение получили следующие механизмы реализации распределенной обработки информации: удаленный вызов процедур, объектно-ориентированный подход на основе удаленного обращения к методам, транзакционное взаимодействие на базе мониторов обработки транзакций, использование моделей обмена сообщениями и моделей согласования.