USB-подобные универсальные порты для корпоративной сервисной шины (ESB): Часть 1. Проблемы современных ESB

Ознакомьтесь с базовыми функциями современных ESB и некоторыми связанными с ними проблемами

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

Уасим Рошен, ИТ-архитектор, IBM

Д-р Уасим РошенУасим Рошен (Waseem Roshen) — доктор наук Университета штата Огайо (г. Колумбус, США), имеющий более чем 18-летний практический опыт в сфере информационных технологий. В настоящее время д-р Рошен работает ИТ-архитектором в Центре изучения и распространения передовых методов архитектуры предприятия и технологий корпорации IBM. Он имеет богатый опыт в области распределенных вычислений, в том числе сервис-ориентированной архитектуры (SOA). Кроме того, он обладает опытом в сфере заказного проектирования, интеграции и J2EE (теперь известной как JEE). В настоящее время его интересы включают SOA и Web-сервисы, квантовые компьютеры и облачные вычисления. Д-р Рошен имеет более 60 публикаций и 37 патентов и является членом IEEE и Компьютерного сообщества IEEE. Он является автором книги “Интеграция предприятия на основе SOA: пошаговое руководство по интеграции приложений на основе сервисов”.



02.04.2012

Введение

Корпоративная сервисная шина (ESB) является ключевым компонентом инфраструктуры сервис-ориентированной архитектуры (SOA). ESB используется для опосредованного соединения приложений, использующих несовместимые формы сервисов, как показано на рисунке 1. Эти разные формы сервисов включают Web-сервисы, сервисы RESTful, асинхронные сервисы (например, сервисы, использующие MQ), сервисы на основе CORBA, сервисы на основе DCOM и Java RMI. Эти сервисы используют разные коммуникационные протоколы и формы сообщений. Например, Web-сервисы используют в качестве коммуникационного протокола HTTP, а в качестве формата сообщений – SOAP, в то время как асинхронные сервисы могут использовать в качестве коммуникационного протокола протокол MQ, а в качестве формата сообщений — XML.

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

Подключение приложений через ESB с помощью специальных портов
Applications connecting through an ESB

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

Базовые функции ESB

Этот раздел ознакомит вас с информацией о ESB. В нем дается краткое описание трех базовых функций и описываются проблемы подключения приложений с разнородными сервисами с применением двухточечных соединений.

Масштабирование соединений и маршрутизация

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

Подключение шести приложений через двухточечные соединения
Applications connecting in point-to-point approach

Как видите, в данном случае количество необходимых соединений равно 15. Это число равно числу пар приложений в схеме интеграции. Аналогичным образом можно подсчитать, что для десяти приложений потребуется 45 соединений. Таким образом, с ростом числа приложений число соединений быстро увеличивается в нелинейной пропорции. Это явление называется проблемой “волосяного шара”, поскольку оно способно застопорить любую сеть. Это можно выразить так: если предприятию нужно интегрировать N-е число приложений, то число необходимых двухточечных соединений определяется формулой:

N(N-1)/2

Это очевидно, поскольку число пар приложений тоже равно N(N-1)/2. Отсюда можно сделать вывод, что интеграция с применением двухточечных соединений для крупных предприятий непригодна, и для обеспечения лучшей масштабируемости нужно искать иное решение.

Корпоративная сервисная шина превосходно решает проблему масштабируемости подключений и потому прекрасно подходит для средних и крупных предприятий, нуждающихся в интеграции значительного числа приложений. Схема взаимодействия в корпоративной сервисной шине предполагает, что приложения непосредственно не взаимодействуют друг с другом. Вместо этого они подключаются к шине, и уже эта шина предоставляет средства соединения приложений между собой. Такое опосредованное взаимодействие иллюстрируется на рисунке 1, где показаны шесть приложений, взаимодействующих между собой через корпоративную сервисную шину. Самое важное, что нужно почерпнуть из рисунка 1, — это то, что в данном случае требуется всего шесть соединений. Это существенно меньше числа соединений, необходимых для объединения шести приложений по двухточечной схеме (15). Другой важный момент, который следует отметить, — число соединений равно числу интегрируемых приложений. Следовательно, если мы имеем десять приложений, нам понадобится всего десять соединений, что значительно меньше, чем требуется для объединения приложений по двухточечной схеме (45).

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

Несоответствие и преобразование протоколов

Проблема несоответствия коммуникационных протоколов возникает из-за того, что разные приложения на крупном предприятии обычно используют разные коммуникационные протоколы. Другими словами, в реальном мире наблюдается быстрое увеличение числа таких протоколов, включая протоколы HTTP, HTTPS, JRMP, IIOP и JMS. В связи с таким разрастанием часто наблюдается несоответствие протоколов приложения-потребителя сервиса и приложения-поставщика сервиса. Таким образом, не обладая возможностью преобразования протоколов, приложение-потребитель сервиса не может воспользоваться сервисом, предлагаемым приложением-поставщиком. Эта проблема иллюстрируется на рисунке 3.

Проблема несоответствия протоколов
Protocol Mismatch Problem

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

Несоответствие и преобразование форматов сообщений/данных

Другая проблема несовместимости связана с несоответствием форматов данных/сообщений. Эта проблема связана с тем, что иногда формат данных приложения-потребителя сервиса не совпадает с форматом данных приложения-поставщика. Это не позволяет приложениям взаимодействовать между собой (рисунок 4).

Проблема несоответствия форматов данных
Process Summary

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

Прочие функции

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

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

Проблемы имеющихся ESB

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

  • Во многих случаях, в связи с изменением требований или среды исполнения, приложение может изменить коммуникационный протокол. Однако это потребует и смены типа порта на стороне ESB, для чего почти наверняка понадобится создать порт другого типа. Очевидно, что на такую операцию потребуется время и ресурсы
  • Широко распространена ситуация, когда приложение использует несколько протоколов для реализации разных функций. Это характерно для системных приложений на языке COBOL, которые реализуют некоторые свои функции с помощью Web-сервисов и в то же время могут реализовать другие свои функции через протокол обмена сообщениями, такой как MQ. В этом случае тоже придется создавать новые типы портов на стороне ESB, чтобы использовать оба протокола, что очень неудобно, поскольку требует затрат времени и ресурсов.
  • Имеющиеся в настоящее время ESB очень трудно расширяются на новые коммуникационные протоколы по той причине, что для этого приходится вносить изменения как на стороне приложения, так и на стороне ESB. Причем на стороне ESB приходится создавать совершенно новый тип порта.
  • Поскольку каждое приложение должно подключаться к ESB через специальный порт, приходится прилагать некоторые усилия для настройки ESB на работу с этим приложением. Для этого может понадобиться создание нового типа порта, внедрение его в ESB и настройка ESB для работы с этим портом. Все это затрудняет подключение большого числа приложений через ESB и тем самым порождает проблемы масштабирования.
  • Кроме того, поскольку каждый порт нужно внедрять и настраивать отдельно, это усложняет обслуживание и обновление ESB.

Заключение

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

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=807945
ArticleTitle=USB-подобные универсальные порты для корпоративной сервисной шины (ESB): Часть 1. Проблемы современных ESB
publish-date=04022012