Интеграция приложений: методы взаимодействия, топология, инструменты

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

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

Следствиями отсутствие должного решения проблемы интеграции являются:

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

Это определяет цели интеграции приложений предприятия.

Цели интеграции

Общие цели интеграции приложений можно сформулировать следующим образом:

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

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

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

Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Автор, выступая в качестве исполнителя работ, сталкивался с разными вариантами «спонсорства» таких проектов. Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Однако для интеграционных проектов такая заинтересованность жизненно необходима. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т.д. Согласование и формализация требований разных подразделений становится очень трудной задачей; отсутствие среди «идеологических лидеров» проекта человека, которому подотчетны все задействованные подразделения, обычно означает провал проекта. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния.

Не надо забывать, что основная цель интеграционных проектов — снижение издержек, равно как и предпосылки к проектам лежат в бизнес-области даже если проект относится сугубо к ИТ. К примеру, задача развертывания систем управления и мониторинга возникает, если бизнес озабочен снижением затрат на эксплуатацию ИТ-инфраструктуры. Мало того, интеграционные проекты в какой-то степени являются перекладыванием проблем с бизнес-подразделений на ИТ-службу. Рассмотрим, к примеру, типичную ситуацию, когда формированием отчетов «в стиле Excel» для руководства занимается группа в составе финансового департамента. От ИТ-подразделения при этом требуется лишь поддержание в работоспособном состоянии корпоративных информационных систем. В случае же внедрения системы, автоматически формирующей эту отчетность, за все — в том числе и за ошибки в данных — будет отвечать ИТ-служба. Действительно, по мере увеличения степени интегрированности и взаимосвязанности информационных систем возрастает ответственность, роль и статус ИТ-службы, увеличивается зависимость основных показателей работы всей организации от надежности и эффективности интегрированной информационной системы предприятия.

Взаимодействие интегрированных приложений

Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный обмен сообщениями. В этом списке нет прямого обмена данными между базами данных приложений: этот метод ближе не к интеграции приложений, а к перемещению данных. С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку (например, при загрузке накладных пересчитывать товарные остатки). Прямой обмен данными, который обычно выполняется средствами класса ETL (extract, transfer, load) или самодельными утилитами, обычно такой возможности не предоставляет.

Обмен файлами

Обмен файлами пожалуй, самый распространенный подход к организации взаимодействия. Это связано с относительной простотой реализации, а также существованием стандартных (или «почти» стандартных) форматов обмена. Например, большая часть корпоративных информационных систем позволяет загружать и выгружать файлы, например, в формате CSV (Comma-Separated Values — «поля, разделенные запятыми»). Но у этого подхода есть и недостатки; если необходимо оперировать сложными структурами, то простые форматы обмена уже не пригодны. Возникающие в таких случаях специализированные форматы файлов должны «понимать» взаимодействующие системы, что ведет к жесткой зависимости систем друг от друга. Этот недостаток обычно преодолевают всевозможными утилитами конвертации данных. Кроме того, обычно обмен файлами подразумевает участие человека — кто-то должен выгрузить файл, скопировать его на другой компьютер, загрузить. Однако если интегрируемые методом обмена файлами системы имеют возможность автоматической загрузки/выгрузки (например, по расписанию), то данный подход позволяет построить полностью автоматизированное решение, которое вследствие своей простоты обладает высокой надежностью и пропускной способностью.

Общая база данных

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

Удаленный вызов

Стандарты на удаленный вызов процедур возникли два десятка лет назад, позволяя программному коду, который выполняется на одном компьютере, вызывать код на другом. Стандарты появлялись, развивались и угасали: RPC, CORBA, DCOM, RMI… последним в этом ряду стал протокол SOAP, основа современных Web-сервисов. Собственно в подходе к интеграции с использованием удаленных вызовов за эти годы ничего принципиально не изменилось — если приложению А что-то нужно от приложения Б, то А одним из перечисленных способов вызывает функцию приложения Б.

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

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

Асинхронный обмен сообщениями

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

Недостаток данного подхода — высокая цена. Система гарантированной доставки на основе очередей сообщений обычно сама по себе недешева; единственным известным мне исключением является Microsoft Message Queue (MSMQ), компонент серверных операционных систем семейства Windows. Правда, есть и свободно распространяемые бесплатные (например, ActiveMQ), которые, тем не менее, нужно развернуть, обучить специалистов, поддерживать, написать адаптеры между системой доставки и приложениями и т.д.

Топология

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

Точка-точка

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

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

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

Хаб + спицы

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

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

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

Недостатком топологии «хаб + спицы» является высокая стоимость приобретения и сложность программного инструментария, играющего роль хаба, а также нехватка специалистов, имеющих опыт применения подобных программных средств.

Выбор средств интеграции

Готовых инструментов интеграции на рынке немало. Так, только корпорация IBM в разделе программного обеспечения интеграции приложений предлагает пару десятков групп продуктов и еще много интеграционных продуктов в других категориях. Сложность выбора состоит в том, что среди представленных средств есть и узко ориентированные (например, IBM Message Broker), и позиционируемые как «универсальные» (скажем, Microsoft BizTalk). Однако выбор того или иного инструментария определяется не тем, что о нем говорит производитель, а конкретным составом «зоопарка» аппаратно-программных решений в организации, которые необходимо заставить работать совместно.

Советы общего плана

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

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

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

Совет конкретный

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

Отдельно про Web-сервисы

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

Непригодность к обработке больших объемов — врожденный недостаток, который связан с XML-природой Web-сервисов. Все данные и параметры вызовов Web-сервисов преобразуются в формат XML, что во много раз увеличивает объем данных со всеми вытекающими из этого последствиями в виде растущей потребности в оперативной памяти и нагрузки на процессоры. К сожалению, речь идет не о гигабайтах передаваемой информации: Web-сервисы «захлебываются», когда за одно взаимодействие между интегрированными системами нужно передавать уже сотню килобайт. (Правда, существует стандарт WS-Attachments, описывающий механизм подсоединения к вызовам Web-сервисов любых данных без перекодирования в XML, однако ведущие поставщики этот стандарт не поддерживают.)

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

Предварительный стандарт WS-Transactions, призванный решить данную проблему, существует, но отсутствуют его полноценные реализации. Так, корпорация IBM заявила о поддержке этого стандарта в своих интеграционных продуктах, основанных на WebSphere Application Server, но с массой ограничений; самое главное из которых — все взаимодействующие Web-сервисы должны работать под управлением WebSphere Application Server. Аналогичная ситуация и у Microsoft в .Net 3.0, что выхолащивает смысл Web-сервисов — простоту межплатформного взаимодействия.

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

Немного о ESB и SOA

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

Подобный инструментарий промежуточного слоя стоил слишком дорого, а специалисты по нему — еще дороже. Когда появился новый метод межплатформного взаимодействия, Web-сервисы, родился и новый подход к организации основы для интеграции — сервисная шина предприятия (Enterprise Service Bus, ESB). Реальным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP. Основанный на ESB подход подавался как более дешевая, простая в реализации альтернатива предыдущей концепции.

Что же получилось в действительности? Появились новые продукты, поддерживающие SOAP, в старые продукты такая поддержка была добавлена, однако они не стали дешевле, а значит, доступнее своих предшественников. Означает ли это конец еще одной красивой сказки? Вовсе нет. Если отбросить пропаганду, то поддержка «хабом» интеграционной системы широкого спектра методов взаимодействия и протоколов облегчает и удешевляет интеграцию. Но не в разы, а на проценты — что уже неплохо с учетом стоимости интеграционных проектов.

Вокруг архитектуры, ориентированной на сервисы (Service-Oriented Architecture, SOA), также очень много маркетинговой шумихи. На мой взгляд, SOA — это не конкретные продукты и даже не технология, а лишь концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. Это означает, что для пользователей ничего не изменится, пока ведущие поставщики программного обеспечения (и прежде всего, производители бизнес-приложений наподобие ERP, CRM, EAM и т.д.) не модифицируют свои системы в соответствии с SOA. Только тогда можно получить реальный выигрыш; пока же популярные бизнес-приложения — это замкнутые системы с очень «узким» внешним интерфейсом.

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

Алексей Добровольский (ADobrovolsky@croc.ru) — директор по разработке программного обеспечения компании КРОК (Москва).