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

Интеграция приложений и интеграционные платформы постепенно становятся существенной статьей ИТ-бюджета. С одной стороны, методология Enterprise Application Integration (EAI) достигла своей зрелости, а с другой — развеялась иллюзия покрыть всю деятельность организации одной суперсистемой. Важную роль сыграла также маркетинговая активность крупных поставщиков, направленная на продвижение новых сервисных платформ интеграции, таких как сервисные шины предприятия (Enterprise Service Bus, ESB). Вероятно, что по этой причине с сервисными шинами сегодня связываются повышенные ожидания клиентов. Разберемся, насколько это оправданно.

Начнем с вопроса о том, что же мы интегрируем. Странности связаны с тем, что шины сервисов плохо приспособлены для обеспечения взаимодействия наиболее распространенных сегодня приложений, таких как привычные ERP-системы, бухгалтерские программы и т.п. Эти приложения практически не поддерживают открытые стандарты новой волны (семейство WS*, Java Message Service, J2EE Connector Architecture и т.п.), на которые ориентированы шины сервисов. С другой стороны, в сервисной шине поддержка «несервисных» методов взаимодействия сопряжена со значительными трудозатратами.

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

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

Может быть, покупая сервисную шину, вы инвестируете в будущее? Может быть, вы решаете задачи завтрашнего дня, и впоследствии сервисные приложения будет внедрять удобнее? Вопрос о необходимости шины сервисов в сервисной инфраструктуре до сих пор открыт — сервисные приложения хорошо взаимодействуют и без нее, причем именно за счет поддержки открытых стандартов и реестров сервисов на уровне спецификаций. Если же все-таки пользователям очень хочется работать именно с шиной, то варианты сегодня можно найти в проектах категории Open Source, например JBoss ESB.

В то же время при внедрении сервисного приложения особенно остро стоит задача его интеграции с «несервисными» системами. И если шина не может здесь помочь, то зачем она вообще нужна?

Другой вопрос, который возникает при знакомстве с коммерческими продуктами, реализующими функции шины сервисов: почему так дорого? Можно много говорить о прозрачности инфраструктуры, сквозных бизнес-процессах, визуальных средствах мониторинга и т.п., но идея шины проста. Как бы они ни назывались, ESB, платформы SOA и т.п., общая идея очень проста — исключить прямые связи между приложениями, оставив только интерфейс с одним общим репозитарием. Правда, шины реализуют не только передачу данных, но и дополнительный функционал: отказоустойчивость, графическое моделирование, мониторинг, аудит, поддержку средств проектирования бизнес-процессов и т.п.

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

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

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

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

Автор намеренно почти избегает ссылок на продукты и производителей: те, кто хотя бы немного знаком с предметной областью, их знает. Чего бы хотелось — это прояснить ситуацию, изрядно затуманенную маркетинговыми заявлениями и «парадами стандартов». Интеграция приложений хотя и «архиважная», но не «архисложная» задача, и попытки напустить в нее туману обесценивают саму идею, задерживая развитие ИТ в организациях. В интеграции приложений, как и в прочих областях ИТ, наилучшие результаты дает здравый смысл, как при выборе инструментов интеграции, так и при их использовании.

Герман Хохлов (german@cma.ru), шеф-архитектор компании CMA Small Systems AB (Москва).