Интеграция: новое решение старых проблем

ОБЗОРЫ

Современные методы и средства EAI открывают новые перспективы для бизнеса

Влад Боркус, Елена Монахова

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

Вспомним эволюцию подходов к автоматизации бизнеса. Как бы ни менялись эти подходы за пятьдесят лет развития вычислительной техники, одно оставалось постоянным - всегда в первую очередь компьютеризировалась работа на отдельных наиболее критичных участках предприятия. Несмотря на усилия многих разработчиков создать решение по типу "все в одном", достичь этой цели не удалось никому - даже сложные интегрированные пакеты наподобие систем ERP нынче покрывают потребности типового предприятия максимум на 50-60%.

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

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

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

Эволюция интеграционных подходов

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

Основные этапы обмена сообщениями в системе IBM WebSphere InterChange Server. Получение (1),

преобразование в обобщенный вид (2,3), пересылка обработчику (4), получение ответа от

обработчика (5), преобразование ответа в формат приложения (6,7), отсылка приложению (8)

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

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

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

· API систем были очень сложными (если были вообще), приходилось обрабатывать множество исключительных ситуаций, а в код встраивать логику восстановления после сбоев.

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

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

Системы обмена сообщениями и адаптеры

В 90-х годах появилось много продуктов, ориентированных на помощь в решении этих проблем. Революцию в подходах к интеграции обеспечило межплатформное ПО, ориентированное на обмен сообщениями (так называемое Message Oriented Middleware, MOM).

Одним из пионеров в этом классе было семейство продуктов MQSeries корпорации IBM (впоследствии неоднократно переименованное, сейчас продукт называется WebSphere MQ).

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

Пример устройства коннектора для IBM WebSphere Interchange Server

Первоначально работа с очередями сообщений требовала модификации имеющихся программ, например использования интерфейса MQI в MQSeries. В случае унаследованных приложений это зачастую оказывалось невозможным. Для решения проблемы начали применять коннекторы (иначе называемые адаптерами или мостами), которые отвечали за то, чтобы открыть функциональность приложения для межплатформного ПО. Написание подобных коннекторов - крайне сложная задача, решаемая, как правило, совместно производителями прикладной программы и межплатформного ПО. Коннекторы следят за изменением состояния базы данных приложения (через API приложения или триггерные механизмы СУБД) и при заданных извне условиях выдают сообщения на шину.

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

Описание бизнес-процесса и его привязка к COM-объектам и очередям сообщений в Microsoft BizTalk 2002

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

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

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

Интеграция на основе пользовательского интерфейса

Основная идея этого подхода состоит в предоставлении пользователю унифицированного интерфейса для доступа к различным приложениям. Как правило, в роли подобного интерфейса выступает портал, обеспечивающий функции однократной регистрации в интегрированных системах, и "нулевой клиент". Портальное ПО может производить также адаптацию контента для устройств разного формата, его перевод на разные языки и персонализацию для каждого пользователя. Типичными примерами являются Plumtree Portal, IBM WebSphere Portal и Microsoft SharePoint Portal. Стоит заметить, что современный портал - это некое обобщение рабочего экрана обычного ПК. Аналогичные по духу решения можно было встретить и в прошлом - например, в эпоху "зеленых" терминалов консолидацию контента из разных источников на одном экране выполняли при помощи ПО типа CICS.

Современный "классический" корпоративный портал предлагает собственное хранилище информации, встроенную систему управления контентом и редакционным процессом, подсистемы поиска информации, онлайнового общения пользователей (чаты, форумы, виртуальные рабочие комнаты и т. п.). Частью решения могут являться "федерированные" базы данных, т. е. такие, в рамках которых в портал интегрируется контент из самых разных источников - баз документов Lotus Domino, Documentum, реляционных хранилищ, внешних Web-сайтов, других порталов.

Приложения подключаются к порталу через механизм портлетов (маленьких окошек на Web-странице, в каждом из них выводится свое приложение; некоторые производители называют портлеты гаджетами или Web-фрагментами). К порталу легко подключать приложения, имеющие Web-интерфейс, и здесь смыкаются даже такие недруги, как Microsoft и Sun, в частности в страницы портала Sun-ONE Portal легко подключаются папки почтовой системы Microsoft Exchange.

Построение карт преобразований сообщений в Microsoft BizTalk Editor

Однако в унаследованных приложениях, как правило, нет браузерного интерфейса, для их подключения в портал приходится добавлять интеграционные компоненты. В каждом таком случае речь фактически идет о написании двух слоев логики: нового Web-интерфейса старого приложения и слоя обмена данными с этим приложением. Так, Plumtree Portal имеет специальный компонент Plumtree Gadget Server, решающий задачу создания Web-интерфейсов приложений. Для него написаны адаптеры к десяткам разных систем. IBM Portal Server также позволяет подключать компоненты iView, обеспечивающие Web-доступ к таким популярным системам, как SAP R/3 и Oracle Applications. Аналогичным образом обстоят дела и с Microsoft SharePoint Portal.

Но у большинства других производителей портал отвечает только за презентацию данных и опирается на функции интеграции, обеспечиваемые серверами приложений или шинами MOM. Таковы, например, Sun-ONE Portal Server, BEA WebLogic Portal или Oracle 9iAS.

Вообще, большинство порталов представляют собой в основном J2EE-приложения, функционирующие под управлением соответствующих серверов приложений. Лишь немногие из них используют двоичный код для решения дополнительных задач - в частности, для интеграции и операций, требующих высокой производительности. Например, Plumtree Portal опирается на сервер приложений BEA WebLogic Application Server или IBM WebSphere Portal, а SunONE Portal Server функционирует на базе BEA Application Server, Sun ONE Application Server и IBM WebSphere Application Server.

Главный плюс портального подхода к интеграции - его простота. Если к продукту прилагаются библиотеки гаджетов (как в случае c Plumtree Portal), то развертывание портала можно произвести в кратчайшие сроки. Главный минус - это то, что по сути своей приложения остаются неинтегрированными, а бизнес-процесс не становится сквозным. Доступ к приложениям для пользователя становится проще, и это все.

Средства взаимной координации работы приложений

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

Типичные примеры шин обмена сообщениями - IBM WebSphere MQ в комбинации с IBM WebSphere Message Broker, IBM WebSphere Interchange Server, SunONE Message Queue в комбинации с SunONE Integration Ser-ver, набор продуктов Microsoft BizTalk. Эти продукты различаются числом и типом поддерживаемых платформ, коммуникационных протоколов, готовых адаптеров и деталями архитектуры. Скажем, SunONE Integration Server поддерживает платформы Microsoft Windows NT/2000, Sun Solaris Operating Environment, IBM OS/390, AIX, Compaq Tru 64, OpenVMS, Hewlett-Packard HP-UX 11, а Microsoft BizTalk - только Windows. За счет этого SunONE Integration Server можно применять в гетерогенной среде, но его внедрение обойдется дороже.

Непохожий на других подход использовала корпорация Oracle в своей интеграционной платформе Oracle9i Integration - вся функциональность по гарантированной доставке сообщений основана на ее реляционной СУБД Oracle9i (этот модуль называется Oracle9i Advanced Queuing), а коммутационный компонент базируется на сервере приложений Oracle9iAS. Использование РСУБД позволило реализовать такие функции, как единая модель данных, безопасности и транзакций, аудит сообщений в базе данных, приоритетная доставка и пр. Однако в данном подходе интеграция строится на базе модели центрального звена со всеми вытекающими из этого плюсами и минусами.

Поток событий в интеграционной платформе Oracle

Из российских разработок признание завоевал пакет "Юпитер" фирмы ИВК, в котором объединены средства интеграции уровня MOM, средства интеграции, работающие в синхронном режиме, а также сертифицированные средства защиты информации в территориально распределенной гетерогенной среде (он функционирует более чем на 10 платформах, в том числе когда-то популярных в СССР). Его сильной стороной является также "продвинутая" поддержка русского языка.

Если суммировать, то типичные брокеры сообщений предоставляют следующие возможности:

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

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

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

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

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

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

Некоторые системы MOM предоставляют и средства для решения других задач, неизменно возникающих при интеграции приложений. Например, упомянутый выше "Юпитер" фирмы ИВК содержит встроенные средства контроля целостности и подлинности системного и прикладного ПО, механизм гарантированной доставки и обработки пересылаемых по шине сообщений, API для написания полностью переносимых приложений, механизм доступа к СУБД через собственный пул соединений, средства защиты информации в локальных и транзитных хранилищах, средства журналирования и высокоуровневого аудита. Благодаря четырем последним качествам он стал единственным продуктом на российском рынке, сертифицированным Гостехкомиссией при Президенте РФ и Министерством обороны для работы с секретными данными, в том числе под грифом "Совершенно секретно". Кроме того, "Юпитер" обеспечивает собственные средства работы с большим числом транспортных протоколов (включая унаследованные), что делает его привлекательным для интеграции территориально распределенных систем и применения в телекоммуникационных компаниях.

Интеграция бизнес-процессов и фоновые процессы

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

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

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

Практически все продукты класса MOM тем или иным образом решают эти задачи.Так, Microsoft BizTalk предлагает среду разработки, в которой аналитик может описать бизнес-процесс на высоком уровне абстракции, указав точки вызова COM-объектов, реализующих конкретные вычислительные функции.

Иногда для повышения гибкости управления бизнес-процессом (особенно когда в его выполнении участвует человек) к этим системам присоединяют подсистемы workflow. Такую подсистему (как комплементарный продукт) предлагает IBM. Модуль workflow входит в платформу Oracle9iAS Integration. А некоторые системы, в частности SunONE Integration Server, содержат другие встроенные средства (фактически уровня workflow) для описания бизнес-процессов.

Еще один частный случай применения MOM состоит в полностью автоматической обработке данных для обеспечения их целостности и согласованности в разных системах. В этой нише позиционируется, например, IBM WebSphere InterChange Server. В нем сценарии представляются в виде объектов "взаимодействия" (collaborations), к которым через "порты" подключаются адаптеры к унаследованным системам. Вся архитектура не предусматривает участия человека в обработке данных (хотя в принципе такое участие возможно).

Очень часто ПО уровня MOM позволяет также определять транзакционные сценарии, которые либо выполняются целиком, либо (при сбое) обеспечивают восстановление данных в КИС. Так как работа происходит не с базами данных, а с приложениями (которые могут не обеспечивать изоляции данных на период транзакции), то в такие системы встраиваются алгоритмы, снижающие риск создания и использования "данных-призраков". Примером здесь также служит IBM WebSphere Interchange Server. Аналогичную задачу решает и механизм гарантированной обработки сообщений ИВК "Юпитер". Если какой-то из обработчиков сообщения не сработал, то этот механизм инициирует соответствующие корректирующие действия.

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

Создание новых композитных приложений

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

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

В последние годы, по мере развития платформы J2EE, серверы приложений (СП) получали все больше функций и по сути превратились в основную платформу для создания новых Web-ориентированных бизнес-приложений. Сейчас они позволяют управлять транзакциями на уровне контейнеров Enterprise Java Beans (EJB), через интерфейсы Java Transaction API (JTA) создавать объекты, способные участвовать в распределенных транзакциях, вызывать транзакционные системы типа CICS и IMS при помощи Java Transaction Service (JTS), обращаться к системам гарантированной доставки сообщений через интерфейсы Java Messaging Services (JMS), подключать унаследованные платформы через коннекторы Java Connector Architecture (JCA) и, наконец, создавать Web-сервисы.

Например, Sun ONE Application Server 7 предлагает комплект средств создания и разработки Web-сервисов Java Web Services Developer Pack, включающий API Java XML, а также обеспечивающий поддержку протокола SOAP и языка WSDL. Им поддерживаются и такие стандарты, как Java API for XML Messaging (JAXM), Java API for XML Processing (JAXP), Java API for XML Registries (JAXR), Java API for XML-based RPC (JAX-RPC). Этот продукт стыкуется с Sun ONE Message Queue, одной из самых развитых реализаций стандарта JMS. Помимо прочего данное ПО обеспечивает функции гарантированной доставки, средства поддержки транзакционности, средства подписки, фильтрации сообщений и т. п.

Создание бизнес-процесса для BEA WebLogic Integration Platform

Некоторые платформы интеграции на основе серверов приложений содержат средства управления бизнес-логикой. Так, BEA WebLogic Integration Platform содержит среду разработки, позволяющую описывать бизнес-процесс с позиций аналитика, манипулирующего терминами потоков данных. Он определяет точки взаимодействия со слоями более низкого уровня, которыми занимаются программист - сборщик приложения из EJB-компонентов и программист системного уровня. Аналогичным образом на высоком уровне бизнес-процесс описывается и в ряде других систем - в частности, в Oracle 9iAS это делается при помощи инструмента iStudio, входящего в состав Oracle9i Integration, а сама реализация осуществляется на основе модуля workflow.

Для интеграции приложений на базе серверов приложений особенное значение имеет стандарт JCA, являющийся частью J2EE. Он описывает методы обращения к КИС из Java-программ, функционирующих под управлением сервера приложений. Эти методы реализует адаптер ресурса - компонент J2EE, "открывающий" функциональность КИС программистам на Java. Благодаря JCA вендор прикладной системы может написать один адаптер и затем использовать его в СП разных поставщиков.

Адаптер JCA взаимодействует с СП J2EE посредством системных контрактов, позволяющих распространить на унаследованную КИС контекст обращения к адаптеру. Этот контекст включает управление соединениями (Connection management), транзакциями (Transaction management) и безопасностью (Security). При этом JCA никак не регулирует протоколы взаимодействия с КИС.

Важной особенностью JCA является то, что она (с точки зрения прикладного программиста) предлагает аналог JDBC, но только ориентированный на доступ к КИС, - этот набор интерфейсов называется CCI (Common Client Interface). Именно он осуществляет упомянутую выше стандартизацию. CCI предлагает набор API, предназначенный для установления связи с КИС (интерфейсы Connection), API для выполнения команд КИС (интерфейсы Interaction), интерфейсы для получения результатов запросов (Record/ResultSet) и метаданных КИС (т. е. определения типов, он называется Metadata).

 Интеграция на основе сервера приложений Oracle

Но следует иметь в виду, что у JCA есть ряд недостатков. Абсолютно все имеющиеся на сегодня серверы приложений поддерживают лишь версию JCA 1.0. А в ней не предусмотрены асинхронный механизм обращений к КИС, обращения могут исходить только в Java-объект в КИС, нет отображения (mapping) данных (оно определяется на уровне контейнера EJB через механизм Container Managed Persistence), все компоненты коннектора сосредоточены на сервере (т. е. нет стандартного способа деления на агентский и серверный компоненты), не разработан стандарт на протоколы связи между агентом со стороны КИС и серверной частью. Иначе говоря, коннекторная архитектура серверов приложений имеет существенные ограничения по сравнению с интеграционными шинами.

Многие вендоры, например BEA, пытаются решить эти проблемы за счет частных расширений. BEA WebLogic Application Server позволяет делать вызовы к КИС через асинхронные обращения JCA, а получать уведомления из КИС через очередь сообщений и механизм JMS. Аналогичным образом действует и компания Oracle, которая предлагает в своей платформе Oracle 9iAS расширения JCA для обеспечения двунаправленных взаимодействий, асинхронной передачи сообщений и доступа к интерфейсам работы с метаданными КИС.

Кроме того, спецификация JCA 1.0 не обязывает поставщика адаптера поддерживать CCI. Он может приложить свой набор API, и даже, если адаптер поддерживает CCI, в нем могут присутствовать специфические для конкретного адаптера интерфейсы. Тот факт, что JCA 1.0 не диктует единообразных интерфейсов CCI, оставляя их определение на откуп вендорам СП, делает адаптеры непереносимыми между серверами приложений, что не способствует популярности спецификации.

Ряд подобных ограничений должен быть устранен в JCA 2.0, сейчас находящейся в процессе утверждения и известной как JSR (Java Specification Request) 112. Она описывает интерфейсы асинхронного доступа, интеграцию JMS c JCA, слой CCI для работы с метаданными и использование XML в слое CCI. В другой версии JCA, имеющей номер 1.5 и уже включенной в состав J2EE 1.4 (правда, она пока не поддерживается ни одним сервером приложений, даже продукт Sun Microsystems, наиболее "продвинутый" в смысле поддержки Java, опирается только на J2EE 1.3), также есть ряд расширений, например определены новые типы контрактов. Скажем, контракт управления работой (Work Management Contract) позволяет определить, какие системные ресурсы (в частности, число потоков исполнения) можно выделить коннектору. Имеются также расширения, позволяющие инициировать транзакцию со стороны КИС с распространением контекста транзакции в сервер приложений и далее - на другие КИС.

Стоит также учесть, что написание адаптера JCA - очень трудоемкое дело, и если к вашей КИС на рынке нет готового адаптера, ее будет сложно интегрировать. Разумнее создать свой коннектор, используя не JCA, а какие-то другие способы, скажем, шину данных или вызовы "родного" кода.

Итак, преимущества описанного подхода в том, что с помощью сервера приложений можно создать абсолютно новое бизнес-ПО. Недостаток - необходимость хорошего знания Java и отсутствие в СП многих возможностей, доступных пользователям MOM.

Интеграция на уровне данных

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

Сейчас интеграция на уровне данных подразумевает применение технологий федерирования (т. е. построения виртуальных БД из разнородных источников), трансформации данных и их агрегирования. Ее иногда называют технологией Enterprise Information Integration (EII).

Среди продуктов для подобной интеграции можно назвать IBM DB2 Relational Connect, Data Joiner с компонентом Classic Connect для доступа к IMS, а также IBM Data Replication Solution. Аналогичные решения предлагают Oracle и BEA. Существует также множество мелких компаний, специализирующихся в области создания "зонтичных" интерфейсов к СУБД и виртуальных БД - Attunity, Business Objects, Ipedo, Metamatrix, Nimble Technology и Venetica.

Технологии интеграции данных похожи на технологии ETL (Extraction, Transformation and Loading), применяемые в хранилищах данных. ETL также позволяют собрать и переместить данные из разных источников в одно общее хранилище, преобразовав их в некий общий формат. Однако они работают в пакетном режиме, а не в режиме реального времени. Поэтому их нельзя использовать для доставки данных внешним потребителям, например корпоративному порталу. ETL, кроме того, не позволяют виртуализировать источники так, чтобы они выглядели как одна большая база данных, и они, как правило, не обеспечивают транзакционности при доступе к данным.

Технологии EII не опираются на модель событий, что накладывает естественные ограничения на возможности интеграции. Но многие КИС недостаточно открыты для других интеграционных технологий, и единственный способ работать с их данными лежит через средства EII. Более того, для малых компаний подходы ETL и EII - наиболее оправданны с точки зрения цены вопроса.

Издержки и проблемы интеграции

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

Недооценка эффекта от интеграции может серьезно подорвать энтузиазм компании при рассмотрении соответствующего проекта. Однако анализ интеграционных проектов показывает, что 100% прямой выгоды достигается лишь в редких случаях. В большинстве же внедрений прямая прибыль от проекта составляет всего 10-15%, а косвенная - до 85-90%.

Недооценка затрат на персонал. Анализ проектов на Microsoft BizTalk показывает, что до 70-80% затрат может приходиться на человеческий фактор (оплату собственных специалистов и внешних консультантов) и лишь 10-15% затрат приходится на ПО и оборудование. Использование других технологий приводит к увеличению затрат на оборудование и ПО, но при этом обычно возрастает и сложность проекта (он ведется в гетерогенной среде), и себестоимость специалистов. Интеграционный проект может длиться от года до трех лет. На первом этапе имеет смысл привлекать консультантов, затем выгоднее действовать силами своего персонала, обученного на первом этапе. В этом контексте стоит обратить внимание на интегрированность подсистем продукта - свойства, наличие которого позволяет значительно снизить данную статью расходов (позитивный пример в этом смысле дает ИВК "Юпитер").

Недооценка затрат на ПО. Аналитическая компания Giga указывает, что в больших компаниях на первое место (более 60%) по затратам может выйти стоимость коннекторов к системам. Следует иметь в виду, что, как правило, интеграционный проект призван согласовать всего лишь несколько типов документов в разных КИС и применение адаптеров и дорогостоящих систем западных производителей может оказаться экономически не оправданным. Кроме того, надо внимательно следить за предложением вендора, у многих компаний, например той же IBM, для построения законченного решения вам придется закупить несколько продуктов.

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

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

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

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

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

Продолжение следует. Во второй части обзора будет рассмотрена новая концепция интеграции на базе Web-сервисов и предложен анализ нескольких проектов внедрений.