Рассматриваются требования, которые нужно выполнить для успешной интеграции, и представлен архитектурный подход, отвечающий этим требованиям. Такой подход основан, в частности, на применении технологий рабочих процессов (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 Интеграция по типу «точка-точка» и по шине сервисов.

<!--[if !vml]--><!--[endif]-->

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

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

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

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

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

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

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

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

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

<!--[if !vml]-->

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

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

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

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

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

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

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

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

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

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