Технологии рабочих процессов в интеграции приложений

Кевин Фрэнсиз

Журнал The Architecture Journal, №1 (4) март 2006 года

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

Рассматриваются требования, которые нужно выполнить для успешной интеграции, и представлен архитектурный подход, отвечающий этим требованиям. Такой подход основан, в частности, на применении технологий рабочих процессов (workflow technologies).

Интеграция приложений становится все более распространенной задачей, и растущий выбор инструментария и стандартов (вроде стандартов WS-I для Web-сервисов), а также появление архитектуры, ориентированной на сервисы (service-oriented architecture, SOA), казалось бы, обещают упростить решение этой задачи. Во многих статьях рекламируется простота связывания приложений на основе Web-сервисов или даже SOA. В наши дни чаще всего применяются два подхода: интеграция по типу «точка-точка» (point-to-point integration) и интеграция по шине сервисов (services bus integration) (рис.1).

При интеграции по типу «точка-точка» между приложениями создаются прямые связи за счет использования каких-либо API, протокола FTP (file transfer protocol) или командных интерфейсов (batch interfaces). Трансформация (трансляция) данных может происходить в процессе их передачи по связи. Как правило, интерфейсы «точка-точка» реализуются без использования интегрирующих продуктов, причем трансляция данных осуществляется с помощью программного кода в точке интеграции на одном или обоих концах интерфейса.

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

Поскольку организации стремятся вывести в Интернет все больший спектр сервисов, нацелены на интеграцию продуктовых линеек и хотят упростить эксплуатацию центров обработки вызовов, интеграционное решение требует установки большего количества внутренних систем. Например, далеко не редкость, когда в центре обработки вызовов операторы, обслуживая клиентов, вынуждены переключаться между десятками приложений. Стремление избавиться от таких ситуаций, при которых пользователь фактически играет роль интегратора приложений, копируя информацию из одной программы и вставляя ее в другую (а то и заново набирая какие-то данные) для выполнения одной транзакции, как раз и является наиболее распространенным стимулом для интеграции приложений.

Основа архитектуры предприятия

Существует ряд методов, пригодных для интеграции приложений, которые составляют основу Web-сайта или центра обработки вызовов, и наиболее распространенное решение — начать с создания интерфейсов «точка-точка» или шины сервисов.

Рис. 1 Интеграция по типу «точка-точка» и по шине сервисов.

Но что будет, когда центру обработки данных и Web-приложению понадобится доступ к одной и той же информации? В идеале они должны использовать одни и те же интерфейсы, верно? Увы, в большинстве случаев группы разработчиков (и архитекторы) разобщены, и такой подход встречается не часто; при этом следует учесть трудности использования существующего интерфейса из собственного весьма сложного кода и обеспечения работы этого интерфейса со сторонним кодом. Эта проблема экспоненциально усложняется с ростом числа интерфейсов, необходимых для взаимодействия с разными системами, и по мере укрупнения организации (большим предприятиям приходится труднее, чем малым).

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

Табл. 1. Требования к уровню интеграции

Уровень	Требования	Описание
Данные	Возможность соединений	Базовая поддержка соединений, позволяющая приложениям взаимодействовать друг с другом
	Трансформация	Трансляция формата данных, передаваемых между приложениями
Информация	Агрегация данных	Агрегированное представление данных от нескольких систем
	Бизнес-правила	Разработка бизнес-правил, действующих между несколькими системами
	Управление транзакциями	Поддержка ACID-транзакций между несколькими системами
	Информационная модель	Согласованная между всеми системами модель данных, где достигнуто общее понимание сущностей данных и их структур
	Управление справочными данными	Централизованное управление часто используемыми справочными данными (reference data) от нескольких систем
	Управление сеансом	Управление сеансовой информацией в процессе взаимодействия; охватывает все системы
	Средства мониторинга и протоколирования	Общая точка протоколирования информации в процессе эксплуатации
	Обработка ошибок	Согласованный подход к обработке ошибок по единому набору правил
	Управление конфигурациями	Возможность конфигурирования всей системы в процессе работы, настройки ее взаимодействия с другими системами, образующими производственную среду, и развертывания новых версий различных компонентов
	Рабочие процессы	Рабочие процессы, в которых участвует несколько систем
Процессы	Комплексные бизнес-правила	Общие, неоднократно применяемые бизнес-правила, действующие между несколькими системами
	Моделирование бизнес-процессов	Моделирование бизнес-процессов, включающих несколько систем, для оптимизации и интеграции
	Мониторинг бизнес-операций	Наблюдение за эффективностью бизнес-процессов для оптимизации и отслеживания проблем

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

• данных — самый базовый уровень; интеграция данных достигается практически в любых сценариях. На этом уровне данные передаются между приложениями и соответственно преобразовываются;
• информационному — на втором уровне данные и вызовы приложений агрегируются, что позволяет единообразно обращаться к нескольким приложениям; при этом действуют базовые бизнес-правила, которые «наводят мосты» между приложениями. Применение этих методик обеспечивает агрегацию сервисов и отвечает минимальным требованиям, необходимым для реализации SOA;
• процессов — третий уровень базируется на уровне интеграции данных, объединяя процессы и данные, которые участвуют в бизнес-процессе, охватывающем несколько приложений.
  

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

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

Почему это имеет такое значение? Когда вы создаете первый интерфейс между двумя приложениями, зачастую достаточно простой интеграции данных. Но по мере добавления интерфейсов выбор архитектуры становится все важнее. Если вы не сумеете правильно выбрать архитектуру интеграции, то столкнетесь с экспоненциальным ростом затрат на создание очередного интерфейса. И наоборот, успешный выбор позволит по мере расширения функциональности, предоставляемой уровнями интеграции, уменьшить объем кода, необходимого на каждом уровне.

Рис.2 Три уровня интеграции

Компоненты уровня интеграции

Компоненты уровня интеграции можно разбить на три уровня — данных, информационный и процессов (см. табл. 1). Более того, их можно разделить на компоненты, образующие техническую инфраструктуру (показаны на рис. 2 темными прямоугольниками), и на компоненты, из которых состоит бизнес-инфраструктура (показаны на рис. 2 светлыми прямоугольниками). Давайте подробнее рассмотрим эти компоненты.

Уровень данных

Два компонента базового уровня данных — это средства поддержки соединений и трансформации; они образуют основу технической инфраструктуры (табл. 2). Здесь часто используются отдельные интерфейсы «точка-точка» с приме- нением Web-сервисов, но многие принципы SOA требуют предоставления сервисов, скрывающих вызовы между системами. Однако, как уже упоминалось, Web-сервисы, существующие на уровне данных, не удовлетворяют этим принципам. В таком контексте Web-сервисы обеспечивают возможности соединений, но для интеграции сервисов нужно проанализировать информационный уровень.

Информационный уровень

Состоит из компонентов, опирающихся на техническую инфраструктуру (табл. 3). Бизнес-инфраструктура строится на основе информационной модели (табл. 4).

Уровень процессов

Здесь фокус смещается с технических требований на ценность для бизнеса; функциональность этого уровня должна давать реальный выигрыш от интеграции — возможность быстрой перенастройки бизнес-процессов (табл. 5).

Уровень интеграции можно реализовать разными способами: полностью самостоятельной разработкой, использованием готовых инфраструктур, наборов инструментов, программного обеспечения с открытым исходным кодом или компонентов, предоставляемых операционной системой, а также применением специального интегрирующего пакета. Самостоятельная разработка — не лучший путь, так как необходимые наборы инструментов и инфраструктуры уже имеются на рынке.

Некоторые инфраструктуры позволяют быстро интегрировать системы на уровне пользовательского интерфейса (UI), например Customer Care Framework от Microsoft. Этот тип решений очень удобен для моментальной интеграции внутренних систем и построения консолидированного UI, но важно понимать плюсы и минусы такого решения. Подобные инфраструктуры (для интеграции систем на уровне UI) дают возможность быстро решать определенные задачи, стоящие перед бизнесом, скажем, ускорять обслуживание клиентов операторами центра обработки вызовов. Однако уровень интеграции дает гораздо больше преимуществ, хотя и требует больше затрат на первоначальное внедрение.

Расширение интеграционного сценария

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

Например, если системы биллинга, обработки жалоб клиентов (troubleticketing), управления клиентами и ERP интегрированы пользовательским интерфейсом CRM, то, поскольку эти системы уже связаны, вы можете создавать простые решения для самопомощи через Интернет (Web self-help solutions), а в дальнейшем расширять их до систем заказов через Интернет и решений для канальной дистрибуции между предприятиями (B2B channel). Если вы приобретете какое-то новое приложение вроде системы управления сетью поставщиков, интеграция этого приложения в такую среду все равно окажется нетривиальным процессом. Однако эта задача заметно упростится при наличии уровня интеграции, так как интегрировать данные будет легче за счет того, что единый набор известных интерфейсов включается в уровень интеграции, а не в каждое приложение.

Табл. 2. Технические требования к уровню данных

Требования	Описание
Возможность соединений	Это возможность передачи информации с применением самых разных протоколов и методов, в том числе интерфейса Web-сервисов. Сюда также следует отнести специфические протоколы, необходимые в конкретных сценариях (в каждой организации может быть своя специфика). Например, во многих организациях, где в качестве основных бизнес-систем по-прежнему используются мэйнфреймы, нужны IBM WebSphere MQ и/или SNA-подключения с применением Microsoft Host Integration Server (HIS). В других системах могут понадобиться интерфейсы COM+ или даже HTTP, низкоуровневые сокеты (raw sockets) или FTP. Все протоколы должны выполняться через общий интерфейс с возможностью подключения специфических реализаций для конкретных сценариев. Все специфические технические требования конкретных протоколов или методов должны удовлетворяться подключаемой реализацией, и во внешних системах не должно быть логики обработки специфических случаев
Трансформация	Это преобразование данных из одной структуры в другую на основе правил. Ядро трансформации должно быть размещено на уровне данных

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

Табл. 3. Технические требованию к информационному уровню

Требования	Описание
Агрегация данных	Сервисы, служащие оболочкой вызовов от разных систем, обеспечивают агрегацию данных. Очень важно рассматривать агрегацию данных как отдельное требование и уделять большее внимание организации данных и бизнес-правилам, которые позволят именно агрегировать данные, а не просто накапливать их
Бизнес-правила	Будьте очень внимательны при разработке бизнес-правил в интеграционном сценарии: правила, составляющие часть каждого приложения, должны находиться в этом приложении, а правила, относящиеся к интеграции приложений, должны быть инкапсулированы на информационном уровне. Такой подход обеспечивает эффективное повторное использование правил, упрощает сопровождение приложений и позволяет создать единую, централизованную точку разработки и применения правил
Управление транзакциями	Это обязательное и в то же время сложное в реализации требование, выдвигаемое при интеграции приложений. Обязательно оно потому, что существует потребность в фиксации или откате транзакции между любыми приложениями, включенными в эту транзакцию. А сложно в реализации из-за того, что откат транзакции для множества систем может потребовать создания обратимых записей (reversing entries) или применения какого-то другого программного способа. Это, кстати, идеальный пример, наглядно демонстрирующий потребность в централизации сложной логики
Управление справочными данными	Справочные данные обычно применяются при выводе через UI списков, где пользователь что-то выбирает, или при проверке данных на допустимость. Как правило, справочные данные являются общими для всех приложений (например, списки стран, почтовых индексов, продуктов, адресов офисов и т. д.). Доступ к справочным данным из общей точки на этом уровне повышает производительность, дает согласованные результаты и упрощает разработку
Управление сеансом	Гарантирует, что во всех системах, охваченных интеграционным сценарием, известно, кто обращается к данным, и что текущие операции синхронизированы между системами. Полноценное управление сеансом позволяет получать представление о сеансе из одной точки доступа, например при обращении клиента к порталу в Интернете, и повторно использовать его в другой точке, скажем, чтобы консультант мог корректировать заказ от клиента
Средства мониторинга и протоколирования	По аналогии с управлением справочными данными централизация средств мониторинга и протоколирования на этом уровне вполне логична, так как позволяет сосредоточить весь код, отвечающий за мониторинг и протоколирование, в одном месте Обработка ошибок Обработка ошибок на этом уровне позволяет централизовать код, отвечающий за обработку ошибок, и единообразно реагировать на ошибки
Управление конфигурациями	Управление конфигурациями в такой среде, как рассматриваемой нами, — дело сложное и заслуживает отдельного обсуждения. Однако оно должно обеспечить создание единой точки, откуда можно было бы изменять адреса систем, контролировать доступ к системам и где можно было бы хранить параметры конфигурации, при необходимости загружаемые общим диспетчером конфигурации

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

• работа с несколькими системами естественным образом строится на основе процессов, при этом задачи выполняются поэтапно, и на каждом этапе поддерживаются точки принятия решений, ветвление по условию и другие базовые возможности рабочих процессов;
• рабочие процессы, связанные с интеграцией систем, выполняются централизованно и размещаются между приложениями, поэтому на них чаще влияют изменения в интеграционной среде (при условии, что каждое изменение в каждой системе отражается на уровне интеграции). Средства управления рабочими процессами делают их понятными более широкому кругу людей (а не только разработчикам), так как рабочие процессы представляются в графическом виде. Эти процессы легче и быстрее модифицировать, их отладка проще по сравнению с отладкой кода;
• схематическое представление, формируемое средствами управления рабочими процессами, облегчает понимание бизнес-процессов, и их модификацию можно разрешить не только группе разработчиков, но даже бизнес-аналитикам и основным бизнес-пользователям.
  

Табл. 4. Бизнес-требования к информационному уровню

Требования

Описание

Информационная модель

Чем больше приложений интегрируется, тем больше объемы доступных данных. Это позволяет приступить к созданию информационной модели, охватывающей все вовлеченные системы. При должной реализации информационная модель, размещаемая на уровне интеграции, способна предоставить единую точку получения ключевых сущностей данных. Например, она позволяет тут же выяснить адреса всех систем, используемые продукты, историю заказов и технической поддержки по конкретным заказчикам. Два распространенных способа создания единой точки получения информации — использование одной ключевой системы и ее синхронизация с остальными системами или применение базы данных, обновляемой согласованно с изменениями в нескольких системах. Общая информационная модель на уровне интеграции особенно эффективна и полезна благодаря тому, что она объединяет данные из множества источников, не оказывая влияния ни на данные, ни на код в этих источниках

Табл. 5. Бизнес-требования к уровню процессов

Требования	Описание
Рабочие процессы	Системы рабочих процессов (workflow systems) можно реализовать как управляемые пользователем или системой. В обоих случаях их можно задействовать на уровне интеграции; однако важно различать эти случаи. Рабочий процесс, управляемый системой (system-driven workflow), требует выполнения ряда операций, связанных с взаимодействием с различными системами в интеграционной среде
Комплексные бизнес-правила	Эти бизнес-правила придают дополнительную ценность уровню интеграции, так как они позволяют предоставлять новую или расширенную функциональность, выходящую за рамки одной лишь интеграции систем
Моделирование бизнес-процессов	Системы рабочих процессов можно использовать и для автоматизации существующих процессов, пока выполняемых с участием людей. Уровень интеграции — идеальное место для среды, моделирующей бизнес-процессы. Применение средств управления рабочими процессами позволяет документировать существующие процессы и представлять их в графической форме. Эти же средства упрощают доступ к нескольким приложениям, особенно при реализации информационной модели, поддержке транзакций и т. д. Моделирование бизнес-процессов открывает простор для таких усовершенствований, которые в ином случае были бы просто невозможны
Business Activity Monitoring (BAM)	Business Activity Monitoring (BAM) — это комплексная система отслеживания транзакций, позволяющая выявлять узкие места, ухудшение производительности, проблемы с конкретными транзакциями и др. Возможности BAM очень велики, но зависят от средств, предоставляемых информационным уровнем

Заключение

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

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

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