Современные архитектурные подходые к построению ПО (5. Сервис-ориентированная архитектура (SOA))

СОВРЕМЕННЫЕ АРХИТЕКТУРНЫЕ ПОДХОДЫ КПОСТРОЕНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ1Борисов А.В., Куриленко И.Е.Московский Энергетический Институт (Технический Университет),РоссияПоследние годы наиболее часто используемым подходом кпроектированию программного обеспечения (ПО) является объектноориентированный подход (ООП) [1].

Разработанный в 80-х годах XX векаон активно развивается. В основе подхода лежат понятия класса (типа),объекта(экземпляракласса),метода(некоторойреализуемойфункциональности) и атрибута (характеристики). Система, построеннаясогласноданному подходу,представляетсобойсовокупностьвзаимодействующих между собой объектов. Задачей разработчика являетсяразработка эффективной иерархии классов для реализации приложения,основываясь на трех основных принципах ООП: полиморфизме,инкапсуляции и наследовании. Первые среды, поддерживающие ООП,реализовывалифункцииупрощенногосозданиясинтаксическихконструкций (классов, методов, атрибутов). Кроме того, поставщиками средстали разрабатываться библиотеки классов, реализующих сервисныефункции в объектно-ориентированном стиле (например, скрывающиевызовы операционной системы (ОС), предоставляющие возможностьупрощенной работы с пользовательским интерфейсом и др.).

Со временемсложность поставляемых библиотек росла в интересах поддержки новыхтехнологий разработки, создания распределенных приложений, работы сInternet. Кроме того стала очевидна низкая степень совместимостисозданных на их базе сред и приложений. В результате по мере увеличениястепени сложности систем все более явными становились сложностисоздания объектно-ориентированных приложений: высокий риск ошибок, заложенных при дизайне системы из-занедостаточного опыта исполнителя или высокой степени сложности ПО;1Работа выполнена при финансовой поддержке РФФИ сложности при разработке распределенных приложений и интеграциисозданных ранее систем из-за отсутствия унифицированных способовсетевого взаимодействия; низкая степень совместимости сред разработки и приложений,построенных на базе платформ от разных поставщиков; сложности при переделке систем как результат исторического развитияархитектуры и низкого качества или отсутствия документации.Перечисленные проблемы привели к удорожанию разработки иосознанию необходимости поиска решения озвученных проблем.Одним из способов решения первой проблемы является использованиешаблонов проектирования и описанных архитектурных подходов.

Шаблоныпроектирования являются важным этапом эволюции подходов к разработке,расширяя концепцию повторного использования результатов разработки наархитектурный уровень. Они активно используются на практике, а знаниешаблонов проектирования стало одним из критериев для определенияпрофессионального уровня разработчика.

В тоже время, использованиешаблонов привело к появлению новой проблемы. Недостаточно обдуманноеприменение шаблонов разработчиками низкого уровня приводит кперегруженности архитектуры, даже если она построена как совокупностьизвестных шаблонов проектирования.Другим способом снижения риска ошибок на стадии разработкиархитектуры является ее моделирование. В этом случае можно говорить овизуализации разрабатываемой архитектуры посредством некоторогопрограммного средства и методологии моделирования.

Такие средства имодели имели независимое развитие и получили широкое распространениене только в сфере разработки ПО, но и за ее рамками. В частности широкоераспространения получило моделирование бизнес процессов (BusinessProcess Modeling, BPM). Моделирование способствует решению третьей ичетвертой проблемы из списка выше. В области разработки ПО средствамоделирования постепенно эволюционировали от средств визуальногопредставления к инструментам с поддержкой автоматической генерациикода и далее к комплексным интегрированным средам.Концепция ООП к архитектуре приложений нашла свое развитие вкомпонентно-ориентированном подходе. Главным отличием последнегоявляется использование понятия компонента, а не класса или объекта вкачестве базовой конструкции.

Компонент – это составная единицапрограммной системы, четко заданная на уровне интерфейса и связей сдругими компонентами. Компонентно-ориентированный подход можнорассматривать как основу для сервис-ориентированного подхода,являющегося в последние несколько лет одним из наиболее популярных.Как результат развития перечисленных направлений выделился рядархитектурных подходов, отражающих концепцию построения сложногоПО и соответствующие практические рекомендации.

Часто эти подходы неявляются взаимоисключающими и дополняют друг друга.Model Driven Architecture (MDA, архитектура управляемая моделью) –это архитектурный подход к построению многокомпонентного ПО,основанный на разработке независимого от платформы и языкапрограммирования представления системы (модели) с последующимпереходим к исходному коду системы через автоматизированнуюгенерацию кода. Разработка MDA началась в 2000 году. Предпосылкой кразработке являлся тот факт, что уже к концу 90-х годов прошлого столетиябыло создано большое количество технологий и протоколов для созданияраспределенных приложений. В качестве примеров можно привестиCOM/DCOM, CORBA, Java/RMI, XML/SOAP/RPC и др.

Большинство такихтехнологий созданы зависимыми от платформы, не все из них былиописаны в виде стандарта. Это создавало большие проблемы при разработкеПО и интеграции компонент в единую инфраструктуру.Основной целью разработчиков MDA являлось создание архитектурногоподхода, позволяющего снизить риск, вызванный различиями между итехнологиями разработки программных систем и платформами. Длярешения этой задачи в MDA вводятся понятия модели, зависимой отплатформы (Platform Specific Model (PSM)), и модели, независимой отплатформы (Platform Independent Model (PIM)). MDA предполагает созданиеPIM и последующий переход к PSM с использованием специализированныхсредств. Кроме того возможен переход от одной PSM модели к другой.Консорциум OMG как разработчик MDA не предоставляет никакихпрограммных средств для обеспечения перехода от модели к модели.Предполагается, что они будут реализоваными силами стороннихразработчиков.

Фактически, MDA – это концепция разработки,поддержанная группой стандартов (UML, MOF, CWM и XMI),разработанных OMG. Эти стандарты накладывают требования, которымдолжны удовлетворять модели, и предоставляют рекомендации дляразработчиков сред создания ПО по MDA.Meta Object Facility (MOF) – это мета-метамодель (модель для описанияметамоделей). MOF состоит из четырех уровней, верхний из которыхсоответствует мета-метамодели. Третий уровень соответствует метамодели(например, UML). Второй уровень соответствует экземпляру UML модели,описывающее какую-либо систему. Самый нижний уровень отражаетэкземпляры моделируемых объектов.Common Warehouse Model (CWM) – спецификация, определяющаяметамодель для обмена экземплярами метаданных между различнымисредствами моделирования и информационными системами.XML Metadata Interchange (XMI) – спецификация описывает отображениеметамоделей, построенных согласно MOF в XML, который в свою очередьможет являться основой для обмена метаданными.Совокупность стандартов MDA MOF достаточна для определениямоделей и метамоделей без введения дополнительных уровней абстракции.Event Driven Architecture (EDA) – это архитектурный подход,основанный на понятии события и его обработке [2].

Система, построеннаяпо EDA, представляет собой совокупность слабосвязанных компонент,обменивающихся сообщениями. Действие в системе выполняется какреакция на такое сообщение. Отправитель сообщения может не знать о том,какой компонент системы будет его обрабатывать.Приложения, построенные по EDA, содержат следующие компоненты: генератор событий – осуществляет первичную обработку сообщений ивыделяет из потока события, на которые требуется реакция. канал событий – обеспечивает транспортный уровень, т.е.

доставкусообщений от компонента к компоненту. процессор событий – реализует логику обработки события, анализируетправила обработки, направляет события подписчикам. управление последующими событиями – обеспечивает реакцию насобытие, фактически, формирует последствия наступления события.В приложениях, построенных по EDA, в той или иной формереализованы перечисленные компоненты, однако реализуемые имифункции могут быть совмещены.

Выделяют три стиля обработкисообщений: простая обработка сообщений предполагает, что все поступающиесообщения значимые и требуют обработки. обработка потока сообщений предполагает, что не все сообщения,попадающие на вход, требуют реакции. Значимые сообщениявыбираются и обрабатываются. Остальные сообщения могутиспользоваться в информационных целях или для анализаисключительных ситуаций. сложный стиль обработки сообщений предполагает, что на входсистемы могут поступать сообщения разных типов и толькоопределенная последовательность событий требует реакции.Наиболее востребованными на практике являются приложения сосложным стилем обработки сообщений. В частности, он реализуется на базетаких продуктов как IBM WebSphere Business Events, TIBCO Business Eventsи др.Service Oriented Architecture (SOA) – это архитектурный подход,основанный на понятии сервиса как базовой единицы построения системы.Обсуждение SOA затруднено тем, что до последнего времени нет единойтрактовки этого термина.

При наличии общего понимания о SOA какархитектуре, основанной на сервисах, в различных источниках возникаютнесогласованности как в определении как самого понятия сервис, так иконцепции в целом [3]. Можно выделить как минимум две трактовки SOA: SOA – это программная архитектура, основанная на построениисистемы как совокупности Web сервисов, реализованных на базе однойили нескольких платформ разработки и взаимодействующихпосредством стандартизованного протокола взаимодействия и четкоописанного на некотором мета-языке интерфейса; SOA – это идеология информатизации бизнеса, основанная напроцессном подходе и локализации этапов бизнес-процессовпосредством выделения сервисов, ассоциированных и обладающихописанным интерфейсом для взаимодействия.Согласно первой трактовке – SOA это архитектурный подход, которыйнапрямую проецируется на одну из платформ для разработки приложений(например, .Net или J2EE).