Сервис-ориентированная архитектура (soa) и архитектура, управляемая моделями (mda)
В последнее время необходимость интеграции и взаимодействия приложений в рамках совокупности большого количества информационных систем предприятия или нескольких предприятий, объединенных в целую партнерскую цепочку, оказывают существенное влияние на используемые программные архитектуры. Детальное рассмотрение этих аспектов выходит за рамки данного курса, но мы посчитали целесообразным привести краткую информацию о новых подходах к проектированию архитектуры информационных систем, так как они имеют непосредственное влияние на принципы формирования архитектуры предприятия в целом.
Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service-oriented architecture SOA) и о реализации архитектуры, "управляемой моделями" (модельная архитектура. Model-driven architecture MDA).
Что такое сервис-ориентированная архитектура и как она связана с вопросами бизнес-архитектуры и архитектуры информационных технологий предприятия?
Хотя концепция сервис-ориентированной архитектуры была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft [4.42] и IBM [4.43], развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически-важных прикладных систем и бизнес-процессов в ближайшем будущем.
Мы уже говорили о том, что в основе бизнес-архитектуры должна быть процессно-ориентированная модель функций предприятия. Комбинация этого подхода с концепцией сервис-ориентированной архитектуры информационных технологий позволяет лучше увязать процесс разработки компонент информационных систем с миссией, основными задачами и функциями организаций.
С помощью SOA организации имеют потенциальную возможность разрабатывать набор реализаций различных бизнес-процессов, которые могут быть многократно использованы предприятием как готовые сервисы.
Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами[4.44]:
явное отделение бизнес-логики прикладной системы от логики презентации информации;
реализация бизнес-логики прикладной системы в виде некоторого количества программных модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в режиме "запрос-ответ", через четко определенные формальные интерфейсы доступа;
при этом "потребитель услуги", который может быть прикладной системой или другим сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие коммуникационные механизмы.
В целом, SOA представляет собой модель взаимодействия компонент, которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Заметим, что одним из известных интеграционных шаблонов как раз и является "Сервис". Интерфейсы сами по себе не зависят от используемых аппаратных платформ, операционных систем или языков программирования, используемых для разработки этих приложений. Это позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом. Такая особенность использования интерфейса, независимого от окружения и платформы, получила название модели "слабой связи". Ее очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на остальных. Достаточно интересное введение в эту проблематику и обсуждение связи терминов SOА и web-cервисов можно найти, например, в [4.45].
Само понятие SOA не является чем-то принципиально новым, так как сходные возможности реализовывались и ранее, например, с помощью технологий обмена сообщениями. Принципиальным фактором является то, что современные подходы к реализации SOA охватывают не только технологический уровень обмена данными, но и уровень бизнес-операций. В частности, одним из важных результатов стала разработка специализированного языка BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-правил. Вообще говоря, принятие SOA как целевой архитектуры будет подразумевать и соответствующий подход к разработке приложений (SODA – service-oriented development architecture).
Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web-сервисов (служб). Под web-сервисами понимаются программные системы, которые используют XML в качестве формата данных, стандарты Web Services Description Language (WSDL) для описания своих интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных систем не обязательно предполагают использование технологий web-сервисов, связь между этими двумя направлениями в развитии информационных технологий является достаточно тесной. При этом web-сервисы являются технологическими спецификациями, в то время как сервис-ориентированная архитектура (SOA) является принципом проектирования архитектуры программных систем.
С учетом отмеченных выше существующих тенденций перехода к бизнесу "реального времени" и создания систем так называемого "расширенного предприятия", объединяющих само предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что технологии web-cервисов найдут свое применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием такого механизма, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.
Более того, даже интеграцию унаследованных приложений целесообразно проводить с применением данной технологии, когда определенная, наиболее важная часть существующей функциональности как бы "инкапсулируется" и представляется стандартизированным интерфейсом. При наличии существующей инфраструктуры web-сервисов на предприятии можно ожидать существенного сокращения сроков и затрат на интеграцию.
Таким образом, влияние сервис-ориентированных подходов на изменения в архитектуре можно охарактеризовать как сбалансированный переход от централизованной инфраструктуры информационных технологий и замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей возможности быстрого создания новых систем из набора доступных сервисов, т.е. более гибкой, динамичной и способной к взаимодействию.
Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия, которая в единой манере описывает как бизнес, так и ИТ [4.46]:
Эта модель состоит из следующих основных компонент:
презентационный уровень описывает интерфейсные сервисы для взаимодействия пользователей с информационной системой, включая корпоративные и публичные порталы, доступ с мобильных устройств, а также различные преобразования информации при взаимодействии с внешними системами и устройствами;
на уровне бизнес-сервисов формируются модели и осуществляется управление выполнением бизнес-процессов предприятия с использованием специализированных средств (типа BPEL), а также координация автоматизированных и "ручных" операций;
интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может быть реализовано, в частности, с использованием средств обмена сообщениями или в рамках единой среды исполнения, такой как сервер приложений J2EE;
cервисы уровня данных реализуют средства извлечения и повторного использования данных из СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях (например, смены вендора или версии продукта), а также обеспечить единый унифицированный подход к выполнению операций с данными;
уровень инфраструктуры, приложений и СУБД является как бы основой для всей структуры, и именно здесь концентрируются основные инвестиции в ИТ.
Рис. 7.13. Ссылочная модель сервис-ориентированной Архитектуры предприятия
Взаимодействие между этими уровнями, однако, осуществляется не напрямую, а через сервисы, выделенные на уровень обработки событий. Сервисы этой компоненты архитектуры обеспечивают сбор данных о событиях в масштабе всего предприятия, необходимое преобразование и маршрутизацию этих данных между разными уровнями, а также "обратную связь" между сервисами каждого отдельного уровня.
В предложенной модели, наряду с рассмотренными уровнями, отвечающими за взаимодействие различных групп сервисов "как бы в процессе деятельности предприятия", выделяется отдельная компонента архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов – то есть их созданием, эксплуатацией и оптимизацией.
MDA является еще одной важной архитектурной концепцией создания информационных систем. Концепция MDA была предложена консорциумом OMG (Object Management Group, http://www.omg.org/), в который сегодня входит более 800 известных производителей программного и аппаратного обеспечения. MDA является определенным обобщением идей SOA, с одной стороны, и повторно используемых программных компонент (шаблонов, паттернов) с другой, предназначенным прежде всего для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.
MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах [3.18]:
основой для разработки приложений масштаба предприятия являются детальные модели с общепринятой нотацией;
построение систем может быть организовано в соответствии с рамочной системой моделей, которые позволяют отделить бизнес-логику приложений от конкретной реализации. Исходной является так называемая независимая модель вычислений (Computational Independent Model), которая путем последовательных трансформаций через платформо-независимые (PIM) и платформо-специфичные модели (PSM) автоматически или с минимальным участием программиста приводится к исполняемому коду и соответствующим структурам данных;
существует формальное описание используемых моделей на основе системы метамоделей (в частности, для таких областей как распределенные вычисления и транзакции, операции в реальном времени и т.п.);
принятие и широкое использование этого подхода основано на открытости промышленных стандартов и на поддержке со стороны производителей соответствующих средств разработки.
В рамках такого подхода сначала создается архитектура, которая описывает модель бизнес-функциональности и поведения прикладной системы независимо от технических деталей реализации. Эта разработка должна вестись в контексте всей корпоративной архитектуры организации. На основе этой модели, не зависящей от платформы реализации, может быть разработана одна или несколько специфических для конкретной платформы моделей, в зависимости от того, какая платформа используется и поддерживается организацией. Уже на основе этих специфических для конкретной платформы моделей разрабатывается код конкретной прикладной системы, как показано нарис. 7.14.
Рис. 7.14. Создание прикладных систем в соответствии с подходом MDA
Этот подход не определяет, какие языки разработки, операционные системы или программное обеспечение промежуточного слоя будут использоваться на практике. Наоборот, упор делается на описание того, как прикладные системы организованы с точки зрения процессов и как они интегрированы между собой. После того как эти высокоуровневые связи определены, могут использоваться соответствующие средства для разработки приложения с использованием конкретных языков и ПО промежуточного слоя. Таким образом, процесс позволяет сократить цикл разработки ИТ-систем и в то же время дает гибкость и возможность быстрого внесения изменений.
Более подробная информация по MDA доступна на сайте http://www.omg.org/mda, а также на сайтах практически всех ведущих производителей систем моделирования и разработки приложений.