Современное состояние общества характеризуется процессом информатизации, затрагивающим практически все сферы деятельности человека. Вслед за периодом локальной компьютеризации наступила эра создания корпоративных информационных систем, эра распределенных систем информации. Сложность этого этапа заключается в том, что автоматический перенос хорошо зарекомендовавших себя решений в области информатизации на распределенные системы информации приводит к плачевным результатам. Требуется выработка новых решений, поиск новых подходов, создание новых технологий обработки информации.
Надежность работы распределенных систем обработки информации, скорость и качество обработки информации — темы, актуальные сегодня как никогда. Для доказательства достаточно обратиться к сети Интернет — одной из наиболее ярких распределенных систем информации современности:
- темпы роста Интернет-трафика последние два года превышают 60% (74% в 2011 году и 62% в 2012 году);
- объем информации в сети Интернет увеличивается с каждым годом в геометрической прогрессии;
- увеличивается доля «сложной» для обработки медиа-информации: звуковой, графической, видео;
- растут объемы «паразитной» информации, например, доля спама в почтовой информации сегодня — свыше 90%.
Пример сети Интернет показывает: темпы развития инструментов, а также средств накопления и передачи данных превышают существующие возможности по их обработке. Проблема усугубляется постоянным ростом доли сложной для обработки информации — графической, звуковой, видео. Многие задачи требуют уже не просто быстрой, а моментальной обработки — «на лету». Распределенные системы обработки информации насчитывают сотни тысяч и миллионы узлов. Вирусные эпидемии распространяются в течение нескольких часов и даже минут, а их масштабы достигают миллионов зараженных компьютеров.
До недавнего времени это не являлось проблемой. Несмотря на свою «распределенность», распределенные системы обработки информации представляли собой статичные по своей структуре комплексы, содержащие весьма ограниченное количество узлов.
Будучи изначально распределенной системой существенно неоднородной структуры и достаточно непостоянного состава, с развитием технологий мобильного доступа в сеть Интернет она трансформируется в первую общедоступную и функционирующую распределенную систему информации с динамически изменяющейся структурой, причем изменяющейся совершенно непредсказуемо. Анализ современных отечественных и зарубежных работ показывает, что существующие подходы к изучению распределенных систем обработки информации не готовы ответить на вопрос, как она будет развиваться дальше.
Автоматизированная система обработки информации на примере системы ...
... аспекты применения видеонаблюдения. Цель курсовой работы – рассмотреть систему видеонаблюдения (далее по тексту – СВ) как автоматизированную систему обработки информации Объектом исследования является анализ автоматизированной системы обработки информации – системы видеонаблюдения. При этом предметом исследования является рассмотрение ...
Системы распределенные обработки информации глобальных масштабов с непредсказуемой и динамически изменяющейся структурой — не просто ближайшее будущее, а самое реальное настоящее. Актуальность поставленной задачи для повышения надежности функционирования распределенных систем обработки информации не вызывает сомнений.
Цель курсовой работы:
Для достижения указанной цели предполагается решить следующие основные задачи:
- Изучить архитектурное построение систем распределённой обработки информации;
- Свойства и требования к построению систем распределённой обработки информации;
- Рассмотреть механизм реализации технологии распределенной обработки информации с использованием удаленного вызова процедур;
- Проанализировать объектно-ориентированный подход к организации распределенной обработки информации;
— Определить возможность взаимодействия вычислительных систем при реализации распределенной обработки информации на основе транзакционного взаимодействия и с применением технологий обмена сообщениями. обработка информация технология распределенный
Глава 1. Архитектурное построение и свойства систем распределённой обработки информации
1.1 Свойства систем распределённой обработки информации как среды реализации обработки информации
Под распределенной обработкой информации понимается комплекс операций с информацией (традиционно описываемый термином «обработка информации»), проводимый на независимых, но связанных между собой вычислительных машинах, предназначенных для выполнения общих задач.
Системы распределенной обработки информации (или распределенные вычислительные системы) в виде многомашинных вычислительных комплексов и компьютерных сетей представляют собой одну из наиболее прогрессивных форм организации средств вычислительной техники.
Распределённая система обработки информации — это набор независимых компьютеров, представляющихся их пользователям единой объединённой системой.
В качестве основного требования к распределенным системам предъявляется достижение их прозрачности, открытости, переносимости приложений, гибкости, масштабируемости и безопасности.
Таблица 1 — Свойства систем распределённой обработки информации
|
Определение понятия |
||
|
Прозрачность — Важная задача распределенных систем состоит в том, чтобы скрыть тот факт, что процессы и ресурсы физически распределены по множеству компьютеров. Распределенные системы, которые представляются пользователям и приложениям в виде единой компьютерной системы. |
Э. Таненбаум, М. Ван Стеен. Распределенные системы. Принципы и парадигмы[50]. |
|
|
Гибкость характеризует, насколько легко конфигурируются системы, состоящие из различных компонент от разных производителей. |
Распределенные базы данных. Курс лекций. http://www.kgau.ru/istiki/umk/ituman/textbox/bdras.htm |
|
|
Открытая распределенная система (open distributed system) — это система, предлагающая службы, вызов которых требует стандартные синтаксис и семантику. Например, в компьютерных сетях формат, содержимое и смысл посылаемых и принимаемых сообщений подчиняются типовым правилам. |
Э. Таненбаум, М. Ван Стеен. Распределенные системы. Принципы и парадигмы[50]. |
|
|
Переносимость характеризует, насколько прикладная программа, разработанная для одной распределенной системы, может без изменения выполняться в другой распределенной системе, реализуя одни и те же интерфейсные средства |
Распределенные базы данных. Курс лекций. http://www.kgau.ru/istiki/umk/ituman/textbox/bdras.htm |
|
|
Масштабируемость — это возможность увеличить вычислительную мощность компьютерной системы (в частности, их способности выполнять больше операций или транзакций за определенный период времени) за счет установки большего числа процессоров или их замены на более мощные. |
Э. Таненбаум, М. Ван Стеен. Распределенные системы. Принципы и парадигмы[50]. |
|
|
Безопасность — защищенность всех ее компонентов (технических средств, программного обеспечения, данных и персонала) от подобного рода нежелательных для соответствующих субъектов информационных отношений воздействий. |
Маглинец Ю.А. Анализ требований к автоматизированным информационным системам [26]. |
|
Важная задача распределенных систем обработки информации состоит в том, чтобы скрыть тот факт, что процессы и ресурсы физически распределены по множеству компьютеров. Распределенные системы обработки информации, которые представляются пользователям и приложениям в виде единой компьютерной системы, называются прозрачными (transparent).
Таблица 2 — Формы прозрачности системах распределённой обработки информации
|
Наименование формы |
Особенности реализации |
|
|
Доступ |
Скрывается разница в представлении данных и доступе к ресурсам |
|
|
Местоположение |
Скрывается местоположение ресурса |
|
|
Перенос |
Скрывается факт перемещения ресурса в другое место |
|
|
Смена местоположения |
Скрывается факт перемещения ресурса в процессе обработки в другое место |
|
|
Репликация |
Скрывается факт репликации ресурса |
|
|
Параллельный доступ |
Скрывается факт возможного совместного использования ресурса несколькими конкурирующими пользователями |
|
|
Отказ |
Скрывается отказ и восстановление ресурса |
|
|
Сохранность |
Скрывается, хранится ресурс (программный) на диске или находится в оперативной памяти |
|
Таким образом, достижение прозрачности распределения — это важная цель при проектировании и разработке распределенных систем обработки информации, но она не должна рассматриваться в отрыве от других характеристик системы ЭВМ, например, производительности.
Открытая распределенная система (open distributed system) — это система, предлагающая службы, вызов которых требует стандартные синтаксис и семантику. Например, в компьютерных сетях формат, содержимое и смысл посылаемых и принимаемых сообщений подчиняются типовым правилам. Эти правила формализованы в протоколах. В распределенных системах службы обычно определяются через интерфейсы (interfaces), которые часто описываются при помощи языка определения интерфейсов (Interface Definition Language, IDL) [43].
Описание интерфейса на IDL почти исключительно касается синтаксиса служб. Другими словами, оно точно отражает имена доступных функций, типы параметров, возвращаемых значений, исключительные ситуации, которые могут быть возбуждены службой и т. п. Наиболее сложно точно описать то, что делает эта служба, то есть семантику интерфейсов. Будучи правильно описанным, определение интерфейса допускает возможность совместной работы произвольного процесса, нуждающегося в таком интерфейсе, с другим произвольным процессом, предоставляющим этот интерфейс. Определение интерфейса также позволяет двум независимым группам создать абсолютно разные реализации этого интерфейса для двух различных распределенных систем, которые будут работать абсолютно одинаково [21].
Переносимость. Самодостаточность и нейтральность необходимы для обеспечения переносимости и способности к взаимодействию. Способность к взаимодействию (interoperability) характеризует, насколько две реализации систем или компонентов от разных производителей в состоянии совместно работать, полагаясь только на то, что службы каждой из них соответствуют общему стандарту [21].
Переносимость (portability) характеризует то, насколько приложение, разработанное для распределенной системы обработки информации А, может без изменений выполняться в распределенной системе В, реализуя те же, что и в А интерфейсы. Хотя ОС часто описываются либо как переносимые, либо как непереносимые, мобильность — это не бинарное состояние, а понятие степени. Вопрос не в том, может ли быть система перенесена, а в том, насколько легко можно это сделать. Для обеспечения переносимости и способности к взаимодействию в интерфейсе должно быть все, что нужно для его реализации, но он не должен определять внешний вид реализации . Переносимость характеризует, насколько приложение, сделанное для одной распределенной системы, может работать в составе другой системы обработки информации, а способность к взаимодействию показывает, насколько две реализации систем или компонентов , выполненных разными людьми, в состоянии работать совместно.
Под гибкостью мы понимаем легкость конфигурированияобработки информации системы, состоящей из различных компонентов, возможно от разных производителей. Не должны вызывать затруднений добавление к системе новых компонентов или замена существующих, при этом прочие компоненты, с которыми не производилось никаких действий, должны оставаться неизменными. Другими словами, открытая распределенная система должна быть расширяемой. Например, к гибкой системе должно быть относительно несложно добавить части, работающие под управлением другой операционной системы, или даже заменить всю файловую систему целиком. Насколько всем нам знакома сегодняшняя реальность, говорить о гибкости куда проще, чем ее осуществить. Достижения необходимого уровня гибкости приводит к тому, что открытая распределенная система становится расширяемой. В построении гибких открытых распределенных систем решающим фактором оказывается организация этих систем в виде наборов относительно небольших и легко заменяемых или адаптируемых компонентов. Это предполагает необходимость определения не только интерфейсов верхнего уровня, с которыми работают пользователи и приложения, но также и интерфейсов внутренних модулей системы и описания взаимодействия этих модулей. Этот подход относительно молод. Множество старых и современных систем создавались цельными так, что компоненты одной гигантской программы разделялись только логически. В случае использования этого подхода независимая замена или адаптация компонентов, не затрагивающая систему обработки информации в целом, была почти невозможна. Монолитные системы обработки информации вообще стремятся скорее к закрытости, чем к открытости [21].
Повсеместная связь через Интернет быстро стала таким же обычным делом, как возможность послать кому угодно в мире письмо по почте. Помня это, мы говорим, что масштабируемость — это одна из наиболее важных задач при проектировании распределенных систем[23].
Масштабируемость системы обработки информацииможет измеряться по трем различным показателям. Во-первых, система может быть масштабируемой по отношению к ее размеру, что означает легкость подключения к ней дополнительных пользователей и ресурсов. Во-вторых, система обработки информацииможет масштабироваться географически, то есть пользователи и ресурсы могут быть разнесены в пространстве. В-третьих, система может быть масштабируемой в административном смысле, то есть быть проста в управлении при работе во множестве административно независимых организаций.
К сожалению, система обработки информации, обладающая масштабируемостью по одному или нескольким из этих параметров, при масштабировании часто дает потерю производительности. Если система обработки информации нуждается в масштабировании, необходимо решить множество разнообразных проблем. Сначала рассмотрим масштабирование по размеру. Если возникает необходимость увеличить число пользователей или ресурсов, мы нередко сталкиваемся с ограничениями, связанными с централизацией служб, данных и алгоритмов. Даже если мы обладаем фактически неограниченным запасом по мощности обработки и хранения данных, ресурсы связи с этим сервером в конце концов будут исчерпаны и не позволят нам расти дальше[24].
Таблица 3 — Примеры ограничений масштабируемости в распределённых системах обработки информации
|
Концепция |
Пример |
|
|
Централизованные службы |
Один сервер на всех пользователей |
|
|
Централизованные данные |
Единый телефонный справочник, доступный в режиме подключения |
|
|
Централизованные алгоритмы |
Организация маршрутизации на основе полной информации |
|
Безопасность распределенных систем обработки информации связана с обеспечением защиты ресурсов от атак со стороны враждебно настроенных пользователей. С целью повышения безопасности распределенные системы обработки информации должны использовать защищенные каналы передачи данных, разрешать доступ к ресурсам только для авторизованных пользователей и допускать чтение передаваемых по сети данных только получателем. Проблема защиты компьютерных сетей от несанкционированного доступа приобрела особую остроту. Развитие коммуникационных технологий позволяетстроить сети распределенной архитектуры, объединяющие большое количество сегментов, расположенных на значительном удалении друг от друга. Все это вызывает увеличение числа узлов сетей, разбросанных по всему миру, и количества различных линий связи между ними, что, в свою очередь, повышает риск несанкционированного подключения к сети для доступа к важной информации. Особенно неприятной такая перспектива может оказаться длябанковских или государственных структур, обладающих секретной информацией коммерческого или любого другого характера. В этом случае необходимы специальные средства идентификации пользователей в сети, обеспечивающие доступ к информации лишь в случае полной уверенности в наличии у пользователя прав доступа к ней[25].
Существует ряд разработок, позволяющих с высокой степенью надежности идентифицировать пользователя при входе в систему. Среди них, например, есть технологии, идентифицирующие пользователя по сетчатке глаза или отпечаткам пальцев. Кроме того, ряд систем используют технологии, основанные на применении специального идентификационного кода, постоянно передаваемого по сети. Так, при использовании устройства SecureID обеспечивается дополнительная информация о пользователе в виде шестизначного кода [26].
1.2 Требования к архитектурному построению систем распределённой обработки информации
Исторически первым вариантом архитектурного построения вычислительной системы была архитектура с централизованной обработкой информации, когда одна мощная универсальная ЭВМ являлась единственной платформой, выполняющей все слои логики приложения. Централизованная архитектура характеризуется рядом существенных достоинств: простота разработка приложений, легкость обслуживания и управления. Именно эти достоинства обеспечили широкое практическое применение и долгое существование вычислительных систем с централизованной обработкой информации [21].
Появление классов мини и микро-ЭВМ, а особенно класса персональных компьютеров (ПК) привело к разработке архитектур с децентрализованной обработкой информации, функционирующих в рамках парадигмы построения сетей, называемой моделью клиент/сервер (client/server model).
Клиентами (client) в данном случае считаются вычислительные машины, нуждающиеся в получении тех или иных услуг, а серверами (server) — вычислительные машины, которые эти услуги предоставляют.
На уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. Так в рассмотренных выше архитектурных построениях при размещении процессов клиента и сервера на одной машине (обычно принято называть эту машину звеном, или ярусом — от англ. «tier») говорят об однозвенной реализации архитектуры клиент/сервер, а при размещении процессов клиента и сервера соответственно на двух разных машинах говорят о двухзвенной реализации такой архитектуры. Таким образом под общим концептуальным названием модели «клиент/сервер» скрывается несколько вариантов архитектурного построения вычислительных систем, а именно архитектуры однозвенные, двухзвенные, трехзвенные и т. д. (обычно при числе звеньев более трех архитектуру называют многозвенной) [24].
Однозвенная архитектура вырождается в классическую архитектуру с централизованной обработкой информации. В двухзвенной архитектуре приложение разделено на две части: клиентскую и серверную. Возможные варианты распределения слоев прикладного программного обеспечения в двухзвенной архитектуре представлены на Рисунке 1. Обычно сторона клиента содержит логику представления, а логика доступа к данным (как правило СУБД) и сама база данных находятся на стороне сервера. Алгоритмы бизнес-логики могут быть размещены либо полностью на стороне сервера (конфигурация так называемого «тонкого» клиента, Рисунок 1б), либо частично или полностью на машине клиента вместе с логикой представления (конфигурация так называемого «толстого» клиента, Рисунок 1в, Рисунок 1г).
В случае размещения на стороне клиента лишь части логики представления, минимально достаточной для функционирования клиента (что характерно для современных архитектур так называемых «терминальных», или «бездисковых», рабочих станций), конфигурация обычно носит наименование «сверхтонкого» клиента (Рисунок 1а)[25].
Рисунок 1 — Варианты построения схемы двухзвенной архитектуры клиент/сервер
Стремление повысить гибкость и масштабируемость многопользовательской распределенной системы привело к архитектурным решениям с тремя и более звеньями. С середины 1990-х годов интенсивное практическое внедрение получила трехзвенная архитектура, которая, как и двухзвенная, поддерживает концепцию «клиент/сервер», но разделяет систему по функциональным границам между тремя слоями: логикой представления, бизнес-логикой и логикой доступа к данным (Рисунок 2).
В трехзвенной архитектуре появилось дополнительное звено (так называемый «сервер приложений»), целиком предназначенное для реализации бизнес-логики. Трехзвенная архитектура позволила более явно отделить прикладную логику от пользовательского интерфейса и уровня баз данных. Так как в трехзвенной архитектуре под бизнес-логику обычно выделяется отдельная машина-сервер, то это повышает гибкость распределенной системы обработки информации (поскольку все три слоя отделены друг от друга, то становится возможным относительно легкое изменение либо перемещение любого из них без существенного влияния на остальные слои)[23].
Рисунок 2 — Схема трехзвенной архитектуры клиент/сервер
Характерным примером использования трехзвенной архитектуры являются веб-приложения, которые реализуются посредством трех компонентов: веб-браузера клиента, веб-сервера и реляционной базы данных. Веб-браузер на машине-клиенте обычно отвечает за предоставление клиенту графического интерфейса, который облегчает доступ к удаленным документам. Браузер интерпретирует страницы, написанные с использованием языка HTML, и формирует их представление на мониторе клиента. Для извлечения удаленного документа браузер связывается с веб-сервером по протоколу HTTP, а затем сервер по тому же протоколу передает клиенту HTML-документ, найденный в базе данных. При этом уровень клиента, уровень сервера и уровень данных физически разнесены по разным машинам[27].
Именно выделение бизнес-логики в отдельное звено позволяет преодолеть фундаментальные ограничения двухзвенной архитектуры. Клиенты в этом случае не поддерживают постоянного соединения с базой данных, а обмениваются информацией со средним звеном только тогда, когда это необходимо. В то же время процесс среднего звена поддерживает всего несколько активных соединений с базой данных, но использует их многократно. Поэтому процессы в среднем звене могут предоставлять обслуживание теоретически неограниченному числу клиентов [22].
распределенной СУБД
Рисунок 3 — Схема четырехзвенной архитектуры клиент/сервер
Перенос основных операций приложения на отдельный уровень позволяет с максимальной эффективностью распределить нагрузку на аппаратные устройства (трехзвенная модель на самом деле может быть многозвенной с разделением нагрузки на несколько серверов приложений) и обеспечивает безболезненное наращивание, как функциональности приложения, так и числа обслуживаемых пользователей [25].
Глава 2. Механизмы реализации технологии распределенной обработки информации
2.1 Механизм удаленного вызова процедур
Синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером) поддерживает спецификация удаленного вызова процедур (remote procedure call — RPC).
Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам — клиентскому и серверному переходникам, или заглушкам (от англ. stub — заглушка, переходник).
Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой процесс.
remote procedure call
языка описания интерфейсов
Рисунок 4 — Принципиальная схема организации удаленного вызова процедур
Операционная система сервера пересылает сообщение операционной системе клиента. Клиент выводится из состояния ожидания, его операционная система принимает сообщение и направляет его клиентскому переходнику, который извлекает результаты из сообщения, передает их клиенту и возвращает клиенту управление [33].
Принципиальная схема организации удаленного вызова процедур представлена на рисунок 4.
По существу, RPC реализует в распределенной среде принципы традиционного структурного программирования. Клиент обращается к процессу-переходнику так, как будто он и есть реальный серверный процесс, и этот вызов ничем не отличается от вызова локальной функции. Другими словами, клиентский переходник превращает локальный вызов процедуры клиента в локальный вызов процедуры сервера. При этом ни клиент, ни сервер могут ничего «не знать» о выполняемых промежуточных действиях.
Клиентские и серверные переходники изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций, а язык IDL обеспечивает независимость механизма RPC от языков программирования. Благодаря этому при вызове удаленной процедуры клиент может использовать свои языковые конструкции, преобразуемые затем IDL-компилятором в собственные описания, а на сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализована серверная процедура.
Как и в случае нераспределенной программы, вызов процедуры на удаленном компьютере влечет за собой передачу управления этой процедуре, то есть блокирует выполнение клиентской программы на время обработки вызова.
Существуют асинхронные реализации механизма RPC. Асинхронный RPC не блокирует выполнение клиентского процесса на время выполнения запроса. Этот вариант удаленного вызова обеспечивает более масштабируемые решения, поскольку значительно сокращает объем поддерживаемой информации о соединении и сеансе связи между клиентом и сервером.
В общем случае механизм RPC создает статические отношения между компонентами распределенного приложения: привязка клиентского процесса к конкретным серверным переходникам происходит на этапе компиляции и не может быть изменена во время выполнения, что является существенным недостатком механизма RPC. Этот недостаток преодолевается в других механизмах и технологиях, рассмотренных далее.
Большинство систем MW категории RPC базируется на стандарте DCERPC (DCE — Distributed Computing Environment — «среда распределенных вычислений») организации Open Group . Эти системы свободно распространяются в виде исходных кодов и существуют в реализациях ряда поставщиков ПО, которые настраивают этот код на определенную операционную систему. Помимо базового механизма взаимодействия распределенных приложений, в DCE реализованы некоторые важные для распределенной среды службы, такие как служба каталогов, средства защиты и распределенная файловая система [35].
2.2 Объектно-ориентированный подход к организации распределенной обработки информации
Объектно-ориентированный подход способствует значительному усовершенствованию механизмов организации распределенной обработки информации. Важнейшим свойством объектов (object) является то, что они позволяют скрыть свое внутреннее строение посредством наличия строго определенного интерфейса. Поэтому при замене или изменении объектов интерфейс может оставаться неизмененным. Вследствие этого возможно относительно легкое распространение и применение принципов RPC к удаленным объектам.
Объекты инкапсулируют данные, называемые состоянием (state), и операции над этими данными, называемые методами (method).
Для доступа или манипулирования состоянием объекта нужно использовать методы, обращение к которым осуществляется через интерфейсы. Объект может реализовывать множество интерфейсов, а для данного описания интерфейса может существовать несколько объектов, предоставляющих его реализацию.
Для распределенных систем разделение на интерфейсы и объекты позволяет помещать интерфейсы на одну вычислительную машину, а сами объекты — на другую. Принципиальная схема организации механизма удаленных объектов представлена на рисунок 5. При выполнении клиентом «привязки» к распределенному объекту в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем (proxy).
Заместитель клиента аналогичен клиентскому переходнику в механизме RPC. Он выполняет маршалинг параметров в сообщения при обращении к методам, демаршалинг данных из ответных сообщений с результатами обращения к методам, передачу результатов клиенту. Сами же объекты находятся на сервере и предоставляют необходимые клиентской системе интерфейсы. Входящий запрос на обращение к методу сначала попадают в так называемый серверный каркас, или скелетон (skeleton), аналогичный серверному переходнику в RPC. Cерверный каркас преобразует входящий запрос в обращение к методу через интерфейс объекта, находящегося на сервере [35].
Каркас также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента. Если объект физически распределен по нескольким вычислительным машинам, то это скрывается от клиентов за интерфейсами объектов.
Рисунок 5 — Принципиальная схема механизма организации удаленных объектов
Форма существования объектов в распределенных системах чаще всего соответствует объектам выбранного объектно-ориентированного языка программирования. Такие объекты представляют собой так называемые объекты времени компиляции. Использование этих объектов в распределенных системах обычно значительно упрощает создание распределенных приложений. Недостатком использования таких объектов является их зависимость от конкретного языка программирования [40].
Альтернатива состоит в создании распределенных объектов непосредственно во время выполнения. При этом подходе распределенные приложения не зависят от конкретного языка программирования и они могут быть созданы из объектов, написанных на различных языках. При работе с такими объектами времени исполнения для превращения конкретной программной реализации в объект, методы которого будут доступны с удаленной вычислительной системы, используется адаптер объектов, служащий оболочкой этой реализации с целью придания ей реализации видимости объекта.
Объекты подразделяются на сохранные (persistent) и транзитные, или нерезидентные (transient).
Сохранный объект не зависит от своего текущего сервера и продолжает существовать, даже не находясь постоянно в адресном пространстве серверного процесса. Сервер, управляющий таким объектом, может сохранить состояние объекта во вспомогательном запоминающем устройстве и прекратить свою работу, а затем после запуска снова прочитать состояние сохранного объекта из запоминающего устройства в свое адресное пространство и приступить к обработке обращений к объекту. Нерезидентный объект существует, пока им управляет сервер. Если сервер завершает работу, то такой объект прекращает существовать.
Системыобработки информации, поддерживающие распределенные объекты, обычно предоставляют ссылки на объекты, уникальные в пределах системыобработки информации. Такие ссылки могут свободно передаваться между процессами, запущенными на различных вычислительных машинах, например, как параметры обращения к методу. Перед обращением к методу объекта по его ссылке сначала выполняется привязка (явная или неявная), в результате создается заместитель объекта, реализующий интерфейс с методами, к которым обращается процесс. Для выполнения привязки система находит сервер, управляющий объектом, и помещает заместитель объекта в адресное пространство клиента. В результате обеспечения таким образом непрозрачности реализации ссылок на объекты (сокрытия истинной реализации ссылок) достигается повышенная прозрачность распределения по сравнению с традиционным механизмом RPC [34].
Клиент, осуществив связь с объектом, может через заместителя объекта обратиться к методам объекта. Таким образом при объектно-ориентированном подходе к распределенной обработке информации реализуется механизм так называемого удаленного обращения к методам (RemoteMethodInvocation — RMI).
Обращение к методу может быть статическим (интерфейсы известны при разработке) или динамическим (параметры собираются перед обращением к методу).
На основе механизма RMI разработано множество стандартов и программных реализаций объектно-ориентированных платформ промежуточного ПО, поддерживающих эффективную распределенную обработку информации [16].
2.3 Распределенная обработка информации на основе транзакционного взаимодействия и с применением технологий обмена сообщениями
Для реализации транзакционного взаимодействия применяются мониторы обработки транзакций TPM (Transaction Processing Monitor), или транзакционные мониторы, разработанные для обеспечения надежного мультиплексного доступа к большому количеству ресурсов для большого количества параллельных пользователей. Механизм TPM — наиболее старая технология реализации распределенных систем, которая появилась в 1970-х годах в среде больших универсальных вычислительных машин для выполнения банковских, страховых и других высококритичных вычислений.
Транзакционные мониторы представляют одну из самых сложных и многофункциональных технологий в мире промежуточного ПО. Они предназначены для автоматизированной поддержки приложений, оформленных в виде последовательности транзакций. Каждая транзакция представляет собой законченный блок обращений к ресурсу (чаще всего — к базе данных) и некоторых действий над ним. Корректное выполнение транзакции должно гарантировать выполнение четырех условий — так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability) [40]:
- Atomicity (атомарность) — операции транзакции образуют неразделимый, атомарный блок («unitofwork» — «единица работы») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;
- Consistency (согласованность) — по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;
- Isolation (изолированность) — одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;
- Durability (долговременность) — все модификации ресурсов в процессе выполнения транзакции будут долговременными.
В системе без TPM обеспечение свойств ACID берут на себя серверы распределенной базы данных на основе протокола 2РС — (two-PhaseCommit — двухфазное подтверждение).
Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы обработки информации опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции. Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, требуется использование механизма монитора обработки транзакций. Транзакционные мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру общего стандарта распределенной обработки транзакций DTP (DistributedTransactionProcessing) для данной категории промежуточного программного обеспечения MW (middleware).
Архитектура DTP поддерживает совместное использование ресурсов (файлов или баз данных) множеством программ, обеспечивая управление доступом, гарантирующее согласованность системы обработки информациив целом. Транзакционный монитор поддерживает выполнение распределенных транзакций на основе транзакционного RPC. Традиционные вызовы удаленных процедур независимы. Если вызывается сервер, который, выполняя удаленную процедуру, вызывает другой сервер, нет способа отличить, где произошла ошибка — в первом или втором сервере. Семантика же транзакционного вызова такова: если группа вызовов процедур внутри транзакции подтверждается (успешно завершается), имеются гарантии, что каждый из вызовов завершился успешно. Если возникло прерывание выполнения группы вызовов, общий эффект будет таким, как если бы ни один из вызовов не выполнялся. Процедурные вызовы, заключенные в транзакционные скобки, рассматриваются как единое целое, а инфраструктура RPC гарантирует их атомарность.
Функциональность транзакционных мониторов достаточна для разработки, выполнения, управления и сопровождения транзакционных информационных распределенных систем. Эта функциональность включает в себя язык IDL, именование, безопасность и аутентификацию, компиляторы переходников, поддержку работы с транзакционными вызовами (транзакционные скобки, обратные вызовы), ведение журнальных записей, восстановление, блокировку, управление процессами и приоритетами, балансировку нагрузки, репликацию, управление ресурсами.
Промежуточное ПО, ориентированное на обмен сообщениями (Message Oriented Middleware — MOM), относительно молодая и динамично развивающаяся категория систем промежуточного слоя [44].
Согласно этой модели приложения обмениваются байтовыми строками — сообщениями, обращаясь к API-интерфейсу системы MOM, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от ранее рассмотренных моделей промежуточного ПО, MOM реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложений. MOM можно считать и наиболее гибкой категорией MW, поскольку системы обработки информации этого типа поддерживают как синхронные, так и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения. По способу обмена сообщениями все продукты MOM могут быть разделены на три подгруппы систем:
1) с передачей сообщений,
2) c очередями сообщений,
3) типа публикация/подписка.
Системы обработки информациис передачей сообщений (MessagePassing — MP) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Отсюда следует, что данное решение не подходит для слабо связанных программ, работающих в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей. Обмен сообщениями может происходить в синхронном и асинхронном режиме. Кроме средства непосредственных коммуникаций, системы обработки информацииэтого типа могут обеспечивать дополнительные службы промежуточного слоя, например, службу каталогов.
Принципиальная схема организации механизма очередей сообщений представлена на рисунке 6 [33].
Рисунок 6 — Принципиальная схема организации механизма очередей сообщений
Основным подходом, который используется в распределенных системах на основе моделей согласования, является отделение собственно вычислительных процессов от механизмов их согласования. Если рассматривать распределенную систему как набор процессов (возможно, многопоточных), то вычислительная часть распределенной системы обработки информацииобразована группой процессов, каждый из которых осуществляет конкретные вычислительные операции, причем эти операции в принципе могут выполняться независимо от других процессов. В этой модели согласующая часть распределенной системы обработки информацииподдерживает все взаимодействие между процессами и организует их взаимную кооперацию. Она образует тот «клей», который связывает воедино деятельность, выполняемую разными процессами. В распределенных системах обработки информации согласования основное внимание уделяется согласованию процессов [42].
В том случае, если процессы обладают связностью ссылок и времени, согласование осуществляется напрямую и имеет название прямого согласования (direct coordination).
Связность ссылок обычно имеет вид явной идентификации собеседника в процессе взаимодействия. Так, например, процесс может взаимодействовать с другим процессом только в том случае, если он знает идентификатор процесса, с которым хочет обменяться информацией. Временная связность означает, что оба взаимодействующих друг с другом процесса активны одновременно. Такая связность имеет место при нерезидентной связи на основе сообщений[42].
Другой тип согласования наблюдается в том случае, если процессы не связаны по времени, но связаны по ссылкам. Такой тип согласования называют согласованием через почтовый ящик (mailboxcoordination).
В этом случае для взаимодействия не нужно, чтобы два взаимодействующих друг с другом процесса выполнялись одновременно. Вместо этого взаимодействие происходит путем посылки сообщений в почтовый ящик, может быть, используемый совместно. При этом необходимо явно указать адрес почтового ящика, в котором должны храниться сообщения. Это и есть ссылочная связность[27].
Комбинация связности по времени и несвязности по ссылкам образует группу моделей согласования на встрече (meeting-orientedcoordination).
В несвязной по ссылкам системе процессы не имеют полной информации друг о друге. Другими словами, когда процесс хочет согласовать свою деятельность с другими процессами, он не может обратиться к ним напрямую. Взамен используется метафора встречи, на которой собираются процессы, чтобы скоординировать свою деятельность. Модель предполагает, что процессы, участвующие во встрече, выполняются одновременно[27].
Наиболее распространенный вариант согласования — это сочетание несвязных по времени и по ссылкам процессов. Этот вариант представлен генеративной связью (generative communication), которая впервые была реализована в программной системе Linda. Основная идея генеративной связи состоит в том, что набор независимых процессов может использовать разделяемое сохранное пространство данных, организуемое с помощью кортежей. Кортежи — это именованные записи, содержащие несколько (но, возможно, и ни одного) типизованных полей. Процесс может помещать в разделяемое пространство данных записи любого типа (то есть генерировать связующие записи).
Для разделения кортежей в соответствии с информацией, которая в них содержится, достаточно их имен. Разделяемые пространства имен реализуют механизмы ассоциативного поиска кортежей. Другими словами, когда процесс хочет извлечь кортеж из пространства данных, ему достаточно определить значения полей, которые его интересуют. Любой кортеж, удовлетворяющий описанию, будет извлечен из пространства данных и передан процессу. Если ничего найдено не будет, процесс может заблокироваться до прихода очередного кортежа.
Примером системысогласования является система Jini («джини») компании SunMicrosystems. Отнесение Jini к системам согласования основано в первую очередь на том, что эта система способна поддерживать генеративную связь при помощи Linda-подобной службы под названием JavaSpace. Однако существует множество служб и средств, которые делают Jini больше, чем просто системой согласования [1].
Jini — это распределенная система, состоящая из разных, но взаимосвязанных элементов. Она жестко привязана к языку программирования Java, хотя многие из ее принципов равно могут быть реализованы и при помощи других языков. Важной частью системы является модель согласования генеративной связи. Jini обеспечивает как временную, так и ссылочную несвязность процессов при помощи системы согласования JavaSpace. JavaSpace — это разделяемое пространство данных, в котором хранятся кортежи. Кортежи
представляют собой типизованные наборы ссылок на объекты Java. В одной системе Jini могут сосуществовать несколько пространств JavaSpace [3].
Заключение
Системы распределенной обработки информации в виде многомашинных вычислительных комплексов и компьютерных сетей представляют собой одну из наиболее прогрессивных форм организации средств вычислительной техники. Возможность взаимодействия вычислительных систем при реализации распределенной обработки информации определяют как их способность к совместному использованию данных или к совместной работе с использованием стандартных интерфейсов. Целью распределенной обработки информации является оптимизация использования ресурсов и упрощение работы пользователя.
Распределенная система позволяет скрыть от пользователя аспекты своей внутренней организации, физические места размещения ресурсов, вопросы реализации и взаимодействия процессов, обслуживающих запросы пользователя. Распределенная система способна увеличиваться в масштабах путем подключения к системе дополнительных компонентов без принципиального влияния на работу существующих приложений и пользователей.
Прикладное программное обеспечение в общем случае может быть представлено в виде композиции трех логических слоев: слоя логики представления, слоя бизнес-логики и слоя логики доступа к данным. Послойное разделение прикладного программного обеспечения минимизирует взаимодействие между составными элементами и служит основой для выделения компонентов, которые могут быть распределены для работы на нескольких вычислительных машинах.
Децентрализованная обработка информации основывается на архитектурной модели клиент/сервер, где клиентами считаются вычислительные машины, нуждающиеся в получении тех или иных услуг, а серверами — вычислительные машины, которые эти услуги предоставляют. Под общим концептуальным названием модели клиент/сервер скрывается несколько вариантов архитектурного построения вычислительных систем, а именно архитектуры однозвенные, двухзвенные, трехзвенные и многозвенные.
Промежуточное программное обеспечение позволяет осуществить связь и взаимодействие между разнородными компонентами распределенных систем, предоставляет стандартные интерфейсы программирования, реализует переносимость программ и прозрачность функционирования систем распределенной обработки информации.
Наибольшее практическое распространение получили следующие механизмы реализации распределенной обработки информации: удаленный вызов процедур, объектно-ориентированный подход на основе удаленного обращения к методам, транзакционное взаимодействие на базе мониторов обработки транзакций, использование моделей обмена сообщениями и моделей согласования.
