Механизм взаимодействия компонент в программах с управляемой программной архитектурой (548609)
Текст из файла
МЕХАНИЗМ ВЗАИМОДЕЙСТВИЯ КОМПОНЕНТ ВПРОГРАММАХ С УПРАВЛЯЕМОЙ ПРОГРАММНОЙАРХИТЕКТУРОЙБорисов А.В., Куриленко И.Е., Лазуткин В.А.ГОУВПО «Московский Энергетический Институт (ТехническийУниверситет)», Москва, РоссияВданнойработерассматриваютсявопросыстандартизациивзаимодействия компонент программы 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..
Характеристики
Тип файла PDF
PDF-формат наиболее широко используется для просмотра любого типа файлов на любом устройстве. В него можно сохранить документ, таблицы, презентацию, текст, чертежи, вычисления, графики и всё остальное, что можно показать на экране любого устройства. Именно его лучше всего использовать для печати.
Например, если Вам нужно распечатать чертёж из автокада, Вы сохраните чертёж на флешку, но будет ли автокад в пункте печати? А если будет, то нужная версия с нужными библиотеками? Именно для этого и нужен формат PDF - в нём точно будет показано верно вне зависимости от того, в какой программе создали PDF-файл и есть ли нужная программа для его просмотра.