Магистральным направлением в сфере интеграции приложений становится сервис-ориентированный подход. Крупнейшие игроки в сфере программного обеспечения представляют свои комплексы поддержки SOA, которые, как правило, являются достаточно сложными решениями. В этой связи интересен опыт компании CMA Small Systems AB, предлагающей свою технологию интеграции Processware Integration Environment
Интеграция приложений — одна из ключевых задач современных предприятий в самых разных отраслях. Общие для них проблемы — «лоскутная» автоматизация, то есть использование разнородных приложений для различных задач, парк унаследованных решений, не потерявших своей актуальности в поддержке существующих бизнес-процессов, необходимость взаимодействия на уровне приложений с системами партнеров, поставщиков и даже клиентов, адаптация ИТ-инфраструктуры к последствиям слияния с другими компаниями. Все это требует определенных усилий по интеграции, и чем больше в организации приложений, тем сложнее и запутаннее становится интеграционная среда, если в ее основе не лежат продуманные архитектурные принципы.
В последнее время магистральным направлением в сфере интеграции стал сервис-ориентированный подход, в соответствии с которым интегрируемые приложения представляются в виде взаимодействующих на уровне бизнес-логики сервисов. Сами сервисы с точки зрения интеграционного механизма представляют собой «черные ящики»: особенности реализации предоставляемых ими функций никак не влияют на процессы взаимодействия, которые задействуют только интерфейсы сервисов. Эта так называемая «слабосвязанность» сервисов обеспечивает гибкость и хорошую масштабируемость инфраструктуры интеграции: изменения приложений никак не влияют на интеграционную среду, и, наоборот, добавление новых приложений или изменение связей между системами не задействует коды интегрируемых решений. Взаимодействие основано на принципах общей шины, по которой идет обмен сообщениями между приложениями. Это позволяет устранить эффект «спагетти» — нагромождения межкомпонентных связей в результате интеграции приложений по принципу «каждое с каждым».
Рынок SOA (Service-Oriented Architecture) сегодня, безусловно, перегрет. Крупнейшие игроки в сфере программного обеспечения и целый ряд компаний, специализирующихся на средствах интеграции приложений, представляют свои комплексы поддержки сервис-ориентированного подхода. Слово «комплексы» здесь является ключевым: как правило, это достаточно сложные решения, включающие множество компонентов, требующие значительных усилий по внедрению и подчас связанные с необходимостью использования других программных систем данного вендора.
В этой связи интересен опыт компании CMA Small Systems AB, основной штат которой составляют российские специалисты. В конце 90-х в компании была разработана технология Processware Integration Environment (PIE), которая служит интеграционной платформой для реализуемых CMA решений по автоматизации бизнес-процессов в финансовых компаниях. Технология PIE создавалась в CMA как внутренний инструмент интеграции для банковских информационных систем, отличительными свойствами которых является наличие большого количества разнородных специализированных приложений для предоставления различных услуг клиентам, эволюционность развития, подразумевающая постепенное включение в среду автоматизации современных средств и одновременно поддержку давно существующих, хорошо зарекомендовавших себя систем, необходимость адекватно реагировать на часто возникающие ситуации слияний и поглощений и адаптироваться к изменениям внешней среды ведения бизнеса. В этих условиях проблема объединения всех используемых приложений в рамках единой бизнес-логики весьма актуальна.
Успешное использование технологии интеграции PIE во многих проектах в финансовом секторе в России и за рубежом и постепенное совершенствование этой системы привело ее создателей к выводу о возможности продвижения PIE как автономного продукта, готовой — «коробочной» — среды интеграции, применимой в любых областях современного бизнеса. В CMA убеждены, что простая в реализации, высокопроизодительная система PIE способна стать достойной альтернативой предложениям крупных игроков рынка, интеграционный инструментарий которых, как правило, сложно и дорого внедрять и поддерживать.
Концепция
Функции внешних интегрируемых приложений в PIE представлены в виде сервисов, детали реализации которых скрыты от других приложений и никак не влияют на процесс интеграции. Сервис определяется набором свойств, таких как имя, адрес, тип взаимодействия (синхронный/асинхронный) и др. Внешнему миру сервисы представляются посредством интерфейсов, которые являются «контрактами» между поставщиком и потребителем сервиса и определяют наборы операций, выполняемых сервисом. Эти операции, в свою очередь, задаются с помощью набора входных и выходных сообщений, которые описывают данные для обмена между сервисами.
Взаимодействие прикладных компонентов в PIE осуществляется посредством обмена сообщениями на языке XML, который становится стандартным форматом представления данных для современных приложений. Транспортную среду для передачи сообщений реализует корпоративная сервисная шина (Enterprise Service Bus, ESB). ESB в PIE — программная инфраструктура, включающая коммуникационный механизм обмена сообщениями и адаптеры для подключения внешних приложений. На уровне шины ESB реализуются гарантированная доставка сообщений, поддержка транзакционного механизма, средства электронной цифровой подписи и криптографической защиты, корреляция сообщений и т. д. PIE имеет и реестр сервисов — централизованный репозитарий с описанием всех свойств сервисов, которые используются в процессе интеграции.
Пожалуй, наиболее важной характеристикой PIE является сборка сервисов в реальные бизнес-процессы. Механизмы автоматизации бизнес-процессов на базе сервис-ориентированной архитектуры предлагаются многими поставщиками, представляя собой, как правило, отдельные непростые программные решения в комплексе интеграционных систем. В PIE сразу заложен механизм интеграции сервисов в соответствии с логикой бизнес-процесса, которая описывается в графическом виде с помощью диаграмм на языке UML. Благодаря такому подходу изменение бизнес-процесса очень быстро может быть отражено в среде интеграции — достаточно внести изменения в диаграмму описания бизнес-процесса.
Архитектура и технологии
Функциональным ядром системы PIE является сервер приложений (рис. 1), который реализует логику бизнес-процессов и выполняет все задачи интеграции. Внешние приложения взаимодействуют с сервером приложений с помощью адаптеров. Адаптеры берут на себя задачи представления фрагментов функциональности внешних приложений (таких, например, как «положить деньги на счет», «запросить кредит» и т.д.) в качестве сервисов и согласования протоколов и форматов данных между приложениями и средой PIE. Подсоединение внешних приложений к инфраструктуре интеграции исключительно посредством адаптеров позволяет максимально абстрагировать сервер приложений PIE от особенностей представления интерфейсов внешних приложений и согласования форматов передаваемых сообщений. Тем самым поддерживается взаимодействие между приложениями как слабосвязанными сервисами, представляющими внешнему миру только набор своих свойств, но не затрагивающими в процессе взаимодействия особенности реализации других сервисов.
Адаптеры в PIE могут быть составными, включающими внутренние и внешние адаптеры. Внутренние адаптеры, наряду с диспетчером, отвечающим за маршрутизацию сообщений, входят в состав корпоративной сервисной шины PIE и являются «поставщиками» и «потребителями» XML-сообщений, с помощью которых приложения общаются друг с другом и другими прикладными компонентами, реализующими бизнес-процесс. Внутренние адаптеры работают в адресном пространстве диспетчера, который осуществляет передачу сообщений между адаптерами и через них — между приложениями.
В общем случае для каждого приложения, подключаемого к PIE, необходимо разработать адаптер, реализующий прямое и обратное преобразование форматов данных и согласование протокола взаимодействия с данным приложением. Но существуют и готовые адаптеры, предназначенные для наиболее востребованных компонентов интеграции. Базовая версия PIE включает несколько внутренних адаптеров, в том числе файловый адаптер, адаптер к СУБД Oracle, FTP-адаптер, адаптер CORBA, адаптер коммуникационной библиотеки XOWAL. Связь диспетчера с внешними приложениями может быть более сложной, включая, помимо внутреннего адаптера, еще и внешний — независимое приложение, взаимодействующее с внутренним адаптером по одному из сетевых протоколов. PIE содержит специальное приложение XAdapter, которое предоставляет модули взаимодействия сервера приложений PIE со стандартными прикладными системами и инфраструктурными решениями, в том числе ODBC/OLE DB, MAPI/Microsoft Exchange, WebSphere MQ, Microsoft MQ, а также расширенный файловый адаптер. В качестве внешних адаптеров могут также использоваться адаптеры сторонних производителей, таких как Actional, iWay Software и др., и готовые адаптеры от самой CMA для ряда известных финансовых систем, сервера совместной работы IBM Lotus Notes/Domino и др. Внешние адаптеры могут работать на удаленных компьютерах.
Основным транспортным механизмом в PIE является диспетчер, который координирует информационный обмен между адаптерами внешних приложений и маршрутизатором. Стандартным для диспетчеризации в PIE является асинхронный тип коммуникаций, хотя возможна реализация и синхронного обмена сообщениями. Формат сообщения включает информацию об отправителе, получателе и тип сообщения. Если явно указан сервис-получатель, диспетчер передает сообщение соответствующему адаптеру. В противном случае необходима дополнительная обработка сообщения на уровне бизнес-логики, которая производится в маршрутизаторе.
Разработчики технологии PIE видят ее главное назначение в интеграции приложений на уровне бизнес-процессов. В сервере приложений PIE центральным компонентом, обеспечивающим выполнение бизнес-процесса, является маршрутизатор. Но сначала бизнес-процесс необходимо описать. В системе PIE для решения этой задачи предназначено приложение PieStudio — визуальная среда разработки и моделирования бизнес-логики, работая в которой архитектор интеграционного решения создает диаграммы деятельности UML, описывающие бизнес-процесс. Учитывая неизбежные ограничения такого рода «графического» программирования, в PIE для бизнес-процесса предусмотрено три уровня представления — уровень задач, уровень бизнес-фреймов и метафреймы (рис. 2).
Анализ выходных сообщений внешнего сервиса позволяет маршрутизатору определять логику выполнения бизнес-процесса. Если необходимо реализовать более сложные алгоритмы обработки данных, используются так называемые «программируемые задачи», которые предназначены не для взаимодействия с внешней системой, а для задания некоторых действий по обработке данных. В задачах этого типа на высокоуровневых языках C++ или JavaScript программируются необходимые манипуляции c XML-сообщениями, их анализ и преобразование. Каждая задача в PIE реализуется как компонент, который может многократно использоваться в ходе выполнения бизнес-процессов.
На следующем уровне представления бизнес-процесса задействуются диаграммы деятельности, созданные в PieStudio и описывающие бизнес-логику. Задачи соответствуют действиям в диаграмме деятельности. В репозитарии описание бизнес-процесса размещается в виде XML-файла, который носит название бизнес-фрейма. При поступлении сообщения, инициирующего выполнение данного бизнес-процесса, маршрутизатор PIE извлекает из репозитария соответствующий бизнес-фрейм и генерирует бизнес-токен — структуру данных, содержащую описание бизнес-процесса и все связанные с ним данные. Информация в бизнес-токене используется маршрутизатором для обработки данных и вызова внешних приложений и внутренних задач. Бизнес-токен включает в себя управляющий блок (для выполнения маршрутизации в соответствии с заданной UML-диаграммой) и локальные данные (XML-документы, которыми бизнес-токен обменивается с внешними приложениями, и результаты выполнения задач). С точки зрения диспетчера, осуществляющего коммуникации между сервисами, токен представляет собой сервис маршрутизации и является таким же потребителем и поставщиком сообщений, как и подсоединяемые посредством адаптеров внешние приложения.
Создатели PIE пришли к выводу, что представление бизнес-процесса в виде одного бизнес-фрейма приводит к неэффективности исполнения. Бизнес-процессы в реальной организации, как правило, очень сложны, и потому разумнее представить их как композицию нескольких менее масштабных подпроцессов. В PIE такая сборка бизнес-процесса из бизнес-фреймов носит название метафрейма. На уровне метафрейма задается последовательность взаимодействия бизнес-фреймов, а также определяется, как бизнес-процесс будет выполняться в конкретной вычислительной среде, и осуществляется управление ресурсами этой среды. В частности, в зависимости от возможностей серверной конфигурации в настройках сервера приложений задается максимальное количество параллельных потоков выполнения бизнес-фреймов. Многопоточность обеспечивает параллельное выполнение задач из разных бизнес-токенов. Если разрешенное количество потоков исчерпано, PIE управляет процессом выполнения токенов в режиме разделения времени. Таким образом, на уровне сервера приложений осуществляется управление загрузкой сервера, где инсталлирована среда интеграции, и поддерживается оптимальная производительность распределенной системы.
Сервер приложений PIE имеет компонентную архитектуру, опирающуюся на модель Cross Platform Component Object Model, которая используется в инфраструктуре создания кросс-платформенных приложений Mozilla. Большинство программных модулей сервера приложений PIE выполнено в виде XPCOM-компонентов, реализующих необходимые функции. Компоненты расширения функциональности позволяют подключать к серверу приложений PIE модули, реализующие дополнительные возможности, скажем, работу с параметрами окружения бизнес-процессов (таких, например, как количество активных пользователей, индикатор открытия/закрытия операционного дня, способность выдать ссуду и т.д.) репозитарий системы PIE, в котором реализован реестр сервисов, размещаются бизнес-фреймы, описание задач, параметры окружения и другая информация, необходимая для выполнения бизнес-процессов, представляет собой XML-структуру. Опциональным компонентом PIE является операционное хранилище данных, которое применяется для решения задач обеспечения транзакционной целостности исполнения бизнес-процессов.
Ответы и вопросы
Решение PIE изначально разрабатывалось как интеграционная среда для приложений в финансовой сфере, где многие системы, например системы поддержки банковских и биржевых операций, работают в режиме реального времени и потому требуют очень высокой производительности. Это обусловило ряд конструктивных особенностей PIE, позволяющих обеспечить максимальную простоту и производительность интеграции, среди которых — хранение бизнес-процесса в виде единого XML-файла, выполнение всех действий с бизнес-процессами только в оперативной памяти, без использования каких-либо СУБД, применение языка C++, а не Java, для программирования задач, поддержка на уровне сервера приложений многопоточности и кластеризации и возможность настройки среды интеграции в соответствии с конфигурацией реальной компьютерной среды, на которой она установлена.
PIE можно охарактеризовать как достаточно гибкое решение: использование адаптеров и концепции сервисной шины для подключения внешних приложений упрощает процесс интеграции, а графическое описание бизнес-процессов позволяет создавать и менять бизнес-логику специалистам, не владеющим навыками программирования на профессиональном уровне. Тем не менее создатели PIE позиционируют свою систему не только как инфраструктуру интеграции, но и как среду быстрой разработки интеграционных приложений, предоставляющую графические средства разработки бизнес-логики и компонентную сборку. Как считают в CMA, возможности PIE не ограничиваются простым обменом информацией между приложениями — эта система, фактически, поддерживает создание нового программного обеспечения, реализующего бизнес-логику интеграции.
Простота подходов, минимальные требования к уровню специалистов по внедрению, значительный положительный опыт использования в определенной сфере, демонстрирующий высокую производительность решения в сочетании с разумным расходованием средств и времени на его инсталляцию, комбинация в одном продукте современного подхода к интеграции приложений с возможностью автоматизации на его базе реальных бизнес-процессов (идеал для большинства реализаций SOA), вполне вероятно, сделают PIE действительно привлекательным вариантом для многих предприятий. Интересно, что CMA не одинока в своем стремлении упростить интеграцию. Многие аналитики рынка живо отреагировали на анонс в середине марта новой версии системы CapeClear разработки одноименной компании. Создатели CapeClear 7 противопоставляют сложным, громоздким стекам SOA-решений относительно простой продукт, реализующий высокопроизводительную шину ESB и инструментарий разработки. По мнению представителей ряда авторитетных аналитических компаний, такой подход имеет право на жизнь и найдет отклик у пользователей, поскольку сейчас возникает реальная угроза превращения интеграционных систем в один из самых сложных компонентов информационной инфраструктуры.
Но вопросы остаются. Предложенное CMA простое решение трудной задачи, сражаясь с которой все игроки рынка SOA предлагают не коробочные продукты, а многофункциональные комплексы, не может не быть связано с определенными жертвами и компромиссами. Вопрос в том, насколько они окажутся критичными. Отказ от механизма баз данных и выполнение всех действий с бизнес-процессами в оперативной памяти упрощает структуру решения и поднимает скорость интеграции, но требует применения специальных мер для обеспечения высокой надежности системы. Минимизация компонентов интеграционной платформы, объединение в одном решении транспортного уровня и поддержки «оркестровки» бизнес-процессов привлекательно с точки зрения стоимости и сроков внедрения; но не останутся ли при этом за бортом важные дополнительные возможности?
Удастся ли добиться широкого успеха, двигаясь своим путем, а не в фарватере современных стандартов сервис-ориентированной архитектуры и управления бизнес-процессами? Большинство известных реализаций SOA сегодня опираются на технологии Web-сервисов и платформу Java и все активнее включают поддержку языка «оркестровки» бизнес-процессов BPEL. На эти стандарты ориентируются и производители средств мониторинга и управления сервис-ориентированными средами. Оригинальность же и независимость подхода обычно таит в себе риск ограничить возможности расширения базовой платформы решениями сторонних фирм с помощью типовых инструментов и процедур. Со своей стороны, в CMA настаивают, что для наращивания функциональности вполне достаточно принятого в системе механизма адаптеров, набор которых недавно пополнился и SOAP-адаптером для поддержки Web-сервисов.
По всей видимости, исчерпывающие ответы на эти вопросы может дать только более широкий опыт использования платформы PIE и открытое обсуждение этого опыта в профессиональном сообществе, чему должны способствовать последние шаги CMA по продвижению своего продукта.
Не только для банков
Помимо успешных реализаций систем автоматизации банковского бизнеса на базе PIE, в активе компании CMA есть примеры внедрения этого интеграционного решения и в других отраслях, например телекоммуникационной. Семь лет назад был начат проект интеграции на базе PIE корпоративных приложений крупнейшего российского оператора мобильной связи «ВымпелКом». PIE обеспечил бесперебойное взаимодействие новой биллинговой системы, систем ERP, CRM, хранилища данных и других программных решений, эксплуатируемых в компании. Основным результатом реализованного проекта явилось повышение уровня надежности и контролируемости информационной и функциональной интеграции приложений, автоматизирующих бизнес-процессы компании.
В настоящее время с помощью PIE в компании «ВымпелКом» интегрируется более 50 внутренних и внешних приложений, в том числе системы дочерних компаний «ВымпелКома» в ряде стран СНГ.
