Требования к интеграции приложений постоянно растут. Многим предприятиям требуется технологическая платформа, которая обеспечит свободное соединение модулей информационной системы и простой информационный обмен. По сути, это единственная задача, которая стоит на протяжении всей эры EAI. Один из самых последних подходов к решению этой задачи - технология Enterprise Service Bus (ESB).

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

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

Назовете ли вы хоть одно предприятие, которое может существенно изменять бизнес, корректируя процессы и организационную структуру, не требуя изменения или даже замены программного обеспечения? Предприятие, возможности которого не ограничивает ИТ? Я не могу. И вина за это положение дел лежит на поставщиках традиционных бизнес-приложений и средств EAI (Enterprise Application Integration). До последнего времени они заботились о гибкости их систем только на словах. Не говоря уже о межсистемной гибкости.

В качестве последнего средства от информационной косности информационных систем предприятия многие EAI-поставщики продвигают новую концепцию - Enterprise Service Bus (ESB). Но сможет ли ESB придать большую гибкость предприятию?

Что такое ESB?

Прежде всего важно понять, что ESB - это маркетинговый термин. Поэтому ESB не имеет точного определения. В целом идея ESB состоит в том, что в противоположность традиционным EAI-решениям, основанным на архитектуре hub-and-spoke (эту архитектуру еще называют "звездой", так как все приложения подсоединены к центральному процессу, называемому сервером сообщений), ESB предполагает децентрализованные операции. Собственно, в этом и состоит все определение. Понятно, что под него можно подогнать огромное количество продуктов. BEA, IBM, Tibco и Web-Methods развивают и продвигают решения, которые могут быть охарактеризованы как ESB. В несколько своеобразном варианте, но похожий архитектурный подход продвигает и Oracle. Из заметных EAI-игроков совсем в стороне от этого процесса остается только Microsoft, которая, по сути, не поднялась выше первичного уровня информационно-ориентированной интеграции (см. "Мифы и парадигмы интеграции приложений" IE № 12-13/2004).

Часть экспертов, давая определение ESB, делают упор на технологии. Дело в том, что идеология ESB появилась одновременно с Web-сервисами, XML и сервисно-ориентированной архитектурой (Service Oriented Architecture, SOA), а в значительной степени и благодаря им. В результате эти технологии и концепции, заложенные в фундамент ESB, позволили более гибко подходить к интеграции инфраструктуры. И под ESB понимают технологии, которые позволяют системам осуществлять слабо связанное взаимодействие путем обмена сообщениями. В таком понимании подход ESB обеспечивает связи типа "все-со-всеми", эквивалентные Интернету, и объединяет поддерживаемые сервисы для обеспечения надежного и безопасного доступа к событиям и получению сообщений. Промежуточное ПО ESB - это интерфейс между каждым бизнес-приложением и шиной, которая связывает его с другими бизнес-приложениями и сервисами. Опора на SOA при реализации идей ESB увеличивает гибкость архитектуры. Бизнес-процессы будут более гибкими, упростятся управление приложениями и их замена. И это принципиальный момент. Ниже мы будем придерживаться именно накого определения ESB.

Требования к ESB-системе

Фундаментальное требование, выдвигаемое к ESB, - это возможность обеспечить обмен сообщениями между системами, как внутри предприятия, так и между предприятиями. Это условие порождает ряд требований.

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

Реализация SOA. Здесь основное требование - открытый доступ к сервисам, без реализации специальных ссылок или протоколов. Среда должна поддерживать доступ к сервисам на уровне запросов и ответов, а также, в случае необходимости, взаимодействие автономных процессов.

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

События. Для событий в ESB-системе должна быть реализована модель публикации по подписке (publish-and-subscribe). В этом случае новые программы или специальные приложения мониторинга смогут просматривать события, не вмешиваясь в приложения-источники.

Безопасность. Для получения доступа к приему сообщений должна существовать идентификация и авторизация. Основанные на ESB системы должны поддерживать цифровые подписи для проверки достоверности и строгого выполнения обязательств.

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

Архитектура ESB

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

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

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

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

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

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

Модуль маршрутизации и подписки определяет адрес назначения сообщения в сети. Для бизнес-приложений желательно, чтобы модуль маршрутизации при определении логического адреса сообщения конвертировал его в так называемый специальный универсальный идентификатор ресурса (Uniform Resource Identifier, URI). Когда подписчик подписывается на определенную тему, функция маршрутизации сообщений получает уведомления о подписке и ее отмене от сервиса каталога событий.

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

Проблемы и перспективы

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

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

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

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

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

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

  • программные интерфейсы приложений для промежуточного ПО ESB;
  • сервис каталога сообщений;
  • протоколы управления ESB.

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