CC BY
143
Шибанов С.В., Горин А. А.
Пензенский государственный университет
ОБЗОР СОВРЕМЕННЫХ ТЕХНОЛОГИЙ И СРЕДСТВ ПОСТРОЕНИЯ АКТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
Введение
На сегодняшний день информационные системы применяются везде, где необходим быстрый доступ к большим объемам часто обновляемой информации. Любая современная информационная система строится на основе базы данных. Информационные системы постоянно совершенствуются, расширяется их функциональность для соответствия современным стандартам и постоянно повышающимся требованиям к функциональности надежности и безопасности.
Одним из требований к функциональности ИС является своевременное реагирование системы на определенное изменение в структуре данных, а также способы взаимодействия распределенных компонент системы между собой. Последнее требование имеет особенно важное значение в современном мире ИС, так как сейчас такие системы по своей структуре далеко не всегда представляют из себя единственный компьютер-сервер и несколько клиентских машин, не сообщающихся между собой. А взаимодействие клиентов и сервера уже не сводится только лишь к запросам и последующим ответам. Обычные коммерческие СУБД, как правило, не предоставляют данные возможности, и при необходимости реализации такого функционала разработчики разных ИС решают эту проблему каждый по-своему. Назовем такие информационные системы активными ИС. За последние несколько лет разработчики СУБД добавили в свои продукты ряд функций, позволяющих частично реализовать выше описанные функции активного взаимодействия. А также появились готовые решения для бизнеса, или предприятия, включающие СУБД и дополнительные продукты для обеспечения активной функциональности.
В данной статье приведен обзор наиболее распространенные стандарты и технологии построения расширяемых и масштабируемых ИС на основе технологии активных систем. Выявлены достоинства и недостатки рассмотренных технологий.
1. Архитектуры для построения расширяемых активных систем
Определим сначала, какие функции будем считать присущими активным ИС. Такие функции будем называть функциями активного взаимодействия.
К данным функциям можно отнести
механизм отправки (публикации) сообщений в результате возникновения каких-либо событий в системе или вне ее;
механизм подписки на эти события различных компонентов системы, а также;
выполнение определенных действий в ответ на то или иное событие или сообщение.
Информационные технологии широко используются в различных сферах хозяйственной и экономической деятельности. При этом, накопленное крупными компаниями множество программных продуктов - это, как правило, слабо расширяемые и плохо интегрируемые приложения. И это по оценкам аналитиков приводит к тому, что большая часть денег, выделенная на автоматизацию, тратится на сопровождение систем. Благодаря негибкой архитектуре приложений, IT-инфраструктура во многих компаниях обладает фрагментарностью и дублированием данных и функций, а на изменение бизнес-процессов зачастую требуются годы. Все это напрямую влияет на ключевые показатели эффективности основной деятельности компаний, особенно в условиях глобального экономического кризиса, когда бизнесу как никогда быстро надо адаптироваться к быстроменяющимся требованиям рынка. Обеспечить подобные преимущества могут новые и активно развивающиеся подходы [1] к построению корпоративных приложений:
Событийно-управляемая архитектура (EDA);
Сервис-ориентированная архитектура (SOA).
1.1. Событийно-управляемая архитектура (EDA)
Событийно-управляемая архитектура или архитектура, управляемая событиями (от англ. EDA, Event-driven architecture) - одна из архитектура, позволяющая создавать приложения на принципах активного взаимодействия.
Термин EDA предложил Рой Шульте, аналитик компании Gartner, в опубликованном 9 июля 2003 года отчете «Повышение значимости событий для интеграции приложений» [2] . Этот документ неожиданно быстро оказался в списке наиболее цитируемых работ по интеграции приложений, а его автор приобрел широкую известность среди специалистов.
Событийно-управляемая архитектура (EDA) - это архитектура, в которой события начинают обмен сообщениями в реальном времени между приложениями в системе. EDA базируется на так называемых программах-агентах, которые обрабатывают возникающие события, после чего передают сообщение о данном событии всем приложениям в системе, так называемым подписчикам (subscriber), которых нужно известить о произошедшем событии [3, 4].
Событийно-управляемый механизм взаимодействия [4] основывается на организации взаимодействия между компонентами путем обмена сообщениями через коммуникационную среду (рис. 1) . Компоненты
могут в произвольный момент времени подключаться к этой среде для приема либо отправки сообщений или отключаться от нее. При этом коммуникационная среда самостоятельно обеспечивает сетевую и локальную передачу сообщений. Подобная архитектура позволяет эффективно реализовать крупнозернистый параллелизм, а также дает широкие возможности для расширения программы [б] . Как указывается в работе [2], реализация бизнес-процессов, подчиненных событиям, отражает событийную природу реального мира, что дает предприятиям финансовое и стратегическое преимущество.
L-------------Коммутационная среда _________Q
^Модуль VI одул ь Модуль
Рисунок 1 - Система обмена сообщениями
Система передачи сообщений разбита на два уровня: локальный уровень обмена сообщениями и сетевой уровень. На локальном уровне (уровне конкретной вычислительной машины в рамках локальной сети) может функционировать от одного до нескольких локальных модулей маршрутизации сообщений (ММС).
Благодаря наличию в приложении локального ММС, оно может состоять из слабозависимых компонент взаимодействующих друг с другом посредством событий. Число компонент может варьироваться в зависимости от назначения приложения.
Локальные ММС могут взаимодействовать друг с другом и с ММС на других ЭВМ через сетевой ММС. При этом, локальный ММС может быть подключен только к одному сетевому. Сетевые ММС предназначены для обеспечения передачи сообщений между вычислительными машинами (удаленное взаимодействие) и между подключенными локальными ММС (кросс-процесное взаимодействие).
Благодаря выбранному механизму взаимодействия получается программная система, компоненты которой являются слабо-связными и событийно-управляемыми. Автоматически получается развязка инициатора событий от его обработчика (-ов), компонент, публикующий сообщение, может не знать кто является его обработчиком и сколько их будет [7].
1.2. Сервис-ориентированная архитектура (SOA)
Сервис-ориентированная архитектура (англ. SOA, service-oriented architecture) - модульный подход к разработке программного обеспечения (в дальнейшем ПО), основанный на использовании сервисов (служб) со стандартизированными интерфейсами.
Такой подход обладает множеством преимуществ. Приложения, созданные на принципах SOA, легче встраиваются в композитные приложения по двум причинам. Во-первых, они по определению являются модульными, а потому крупные работы проще разбивать на отдельные задачи. Во-вторых, они обладают свойством инкапсуляции, то есть способностью к прозрачному описанию интерфейсов, изолирующих внутренние части компонентов от внешних контактов. Все это позволяет организовывать взаимно независимую деятельность групп разработчиков, каждая из которых может сосредоточиваться на своей теме, не уделяя значительного внимания вопросам координации.
Слабая связанность SOA позволяет разработчикам, провайдерам и потребителям сервисов взаимодействовать вне зависимости от использованных ими технических решений и с минимальным знанием друг о друге — достаточно умения идентифицировать и использовать необходимый сервис.
SOA предполагает, что потребитель запрашивает получение некоторых данных или некоторой функциональности, а провайдер сервиса отвечает ему, реализуя этот запрос.
SOA поддерживает синхронный режим сервиса, то есть при отработке запроса обе стороны находятся в режиме взаимодействия.
Первым механизмом реализации SOA стал непосредственный обмен сообщениями между провайдером и потребителем сервисов (replay/request). Предполагается, что потребитель посылает запрос в виде сообщения и ждет ответного сообщения, содержащего нужный сервис. Сообщение заказчика должно содержать обратный адрес и спецификацию желаемого действия. Ответное сообщение поставщика может содержать желаемые сведения или, к примеру, быть пустым.
Механизм «публикация/подписка» в некоторых случаях ассоциируют с EDA, хотя он точно так же может быть использован и для создания SOA. Потребитель подписывается на сведения об определенных категориях событий, описывая средствами метаданных интересующие его события. Провайдер сервисов или промежуточное звено анализирует заявку и передает сведения о событиях подписчику.[2]
Маршрутизация сообщений о событиях отличается от двух описанных механизмов тем, что в этом случае выполняется не простая механическая пересылка сообщений: вдобавок обеспечивается анализ контекста сообщения, а маршрутизация осуществляется в соответствии с имеющимися интеграционными сценариями. Сценарные правила позволяют более гибко выбирать каналы. В качестве одной из технологий контентной маршрутизации можно использовать ESB.
Асинхронность освобождает от излишней связанности двух сторон, но предполагает абсолютную надежность сети. Если сеть «падает», сообщения могут оказаться потерянными. Встроенные хранилища сообщений позволяют установить асинхронную передачу сообщений о событиях без риска их потери.
Все четыре механизма активно развиваются; разрабатываются несколько поддерживающих их стандартов, в том числе WS-ReliableMessaging, WS-Eventing и WS-Notification. [5]
1.3. Сравнение EDA и SOA архитектур
Рассмотренные выше архитектуры EDA и SOA имеют свои преимущества и недостатки.
Преимущества EDA:
Обеспечивает параллельное функционирование компонент приложения;
Динамическое изменение структуры за счет подключения и отключения модулей;
Широкие возможности расширения системы за счет компонентной структуры;
Механизмы обеспечения отказоустойчивости;
Механизмы подписки и доставки уведомлений о событиях;
Отдельная коммуникационная среда, обеспечивающая передачу сообщений;
Отправитель может не знать адресата и их количество.
Преимущества SOA:
Модульный подход;
Слабая связанность и большая надежность сети за счет асинхронной передачи сообщений;
Поддерживается механизм сообщений с гибкой системой маршрутизации.
Недостатки SOA:
Не поддерживается синхронная передача сообщений
2. Продукты и решения с функциями активного взаимодействия
2.1 Решения на базе продуктов IBMWebSphere
Компанией IBM разработан ряд продуктов для построения корпоративных систем на основное технологий активного взаимодействия.
Компания IBM активно применяет в своих решениях технологию SOA. Она разработала SOA Foundation - это инфраструктура программного обеспечения и услуг, позволяющая заказчикам из самых различных отраслей извлечь максимум выгоды из своих инвестиций в ИТ и предоставляющая комплексное решение по интеграции людей, процессов и информации. Она включает набор программных средств, основанных на открытых стандартах, а также описания оптимальных методик и соответствующих ресурсов, помогающих клиентам начать работу с SOA.[8]
WebSphere Application Server предоставляет среду для работы Web-приложений бизнеса по требованию .
WebSphere Enterprise Service Bus. Чтобы помочь клиентам в развертывании SOA, IBM представляет решение WebSphere Enterprise Service Bus (ESB) - это продукт, построенной на основе открытых стандартов и SOA. Он предоставляет простую в использовании функциональность, построенную на испытанных технологиях обмена сообщениями и Web-сервисов, имеющихся в составе WebSphere Application Server.
Enterprise Service Bus (ESB) - это гибкая коммуникационная инфраструктура для интеграции приложений и сервисов . ESB расширяет возможности вашей сервис-ориентированной архитектуры, уменьшая число, объем и сложность интерфейсов между этими приложениями и сервисами.
ESB выполняет следующие задачи:
Распределяет сообщения между сервисами.
Конвертирует транспортные протоколы между источником запроса и сервисом.
Конвертирует форматы сообщений между источником запроса и сервисом.
Управляет бизнес-событиями различных источников.
Для ESBIBM предлагает два основных продукта: IBMWebSphereESB и IBMWebSphereMessageBroker.
ПО WebSphere ESB обеспечивает возможности взаимодействия Web-сервисов и сервис-ориентированной интеграции. Это решение для компаний, которые стремятся к взаимодействию на базе Web-сервисов и к сервис-ориентированной интеграции. Продукт WebSphere ESB предоставляет стандартизованные средства взаимодействия на базе Web-сервисов и сервис-ориентированную интеграцию.
IBM WebSphere Process Server. Решение IBM WebSphere Process Server основано на архитектуре SOA и рассчитано на максимальное использование ее возможностей. Для создания эффективного SOA-решения необходимы как универсальная модель вызова компонентов, так и универсальное представление данных.
В состав SOA-ядра входят: архитектура ServiceComponentArchitecture (SCA), объекты типа BusinessObject и инфраструктура CommonEventInfrastructure - эти базовые компоненты будут использоваться и в других будущих продуктах IBM. [8]
2.2. Технология SQL Server Service Broker от Microsoft
В Microsoft SQL Server 2005 была реализована распределенная платформу обмена сообщениями, для поддержки асинхронного программирования. Брокер служб (Service Broker) является новой платформой для создания асинхронных приложений распределенной базы данных.
С новой платформой Брокер служб внутренние или внешние экземпляры SQL Server могут отправить и получить гарантируемые, асинхронные сообщения при использовании T-SQL. Сообщения могут быть отправлены изнутри той же самой базы данных, отличающейся базы данных, или даже из удаленных экземпляров SQL Server.
Брокер служб основан на протоколе, названном Диалогом, который допускает двунаправленную передачу между двумя конечными точками. Диалоговый протокол определяет логические шаги, требуемые для надежного обмена данными, и удостоверяется, что сообщения получаются правильно, если они были отправлены. Следующая ниже схема от Microsoft SQL Server 2005 показывает, как протокол Диалог используется в платформе Брокера служб.
Рисунок 2 - Использование протокола Диалог в платформе Брокера служб.
На рисунке 2 показаны основные объекты Брокера служб, такие как сообщение, Контракт и Служба, которые будет объяснены далее. Диалоговый протокол обмена данными, как мы видим, не является протоколом транспортировки, это - протокол приложения, чтобы поддержать сообщение "Точно - Однажды -В порядке очередности" (EOID). EOID, понятие упорядочивания сообщений независимо от того, в каком порядке они были получены из канала транспортировки.
Конечные точки Службы являются коммуникационными конечными точками между двумя Брокерами Служб. Они поддерживает протоколы транспортировки, такие как TCP/IP, HTTP, SOAP и т.д.
Конечные точки создаются на каждом Брокере служб, чтобы учесть удаленную передачу между различными экземплярами SQL Server.
2.3. Проект HiPAC
Данный проект разрабатывался в конце 80-х годов, но так и не получил дальнейшего развития. Однако, концепция построения систем, разработанная создателями данного проекта интересна с точки зрения построения активных систем.
Проект HiPAC исследует активное, ограниченное временем управление базами данных. СУАБД автоматически выполняет определенные действия, когда возникают определенные условия. Используются правила Условие событие - Действие (ECA). Была также разработана модель выполнения, которая определяет, как эти правила обрабатываются в контексте транзакций базы данных. Дополнительная функциональность, обеспеченная правилами ECA диктует новое требование к проектированию СУАБД. Эта архитектура обеспечивает новые формы взаимодействия, для поддержки правил ECA, между прикладными программами и СУБД. Это приводит к новому взгляду на то, как создать приложения баз данных.
Проект HiPAC предложил правила Событие-Условие-Действие (ECA) как общий формализм, который включают в себя большинство активных функций СУБД, которые ранее были реализованы механизмами особого назначения.
Правила ECA обеспечивают активные возможности базы данных сверх того, что является стандартом для пассивных СУБД. При проектировании СУАБД необходима будет эта дополнительная функциональность .
Центральное понятие модели знаний HiPAC - правила Событие-Условие-Действие (ECA). Семантика правил ECA является прямой: когда событие происходит, оценивается условие; и, если условие удовлетворительно, выполняется действие. Ограничения целостности, ограничения доступа, производные данные, обработчики предупреждений, и другие активные функции СУБД могут быть все выражены как правила ECA.
Даже в тех СУБД, которые обеспечивают некоторые средства для активных баз данных, и события, которые инициировали действия и действия, которые они инициировали, ограничиваются операциями
базы данных. HiPAC позволяет событиям правила быть определенными приложением, и позволяет действиям правила содержать запросы к приложениям. Результатом является совершенно новая парадигма для создания приложений базы данных.[10]
Рисунок 3 изображает интерфейс между прикладной программой и HiPAC. Этот интерфейс делится на четыре модуля. Два из них обеспечивают обычную функциональность СУБД, а другие два уникальны для HiPAC. Разработчик создает модули, которые поддерживают операции на данных и транзакциях. Они содержат операции на событиях, и специализированные операции.
Операции над данными подразумевают как определение данных, так и манипулирование данными. Так как HiPAC использует объектно-ориентированную модель данных, определение данных состоит из определения классов (типы) и операции на экземплярах этих классов. Приложения управляют данными, вызывая операции через этот интерфейс.
2.4 Сравнение продуктов и решений с функциями активного взаимодействия
Перечислим достоинства и недостатки рассмотренных выше реализаций систем с элементами активности.
Преимущества IBM WebSphere:
Маршрутизация и выбор получаемых сообщений по содержимому Изменение содержимого сообщения в процессе передачи Использование стандартов WSDL, SOAP, HTTP, XML Недостатки IBM WebSphere:
Передача сообщений разных типов и необходимость в их конвертировании Преимущества SQL Server Service Broker:
Производится контроль за порядком приема сообщений Поддержка протоколов TCP/IP, HTTP, SOAP
Надежная связь между 2-мя конечными точками даже через интернет Обеспечение безопасности с помощью шифрования сообщений и аутентификации Недостатки SQL Server Service Broker:
Связь осуществляется только между 2-мя конечными точками Компоненты системы сильно связаны Преимущества HiPAC:
Присутствует обратная связь клиентов с СУБД Недостатки HiPAC:
Монолитность архитектуры, негибкость
Большая нагрузка на СУБД - бизнес-логика, данные и правила сосредоточены на СУБД Усложняется структура БД по мере расширения системы;
Слабая масштабируемость.
Итоги
В данной статье были рассмотрены самые распространенные архитектуры построения активных систем, такие как SOA и EDA, выявлены их преимущества и недостатки.
Был проведен краткий сравнительный обзор существующих продуктов и решений, а также нереализованных проектов, использующих технологии активного взаимодействия.
ЛИТЕРАТУРА
1. Куриленко И.Е. Сравнение управляемой программной архитектуры с сервис-ориентированной архитектурой и с архитектурой, управляемой событиями / Куриленко И.Е., Борисов А.В., Чернышева Н.В.//
Москва 2008.
2. Черняк Л. EDA — архитектура, управляемая событиями // Открытые системы № 02/2005.
3. Борисов А. В. Применение управляемой программной архитектуры при разработке систем автоматизации парковочных комплексов / Борисов А.В., Куриленко И.Е.// Труды междунар. науч.- техн. конф. «Информационные средства и технологии МФИ-2007». - М.: МЭИ, 2007. - Т.3. - С. 35-38.
4. BrendaM. Michelson.Event Driven Architecture Overview. // Patricia Seybold Group. 2, 2006.
5. Борисов А. В. Управляемая программная архитектура / Борисов А. В., Куриленко И. Е., Чернышева Н.В. // Сб. док. IX международной конференции «Информатика: проблемы, методология, технологии» в 2 т. - Т.1 - 2009. - С. 438-441.
6. Кутепов В.П. Об интеллектуальных компьютерах и больших компьютерных системах нового поколения // Изв. РАН. Теория и системы управления 1996. № 5.
7. K. Mani Chandy. Event Driven Applications: Costs, Benefits and Design Approaches//
California Instituate of Technology, 2006.
8. IBM WebSphere Software - Обзорпродуктовирешений 2007
9. A. Hussein. Introducing Distributed Messaging using Service Broker in SQL Server 2005. //
codeproject.com, 2005.
10. D. R. McCarthy. The Architecture Of An Active Data Base Management System / D. R. McCarthy, U. Dayal. // University of Cambridge, 1989.
