EAI (Enterprise Application Integration) - Средства интеграции приложений

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

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

Проблема интеграции разнообразных приложений восходит к самым истокам ИТ, возможно, она возникла в тот момент, когда в каком-то вычислительном центре впервые было установлено второе приложение.

Глеб Галкин

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

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

Ранние подходы

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

Первоначально идея интеграции развивалась по двум направлениям.

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

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

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

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

Как правило, технологии интеграции на уровне пользовательских интерфейсов используют некоторые ограничения в презентационном слое для связывания систем. В случае со screen scraping таким ограничением является символьный дисплей. Более новый вариант интеграции на уровне пользовательских интерфейсов -- HTML-scraping -- основан на результатах работы веб-приложений, выведенных в браузере. Инструменты этого класса, такие, как Composite Application Platform компании CrossWeave, идентифицируют компоненты HTML-документа, полученного в результате работы веб-приложения, и предоставляют эти компоненты для повторного использования и интеграции.

Стало прописной истиной, что самая постоянная вещь в бизнесе - это изменения. Однако при разработке стратегий ИТ-развития почему-то принято полагать, что все требования известны заранее.

Это быстрая интеграция, однако такой подход предлагает доступ к интегрированным системам "только для чтения". Кроме того, этот подход сильно ограничен, так как для остальных (не веб) приложений имитация пользователя в качестве парадигмы интеграции представляется более сложным делом. Для этого требуются программы, способные воспринимать вызовы GUI, соотнося их с объектами приложений и представляя в качестве программируемых средств управления в режиме близком к режиму реального времени.

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

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

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

Чуть позже появился подход хранилищ данных (datawarehouses), который в последнее время стал базовым. Он подразумевает поддержку данных в специальных хранилищах независимо от бизнес-логики, их породившей. Доступ к хранилищам могут получать различные приложения. Например, база данных по сотрудникам может служить общим фундаментом для нескольких HR-приложений, таких, как распределение премий и пособий, планировщик направления сотрудников на тренинги и отслеживание эффективности работы. Интеграция приложений по такой схеме подразумевает составление запросов и проведение обновлений по общей, хорошо документированной модели данных. Во многом благодаря успеху продуктов, созданных на основе реляционных баз данных и сопутствующих стандартов (таких, как SQL и ODBC) интеграция на уровне данных продолжает господствовать в качестве способа оптимизации взаимосвязей между различными системами.

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

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

Интеграция на уровне корпоративных приложений

Когда технологии и инструменты созрели, появился другой эффективный подход -- интеграция на уровне приложений (EAI, Enterprise Application Integration). Он подразумевает совместное использование исполняемого кода, а не внутренних данных. EAI устраняет необходимость в выполнении больших объемов программирования. Вместо этого подход интеграции на уровне приложений разбивает программы на компоненты и интегрирует их с помощью стандартизированных программных интерфейсов, распределенных объектных технологий и связующего ПО. В арсенал средств EAI входят традиционные библиотеки функций и API, созданные для объединения программ на одной платформе, а также межплатформные инструменты, такие, как RPC (Remote Procedure Call -- удаленный вызов процедуры) и ORB (Object Request Brokers -- брокер объектных запросов). Все эти технологии сильно различаются в частностях, но суть сводится к тому, что функциональность, присутствующая в одном приложении, может использоваться другими, независимо от базовой платформы.

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

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

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

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

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

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

Веб-услуги

И наконец, самая свежая идея -- подход веб-услуги. По сути это тот же подход интеграции на уровне приложений, но на современном технологическом базисе. Этот подход основан на использовании объектно-ориентированных технологий для заключения данных и программных элементов в некую "оболочку", чтобы к ним могли получать доступ различные веб-приложения. Например, используя SOAP (Simple Object Access Protocol), браузер может сравнить цены на нескольких сайтах и предоставить клиенту сравнительный отчет.

Важнейшее отличие веб-услуг от более ранних EAI-проектов заключается в следующем. Веб-услуги предоставляют стандартизированные способы работы с интеграцией, а EAI-технологии всегда зависели от одного-двух поставщиков или разрабатывались для конкретных продуктов. Другими словами, может существовать EAI-интерфейс, связывающий пакет PeopleSoft по работе с персоналом с системой SAP R/3, однако он не сможет подключить к SAP другие пакеты по работе с персоналом. С другой стороны, веб-услуги основаны на стандартах, поддерживаемых консорциумом World Wide Web (W3C). Кроме того, в то время как веб-услуги с самого начала разрабатывались для использования в распределенных средах, EAI-технологии далеко не всегда предназначались для этого.

Несколько факторов -- повсеместное использование интернет-стандартов, возникновение стандартной индустриальной платформы взаимодействия J2EE и быстрое распространение XML в качестве независимого от платформы формата передачи сообщений -- способствуют активному продвижению такого подхода и в конечном счете увеличению инвестиций в интеграцию на уровне приложений. Java-программирование особенно способствует интеграции процессного уровня, которая напрямую поддерживается многими сервисами J2EE, включая RMI (remote method invocation), JMS (Java messaging service) и JCA (Java Connector Architecture). Новая структура компоновки приложений, позволяющая удаленным объектам обмениваться XML-сообщениями, обещает ускорить процесс интеграции, по крайней мере для приложений, которые (изначально или после перевода) воспринимают XML-сообщения.

Многие компании, в том числе лидеры рынка EAI -- BEA и IBM -- полны энтузиазма в отношении веб-услуг. Так, во время выступления на конференции разработчиков BEA eWorld 2002 Питер Холдрич, системный архитектор английского подразделения BEA, сравнил происходящие сейчас сдвиги с изменениями понимания вселенной в европейской культуре. Информационные системы перестают быть "плоскими", и начинает формироваться более сложная картина. И символом нового можно считать изменившееся представление о транзакции. На протяжении предыдущего десятилетия транзакция представляла собой простое сообщение между жестко связанными системами, передаваемое в синхронном режиме. Теперь же системы становятся слабосвязанными и асинхронными, что гораздо более удобно для бизнес-процессов.

Клубок проблем

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

• 85% проектов по программной разработке не доводятся до конца;

• 58% крупных системных проектов не укладываются в бюджет;

• 63% выбиваются из графика;

• 58% компаний сообщают, что успешных их проектов у них менее 50%.

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

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

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

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

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

Традиционные EAI-технологии или веб-услуги?

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

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

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

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

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