Из IBM WebSphere Developer Technical Journal.

Введение

На протяжении данной серии статей мы охватили большое количество материала по теме Enterprise Service Bus (ESB). Мы установили некоторые из основных характеристик ESB, рассмотрели пример бизнес-сценария и присущую ему проблему, для которой ESB мог бы предложить хорошее решение. Мы решили реализовать несколько ключевых конструктивных возможностей, включенных во многие реализации ESB, воспользовались поддержкой системы обмена сообщениями в IBM WebSphere Application Server V6 (в качестве примера) для реализации некоторой нужной нам бизнес-функциональности. Сюда входит поддержка базового обмена JMS-сообщениями, использование Web-служб, объектов-посредников и, наконец, обмен сообщениями с разными протоколами. В данной статье мы кратко пересмотрим все эти этапы, чтобы показать, как объединяются индивидуальные части для создания одного основанного на ESB решения.

Кроме того, мы поговорим о том, чего мы можем ожидать в будущем. За последнее время были сделаны анонсы нескольких новых продуктов IBM и новых версий продуктов, имеющих отношение к Enterprise Service Bus. Мы познакомим вас с некоторыми новыми представленными технологиями и объясним, как они соотносятся и дополняют SIBus, которую мы использовали в этой серии. К ним относятся появление новой и захватывающей спецификации программной модели, представленной IBM и несколькими другими производителями: Service Component Architecture (SCA – компонентная архитектура служб).

В начало

Пересмотр серии статей

Часть 1: Пересмотр Service Integration Bus

В первой части этой серии мы рассмотрели базовую функциональность, предлагаемую так называемой Service Integration Bus (SIBus) в WebSphere Application Server V6. SIBus предлагает базовые ESB-возможности, предоставляя "адресаты", которые служат в качестве целей для сообщений, переданных в шину. Для управления сообщениями, достигающими адресата (например, для изменения их формата или маршрута), SIBus использует понятие объектов-посредников, каждый из которых состоит из одного или нескольких обработчиков-посредников, имеющих доступ к сообщению во время его прохождения по шине. Сообщения преобразуются в Service Data Objects (SDO), как только они достигают адресата, который разрешает общий доступ к содержимому сообщения. SDO – это один из краеугольных камней программной модели IBM SOA. Он предлагает одну общую форму доступа к данным для множества различных источников данных, облегчая разработку кода (и обработку!), работающего с данными. Естественно, это полезно для реализации ESB, в которой становится возможным разрабатывать код, обращающийся к сообщениям независимо от источника, создавшего это сообщение. IBM недавно опубликовала еще одну ключевую часть программной модели (предназначенную для разрешения общего доступа к службам), называемую Service Component Architecture (компонентная архитектура служб). SCA и SDO формируют общую модель для работы со службами и предлагаемыми ими данными. Более подробно об этом далее.

Часть 2: Пересмотр бизнес-сценария

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

Здесь важно помнить, что требование бизнес-уровня напрямую не запрашивает применения ESB. Мы предположили, что Posts-R-Us решила начать работы по сервис-ориентированной архитектуре для создания набора служб, непосредственно решающих бизнес-проблемы. ESB обеспечивает уровень косвенности и разделения между потребителями служб и провайдерами служб, что позволяет лучше распределить задачи. Другими словами, логика интеграции (например, преобразование протокола, преобразование формата сообщения) отделена от бизнес-логики (то есть, реальной функцией, которую выполняет служба). ESB может предоставить виртуальные службы, которые могут эффективно заключить существующую логику приложения в основанный на стандартах интерфейс службы. Следовательно, ESB помогает преодолеть разрыв между бизнес-проблемой (предоставляя гибкий набор служб, которые могут реализовать необходимые бизнес-процессы) и существующей IT-структурой со всеми ее протоколами, форматами и существующими традиционными приложениями.

В конечном итоге, это приводит к архитектуре высокого уровня, показанной на следующем рисунке, который взят из второй части нашей серии статей:

Часть 3: Пересмотр JMS Messaging

Большинство ESB будут нуждаться в поддержке большого количества форматов сообщений и протоколов, включая Web-службы и обмен сообщениями, например IBM WebSphere MQ и JMS. Мы реализовали примеры с использованием JMS-поддержки и, позже, MQ-поддержки для демонстрации важности протоколов, отличных от Web-служб, и способов применения этих ключевых протоколов с SIBus. Мы определили поддержку системы обмена JMS-сообщениями как одно из основных требований нашего решения, приведенного в третьей части. JMS-протокол обеспечивает качество обслуживания (Qualities of Service), часто требуемое для интеграции систем, и, следовательно, является общим ESB-требованием в среде Java 2 Enterprise Edition (J2EE). Например, JMS обеспечивает поддержку гарантированной доставки сообщений, поддерживает транзакции и предоставляет API для шаблона сообщений публикация/подписка. Кроме того, это стандартный API, являющийся частью J2EE, который поддерживается многими серверами приложений на многих различных платформах, обеспечивая, таким образом, хорошую способность к взаимодействию для гетерогенных сред.

Messaging Resources в WebSphere Application Server V6 является JMS-провайдером по умолчанию для сервера приложений. JMS-приложения могут напрямую подключиться к адресатам SIBus, передавая и принимая сообщения из JMS-очередей, делая SIBus прозрачной для потребителей и отправителей сообщений.

Часть 4: Пересмотр объектов-посредников

Как упоминалось выше, объекты-посредники являются компонентами SIBus, разрешающими манипулирование сообщениями. Мы рассмотрели детальный пример создания обработчика-посредника и его развертывания в объекте-посреднике на WebSphere Application Server V6 в четвертой части этой серии статей. Когда бы сообщение ни достигло адресата, передано ли оно было от JMS-клиента или явилось результатом активизации web-службы, оно преобразовывается в SDO DataGraph и перенаправляется в любой объект-посредник, связанный с этим адресатом. Обработчики-посредники, содержащиеся в объекте-посреднике, могут читать и изменять сообщение, контекстную информацию, и даже маршрут (то есть, куда сообщение направится далее). Это позволяет вам эффективно применить логику интегрирования для удовлетворения большого разнообразия требований, включая зависящую от содержимого маршрутизацию, ведение журналов регистрации и преобразование данных.

Часть 5: Пересмотр Web-служб

В пятой части мы рассмотрели поддержку Web-служб в WebSphere Application Server V6 SIBus. Одной из важных возможностей ESB является поддержка множества протоколов, как протоколов, основанных на системе обмена сообщениями, так и Web-служб. Web-службы становятся главной технологией для реализации служб и обеспечения возможности взаимодействия между гетерогенными системами. Независящий от реализации, основанный на стандартах и описанный на WSDL интерфейс разъединяет технологию реализации провайдера и потребителя. Использование ESB между провайдером и потребителем обеспечивает возможность добавить дополнительную степень разъединения:

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

В предыдущих статьях мы рассмотрели процесс создания ESB как промежуточного уровня для взаимодействия служб с поддержкой определенного качества обслуживания (quality of services - QoS) для управления сообщениями и маршрутизацией (просто перечислили ключевые функции).

WebSphere Application Server V6 и SIBus полностью поддерживают взаимодействие Web-служб, используя протоколы "SOAP over HTTP" и "SOAP over JMS". SIBus использует так называемые исходящие службы для направления сообщений в существующие Web-службы и входящие службы для обеспечения взаимодействия Web-служб с инициатором запроса службы. За кулисами она использует встроенную поддержку Web-служб WebSphere Application Server V6, которая основана на соответствующих J2EE-стандартах для Web-служб. С исходящими и входящими службами в SIBus могут использоваться расширенные функции Web-служб, такие как обработчики JAX-RPC и WS-Security. Информация по этим возможностям доступна на developerWorks и WebSphere Application Server Information Center.

Часть 6: Пересмотр способности к взаимодействию WebSphere MQ

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

WebSphere Application Server V6 имеет функциональную возможность, называемую MQLink, которая позволяет SIBus выглядеть просто как еще один менеджер очереди WebSphere MQ. Это дает возможность плавной интеграции SIBus с любой существующей функциональностью WebSphere MQ, сводя влияние от ее интеграции на существующие традиционные приложения к минимуму. Для использования MQLink необходима и настройка SIBus, и настройка менеджера очереди MQ, которые рассматривались в шестой части.

Часть 7: Пересмотр переключения протоколов сообщений

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

В нашем примере Posts-R-Us реализует общую повторно используемую службу (Web-службу) и делает ее доступной через ESB. ESB может также сделать эту службу доступной для клиентов, которые не могут прямо использовать предложенный интерфейс SOAP/HTTP. Здесь становится очевидным одно из преимуществ ESB. Мы продемонстрировали, как вы можете использовать SIBus для подключения к очереди сообщений MQ, которая взаимодействует с клиентскими приложениями и существующей Web-службой, предлагающей реальную бизнес-функцию. Эту повторно используемую службу необходимо создать один раз, и, опять же, мы имеем распределение задач между разработкой соответствующей бизнес-логики и разрешением этой функции быть доступной на предприятии.

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

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

В начало

ESB-стратегия IBM развивается

IBM недавно анонсировала новый продукт WebSphere Enterprise Service Bus (WebSphere ESB), WebSphere Message Broker V6, и новую программную модель SOA, составленную из Service Component Architecture и Service Data Objects.

IBM продолжает верить в то, что корпоративная шина служб является архитектурным шаблоном. Пользователи реализуют свои собственные ESB на основе своих требований. Поскольку каждый бизнес отличается от других, требования для соединения процессов, приложений и данных тоже отличаются. Фактически, есть возможность построить шины служб из разнообразных ESB-продуктов, включая WebSphere Application Server и его функциональность SIBus, WebSphere Message Broker, и WebSphere ESB. WebSphere ESB является на самом деле относящимся к ESB продуктом, способствующим созданию конкретных экземпляров этого шаблона.

WebSphere ESB и WebSphere Message Broker предлагают много уже готовых функций объектов-посредников, инструменты для визуального конструирования и другие возможности, лежащие далеко за пределами базовой поддержки системы обмена сообщениями в SIBus. WebSphere ESB плотно интегрирована с WebSphere Process Server, и ее модель объектов-посредников использует SCA и Service Message Objects (расширение SDO, включающее в граф данных заголовки сообщения и контекст).

IBM, в сотрудничестве с производственными партнерами, представила высокоуровневую абстракцию для конструирования SOA-приложений, позволяющую вам собирать компоненты без знания технологий, которые используются этими компонентами, и затем настраивать реализации компонентов в вашей системе через свойства метаданных. Служебный компонент должен содержать в себе всю логику, назначенную для этого компонента. Между компонентами могут быть определены связи, поддерживающие позднее связывание с реализациями других компонентов; разработчики интеграционных решений сосредоточивают внимание на связывании компонентов вместе. SDO дополняет SCA. Они предоставляют общий метод, помогающий пользователям подключаться к данным, расположенным в различных местах и имеющим различный формат, облегчая использование разработчиками программных интерфейсов без необходимости их кодирования.

Так что же WebSphere ESB, WebSphere Message Broker V6 и SCA означают для будущего SIBus? SIBus продолжает быть JMS-провайдером по умолчанию и базовой платформой системы обмена сообщениями для WebSphere Application Server. WebSphere ESB и WebSphere Process Server добавляют функциональность к WebSphere Application Server и используют SIBus для базовой системы обмена сообщениями. Вы можете рассматривать SIBus как базовую водопроводную сеть для WebSphere ESB и WebSphere Process Server. IBM подтверждает свои обязательства перед пользователями, которые используют в настоящее время SIBus в качестве ядра реализации своей ESB. Со временем SIBus будет эволюционировать таким образом, чтобы ее программная модель объединялась с моделью WebSphere ESB.

При разработке ESB выбор ESB-продукта должен основываться на требованиях. WebSphere Application Server с его функцией SIBus предоставляет фундамент для создания Enterprise Service Bus, как было рассмотрено в данной серии статей. Вы должны попробовать SIBus и другие более развитые ESB-продукты для определения того, что лучше всего подходит для создания вашей ESB.

В начало

Заключение

В этой серии статей мы рассмотрели процесс создания базовой функциональности Enterprise Service Bus с использованием WebSphere Message Resources, появившихся в WebSphere Application Server V6, (также известна как SIBus). В этой финальной части мы подвели итоги по сценарию, требованиям и функциональным возможностям, рассмотренным в этой серии статей, и вкратце рассказали о будущем технологий IBM ESB.

Ресурсы

Научиться

• Оригинал статьи Building an Enterprise Service Bus with WebSphere Application Server V6 -- Part 8.
  
  

• Статьи этой серии:

  • Часть 1. Введение в WebSphere V6 Messaging Resources
  • Часть 2. Постановка задачи и шина
  • Часть 3. Простой пример обмена JMS-сообщениями
  • Часть 4. Улучшение шины при помощи объектов-посредников
  • Часть 5. Простой пример поддержки Web-служб в SIBus
  • Часть 6. Простой обмен сообщениями между SIBus и WebSphere MQ
  • Часть 7. Переключение протоколов сообщений
  
  
• Преимущества ESB
  
  
• WebSphere Enterprise Service Bus
  
  
• WebSphere Message Broker
  
  
• Модель программирования SOA для реализации Web-служб, Часть 4: Введение в IBM Enterprise Service Bus
  
  
• WebSphere Application Server Information Center
  
  
• Хорошее введение в SDO
  
  
• Спецификация Service Component Architecture
  
  
• WebSphere Application Server V6 Information Center
  
  
• Apache Xerces
  
  

Получить продукты и технологии

• Загрузите пробное программное обеспечение WebSphere
  
  

Обсудить

• Обсудите данную тему на форуме developerWorks
  
  

Об авторах

Рэйчел Рейниц (Rachel Reinitz) является старшим специалистом-консультантом по информационным технологиям и программным службам IBM для WebSphere, специализируется на Web-службах. Рэйчел консультирует пользователей и ISV по вопросам использования сервис-ориентированной архитектуры и Web-служб для решения их технических и бизнес-задач. Она разработала курс обучения расширенным Web-службам IBM и часто выступает на конференциях. Рэйчел также опытный инструктор по экстремальному программированию (eXtreme Programming – XP) и использует принципы XP четыре года. Она живет в Bay Area, Калифорния, любит туризм, общение и международные путешествия.

Андре Тост (Andre Tost) работает старшим сотрудником технической службы в подразделении WebSphere Business Development, где помогает стратегическим партнерам IBM интегрировать их приложения с WebSphere. Уделяет особое внимание технологии Web-служб семейства продуктов WebSphere. До этого он десять лет занимался различными вопросами разработки и архитектуры программного обеспечения IBM, в частности программой WebSphere Business Components. Приехав из Германии, он поселился в в Рочестере, Миннесота. В свободное время любит заниматься своей семьей и, когда есть возможность, играет и смотрит футбол.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Пересмотр серии статей
• ESB-стратегия IBM развивается
• Заключение
• Ресурсы
• Об авторах
• Комментарии