IBM WebSphere Developer Technical Journal: Построение Enterprise Service Bus с использованием WebSphere Application Server V6 – Часть 1

Введение в WebSphere V6 Messaging Resources

Это первая статья в серии статей, в которых рассматривается использование нового механизма обмена сообщениями в IBM® WebSphere® Application Server V6 для создания Enterprise Service Bus (корпоративная сервисная шина), ключевой части инфраструктуры SOA.

Рэйчел Рейниц, старший специалист-консультант по информационным технологиям, IBM 

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



Андре Тост, старший сотрудник технической службы, IBM 

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



26.01.2005

Введение

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

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

Кроме Messaging Resources в WebSphere Application Server V6 имеются и другие функциональные возможности (такие как EJB-клиенты или компоненты MBeans JMX), которые можно использовать при построении ESB. Мы не будем рассматривать их в данной серии статей. Существуют также и другие программные продукты IBM, включая продукты WebSphere, которые часто используются при построении ESB и обладают некоторыми аналогичными возможностями, а также возможностями, отсутствующими в WebSphere V6 Messaging Resources.

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


Что такое WebSphere V6 Messaging Resources?

WebSphere Application Server V6 имеет совершенно новый мехианизм обмена сообщениями, написанный на Java™. С точки зрения J2EE™ этот механизм выступает как JMS-провайдер по умолчанию для сервера приложений. Это означает, что любой компонент приложения, использующий службу обмена сообщениями J2EE (например, управляемые событиями компоненты), может пользоваться возможностями этого механизма. Продолжают поддерживаться и другие JMS-провайдеры, в том числе WebSphere MQ. В нашем сценарии ESB мы будем использовать WebSphere MQ и WebSphere V6 Messaging Resources совместно для обеспечения ESB-функциональности.

WebSphere V6 Messaging Resources осуществляет также комплексную поддержку работы с очередями, pub/sub (издатель/подписчик) и Web-служб, предоставляя таким образом платформу для нескольких ключевых схем обмена сообщениями и взаимодействия. Например, поддерживаются как синхронный обмен сообщениями "запрос/ответ", так и асинхронный однонаправленный обмен. Вводится в действие термин "интегрированная шина"; авторы и получатели сообщений взаимодействуют посредством шины, а не прямо друг с другом. Этот промежуточный уровень предоставляет возможность централизованного управления и контроля в одной локальной сущности без влияния на компоненты приложения. Ниже мы рассмотрим этот принцип более детально.

Ключевой возможностью новой платформы является способность использовать множество протоколов передачи и приема сообщений из шины. Например, сообщение может быть передано в шину как запрос Web-службы на основе протокола "SOAP over HTTP". Шина может затем перенаправить это сообщение JMS-потребителю как управляемый сообщениями компонент. Другой пример: вы можете передать сообщение в шину через WebSphere MQ и перенаправить его в компонент EJB как обычный вызов EJB-метода. Производители и получатели сообщений, таким образом, полностью разделены, включая сообщения и транспортные протоколы. Такое разделение является основным преимуществом ESB.

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


Три основных компонента: шина, адресат и объекты-посредники

В своей основе механизм обмена сообщениями состоит из трех главных компонентов:

  • Шина работает как главный транспортный механизм для сообщений. Как отмечалось ранее, производители и потребители сообщений не обмениваются сообщениями напрямую; они посылают и принимают сообщения через шину. Приложения работают так, как будто они взаимодействуют с одной сущностью – шиной; фактически же шина может быть распределена по многим процессорам и машинам, обеспечивая масштабируемость (подробнее об этом далее). Администраторы могут также сконфигурировать несколько экземпляров шины для отдельных приложений;
  • Каждая шина содержит список адресатов. Адресат представляет собой логическое назначение каждого сообщения, передаваемого по шине. Адресат может быть представлен как обобщение очереди и темы. Таким образом, происходит разделение отправителя и получателя сообщений: сообщение передается адресату, из которого получатель (потребитель) будет его извлекать. Естественно, сообщение может быть извлечено несколькими получателями в сценарии pub/sub.

    WebSphere V6 Messaging Resources предоставляет устойчивую и гибкую поддержку системы обмена сообщениями, включая способность устанавливать различное качество обслуживания для различных адресатов, например, формируя политику продолжительности жизни (персистентности) сообщения.

    Важно также, что сообщение может быть перенаправлено от одного адресата другому перед его извлечением получателем. Это дает возможность внедрения любой логики маршрутизации сообщений в шину без воздействия на отправителя и получателя. Такая функциональность дает возможность реализовать одну из ключевых, основанных на SOA ESB, характеристик: распределение задач. Обработка (или маршрутизация) сообщения производится шиной и не загромождает бизнес-логику;
  • Третий компонент, объекты-посредники, содействует распределению задач. Объект-посредник представляет собой часть кода, которая всегда связана с адресатом. Посреднический код работает с сообщением, когда оно проходит через этого адресата. Для написания такого кода предоставляется программная модель, основанная на общем Java-представлении сообщения; Java-объекты представляют сообщение и его свойства.

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

Двумя наиболее традиционными функциями объектов-посредников являются:

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

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

На рисунке 1 показаны основные концепции адресата и объекта-посредника.

Рисунок 1. Адресат и объект-посредник
Рисунок 1. Назначение и объект-посредник

Web-службы

Web-службы описаны в большом количестве литературы по Enterprise Service Bus и Service Oriented Architecture. Web-службы широко распространены и являются ключевой технологией для SOA, в основном благодаря своей независимости от платформы и языка программирования. Web-службы уже стали почти элитой в мире J2EE, особенно с появлением Java API для Web-служб в J2EE Version 1.4 (поддерживается в WebSphere Application Server V6).

По своей сути технология Web-служб – это обмен сообщениями между приложениями, так что не удивительно, что WebSphere V6 Messaging Resources обеспечивает первоклассную поддержку Web-служб. Отправитель сообщения может быть просто клиентом Web-служб, а потребитель сообщения может быть провайдером Web-службы.

Консоль администратора WebSphere Application Server поддерживает WebSphere V6 Messaging Resources и предоставляет набор мастеров для использования WSDL-файлов (Web Services Description Language) служб и генерирования артефактов (специализированных прослушивателей и адресатов) в шине. Эти мастера могут получать сообщения Web-служб от инициаторов запроса Web-служб и/или передавать эти сообщения провайдерам Web-служб.

Поддерживаются Web-службы "SOAP over HTTP" и "SOAP over JMS". Для представления на шине клиента и провайдера Web-служб используются адресаты. Сообщения Web-служб могут обрабатываться в коде объектов-посредников. Следовательно, WebSphere V6 Messaging Resources дает возможность управлять и контролировать сообщения Web-служб (включая организацию динамической маршрутизации и преобразования) в шине так, как будто это просто другой тип сообщений.

Еще раз. Целью является разделение инициатора запроса и провайдера службы, для того чтобы в шине можно было ввести дополнительное управление и управление качеством обслуживания. Важно то, что это не влияет на программную модель Web-служб. Web-служба в шине может быть активизирована так же, как и любая другая Web-служба на других платформах. Например, вы (как и раньше) можете вызвать Web-службу через JAX-RPC. Отличие состоит в том, что сообщение SOAP-запроса будет передано адресату по шине, а не прямо в службу.

С точки зрения разработки, клиент не догадывается о различиях. Единственным изменением для клиента является изменение URL-адреса с фактической службы на адресат службы в шине. Нет изменений и у провайдера службы, служба может быть активизирована по шине или напрямую клиентом Web-службы. Бизнес-логика службы не меняется. Развертываемые через WSDL в шине Web-службы не ограничиваются J2EE-службами, и могут быть любыми WS-I-совместимыми Web-службами на любой платформе.

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


Множество протоколов, множество API

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

Главный принцип – это разделение и распределение задач. Клиент не должен знать о том, где расположен ресурс, какой протокол он поддерживает и какой нужно использовать API для передачи ему сообщения. Всем этим занимается шина. Конфигурирование ресурсов в виде (виртуальных) адресатов на шине делает эту цель возможной. Сообщения могут быть переданы адресату с использованием "SOAP over HTTP", или MQ, или "RMI over IIOP" (перечислены только лишь некоторые из возможностей). Это же сообщение может быть извлечено своим потребителем по любому из этих протоколов, независимо от того, как оно попало в шину. Это будет важной темой для обсуждения в следующих статьях.


Общий формат сообщения

Обработка сообщений в шине независимым от протокола способом требует того, чтобы формат представления данных тоже не зависел от протокола. Для механизма передачи сообщений WebSphere в качестве такого формата был выбран Service Data Objects (SDO). Детальное описание SDO выходит за рамки данной статьи, поэтому обратитесь, пожалуйста, к документам и статьям, обсуждающим эту тему и перечисленным в разделе Ресурсы.

Вкратце, SDO описывает способ представления данных способом, независимым от источника этих данных; например, данные могут прийти от JMS-клиента, или от Web-службы. Для доступа к SDO существует набор Java API, а для представления данных о сообщении, таких как, например, длины, формата, информации в заголовке сообщения и т.д., применяется SDO-модель. Для манипулирования данными в сообщении объекты-посредники в шине используют программную SDO-модель.

SDO используется для того, чтобы не зависеть от протокола. Шина не преобразовывает содержимое сообщения в каноническую модель данных (например, XML-теги); если это необходимо – можно написать пользовательский код объекта-посредника.


Сервер приложений + система обмена сообщениями = ESB?

Функциональные возможности системы обмена сообщениями, рассмотренные в данной статье, поставляются как часть WebSphere Application Server V6. Наличие данной технологии в сервере приложений приводит к мощной комбинации возможностей: вы можете построить, скомпоновать и разместить устойчивые и масштабируемые приложения и службы, что обеспечивается ведущим J2EE сервером приложений, и в то же время иметь усовершенствованную технологию обмена сообщениями, лежащую в основе любой сервис-ориентированной архитектуры.

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

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

Наконец, общедоступны все инструментальные средства как механизма обмена сообщениями, так и сервера приложений. С сервером приложений поставляется Application Server Toolkit, предлагающий все необходимые средства для компоновки, развертывания и отладки J2EE и приложений обмена сообщениями. Rational® Application Developer V6 также предлагает большой набор средств для разработки приложений, включая инструментарий для Web-служб, J2EE, XML-разработки, баз данных, UML-визуализации и многое другое.


Заключение

В данной статье представлено общее описание нового механизма обмена сообщениями в WebSphere Application Server V6 и Enterprise Service Bus. WebSphere V6 Messaging Resources базируется на трех основных компонентах: интегрированной шине, адресатах, как средстве виртуализации подключаемых к шине ресурсов, и объектах-посредниках, которые могут маршрутизировать и управлять прохождением сообщений по шине. Во второй статье серии мы рассмотрим начало работы с простым сценарием, настройку шины и адресатов, а также использование JMS для подключения к шине. Оставайтесь на связи.

Ресурсы

Комментарии

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=WebSphere
ArticleID=107664
ArticleTitle=IBM WebSphere Developer Technical Journal: Построение Enterprise Service Bus с использованием WebSphere Application Server V6 – Часть 1
publish-date=01262005