Механизм взаимодействия компонент в программах с управляемой программной архитектурой (4. Событийно-ориентированная архитектура (EDA))

МЕХАНИЗМ ВЗАИМОДЕЙСТВИЯ КОМПОНЕНТ ВПРОГРАММАХ С УПРАВЛЯЕМОЙ ПРОГРАММНОЙАРХИТЕКТУРОЙБорисов А.В., Куриленко И.Е., Лазуткин В.А.ГОУВПО «Московский Энергетический Институт (ТехническийУниверситет)», Москва, РоссияВданнойработерассматриваютсявопросыстандартизациивзаимодействия компонент программы c управляемой программнойархитектурой. Управляемая программная архитектура позволяет [1]:ƒ сократить время разработки и повысить качество программы;ƒ достичь глубокой стандартизация компонент программного средства(ПС) и получить возможность применения средств автоматизации икодогенерации;ƒ автоматизировать процесс построения ПС из компонент;ƒ реализовать автономное тестирование отдельных компонент ПС;ƒ изменять логику работы программы путем изменения набораиспользованных компонент и связей между ними в моментвыполнения программы без перекомпиляции и переустановки;ƒ упростить модификацию приложения при изменении требований;ƒ получить возможность автоматической балансировки нагрузки навычислительных узлах при работе в распределенном режиме;ƒ организовать автоматическое версионирование и упростить процессвыпуска редакций ПС (версий с разными возможностями).Без стандартизированного механизма взаимодействия компонент междусобой трудновыполнимыми оказываются требования независимости ислабойсвязности,заложенныевсамоопределениеуправляемойпрограммной архитектуры [2].

В качестве такого механизма предлагаетсяиспользовать событийно-управляемый механизм взаимодействия [3]. Оносновывается на организации взаимодействия между компонентами путемобменасообщениямичерезкоммуникационнуюсреду(рис.1).Компоненты могут в произвольный момент времени подключаться к этойсреде для приема либо отправки сообщений или отключаться от нее. Приэтом коммуникационная среда самостоятельно обеспечивает сетевую илокальнуюпередачусообщений.Подобнаяархитектурапозволяетэффективно реализовать крупнозернистый параллелизм, а также даетширокие возможности для расширения программы [4].

Как указывается вработе[5],реализациябизнес-процессов,подчиненныхсобытиям,отражает событийную природу реального мира, что дает предприятиямфинансовое и стратегическое преимущество.Рис. 1. Система обмена сообщениямиРассмотрим основные требования к системе обмена сообщениями:ƒ обеспечить возможность синхронной и асинхронной передачисообщений между параллельно выполняющимися компонентами вадресном и безадресном режиме как на уровне отдельно взятойэлектронной вычислительной машины (ЭВМ), так и на уровневычислительной системы в целом;ƒ обеспечить корректное функционирование системы на локальнойЭВМ при потере связи с другими ЭВМ, а также восстановлениепрограммной связи, когда аппаратная связь будет восстановлена безперезапуска локальной системы и потери данных;ƒ обеспечить простоту подключения и отключения компонент вовремя работы системы без какого-либо останова либо перезапускасистемы, перезагрузки схем взаимных соединений модулей и т.п.;ƒ обеспечить возможность многоуровневой фильтрации передаваемыхпо системе сообщений с целью снижения числа сетевых пересылок;ƒ обеспечить надежность на локальном уровне (при сбоях и ошибках вработе одного конкретного локально подключенного модуля недолжна останавливаться ни локальная, ни сетевая рассылкасообщений для других модулей).Обратимся к базовой архитектуре системы передачи сообщений.

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

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

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

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

3). Типизируются сообщения числовымкодом типа сообщения. Для сообщений с одинаковым кодом типа долженбыть одинаковым тип и число аргументов в блоке аргументов.Рис. 3. Формат передаваемого сообщенияКоличество типов передаваемых сообщений произвольно. Формат блокааргументов (его размер и типы значений) определяются разработчикомкомпонент. За счет типизации сообщений упрощается обмен информациеймежду компонентами, и становятся допустимыми дополнительныемеханизмы фильтрации. В частности, к возможности фильтрации по тремуровням (внутрипроцессный / кросспроцесный / сетевой), описаннымвыше, добавляется возможность фильтрации сообщений по типам. Длявключения такой фильтрации компонент должен установить локальномуММС список принимаемых сообщений и в этом случае ему будутпередаваться только сообщения с типами из этого списка (пустой списоксоответствует разрешению на прием сообщений всех типов). В локальноми сетевом ММС на базе списков отдельных компонент формируютсясовокупные списки фильтрации, которые позволяют отсекать от приемасообщения, обработка которых не представляется возможной, чтопозволяет снизить объем «лишних» пересылок.Благодарявыбранномумеханизмувзаимодействияполучаетсяпрограммная система, компоненты которой являются слабо-связными исобытийно-управляемыми.Автоматическиполучаетсяразвязкаинициатора событий от его обработчика(ов), компонент, публикующийсообщение может не знать кто является его обработчиком и сколько ихбудет [6].

Описанная схема:ƒ позволяетосновнымизадатьунифицированныйкомпонентамимеханизмприложенияиобменадобитьсямеждухорошейраспределенности;ƒ позволяетисполнениереализовыватьмодулей)таккакисреднезернистый(параллельноекрупнозернистый(параллельноефункционирование компонент приложения) параллелизм. При этом неисключаетсяреализациямелкозернистогопараллелизма(приреализации каждого из подключаемых модулей);ƒ дает возможность гибкой реконфигурации (или наращивания) системы(замена какого-либо компонента на более новый потенциально можетбыть осуществлена без остановки всей системы);ƒ обеспечивает простоту доработки компонент системы.При разработке компонент в приложении, построенном по управляемойпрограммной архитектуре, рекомендуется использовать исключительнособытийный способ взаимодействия компонент между собой.ЛИТЕРАТУРА1.

Борисов А.В., Куриленко И.Е., Чернышева Н.В. Управляемаяпрограммнаяконференцииархитектура//«Информатика:Сб.док.IXмеждународнойпроблемы,методология,технологии» в 2 т. – Т.1 – 2009. – С. 438–441.2. Борисов А.В., Куриленко И.Е., «Применение управляемойпрограммной архитектуры при разработке систем автоматизациипарковочных комплексов», Труды междунар. науч.-техн. конф.«Информационные средства и технологии МФИ-2007». – М.:МЭИ, 2007. – Т.3. – С. 35-38.3. Brenda M. Michelson «Event Driven Architecture Overview» PatriciaSeybold Group. 2, 2006.4. Кутепов В.П.

Об интеллектуальных компьютерах и большихкомпьютерных системах нового поколения // Изв. РАН. Теория исистемы управления 1996. № 5.5. Черняк Л. «Архитектура, управляемая событиями» – Открытыесистемы, №2, 2005.6. K. Mani Chandy «Event Driven Applications: Costs, Benefits andDesign Approaches» - California Instituate of Technology, 2006..