ESB (Enterprise Service Bus) - дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).
Основные функции ESB
- Обеспечение интерфейсов взаимодействия
- Отправка сообщений и маршрутизация
- Преобразование данных
- Сенсоры событий
- Управление политиками
Архитектура ESB
Основа архитектуры ESB - это идея использования общей интеграционной инфраструктуры всеми корпоративными приложениями на базе обмена сообщениями. Все приложения взаимодействуют через одну точку, которая, в случае необходимости, обеспечивает сохранность обращений, преобразование данных и транзакции. При этом целью интеграции приложения является создание единственного модуля (или адаптера), который отвечает за «подключение» приложения к ESB. Последующую обработку сообщений и их маршрутизацию в другие системы, ESB выполняет на основании установленных бизнес-правил самостоятельно. Этот подход обеспечивает превосходную гибкость, простоту масштабирования и переноса, поэтому в случае замены одного из приложений подключенного к шине, перенастраивать остальные не нужно.
Достоинства и недостатки
Достоинствами ESB является:
- Организация размещения существующих систем осуществляется быстрее и дешевле.
- Повышение гибкости.
- ESB основывается на общепризнанных стандартах.
- Наличие большого количества конфигурации для интеграции.
К числу недостатков ESB относят:
- Сложность реализации
- Требует больших ресурсов.
Разработка Enterprise Service Bus
Отличительной чертой Web-служб является то, что потребитель имеет возможность динамически связываться с провайдером службы. Все это происходит благодаря двум главным функциональным возможностям:
- Обнаруживаемость. В автоматически поддерживаемые каталоги могут быть собраны провайдеры Web-служб. Таким образом, потребителю предоставляется возможность просматривать такой каталог, чтобы найти провайдера нужной службы.
- Самоописание. Web-служба способна описывать себя удобным для машинного чтения способом. Так, можно распознать двух или более провайдеров одной и той же службы, даже если они выполнены совершенно по-разному, так как их описательные интерфейсы отвечают одному и тому же описанию.
Такие функциональные способности Web-служб кардинально отличаются от существовавших подходов к интеграции, в которых интерфейсы определялись во время компиляции и во время связи потребителя с провайдерами. Форматы сообщений выражались не описательно.Они не могли заставить следовать этому формату поэтому были основаны на внутренней договоренности, в результате чего получатель не мог обработать структуру, созданную отправителем.
Самоописание Web-служб облегчило интеграцию с помощью объявления интерфейсов, которым нужно было следовать. Благодаря динамическому обнаружению службы, потребитель был освобожден от зависимости от конкретного провайдера с определенным адресом, однако, и эта возможность создала свои собственные проблемы. Достаточно тяжело было решить вопрос связи потребителя с провайдером раз и навсегда во время компиляции и потенциальным поиском нового провайдера при каждом вызове во время исполнения. Тогда ESB предложила другой вариант - дать возможность потребителю один раз динамически связаться с прокси-службой, имея при этом возможность использовать нескольких провайдеров и провайдеров, которые могут появиться в будущем, через эту прокси-службу. Все это говорит о том, что ESB делает службы доступными для их вызова потребителями и дает возможность потребителям найти службы программным способом.
Шлюз служб
Так называемый шлюз служб является краеугольным камнем синхронной ESB. Он выступает посредником между провайдерами и потребителями служб, оказывая при этом содействие в обработке синхронных вызовов с использованием брокера. Данный шлюз открывает доступ ко всем известным службам и прокси-службам каждой из них, поэтому он является своего рода «единым окном» для потребителя, желающего вызывать любую службу у любого провайдера, который известен шлюзу. Когда Web-службы координирует шлюз, они обладают способностью к самоописанию. Каждая служба предоставляет свой интерфейс с помощью WSDL, который состоит из следующих четырех частей:
- Типы портов - набор операций, которые выполняет Web-служба.
- Сообщения - то есть формат запросов и ответов
- Типы - Типы данных, которые используются Web-службой
- Связи - адрес для вызова операции
Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI -службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL -операции и получает обратно адрес прокси-службы шлюза для этой операции.
Шина сообщений
Шаблон Message Bus (Шина сообщений) является основой асинхронной ESB. Шина сообщений - это набор каналов сообщений, которые настроены как пары каналов запрос-ответ. Каждая пара представляет службу, которую может вызвать потребитель, использующий шину. Потребитель посылает сообщение в очередь запросов службы и после этого выслушивает очередь ответов для получения результата. О том, кто предоставляет службу потребитель на самом деле не знает. Провайдеры служб также подсоединены к шине сообщений и прослушивают ее на наличие сообщений запросов. При наличии нескольких провайдеров службы, между ними происходит соревнование как между потребителями за получение конкретного запроса. Система сообщений, выполняемая шиной сообщений, функционирует как диспетчер сообщений и рассылает запросы провайдерам служб, оптимизируя эту рассылку в зависимости от степени нагрузки, сетевых задержек и т. д. После того как провайдер получил запрос, он выполняет службу и вносит результат в сообщение в очередь ответов, то есть провайдер и потребитель никогда не знают о месторасположении друг друга. Эта шина сообщений и является сущностью ESB.
В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали - теперь это улица Марии Ульяновой, а дом 25 по этой улице - хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…
Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.
Как это было раньше? Один банк отправлял другому электронное сообщение (Уж извините, я тогда в Инкомбанке работал, потому про банки буду рассказывать). Второй банк сообщение получал и отправлял на него квитанцию. Все это десять раз шифровалось, заверялось цифровой подписью, в квитанцию включалась хеш-функция исходного сообщения … номера входящих и исходящих, отметки времени (тоже, кстати, криптографические) и т.д. и т.п. Наиболее обсуждаемый вопрос тех лет, а нужно ли на квитанцию формировать квитанцию о получении квитанции и что делать, когда квитанция не доставлена. В общем, страшно вспомнить до какого уровня сложности можно довести процесс синхронизации состояний множественных виртуальных образов одного реального документа. С бумагой было проще. По крайней мере, до изобретения ксерокса.
Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли
Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример — моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе — MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр. Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)
Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее - ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) - связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:
- Порядок и единообразие архитектурных связей
- Централизованное управление
- Конфигурация приложений на стороне сервера
- Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
- Протоколо-независимость разрабатываемого программного кода
- Широкие возможности конфигурирования шины и приложений
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» - если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:
Порядок
Чем большего размера система, тем более важен в ней порядок и единообразие. Если речь идет о комплексе систем большого предприятия, то его точно уж можно назвать системой большого размера. Конечно, всегда можно найти администратора, держащего в голове схему взаимодействия сотни серверов, или кучу томов несвязанной документации по каждому программному модулю, где описано, с чем и как он взаимодействует. 
Но намного проще иметь сервис (ESB), который позволяет проводить все взаимодействие через себя. При таком подходе часть архитектуры взаимодействия в любой подсистеме уже понятна – нет бардака в связях между системами, серверами и приложениями: все связано с ESB и ESB связано со всем.
Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика. 
Например, при переезде сервера БД не нужно залезать в конфигурацию всех существующих серверов приложений, и в настройки конкретных приложений в частности – достаточно иметь одну переменную среды в ESB, в которой указывается адрес БД, и тогда изменения нужно будет выполнить всего в одной точке.
Или же если одна из внешних систем была недоступна длительное время, а ни один запрос к ней не должен потеряться – можно воспользоваться сервисом обработки сбойных событий для «вбрасывания» недошедших сообщений тогда, когда это будет удобно.
Если вам нужно регулировать количество одновременных запросов к какой-либо системе, либо мониторить эти запросы, анализировать нагрузку, искать узкие места – вам нужно в центр управления обмена сообщениями – в консоль ESB-сервера.
Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее. 
Во-вторых, при конфигурировании на стороне сервера именно среда работы приложения во многом может на него влиять, что позволяет переносить приложения между разными контурами (тестовым и продуктивным), тюнинговать и даже исправлять баги без внесения изменений в приложение.
Если использовать все эти преимущества, приложения получают способности истинного хамелеона – они настолько гибкие, что стают частью среды, в которой работают, и при этом привносят свой важный функционал.
Но гибкость приложений под IBM WebSphere ESB не ограничивается средой их работы. Громадный вклад в это делают возможности разработки. Поскольку, системы не только нужно иметь, где запускать, но еще нужно разрабатывать и дорабатывать, эти интересные пункты упускать нельзя:
SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).
Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).
Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.
Удобства очевидны – гибкость, универсальность, повторное использование кода, быстрота разработки и модификации.
Кстати, SCA привязка использует особый протокол и предназначена для сообщения между модулями в рамках одного сервера/кластера. Взаимодействие через эту привязку менее ресурсоемкое и более быстрое по сравнению с другими протоколами.
Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.
Все вышеприведенное утверждает ESB как удобный, мощный и гибкий интеграционный аппарат, пусть и не всегда легкий в освоении. В дальнейшем нужно всего лишь научиться им пользоваться.
В статье использованы следующие изображения:
Функции Enterprise Service Bus
Современная интеграция информационных систем представляет собой реализацию сервис-ориентированной архитектуры (Service-Oriented Architectures, SOA) с использованием технологий Web-cервисов; существует много превосходных описаний преимуществ и методов такой реализации (см. раздел ). В последнее время ключевым компонентом инфраструктуры SOA считается корпоративная сервисная шина Enterprise Service Bus (ESB) (см. раздел ). Однако важно точно знать, что такое ESB - продукт, технология, стандарт или что-либо еще. В частности, можно ли построить ESB сегодня, и если да, то как именно?
В этой статье ESB описывается как набор функций инфраструктуры, реализуемый при помощи технологий связующего ПО, обеспечивающих поддержку SOA. ESB поддерживает взаимодействия с использованием сервисов, сообщений и событий в неоднородной среде, с надлежащим уровнем сервиса и управляемостью. В статье мы собрали и классифицировали самые различные функции. Однако не во всех ситуациях работы с ESB обязательно использовать все эти функции.
В статье определяется минимальный набор функций, обеспечивающих выполнение большей части требований к ESB в соответствии с принципами SOA. Определив минимальный набор функций, мы сможем понять, какие из имеющихся технологий можно использовать для реализации ESB, поддерживающей SOA. Поняв, какие дополнительные функции диктуются требованиями конкретной ситуации, вы сможете выбрать наиболее подходящую в этой ситуации технологию реализации.
В следующих статьях будет описан набор ESB-сценариев в обычных исходных точках SOA для реализации ESB или SOA. В свою очередь, шаблоны решений помогают выбрать подходящие технологии для реализации.
Поскольку развиваются ситуации, в которых используется решение ESB, соответствующим образом развиваются и необходимые для ESB функции. Аналогично будут развиваться функции и средства явно использующих ESB продуктов. Поэтому в заключительной статье данной серии мы рассмотрим схему внедрения SOA и ESB, чтобы дать рекомендации на первом этапе использования функций и технологий ESB и продемонстрировать возможности постепенного внедрения.
Роль ESB в структуре SOA
Хотя мы и не станем рассматривать в деталях определение SOA (см. раздел ), все же здесь полезно будет собрать все принципы, с которыми соглашается большинство авторов определений SOA:
- Использование явно независимых от реализации интерфейсов для определения сервисов;
- Использование протоколов связи, усиливающих прозрачность расположения и функциональную совместимость;
- Определение сервисов, инкапсулирующих многократно используемые бизнес-функции.
Конечно, разные технологии будут иметь различные ограничения по физическому развертыванию поддерживаемых ими шаблонов - одни из них могут оказаться подходящими для очень масштабного распределения и поддержки интеграции в крупных географических областях, тогда как другие больше подходят для развертывания в локализованных кластерах и обеспечивают поддержку решений с высокой доступностью и масштабируемостью. Сопоставление требований к физической распределенности функций технологий, которые предполагается использовать, является важным аспектом разработки ESB. Кроме того, очень важно обеспечить возможность прирастающего расширения первоначального развернутой системы для отражения эволюционирующих требований, интеграции дополнительных систем или расширения географической доступности инфраструктуры.
Рисунок 2. Централизованное управление распределенной инфраструктурой ESB
Кроме того, следует обозначить позицию ESB по отношению к другим компонентам инфраструктуры SOA, в частности, компонентам службы каталогов Service Directory, Business Service Choreography и Business-to-Business (B2B) Gateway. Поскольку перечисленные выше принципы SOA не требуют обязательного наличия этих компонентов, давайте считать их необязательными компонентами. На показана инфраструктура SOA, демонстрирующая отношения этих компонентов к ESB.
Рисунок 3: Роль ESB в структуре SOA
Для осуществления маршрутизации запросов сервиса ESB необходим особый каталог маршрутизации сервиса . Однако в SOA может также присутствовать отдельный каталог бизнес-сервиса , который, в самой простой форме, может представлять собой временный (используемый при разработке проекта) каталог, который используется для обеспечения многократного использования сервисов разработчиками организации. В представлении о Web-cервисах роль каталога бизнес-сервиса и каталога маршрутизации сервиса отводится каталогу UDDI, тем самым обеспечивается динамическое обнаружение и вызов сервисов. Такой каталог может рассматриваться как часть ESB, однако до тех пор, пока такие решения не получат достаточного распространения, лучше, чтобы каталог бизнес-сервиса существовал отдельно от ESB.
Функцией компонента Business Service Choreographer является компоновка бизнес-процессов из нескольких бизнес-сервисов ; поэтому этот компонент вызывает сервисы через ESB, а затем предлагает бизнес-процессы клиентам как другие сервисы, также через ESB. Однако роль компонента Business Service Choreographer, технологии организации производственного процесса, в координации работы бизнес-процессов и сервисов идентифицирует этот компонент как невходящий в ESB, технологию инфраструктуры.
И наконец, функцией компонента B2B Gateway является обеспечение доступности сервисов каждой из двух или более организаций всем остальным организациям управляемым и безопасным способом. Полезно рассматривать такие компоненты как подключенные к ESB, но не входящие в ее состав. Хотя существуют шлюзовые технологии, предоставляющие функции, необходимые для реализации как компонентов B2B Gateway, так и ESB, само назначение компонента B2B Gateway отделяет его от ESB. Действительно, для выполнения своих функций этому компоненту могут потребоваться дополнительные средства, например, инструменты управления партнерскими взаимоотношениями, которые не являются частью ESB и не обязательно поддерживаются технологиями ESB.
Модель производительности ESB
Обобщает и классифицирует некоторые функции ESB, описанные в имеющейся литературе (см. раздел ). Одни из этих функций являются простыми, другие, например, функции автономности и интеллектуальные функции, представляют собой значительный шаг к операционной среде по требованию (On Demand). Важно понимать, что для большинства существующих сценариев использования ESB необходимыми являются только некоторых из этих функций из некоторых категорий. О минимальном наборе функций, необходимых для реализации ESB, мы поговорим в разделе Минимальный набор функций ESB для SOA .
Таблица 1. Функции ESB, описанные в специальной литературе
| Связь | Взаимодействие сервисов |
|
|
| Интеграция | Качество сервиса |
|
|
| Безопасность | Уровень сервиса |
|
|
| Обработка сообщений | Управление и автономность |
|
|
| Моделирование | Интеллектуальные функции инфраструктуры |
|
|
Многие из этих функций могут быть реализованы при помощи соответствующих технологий или с использованием открытых стандартов. Но технологии, претендующие на использование в реализации ESB, могут в значительной степени различаться по характеристикам производительности, масштабируемости и доступности, а также по тому, какие функции ESB и открытые стандарты они поддерживают. По этим причинам и вследствие того, что некоторые из значимых стандартов были разработаны недавно или все еще находятся в стадии разработки, многие критически важные решения по реализации ESB в настоящее время сопряжены с поиском компромиссов между поддержкой зрелых, сложившихся технологий и менее зрелых открытых стандартов.
В данной серии статей я не буду подробно рассказывать о каждой из этих категорий функций. Скорее мы сосредоточимся на тех из них, которые имеют значение для принятия решений по поводу выбора подхода к внедрению или реализации ESB. В частности, в следующем разделе мы остановимся на том, какой минимальный набор функций необходим для поддержки SOA реализацией ESB.
Минимальный набор функций ESB для SOA
Если для большинства SOA-сценариев имеет значение только подмножество перечисленных ранее функций, мы можем поставить следующий вопрос: какие функции входят в минимальный набор функций, необходимых для того, чтобы реализовать ESB? Чтобы ответить на этот вопрос, мы рассмотрим самые распространенные элементы определения ESB, по поводу которых не существует особых разногласий:
- ESB представляет собой логический компонент архитектуры, который предоставляет инфраструктуру интеграции, согласующуюся с принципами SOA;
- Согласно принципам SOA, необходимо использование независимых от реализации интерфейсов, протоколов связи, усиливающих прозрачность размещения и функциональную совместимость, а также определения сервисов, которые являются относительно малодетализированными и инкапсулируют функцию, допускающую многократное использование;
- ESB может быть реализована как распределенная неоднородная инфраструктура;
- ESB предоставляет средства для управления инфраструктурой сервисов и дает возможность работать в современной распределенной разнородной среде.
В приводится минимальный набор функций ESB, выбранных с учетом этих принципов.
Таблица 2. Минимальный набор функций ESB
| Связь | Интеграция |
|
|
| Взаимодействие сервисов | |
| Открытая и независимая от реализации модель обмена сообщениями и организации интерфейсов, которая должна изолировать код приложения от специфических условий маршрутизации сервисов и транспортных протоколов, а также обеспечение возможности замены реализации сервиса | |
Обратите внимание на то, что минимальный набор функций не требует использования каких-либо определенных технологий , например, связующего ПО EAI, Web-сервисов, J2EE или XML. Вполне вероятно, что такие технологии будут использоваться, поскольку они отвечают требованиям, но это не является обязательным. И наоборот, минимальный набор функций почти, если не полностью, обеспечивается простым использованием SOAP/HTTP и WSDL.
- Адресация URL и существующая инфраструктура HTTP и DNS предоставляют инфраструктуру "шины", обеспечивающей маршрутизацию сервисов и прозрачность размещения;
- SOAP/HTTP поддерживает парадигму обмена сообщений запрос-ответ ;
- Транспортный протокол HTTP является широко доступным;
- SOAP и WSDL представляют собой открытую, независимую от реализации модель организации интерфейса и обмена сообщениями сервисов.
Тем не менее, использование SOAP/HTTP и WSDL в простейшей форме в действительности обеспечивает только интеграцию от точки до точки и не предоставляет следующих ключевых функций, необходимых для ESB:
- Отсутствует функция администрирования для управления адресацией и наименованием сервисов Имена сервисов контролируются в индивидуальном порядке каждым адаптером, поэтому управление маршрутизацией сервиса распределяется между адресами, вызываемыми клиентами сервиса, инфраструктурой HTTP и именами сервисов, присваиваемых адаптерам;
- Хотя этот подход зависит от деталей реализации, он не способствует обеспечению замены реализации сервиса; код запросчика сервиса (возможно, сгенерированный инструментами разработки), часто будет напрямую привязан к специфической реализации поставщика сервисов через специфические протоколы по специфическим адресам. Замена реализации сервиса другой реализацией потребует изменений в коде приложения и его повторного развертывания.
Безусловно, для многих или даже для большинства сценариев необходимы дополнительные функции, которые со временем станут все более распространенными. В частности, следующие типы требований, вероятно, приведут к использованию более сложных технологий, сейчас или в будущем:
- Функции обеспечения качества сервиса и уровня сервиса;
- Концепции SOA более высокого уровня - service choreography, каталог, преобразование и т. д.;
- Требования операционной среды по требованию (On Demand), такие как функции автономности и управления, а также интеллектуальные функции инфраструктуры;
- По-настоящему неоднородные операции в нескольких сетях, с несколькими протоколами и несколькими доменами с разными моделями владения.
Проблемы безопасности, связанные с ESB
В этой статье не предполагалось рассматривать сами требования к безопасности, однако, они могут иметь значение при выборе технологии ESB. Например, если нет необходимости в аутентификации и авторизации запросов к серверу, то выбор технологий может быть очень обширным. Если требуется обеспечить определенный уровень безопасности, что более вероятно, то важно оценить, какой стиль обеспечения безопасности будет приемлемым. Например:
- Будет ли приемлемым уровень безопасности инфраструктуры связи при использовании взаимной аутентификации по протоколу безопасных соединений Secure Socket Layer EAI между серверами связующего ПО EAI или при использовании протокола HTTPS?
- Будет ли достаточно индивидуальной, от точки к точке, системы безопасности между системами-участниками, или необходима сквозная модель обеспечения безопасности? Например, есть ли необходимость в распространении идентификационной информации клиента через промежуточные системы, например, брокеры, конечным поставщикам или реализациям сервиса?
- Будет ли приемлемой безопасность на прикладном уровне, например, может ли клиентский код выполнить базовую аутентификацию HTTP по идентификатору пользователя и паролю, или сможет ли он передать эту информацию сервису как данные приложения?
- Требуется ли соответствие механизма безопасности стандартам обеспечения безопасности, например, Kerberos или WS-Security?
Хотя возможны все перечисленные подходы к обеспечению безопасности, рекомендуется использование соответствующих стандартам (например, WS-Security) функций обеспечения безопасности при поддержке инфраструктуры и связующего ПО. Однако эти стандарты появились сравнительно недавно, и поддержка их программными продуктами пока находится в фазе развития, особенно в случаях, связанных с обеспечением функциональной совместимости. Таким образом, одним из приоритетов архитектуры ESB должно стать утверждение требований к обеспечению безопасности на ранних фазах разработки, чтобы их можно было учесть при выборе технологии реализации.
Заключение
В данной статье рассказывалось о самых общих принципах SOA и их связи с технологией Web-сервисов. Исходя из этих принципов автор утверждает, что компонент инфраструктуры, предоставляющий функцию маршрутизации, должен обеспечить взаимодействие сервисов между собой, а также поддержку замены одной реализации сервиса другой реализацией. Эти функции, в числе многих других, реализуются посредством ESB.
ESB предоставляет распределенную инфраструктуру и функции централизованного управления, для чего необходим каталог маршрутизации сервиса и кроме того, возможно, каталог бизнес-сервиса. Компонент Business Service Choreographer вызывает сервисы из ESB, а затем представляет процессы как новые сервисы через ESB.
Среди множества функций, предоставляемых ESB, имеются функции:
- Связи;
- Взаимодействий сервисов;
- Интеграции;
- Обеспечения качества сервиса;
- Безопасности;
- Обеспечения уровня сервиса;
- Обработки сообщений;
- Управления и автономии сервиса;
- Моделирования;
- Интеллектуальные функции инфраструктуры.
В следующей статье серии мы рассмотрим распространенные сценарии, подходящие шаблоны решений для сценариев и поговорим о самых распространенных проблемах, связанных с этими сценариями.
Благодарности
Эта статья вряд ли вышла в свет, если бы автор не обсуждал свои идеи со следующими людьми: Бет Хатчисон (Beth Hutchison), Рейчел Рейниц (Rachel Reinitz), Олаф Циммерман (Olaf Zimmerman), Хелен Уайли (Helen Wylie), Кайл Браун (Kyle Brown), Марк Колан (Mark Colan), Джонатан Адамс (Jonathan Adams), Пол Фремантл (Paul Fremantle), Кейт Джонс (Keith Jones), Пол Вершурен (Paul Verschueren), Дэниэл Стэрмен (Daniel Sturman), Скотт Косби (Scott Cosby), Дейв Кларк (Dave Clarke), Бен Манн (Ben Mann), Луиза Гиллис (Louisa Gillies), Эрик Хернесс (Eric Herness), Билл Хасселл (Bill Hassell), Гуру Васудева (Guru Vasudeva), Карим Юсуф (Kareem Yusuf), Кен Уилсон (Ken Wilson), Марк Эндреи (Mark Endrei), Норберт Биберштейн (Norbert Bieberstein), Крис Нотт (Chris Nott), Алан Хопкинс (Alan Hopkins) и Ярослав Данчич (Yaroslav Dunchych).
В стремительном процессе эволюции компьютерных технологий иногда совершенно неожиданно раскрываются новые возможности старых идей. Например, такой, как, казалось бы, давно забытая память на ферритовых сердечниках. При всех недостатках ее положительным качеством была способность запоминать и сохранять данные бесконечно долго без подпитки - в отличие от современных модулей RAM на полупроводниках. И вот буквально на наших глазах она возрождается в виде многообещающей технологии MRAM, в которой точно так же используется двухпозиционность петли магнитного гистерезиса. Следовательно, она будет сохранять свое состояние без питания. С возрождением магнитной памяти уйдет в прошлое такая привычная процедура загрузки компьютера.
Нечто подобное происходит и с магистралями обмена данными, построенными по принципу «общей шины». Сейчас трудно оценить революционность идеи общей шины, а ведь в свое время это был настоящий переворот. Общая шина Unibus, предложенная три десятка лет назад инженерами корпорации Digital Equipment в качестве архитектурной основы для миниЭВМ PDP-11, оказалась чрезвычайно эффективным (а главное, дешевым) средством интеграции разнотипных устройств. В последующем на шинном принципе было построено множество компьютеров, в том числе все современные ПК. Собственно, с общей шины и начал формироваться рынок периферийных устройств. Однако со временем шины, используемые в качестве центрального архитектурного элемента компьютера, стали уступать свое место более быстродействующим коммутаторам, оставаясь при этом одним из основных вариантов подключения периферийных устройств. Сегодня шина, которую называют Enterprise Service Bus (ESB) , может сыграть примерно ту же роль, что и шина Unibus, со всеми достоинствами, но на более высоком уровне.
События и в самом деле развиваются стремительно. Всего лишь год назад один из ведущих аналитиков Gartner Group Ефим Натис высказал следующее предположение: «Один из основных подходов к созданию корпоративной инфраструктуры приложений строится с использованием слабосвязанных асинхронных процессов». А уже в октябре 2002 года в еженедельнике InfoWorld в статье Джона Уделла можно было прочитать: «Теперь, когда мы все согласны с тем, что Web-службы должны взаимодействовать в асинхронной манере, стало ясно, что программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями (message-oriented middleware, MOM), приобретает решающее значение».
Как видим, всего за год предположение превратилось в утверждение. В том, что это произошло, заметную роль сыграла компания Sonic Software, образованная несколькими выходцами из BEA Systems и сегодня признаваемая в качестве одного из лидеров в разработке программного обеспечения промежуточного слоя. Очень интересные работы проделаны еще в нескольких небольших компаниях (например, Collaxa), однако Sonic одной из первых предложила свою реализацию слабосвязанных асинхронных процессов. При всей новизне, в своем программном продукте SonicXQ ESB компания, по сути, реализует старую, заимствованную у миниЭВМ идею общей шины, но при этом воплощает ее в новом обличии.
В данном случае ESB является общей в том смысле, что объединяет все приложения предприятия. ESB, реализованная с использованием архитектуры SOA (Service-Oriented Architecture), предназначена для интеграции корпоративных приложений на основе ориентированных на документы асинхронных Web-служб и J2EE Connector Architecture (JCA). Две этих технологии обеспечивают контентную маршрутизацию сообщений и позволяют так организовать взаимодействие между приложениями, и так интегрировать управление бизнес-процессами, что появляется возможность обойтись без дорогостоящих брокеров.
Оригинальность разработки SonicXQ привлекала к себе значительное внимание. Исторически первыми появились интеграционные брокеры (иногда их называют интеграционными серверами). Решения, построенные на основе интеграционных брокеров, можно представить в виде коммутаторов. С их помощью формируется некоторый гипотетический метакомпьютер, где все управление строится по централизованному принципу. В результате получается что-то вроде гипер-мэйнфрейма. Sonic совершила примерно то же самое, что DEC, предложившая три десятилетия назад шинные миниЭВМ в качестве недорогой альтернативы мэйнфремам; решение Sonic позволяет построить своего рода метакомпьютер для всего предприятия, но более дешевый. В итоге получается аналог мини-метакомпьютера: вместо дорогого коммутатора предлагается информационная магистраль предприятия Enterprise Service Bus.
Технология SonicXQ появилась не вдруг. У нее два достаточно хорошо известных источника. Первый - программное обеспечение промежуточного слоя на основе сообщений. Этот тип программного инструментария переживает настоящую реинкарнацию, особенно в связи с появлением Java Message Service от компании Sun Microsystems. О происходящем на этом фронте можно прочитать в , а более подробно о SonicMQ, непосредственном предшественнике SonicXQ, - в . Обе эти публикации сохраняют актуальность, но за прошедший год пейзаж корпоративного программного обеспечения заметно изменился, особенно под воздействием Web-служб. Еще год назад, когда готовились указанные публикации, представление о том, что такое Web-службы и каково их значение, было достаточно расплывчатым. За прошедшее время ситуация заметно прояснилась, и Web-службы следует назвать в качестве второго источника SonicXQ.
Enterprise Service Bus
Среди событий прошедшего года следует отметить появление в профессиональной терминологии нечто нового и непривычного. Одни, приверженцы лагеря Micrososft/IBM, называют это «оркестровкой» (orchestration) Web-служб, другие, из лагеря Sun/BEA, - «хореографией» (choreography) . Разгорается очередная битва в войне стандартов, за то, как лучше наладить согласованную работу корпоративных приложений с использованием Web-служб. Причина новой активности заключена в том, что всем, наконец, стало ясно: в сложившихся условиях исчерпаны возможности жестко связанных приложений, сложность систем стала слишком велика. Однако исходная схема распространения Web-служб с использованием построенных по стандарту UDDI репозиториев оказалась малоприменимой для корпоративных целей. В то же время, Web-службы и особенно их асинхронные ориентированные на документы версии предлагают реальный выход из «тупика сложности». С технической точки задача создания корпоративной инфраструктуры приложений с использованием слабосвязанных асинхронных процессов имеет несколько альтернативных решений.
Enterprise Service Bus, построенная на основе SonicXQ является одним из них. С помощью формируемой SonicXQ корпоративной магистрали реализуется распределенная архитектура, ориентированная на службы. ESB позволяет создавать контейнеры для размещения служб. Службы легко собрать и согласовать, поскольку упакованная в контейнер и являющаяся частью ESB служба представима другим частям ESB. При этом вся конструкция является виртуальной; реальная физическая сеть, в которой она «живет», может подвергаться изменениям без потери функциональности.
В процессе функционирования ESB одна или несколько связанных служб находятся в специальном контейнере (service container). Контейнеры являются средством для продвижения служб по распределенному процессу в соответствии с маршрутами сообщений (message itinerarу). Процедура прохождения сообщения выглядит следующим образом. Сообщение поступает на вход шины ESB. Здесь к нему добавляется маршрут, который позволяет организовать контентно-управляемое продвижение по распределенному процессу, этот процесс имеет децентрализованное управление. В рамках этого процесса сообщение проходит через ряд служб, достигая конечной точки, где извлекается из контейнера.
Для указания конечных точек могут быть использованы не физические, а логические имена. Установление соответствия между физическими и логическими именами (mapping) осуществляет специальный имеющийся в составе ESB механизм. Таким образом, в архитектуру изначально заложена способность к виртуализации; система может изменяться без модификации кода и разрушения действующих бизнес-процессов. Конфигурация допускает несколько уровней качества обслуживания (Quality of Service, QoS), гарантирующих надежное прохождение сообщений между приложениями. В общем случае, когда сообщение проходит весь свой маршрут, оно выходит за конечную точку получателя, а отправителю посылается подтверждающее получение сообщение. Достоинство распределенного процесса передачи сообщений на основе ESB заключается в том, что по своей логике он очень близок взаимодействию в реальном мире.
Основы: JCA и Web-службы
Предлагаемая в ESB интеграция приложений стала возможной благодаря появлению архитектуры соединений JCA от Sun Microsystems и SOAP, стандартного протокола для Web-служб. JCA, специально разработанная для преодоления сложностей, связанных с интеграцией приложений, предлагает стандартизированные методы для решения этой задачи. Корпоративная информационная система, построенная по принципам JCA, использует для доступа к приложениям интерфейс JDBC. Сегодня этот подход весьма популярен; большинство современных серверов приложений, в том числе, BEA WebLogic и IBM WebSphere поддерживают адаптеры JCA. Кроме того, многие поставщики пакетных решений намерены поддерживать JCA в будущих версиях своих продуктов.
Оригинальность использования Web-служб в SonicXQ заключается в том, как организован процесс «оркестровки» (или «хореографии»). В его основе лежит протокол SOAP, но наложенный на простой и масштабируемый формат сообщений. При этом SonicXQ Enterprise Service Bus обеспечивает совместимость и с асинхронной документальной моделью SOAP (document asynchronous model), так и с синхронной моделью SOAP, построенной по принципу вызова удаленных процедур (RPC). В SonicXQ службы описываются на языке WSDL, но WSDL непосредственно интегрирован Distributed Processing Framework. В результате служба может быть зарегистрирована во внешнем каталоге UDDI, а может и не быть, если в этом нет необходимости.
Технологию SonicXQ можно без всякого преувеличения назвать экстремальной: она собрала в себе целый ряд современных тенденций в корпоративных вычислениях. Но, пожалуй, самое интересное заключается в том, что она позволяет лучше понять, что такое Web-службы. Причем не на словах, а на деле.
Литература
1. Леонид Черняк. МОМ, второе рождение //
2. Валерий Кор жов. Почтальон для приложений //
3. Stuart J. Johnston, Web Services Wars Take Artistic Turn. Choreography or orchestration? XML Magazine, 2002, № 10/11
