IBM WebSphere Developer Technical Journal: Создание Enterprise Service Bus с использованием WebSphere ESB - Часть 2

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Исходные тексты примера Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

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

27.07.2007

В первой части были представлены основные функциональные возможности, предоставляемые IBM® WebSphere® Enterprise Service Bus (ESB) для создания ESB, и пример бизнес-контекста, который мы будем использовать в данной серии статей, а также рассмотрены взаимоотношения между функциональностью SIBus WebSphere Application Server и WebSphere ESB. Во второй части рассказывается, как подключить клиентское J2EE™-приложение к ESB путем передачи сообщения по JMS, регистрации сообщения шиной ESB и направления его сервис-провайдеру, реализованному управляемым сообщениями bean-компонентом (message-driven bean - MDB). То есть, в данной статье продемонстрирована ESB-поддержка для инициатора запроса и провайдера JMS-сервиса.

Из IBM WebSphere Developer Technical Journal.

Введение

Исходную серию статей по WebSphere Application Server ESB мы начали примером, показывающим, как System Integration Bus (SIBus) работает в качестве JMS-провайдера по умолчанию для сервера приложений. В первой статье той серии было показано, как подключить клиентское J2EE-приложение (передавая простое текстовое JMS-сообщение) к провайдеру JMS-сервиса, выполняющемуся на сервере приложений и реализованному в виде управляемого сообщениями bean-компонента (MDB). В данной статье мы будем использовать этот же пример как образец для работы, но вместо передачи сообщения от клиента в очередь SIBus и последующего получения сообщения из этой очереди MDB-компонентом сервиса мы перенаправим его в компонент-посредник, работающий в WebSphere ESB.

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

В начало

Усовершенствованная архитектура

ESB позволяет создавать разделенные (decoupled) системы, предлагая интерфейсы виртуальных сервисов, означающих, что клиент не получает доступ к реальному сервис-провайдеру напрямую; вместо этого он обменивается сообщениями с ESB. ESB затем направляет сообщения к (или от) реальному сервис-провайдеру. Это истинно не только для Web-сервисов (то есть, сервисов, предоставляемых через связывание SOAP/HTTP), но и для любого другого сервиса. В нашем примере J2EE-приложение получает обычные текстовые сообщения из JMS-очереди. В контексте ESB мы видим это приложение как сервис-провайдера. Аналогично, мы предлагаем интерфейс сервиса клиентским JMS-приложениям.

Мы не будем тратить время на описание используемого в данном примере кода инициатора запроса и провайдера сервиса (этот код не отличается от любого типичного JMS-кода; в разделе "Ресурсы" приведены ссылки на обучающее руководство по JMS), а просто рассмотрим основные положения:

• Клиентское J2EE-приложение просто посылает сообщение, содержащее номер доставленного пакета.

• Поскольку код для передачи сообщения выполняется в клиентском J2EE-приложении, мы не кодируем жестко имена используемых JMS-ресурсов, а используем вместо этого пространство имен java:comp/env. Оба имени (одно для фабрики соединений, а другое для реальной очереди) связываются при помощи ссылок на ресурсы в дескрипторе развертывания клиентского приложения.

• Первоначально клиент был написан для передачи простого текстового сообщения, но будет обновлен для передачи XML-сообщения.

• Для MDB все даже проще: каждый MDB имеет метод onMessage(), активизирующийся сразу после постановки сообщения в очередь, которую прослушивает MDB, и он выводит сообщение в System.out.

Интересным аспектом является то, что перенаправляя сообщения через WebSphere ESB, мы разделяем клиентскую JMS-конфигурацию и MDB-конфигурацию – их обе можно настроить на общение с WebSphere ESB. Если MDB развернут на другом сервере, клиентское приложение менять не нужно. Поскольку сообщение проходит через WebSphere ESB, его можно обработать в компонентах-посредниках в ESB.

На рисунке 1 показана конфигурация, при которой JMS-инициатор запроса и MDB напрямую соединены через SIBus-очередь (описано в третьей части нашей предыдущей серии статей), в сравнении с тем, что мы собираемся сделать в данной статье.

В обновленной архитектуре обратите внимание на то, что мы используем две очереди: одну между клиентом и компонентом-посредником WebSphere ESB, а вторую - между компонентом-посредником и реальным адресатом (то есть, сервис-провайдером). На рисунке 1 показано также, что артефакты WebSphere ESB выполняются внутри WebSphere Application Server, обеспечивающего исполняющую систему JMS и содержащего управляемый сообщением компонент. Для простоты мы запускаем MDB на том же сервере, что и WebSphere ESB; в реальной среде MDB обычно выполняется на отдельном сервере, требующем дополнительных действий по настройке.

Компонент-посредник потока (mediation flow component) в WebSphere ESB представляет собой просто еще один тип компонента сервиса, определенный в Service Component Architecture (SCA). SCA требует определения интерфейса сервиса, описывающего оконечную точку сервиса на шине (интерфейса, который будет вызывать клиентское приложение). Наличие формального (WSDL) описания позволяет представить процесс обмена JMS-сообщениями в виде активизации сервисов. (Ссылка на руководство "Введение в SCA" приведена в разделе "Ресурсы".)

Обзор процесса создания и настройки ESB

Перед началом работы приведем обзор действий, которые вы выполните в данной статье. (Если вы предпочитаете минимизировать свою работу, данная статья предоставляет для загрузки EAR-файлы инициатора запроса и провайдера сервиса, файл замены проекта с готовым компонентом-посредником WebSphere ESB. Если вы выберете использование файла замены проекта, вам все равно понадобится настройка дескрипторов развертывания клиентского и MDB-приложения, а также самого сервера.)

1. Создание сервера WebSphere ESB.

2. Создание интерфейса сервиса. Создавая WSDL-описание интерфейса сервиса для передачи сообщений инициатором запроса в шину и для MDB, как провайдера сервиса, вы будете использовать WebSphere Integration Developer.

3. Создание компонента-посредника. Вы создадите модуль-посредник и компонент-посредник потока. Операции импорта и экспорта в компоненте-посреднике будут настроены на интерфейс сервиса, созданного на втором шаге, описанном выше. Для импорта и экспорта будут созданы JMS-связывания. Компонент-посредник будет просто регистрировать сообщение при его прохождении.

4. Настройка инициатора запроса сервиса. Вы измените оригинальное тестовое клиентское приложение, которое передавало простую текстовую строку, на передачу XML-сообщения. Вы настроите JMS-конфигурацию клиентского приложения и сервера WebSphere Application Server, на котором выполняется WebSphere ESB и к которому подключается клиент. Как часть конфигурации будут использоваться SIBus-очереди, генерируемые WebSphere ESB.

5. Настройка провайдера сервиса. Вы измените конфигурацию EAR MDB, используя SIBus-очереди, сгенерированные WebSphere ESB.

6. Выполнение полного тестирования.

Версии

Используйте последние доступные версии WebSphere Integration Developer и WebSphere Enterprise Service Bus. При подготовке данной статьи мы использовали WebSphere Integration Developer V6.0.1.2 и WebSphere ESB V6.0.1.2. В конце декабря 2006 появится пакет обновления до версии 6.0.2 со значительными улучшениями функциональности и производительности, поэтому используйте его, как только он станет доступным.

В начало

A. Создание сервера WebSphere ESB

Создайте тестовый сервер в WebSphere Integration Developer, который будете использовать для тестирования.

1. В панели Servers программы WebSphere Integration Developer выберите New => Server.

2. Выберите WebSphere ESB Server v6.0, примите значения по умолчанию и нажмите кнопку Finish.

Если вы уже создали тестовый сервер, можете повторно использовать его, но знайте, что в нем могут быть определены артефакты, которые могут вызывать конфликты.

В начало

B. Создание интерфейса сервиса

Компонент сервиса взаимодействует с внешними партнерами через операции импорта и экспорта. В нашем случае операция экспорта взаимодействует с клиентским JMS-приложением, а импорта - с MDB.

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

Давайте начнем с интерфейса. В оригинальном примере мы просто передаем строку (уведомление о получении посылки "package received"). В нашей обновленной версии мы хотим формализовать это, определив XML-схему, содержащую определение структуры сообщения. Это облегчит обработку сообщения в компоненте-посреднике, а также в конечном получателе. Мы будем использовать редактор бизнес-объектов и редактор интерфейсов в WebSphere Integration Developer для создания интерфейса. Редактор бизнес-объектов используется для описания содержимого сообщений, а редактор интерфейсов описывает, как сообщение заключается в конверт операции. Эти графические инструментальные средства генерируют схему и WSDL, описывающие интерфейс и которые можно предоставить инициаторам запросов и провайдерам сервиса.

Приведенные здесь инструкции немногословны и предполагают, что вы использовали эту программу ранее и знакомы с основами ее использования. Статьи и учебные руководства, предоставляющие подробные указания по созданию артефактов в WebSphere Integration Developer, перечислены в разделе "Ресурсы".

1. Откройте WebSphere Integration Developer в перспективе Business Integration.

2. Создайте новый модуль-посредник под названием PackageReceivedModule. Модуль-посредник служит контейнером для компонента-посредника (и содержащейся в нем логики) и отображается в развертываемый EAR-проект.

3. Откройте редактор бизнес-объектов, выбрав узел Data Types в навигационном дереве. Нажмите правой кнопкой мыши для создания нового бизнес-объекта.

4. В мастере New Business Object назовите бизнес-объект PackageReceivedBO и оставьте значения по умолчанию для всех других полей. Нажмите кнопку Finish.

5. После открытия редактора бизнес-объектов добавьте атрибут message и выберите для него тип string. Окончательное определение выглядит так, как показано на рисунке 3.

   
   
   Рисунок 3. Определение бизнес-объекта
   
   
   

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

6. Сохраните изменения.

7. Теперь вы готовы создать реальный интерфейс сервиса. Нажмите правой кнопкой на узел Interfaces в навигационном дереве и выберите Create a new Interface.

8. Назовите новый интерфейс PackageReceivedIF и сохраните все оставшиеся значения установленными по умолчанию. Нажмите кнопку Finish. Откроется редактор интерфейсов.

9. В редакторе интерфейсов выберите Add One Way Operation и назовите ее package_received.

10. Добавьте входной параметр, нажав Add Input, и назовите его packageReceivedBO с типом бизнес-объекта PackageReceivedBO (найдите этот тип, который создали выше). Интерфейс должен выглядеть так, как показано на рисунке 4.

    
    
    Рисунок 4. Определение интерфейса
    
    
    

11. Сохраните изменения.

Для просмотра сгенерированного WSDL-файла выберите PackageReceivedIF и Open with => XML Source Page Editor. Аналогично вы можете открыть схему PackageReceivedBO.

Теперь все готово для создания реального компонента-посредника.

В начало

C. Создание компонента-посредника

В данном разделе описывается процесс создания необходимого модуля-посредника с нуля. Однако, если вы хотите пропустить эти шаги, можете импортировать готовый модуль, включенный в поставляемый с данной статьей файл для загрузки, который содержит файл замены проекта WebSphere Integration Developer под названием PackageReceivedModule.zip. Этот файл содержит полное готовое решение.

1. В WebSphere Integration Developer выполните двойной щелчок кнопкой мыши на пиктограмме компоновки PackageReceivedModule , чтобы открыть редактор компоновки. Создается компонент-посредник потока по умолчанию, называемый Mediation1. Переименуйте этот компонент в PackageReceivedMediation.

2. Затем, необходимо создать операцию импорта, которая соединяет компонент-посредник с реальным сервис-провайдером (в нашем случае с MDB). Перетяните объект импорта из палитры прямо на компонент-посредник потока. Переименуйте импорт в MDBImport. Нажмите правой кнопкой мыши на операции импорта и выберите Add Interface.

3. В следующем диалоговом окне выберите интерфейс PackageReceivedIF, который вы создали ранее. На самом деле, здесь вы назначаете созданный вами интерфейс для использования при отправке сообщения в MDB; сообщение, отправляемое из ESB, должно соответствовать этому интерфейсу.

4. Соедините операцию импорта с компонентом-посредником потока при помощи инструмента wire (нажмите кнопку OK в любом всплывающем окне, которое запрашивает, нужно ли генерировать ссылку на компонент-посредник потока).

5. Сервис-провайдер реализован в виде MDB, и мы собираемся взаимодействовать с ним по JMS; следовательно, необходимо определить JMS-связывание для импорта. Нажмите правой кнопкой мыши на операции импорта и выберите вариант меню Generate Binding... => JMS Binding. В появившемся диалоговом окне мы определяем набор критичных значений, как показано на рисунке 5.

   
   
   Рисунок 5. Настройка JMS-сервиса импорта
   
   
   

   • JMS messaging domain - Оставьте значение по умолчанию, Point-to-Point, потому что мы используем специфическую очередь для передачи сообщений, в отличие от pub-sub topic.

   • Configure new messaging provider resources - Выбор этого варианта означает, что все связанные JMS-ресурсы, включая очереди и их соответствующие SIBus-артефакты, будут генерироваться автоматически при развертывании модуля-посредника на сервере.

   • Serialization type - Сообщения, проходящие через компонент-посредник, преобразуются в бизнес-объект, когда принимаются в export, и преобразуются в соответствующий выходной формат, когда выходят из import. Для JMS необходимо указать системе, какой класс использовать для выполнения этого преобразования. WebSphere ESB предоставляет пару готовых классов, которые принимают специально отформатированные XML-сообщения и преобразуют их в (и из) формат бизнес-объекта. В нашем случае вы будете использовать класс, принимающий JMS TextMessage и преобразующий его в бизнес-объект. Текстовое сообщение должно придерживаться конкретного формата, для того чтобы класс converter мог определить правильный бизнес-объект для использования. Мы вернемся к этой теме ниже.

     (WebSphere ESB V6.0.2 будет поддерживать JMS-сообщения, не содержащие XML, которые можно отображать в бизнес-объект и которые могут иметь произвольное содержимое. Более подробное описание процесса создания собственной логики сериализации JMS-содержимого приведено в статье "Создание мощной и надежной SOA при помощи JMS и WebSphere ESB".)

   • JMS Function Selector - Помните, мы объясняли, как мы рассматриваем приложение, принимающее JMS-сообщение в виде сервиса? Это означает, что оно поддерживает одну или несколько операций. В случае JMS-сервиса одна очередь может использоваться повторно для нескольких операций. Следовательно, вы должны указать системе, какой тип сообщения в какую операцию сервиса отображать. WebSphere ESB делает это путем установки поля JM-заголовка, называемого TargetFunctionName, которое содержит имя активизируемой операции с исходящим сообщением. Принимающее приложение, в нашем случае PackageReceivedMDB, может теперь различать операции, проверяя этот заголовок. Однако в нашем сценарии мы не будем использовать это, поскольку MDB все равно поддерживает только одну операцию. Следовательно, снимите отметку с этого флажка.

6. После установки всех значений так, как описано выше, нажмите кнопку OK для генерирования связывания.

7. Выберите import в редакторе компоновки и перейдите в закладку Properties внизу экрана. В виде Properties выберите закладку Summary. Ваш вид должен выглядеть так, как показано на рисунке 6.

   
   
   Рисунок 6. Импорт свойств
   
   
   

   Обратите внимание на то, что имя очереди передачи установлено в PackageReceivedModule/MDBImport_SEND_D. Это имя было сгенерировано при создании связывания, а соответствующие артефакты будут генерироваться при развертывании. Это имя очереди понадобится позже при конфигурировании MDB.

8. Осталось сделать еще одну вещь, а именно, определить соответствующий JMSType для исходящего сообщения. MDB только обрабатывает сообщения, в которых поле заголовка JMSType установлено в package_received (это определено в дескрипторе развертывания MDB). Определите JMSType в закладке Method bindings вида Properties, как показано на рисунке 7.

   
   
   Рисунок 7. Закладка Method bindings
   
   
   

9. Вернитесь в редактор компоновки, перетащите элемент export на канву (слева от компонента-посредника) и назовите его JMSClientExport. Этот элемент export будет отображать компонент-посредник тестовому JMS-клиенту.

10. Добавьте интерфейс PackageReceivedIF к элементу export и подключите его к компоненту-посреднику потока. При этом также создастся интерфейс для компонента-посредника потока. Подключите этот элемент export к PackageRecievedMediation, используя инструмент wire.

11. Подобным образом мы должны сгенерировать JMS-связывания для экспорта, поскольку так клиент будет взаимодействовать с компонентом-посредником. Нажмите правой кнопкой мыши на export и выберите пункт меню Generate Binding... => JMS Binding. Отображаемое диалоговое окно выглядит почти так же, как и для import. Укажите те же определения, за исключением одного, как показано на рисунке 8.

    
    
    Рисунок 8. JMS-связывания для экспорта
    
    
    

12. Для поля Serialization type выберите Business Object XML using JMS TextMessage. Экспорт будет использовать класс селектора JMS-функции по умолчанию. Как описывалось выше, входящее JMS-сообщение должно отображаться в конкретную операцию интерфейса сервиса, и класс селектора по умолчанию ожидает, что поле JMS-заголовка TargetFunctionSelector установлено в имя активизируемой операции. Вы обновите клиентское приложение далее и установите это поле JMS-заголовка.

13. Нажмите кнопку OK для генерирования связывания и взгляните на его вид Properties.

14. Выберите закладку Binding - Endpoint configuration, а в ней закладку JMS Destinations. Разверните Receive Destination Properties. Вид должен выглядеть так, как показано на рисунке 9.

    
    
    Рисунок 9. Вид Receive Destination Properties
    
    
    

    Обратите внимание на то, что имя очереди, принимающей сообщения для компонента-посредника, установлено в "PackageReceivedModule.JMSClientExport_RECEIVE_D". Мы настроим клиентское приложение на использование этого имени очереди.

15. После сохранения всех изменений можно приступить к последнему шагу - созданию реализации компонента потока. Нажмите правой кнопкой мыши на PackageReceivedMediation в редакторе компоновки и выберите Generate Implementation. Откроется редактор потока компонентов-посредников.

16. В нашем примере мы ограничимся очень простой логикой: будем регистрировать в log-файле каждое сообщение, проходящее через компонент-посредник, что поможет нам визуализировать прохождение сообщений через ESB. Для этого подключите операцию package_received интерфейса PackageReceivedIF слева (он представляет интерфейс - подключенный к экспорту - компонента-посредника потока) к операции package_received интерфейса PackageReceivedIFPartner (представляет ссылку - подключенную к импорту - компонента-посредника потока). В нижней части редактора перетащите примитив-посредник Message Logger на канву и подсоедините поток сообщений так, чтобы каждое сообщение проходило через регистратор, как показано на рисунке 10.

    
    
    Рисунок 10. Подключение каждого сообщения к регистратору
    
    
    

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

В начало

D. Настройка инициатора запроса сервиса

Для завершения этой задачи необходимо выполнить следующие основные действия:

• Импортировать тестовое клиентское J2EE-приложение в WebSphere Integration Developer.
• Настроить имя очереди в дескрипторе развертывания на очередь, сгенерированную экспортом модуля-посредника WebSphere ESB.
• Обновить код приложения на передачу XML-сообщения и установить JMSHeader TargetFunctionName, что требуется для WebSphere ESB.
• Создать фабрику JMS-соединений на сервере WebSphere ESB, используемую клиентом для получения соединений.

Теперь подробно:

1. Импортируйте тестовое клиентское приложение, расположенное в файле PackageReceivedClient.ear. Это обновленный EAR-файл, основанный на используемом в нашей предыдущей статье. Обновления рассмотрены ниже.

   1. При выборе Import => EAR, возможно, отобразится запрос на разрешение Base J2EE Support (если вы еще не сделали этого). В таком случае нажмите кнопку OK и перейдите в перспективу J2EE.
   2. Во время импорта убедитесь, что имя EAR-проекта равно PackageReceivedClientEAR, и выберите WebSphere ESB Server v6.0 в качестве целевого сервера. Новый проект Application Client под названием PackageReceivedClient содержит файл Main.java с кодом тестового клиента.

2. Затем измените имя очереди, в которую будет передаваться тестовое сообщение, поскольку вместо передачи сообщения в очередь, прослушиваемую MDB, мы хотим, чтобы сообщение передавалось в экспорт WebSphere ESB. На это имя есть ссылка в дескрипторе развертывания для проекта клиентского приложения, поэтому выполните на нем двойной щелчок клавишей мыши. Дескриптор развертывания содержит ссылку с названием jms/PackageReceivedQueue. Измените его имя WebSphere Bindings => JNDI name на PackageReceivedModule/JMSClientExport_RECEIVE_D, являющееся именем очереди WebSphere ESB, сгенерированной для его экспорта.

3. В оригинальном тестовом клиентском приложении мы передавали в очередь обычную строку. В нашем обновленном сценарии мы передадим строку в формате XML, представляющую бизнес-объект, который мы определили в модуле-посреднике. Это позволит сериализатору (serializer) по умолчанию преобразовывать это XML-сообщение в бизнес-объект, которым мы можем управлять в компоненте-посреднике. Исходя из созданной ранее схемы определения интерфейса и бизнес-объекта, XML-строка должна выглядеть примерно так:

   <?xml version="1.0" encoding="UTF-8"?> <ns:package_received xmlns:ns="http://PackageReceivedModule/PackageReceivedIF"> <packageReceivedBO> <message>Package Received - 24595023</message> </packageReceivedBO> </ns:package_received>

   
   

   Следовательно, обновленный файл Main.java отправляет это новое сообщение:

   // private final static String messageText = "Package Received - 24595023"; private final static String messageText = "<?xml version=\"1.0\" encoding=\"UTF-8\"?> " + "<ns:package_received xmlns:ns=\"http://PackageReceivedModule/PackageReceivedIF\"> " + " <packageReceivedBO>" + " <message> Package Received - 24595023</message> " + " </packageReceivedBO> " + " </ns:package_received> ";

   
   

   Более того, вспомните, что в WebSphere ESB вы используете селектор JMS-функций по умолчанию, который выбирает для вызова соответствующую операцию в интерфейсе сервиса. Необходимо добавить поле JMS-заголовка (TargetFunctionName) для отображения операции, которую вы активизируете (package_received):

   ... // Создать MessageProducer и TextMessage MessageProducer queueSender = session.createProducer(q); TextMessage outMessage = session.createTextMessage(); outMessage.setText(messageText); // установить имя целевой операции для селектора JMS-функций WESB по умолчанию outMessage.setStringProperty("TargetFunctionName", "package_received"); // Установить тип и адресат, отправить outMessage.setJMSType("package_received"); outMessage.setJMSDestination(q); ...

   
   

   Заметьте, что мы уже сделали все изменения в коде, поэтому вам ничего не нужно делать.

4. Необходимо также выполнить определенную настройку JMS для разрешения клиентскому J2EE-приложению (инициатору запроса сервиса) подключаться к серверу WebSphere ESB при помощи его JMS-ресурсов. Откройте консоль администратора тестового сервера (запустите сервер, если он еще не запущен) и перейдите в вид Servers. Нажмите правой кнопкой мыши на WebSphere ESB v6.0 server и выберите Run administrative console.

5. Клиентское J2EE-приложение использует фабрику JMS-соединений для подключения к JMS-очереди. Вы создадите эту фабрику соединений на сервере и затем разрешите клиентскому приложению получать ее. Клиентское приложение открывает соединение с JMS-очередью на этом сервере. Обратите внимание на то, что клиентское приложение использует специальный порт для взаимодействия с механизмом обмена сообщениями на сервере, который по умолчанию равен 7276. Однако тестовый сервер, выполняющийся внутри инструментальной программы, будет, по всей вероятности, использовать другой порт, поэтому вы должны настроит фабрику соединений на корректный номер порта. Для определения используемого вашим сервером номера порта, перейдите в консоль администратора и нажмите на узел Servers => Application Servers.... Выберите сервер под названием server1. На экране должна отобразиться информация о данном сервере со ссылкой Ports, как показано на рисунке 11.

   
   
   Рисунок 11. Поиск порта, используемого сервером
   
   
   

   Выберите ссылку Ports для извлечения списка портов, использующихся вашим сервером. Номер порта, используемого для JMS-взаимодействия, называется SIB_ENDPOINT_ADDRESS. На рисунке 12 номер порта равен 7278.

   
   
   Рисунок 12. Порты, используемые серверами
   
   
   

   Запомните этот номер порта.

6. Теперь, в консоли администратора перейдите к Resources => JMS Providers => Default Messaging. Нажмите ссылку JMS connection factory и кнопку New. Введите следующие значения:

   • Name: TheConnectionFactory
   • JNDI name: jms/TheConnectionFactory
   • Bus name: SCA.APPLICATION.esbCell.bus
   • Provider endpoints: localhost:7278:BootstrapBasicMessaging

   Определение Provider endpoints должно содержать номер порта для вашего механизма обмена сообщениями (который вы видели раньше); в нашем примере, он равен 7278. (Конкретное имя ячейки может отличаться в зависимости от индивидуальной конфигурации, поэтому имя SCA-приложения по умолчанию может быть разным для разных установок.)

   Более подробная информация по подключению к нестандартному порту JMS-провайдера приведена в WebSphere Application Server Information Center.

   Оставьте значения всех остальных полей установленными по умолчанию и нажмите кнопку OK.

7. Сохраните изменения и закройте консоль администратора.

В начало

E. Настройка провайдера сервиса

Как упоминалось ранее, провайдер сервиса, получающий JMS-сообщение, реализуется с использованием управляемого сообщениями bean-компонента. Мы будем использовать такое же приложение, которое использовали в предыдущих сериях статей; соответствующий EAR-файл (enterprise archive) входит в материалы для загрузки, поставляемых с данной статьей.

Для выполнения данной задачи вы должны выполнить следующие основные шаги:

• Импортируйте EAR с MDB в WebSphere Integration Developer.

• Настройте дескриптор развертывания на прослушивание очереди, сгенерированной элементом import модуля-посредника WebSphere ESB.

• Создайте ActivitationSpec для MDB на сервере WebSphere ESB (поскольку это тот же сервер, который используется для выполнения MDB EAR).

Теперь подробно:

1. В WebSphere Integration Developer перейдите в перспективу J2EE. Перед импортом файла PackageReceived.ear запустите тестовый сервер WebSphere ESB в WebSphere Integration Developer, если он еще не запущен.

   1. При импорте EAR-файла убедитесь, что имя вашего EAR-проекта - PackageReceivedEAR.
   2. Выберите WebSphere ESB Server v6.0 в качестве целевого сервера для проекта. Оставьте все остальные поля установленными в значения по умолчанию.
   3. После завершения импорта вы должны увидеть новый EJB-проект PackageReceived с одним MDB PackageReceived.

2. Измените дескриптор развертывания MDB и настройте его на получение сообщений из очереди, в которую их помещает WebSphere ESB. Выполните двойной щелчок кнопкой мыши на дескрипторе развертывания, чтобы открыть его в редакторе.

3. В закладке Bean для PackageReceived MDB удалите значение Message destination. Необходимо также изменить WebSphere Bindings => Destination JNDI name очереди, из которой принимаются сообщения, на PackageReceivedModule/MDBImport_SEND_D, сгенерированную WebSphere ESB для элемента import модуля-посредника. (Если вы посмотрите на значение messageSelector, то увидите, что оно установлено вами в JMSType в связывании элемента import компонента-посредника.) Дескриптор развертывания должен выглядеть так, как показано на рисунке 13.

   
   
   Рисунок 13. Обновленный дескриптор развертывания MDB
   
   
   

   Если после импорта появляются дополнительные ошибки компиляции, выберите Project => Clean... для повторной компиляции проекта и устранения этих ошибок.

4. Также необходимо выполнить определенную настройку JMS на сервере, на котором выполняется MDB. Таким сервером (в целях упрощения) является наш сервер WebSphere ESB. Откройте консоль администратора тестового сервера, перейдя в вид Servers. Нажмите правой кнопкой мыши на сервер WebSphere ESB v6.0 и выберите Run administrative console (предполагается, что сервер уже запущен; если нет, - сделайте это).

5. Приложение провайдера сервиса использует управляемый сообщениями компонент для приема сообщений из ESB. Этот MDB, помимо всего прочего, настроен на использование спецификации активации, содержащей определение очереди. Все это стандартные процедуры J2EE, и поэтому мы должны настроить спецификацию активации перед развертыванием приложения. В консоли администратора разверните Resources => JMS Providers => Default messaging.

   1. В правой нижней части экрана нажмите на ссылку под названием JMS activation specification.
   2. На следующем экране нажмите кнопку New и введите следующие значения для новой спецификации активации:
      • Name: PackageReceivedActivationSpec
      • JNDI name: eis/PackageReceivedActivationSpec
      • Destination JNDI name: PackageReceivedModule/MDBImport_SEND_D
      • Bus name: SCA.APPLICATION.esbCell.bus

   (Опять же, реальное имя шины может быть иным в зависимости от вашей индивидуальной конфигурации.)

   
   
   Рисунок 14. Спецификация активации
   
   
   

6. Оставьте все остальные поля установленными в значения по умолчанию и нажмите кнопку OK. Сохраните изменения.

Это все, что нужно сделать для провайдера сервиса.

В начало

F. Выполнение полного тестирования

Теперь вы готовы развернуть весь пример на тестовом сервере и выполнить его.

1. В WebSphere Integration Developer в главном меню выберите Project => Clean... => Clean all projects => OK. Это действие гарантирует целостность кода, сгенерированного для проекта. В виде Servers нажмите правой кнопкой мыши на WebSphere ESB Server v6.0 и выберите Add and remove projects....

2. В появившемся диалоговом окне выберите сначала PackageReceivedModuleApp, а затем нажмите кнопку Add >.

3. Затем добавьте PackageReceivedEAR на сервер и нажмите кнопку Finish. Добавляя их в этом порядке, вы гарантируете, что PackageReceivedModuleApp загружается первым. Это необходимо, поскольку он настраивает адресаты, используемые MDB EAR. Если проекты загружаются в неправильной последовательности, при загрузке ActivationSpec могут появиться ошибки, сообщающие о том, что адресат не найден.

   
   
   Рисунок 15. Добавление доступных проектов в настроенный проект
   
   
   

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

4. После завершения публикации остановите и запустите ваш сервер, используя кнопки Restart или Stop и Start в панели инструментов. После перезагрузки оба приложения должны запуститься без проблем. Одним из способов убедиться в успешном запуске приложений является загрузка консоли администратора и выбор Applications => Enterprise Applications. Она должна отобразить список приложений, включая оба установленные, и все они должны быть запущены (см. рисунок 16).

   
   
   Рисунок 16. Состояние приложений
   
   
   

5. Для запуска тестового клиентского приложения выберите Run => Run... в главном меню WebSphere Integration Developer.

6. В следующем диалоговом окне выберите конфигурацию WebSphere v6.0 Application Client, затем нажмите кнопку New.

7. В этой новой конфигурации выберите WebSphere ESB Server v6.0 в поле WebSphere runtime, введите PackageReceivedClientEAR в поле Enterprise application и PackageReceivedClient в поле Application client module. Также отметьте флажок Enable application client to connect to a server и выберите в поле Use specific server вариант WebSphere ESB Server v6.0, как показано на рисунке 17.

   
   
   Рисунок 17. Выбор конфигурации
   
   
   

8. Теперь вы можете нажать Run для запуска клиентского приложения. После завершения его работы в консоли отобразится следующая информация:

   
   
   Рисунок 18. Сообщения о состоянии приложения в консоли
   
   
   

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

9. Вы можете переключать консоль для различных процессов, отображая выходную информацию клиентского приложения или серверного процесса:

   
   
   Рисунок 19. Альтернативная консоль
   
   
   

   Переключите консоль на вывод выходной информации процесса тестового сервера.

10. Компонент-посредник потока и MDB выполняются на одном и том же сервере, поэтому их выходная информация будет отображаться в консоли одновременно.

    
    
    Рисунок 20. Сообщения консоли для компонента-посредника потока и управляемого сообщениями компонента
    
    
    

Выводимая информация, относящаяся к базе данных, указывает на то, что выполнился примитив регистратора (logger) сообщения, и сообщения System.out пришли из MDB.

В начало

Заключение

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

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

В следующей статье мы рассмотрим сценарий, более ориентированный на использование Web-сервисов, прежде чем продолжить объединение двух миров (JMS/MQ и Web-сервисов). Оставайтесь на связи!

Да, еще одно: в третьей части данной серии статей мы будем использовать новую версию 6.0.2 обеих программ (WebSphere ESB и WebSphere Integration Developer)!

В начало

Остальные статьи серии

• Часть 1: Введение в использование WebSphere ESB, или WebSphere ESB против SIBus
• Часть 3: Добавление Web-сервисов и поддерживающих свойств

В начало

Загрузка

	Информация о методах загрузки

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи "IBM WebSphere Developer Technical Journal: Building an Enterprise Service Bus using WebSphere ESB, Part 2".
  
  
• Создание ESB при помощи WebSphere Application Server V6, часть 3: Простой пример обмена сообщениями JMS.
  
  
• Введение в IBM Enterprise Service Bus.
  
  
• Руководство по JMS.
  
  
• Страница продукта WebSphere Enterprise Service Bus.
  
  
• Начало работы с WebSphere Enterprise Service Bus и WebSphere Integration Developer.
  
  
• Разработка специализированных объектов-посредников для WebSphere Enterprise Service Bus.
  
  
• Создание мощной и надежной SOA при помощи JMS и WebSphere ESB.
  
  
• Динамическая маршрутизация во время выполнения в WebSphere Enterprise Service Bus.
  
  
• Руководство: Активизация Web-сервиса JMS-клиентом.
  
  
• Service Component Architecture.
  
  
• Справочник: Создание SOA с использованием WebSphere Messaging.

Об авторах

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

		Андре Тост (Andre Tost) является старшим техническим сотрудником в организации по проблемам интегрированных корпоративных решений (Software Group's Enterprise Integration Solutions), где он помогает клиентам IBM создавать сервисно-ориентированную архитектуру. Он уделяет большое внимание технологии Web-сервисов. До своего назначения на текущую должность он десять лет занимал различные посты в отделах по разработке программного обеспечения IBM для разблокировки, усовершенствования и архитектуры, в последнее время в группе разработчиков деловых приложений для WebSphere. Он родился в Германии, но сейчас живет и работает в Рочестере, штат Минессота. Свободное время он любит проводить со своей семьей, а также является страстным футбольным болельщиком и игроком.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало