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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применение средств управления рабочими процессами - идеальный

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

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

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

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

Заключение

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

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

Об авторе

Кевин Фрэнсиз (Kevin Francis) — ИТ-специалист с 19-летним стажем. За это время успел поработать на таких должностях, как руководитель ИТ-отдела в одной из промышленных компаний, консультант по безопасности и архитектор. Владелец собственной компании, успешно разрабатывающей программные продукты. Как архитектор и менеджер участвовал в передовых проектах, относящихся к электронной коммерции (еще в те времена, когда эта отрасль только-только зарождалась). В качестве ведущего архитектора внес большой вклад в успехи Infosys. Часто консультирует крупные организации, сотрудничает с архитекторами, группами разработчиков Infosys и ее заказчиками, является членом The Infosys Australia Technology Council. В июле 2005 года был отмечен Microsoft наградой Most Valuable Professional (MVP) за свои познания и опыт в области Visual Developer — Solutions Architect.

ОригиналСтатьи: The Archtecture Journal