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

Добавление Web-сервисов и поддерживаемых свойств

После обсуждения ключевых функциональных возможностей WebSphere ESB и описания процесса обмена сообщениями через JMS в предыдущих статьях данной серии, мы расширим набор используемых технологий IBM® WebSphere® ESB, добавив сценарий Web-сервисов. Более того, мы рассмотрим две новые возможности, появившиеся в версии Version 6.0.2 продуктов WebSphere ESB и WebSphere Integration Developer.

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

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



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

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



04.06.2007

Из IBM WebSphere Developer Technical Journal.

Введение

Наш сценарий включал однонаправленную отправку сообщения в серверное приложение через JMS, показывающего, что посылка была доставлена клиенту. Мы отобразили его в "однонаправленную" операцию сервиса (то есть, операция имеет запрос, но не имеет ответа) и выполнили для него JMS-связывание. Далее мы откроем синхронное взаимодействие между инициатором запроса и провайдером сервиса через операцию "запрос-ответ" (то есть, имеется ответ на каждый запрос). Наш сервис будет использовать в качестве протокола SOAP/HTTP-связывания. Как и в предыдущем случае, мы будем направлять каждое сообщение через Enterprise Service Bus, реализованную в WebSphere ESB V6.0.2, для разделения инициатора запроса и провайдера сервиса. Инициатор запроса и провайдер сервиса не беспокоятся о прохождении сообщения по ESB и ничего не знают о маршрутизации или регистрации в ESB.

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


Развитие сценария

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

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

Как обычно, компонент-посредник потока (mediation flow component) взаимодействует со своими клиентами и с реальным провайдером сервиса через операции экспорта и импорта соответственно. На рисунке 1 показана архитектура системы.

Рисунок 1. Архитектура сценария примера
Рисунок 1. Архитектура сценария примера

Провайдер сервиса

Здесь и далее мы не будем описывать пошаговые инструкции, а призываем вас импортировать готовые EAR-файлы, включенные в раздел "Загрузка". Мы выделим важные участки каждого приложения при создании завершенного сценария примера.

Для нашего примера необходим провайдер сервиса, принимающий переменную trackingNumber в качестве входного параметра и возвращающий структуру packageStatus с информацией о посылке.

  1. Для работы с тестами, приведенными в данной статье, необходимо убедиться в корректной настройке тестового сервера. Выполните двойной щелчок на WebSphere ESB Server v6.0 в виде Servers и убедитесь, что выбран вариант Run server with resources on Server (см. рисунок 2). Это должно быть сделано до запуска сервера и развертывания какого-либо EAR-архива приложения данной статьи.

    Рисунок 2. Конфигурация тестового сервера
    Рисунок 2. Конфигурация тестового сервера
  2. Вы можете найти пример провайдера сервиса в файле PackageSatusServiceEAR.ear, включенном в материалы для загрузки, поставляемые с данной статьей. Импортируйте этот файл в WebSphere Integration Developer V6.0.2 и выберите WebSphere ESB Server v6.0 в качестве Target server. Для выполнения сервисов мы используем тот же экземпляр WebSphere Application Server, на котором установлена WebSphere ESB; в реальной среде сервисы, вероятнее всего, будут работать на отдельном сервере.

  3. В перспективе J2EE вы увидите новый Web-проект под названием PackageStatusService. Обратите внимание на то, что он содержит WSDL-файл PackageTrackingService.wsdl с определением сервиса. Если вы откроете этот WSDL-файл в редакторе интерфейсов, то сможете увидеть, что в нем определена операция запрос-ответ под названием getPackageStatus, как показано на рисунке 3.

    Рисунок 3. Интерфейс PackageTrackingService
    Рисунок 3. Интерфейс PackageTrackingService
  4. Перейдите к реальному классу реализации, называемому PackageTrackingServiceSoapBindingImpl.java в пакете postsrus.service. Если вы откроете этот класс в Java-редакторе программы, то сможете увидеть, что в нашем примере обрабатываются два номера маршрута, а именно "123" и "456". Все остальные номера приводят к возникновению исключительной ситуации. Мы будем использовать эту информацию позже при тестировании сценария.

  5. Другим интересным классом, расположенным в этом же пакете, является PackageStatus.java, содержащий структуру данных, возвращаемую как результат активизации операции сервиса и состоящую из четырех свойств:

    package postrus.service;
    
    public class PackageStatus  {
        private java.util.Calendar actualDeliveryDate;
        private java.lang.String location;
        private java.util.Calendar projectedDeliveryDate;
        private java.lang.String status;
    
        public PackageStatus() {
        }
    ...
    }

    Обратите внимание на то, что время и дата доставки представлена свойствами с типом java.util.Calendar. Позже вы увидите, как они отображаются в элементы типа <xsd:dateTime> в нашей XML-схеме.

  6. Теперь вы можете протестировать этот сервис, для того чтобы убедиться в корректном развертывании и функционировании. Для этого запустите тестовый сервер WebSphere ESB 6.0.2 в инструментальной программе, затем используйте пункт меню Add and remove projects... для развертывания приложения PackageStatusServiceEAR на сервере.

  7. После развертывания и запуска приложения вы захотите использовать программу тестирования Web-сервисов WebSphere Integration Developer. Разрешите функциональность Web-сервисов в WebSphere Integration Developer, развернув Workbench => Capabilities в Preferences и отметив флажок Web Service Developer. Теперь, щелкните правой кнопкой мыши на файле PackageStatusService.wsdl и выберите Web Services => Test with Web Service Explorer, как показано на рисунке 4.

    Рисунок 4. Выбор варианта Web Services Explorer
    Рисунок 4. Выбор варианта Web Services Explorer

    Отобразится вид Web Service Explorer, позволяющий протестировать Web-сервис без генерирования реального тестового клиентского приложения.

  8. Нажмите ссылку операции getPackageStatus, введите 123 в качестве номера маршрута и затем нажмите кнопку Go. Назначения портов на тестовом сервере могут отличаться, поэтому при возникновении ошибки соединения выберите PackageTrackingServiceSoapBinding в Web Services Explorer, и вы сможете добавить другую оконечную точку. Попробуйте установить порт в значение 9081 или просмотрите настройки вашего тестового сервера для определения корректного порта. Вы должны увидеть выводимую информацию в консоли сервера, указывающую на то, что сервис был вызван, и возвращен объект PackageStatus (см. рисунок 5).

    Рисунок 5. Web Services Explorer
    Рисунок 5. Web Services Explorer
  9. Затем, импортируйте файл PackageStatusServiceBackupEAR.ear в WebSphere Integration Developer и выберите WebSphere ESB в качестве целевого сервера. Измените при необходимости порт оконечной точки. Данный проект содержит идентичный набор Java-классов и других артефактов, а также определенный в нем Web-сервис, содержащий операцию getPackageStatus. Другими словами, это точная копия сервиса, который мы только что рассматривали; единственным отличием является то, что он развернут по другому адресу оконечной точки и имеет другое выражение System.out, указывающее на вызов "backup service".

  10. Вы можете добавить этот проект на сервер WebSphere ESB и протестировать его с Web Services Explorer. Проверьте его работу, щелкните правой кнопкой мыши на WSDL-файл в проекте PackageStatusBackupService. После выполнения теста вы должны увидеть следующую строку в консоли сервера, указывающую на вызов резервного сервиса:

    [1/22/07 10:52:59:422 CST] 00000048 SystemOut     O Package status 
    request in backup service for tracking number 456

Модуль-посредник

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

  1. Мы сохранили модуль как файл Project Interchange под названием PackageStatusModule.zip. После импорта этого файла перейдите в перспективу Business Integration в WebSphere Integration Developer. В модуле PackageStatusModule вы должны увидеть файл PackageStatusService в разделе Interfaces. Это тот же WSDL-файл, который мы использовали в провайдере сервиса. Другими словами, модуль-посредник будет предоставлять такой же интерфейс, что и оригинальный сервис, поэтому в ESB не нужно преобразование. В Data Types обратите внимание на определение PackageStatus с полями, возвращаемыми из сервиса.

  2. Теперь откройте схему компоновки для модуля в редакторе Assembly. Здесь нет ничего необычного; отображается компонент-посредник потока, элементы export и import (см. рисунок 6).

    Рисунок 6. Схема компоновки
    Рисунок 6. Схема компоновки
  3. Выберите PackageStatusServiceImport и перейдите в вид Properties. В закладке Binding можно увидеть, что указан адрес оконечной точки реализации сервиса, который вы развернули ранее. Обратите внимание на то, что номер порта установлен в значение 9082. Если ваш тестовый сервер использует порт 9081, здесь можно изменить номер порта. Аналогично, если вы выберете PackageStatusExport, то увидите, что с ним связан Web-сервис с новым адресом оконечной точки. Этот адрес вы будете использовать в Web Services Explorer позднее при тестировании готового решения.

  4. Выполните двойной щелчок кнопкой мыши на PackageStatusMediation, чтобы открыть редактор Mediation Flow. Поскольку компонент-посредник потока был создан ранее, больших сюрпризов нет: каждое сообщение запроса и ответа направляется через примитив-посредник MessageLogger и регистрируется в базе данных по умолчанию.

    Рисунок 7. Компонент-посредник потока
    Рисунок 7. Компонент-посредник потока

    Возможно, вы помните, что в свойствах примитива MessageLogger можно определить XPath-выражение, указывающее на то, какую часть сообщения нужно регистрировать. Можно изменить это в закладке Details вида Properties. Значением свойства Root по умолчанию является "/body", означающее, что регистрируется все тело сообщения. Для нашего примера мы изменили это свойство на "/body/getTrackingStatus/trackingNumber" для регистрации только номера маршрута.

Поддерживаемые свойства

Сейчас мы начнем использовать новую функциональную возможность версии 6.0.2 WebSphere ESB, называемую поддерживаемые свойства (promoted properties). В более ранних версиях единственным способом изменить свойство, например, Root примитива MessageLogger, была загрузка модуля в WebSphere Integration Developer, изменение свойства и повторное развертывание всего модуля на сервере. В версии 6.0.2 свойства, которые "поддерживаются" ("promoted"), можно также изменить в консоли администратора во время исполнения. В виде Properties имеется новая закладка Promoted Properties, позволяющая выбрать свойства, специфичные для примитива-посредника, которые можно сделать изменяемыми. Каждый примитив-посредник имеет специфический набор свойств, которые могут поддерживаться.

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

  1. Откройте вид Properties для примитива RequestMessageLogger в потоке и выберите вид Promoted Properties (см. рисунок 8).

    Рисунок 8. Поддерживаемые свойства
    Рисунок 8. Поддерживаемые свойства

    Обратите внимание на то, что для каждого поддерживаемого свойства указывается имя псевдонима. Таким образом, при наличии нескольких свойств в одном и том же модуле с одинаковыми именами, можно различать их в консоли администратора. В данном случае мы назвали свойство RequestMessageLogger.root. Если вы проверите примитив регистратора сообщений в очереди ответов, то заметите, что мы поддерживаем такое же свойство, но с другим псевдонимом, а именно ResponseMessageLogger.root. Поддерживаемые свойства с одинаковым псевдонимом будут совместно использовать одно и то же значение.


Завершение решения

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

  1. Добавьте PackageStatusModuleApp к вашему тестовому серверу. После запуска приложения перейдите в перспективу J2EE и найдите файл с названием PackageStatusExport_PackageTrackingServiceHttp_Service.wsdl в проекте PackageStatusModule в разделе Other Projects. Этот файл был сгенерирован как часть процесса создания связываний Web-сервисов для экспорта модуля-посредника. Щелкните правой кнопкой мыши на файле и выберите Web services => Test with Web Services Explorer.

  2. Протестируйте активизацию ESB-сервиса с номером маршрута 123. Результат должен быть такой же, как и прежде, просто на этот раз вы должны увидеть больше выводимой информации в консоли сервера, поскольку активизируется примитив-регистратор. По умолчанию примитив регистрирует сообщения в базе данных Cloudscape®. Позднее мы проверим, какие элементы регистрируются.

  3. Но сначала откройте консоль администратора тестового сервера, щелкнув правой кнопкой мыши на нем в виде Servers и выбрав Run administrative console. В консоли администратора перейдите на страницу SCA Modules, как показано на рисунке 9.

    Рисунок 9. Страница SCA Modules
    Рисунок 9. Страница SCA Modules
  4. Нажмите ссылку на модуль PackageStatusModule. На следующей странице нажмите Module Properties в Additional Properties, а на следующей странице обратите внимание, как отображаются два свойства, которые мы ранее указали поддерживаемыми, а также на их значения:

    Рисунок 10. Свойства модуля
    Рисунок 10. Свойства модуля
  5. Измените свойство RequestMessageLogger.root на "/body". Нажмите кнопку OK и сохраните изменения. Выйдите из системы и закройте окно консоли администратора.

  6. Теперь выполните этот же тест в Web Services Explorer. Но на этот раз используйте номер маршрута "456". Это поможет вам увидеть разницу между регистрируемыми сообщениями.

  7. После выполнения теста остановите сервер, для того чтобы снять блокировку базы данных и получить возможность исследовать зарегистрированные сообщения. Используйте программу cview, расположенную в каталоге [каталог установки WebSphere Integration Developer]\runtimes\bi_v6\cloudscape\bin\embedded. Запустите программу, выберите пункт меню File => Open и найдите базу данных EsbLogMedDB, расположенную в каталоге [каталог установки WebSphere Integration Developer]\pf\esb\databases. Откройте таблицу MSGLOG и исследуйте ее содержимое, используя закладку Data. Окно должно выглядеть примерно так, как показано на рисунке 11.

    Рисунок 11. Программа cview
    Рисунок 11. Программа cview

Остановка сервера для просмотра зарегистрированных сообщений нужна только потому, что мы используем в качестве базы данных Cloudscape. В реальной рабочей среде использовалась бы база данных промышленного уровня (например, DB2®), и остановка сервера не понадобилась бы.

Изменение адреса оконечной точки

Ранее вы развернули два экземпляра провайдера сервиса - один основной PackageStatusService и один дополнительный PackageStatusBackupService. Существует много ситуаций, когда нужно иметь возможность легко переключить оконечную точку вызываемого сервиса, например, при переключении со среды разработки на тестовую среду. Так как же перенаправить сообщения на резервный сервис без изменения модуля в WebSphere Integration Developer (что потребовало бы повторного развертывания)? Есть два метода, один из которых мы опишем.

  1. Можно динамически направить сообщение в новый адрес оконечной точки, вставив дополнительный примитив (то есть, примитив MessageElementSetter) в поток. Этот примитив может обновить заголовок контекста, заставляя сообщение передаваться по адресу, отличному от настроенного в связываниях элемента import. Можно по желанию комбинировать это действие с поиском в реестре, например, WebSphere Registry and Repository (для которого имеется дополнительный новый примитив в Version 6.0.2 WebSphere ESB и WebSphere Integration Developer). Описание подробной работы этого метода выходит за рамки данной статьи, но дополнительную информацию, вместе с подробным сценарием, можно найти в разделе "Улучшения динамической маршрутизации" в WebSphere Enterprise Service Bus V6.0.2.

  2. Можно изменить адрес оконечной точки SCA-модуля в консоли администратора сервера. Если вы остановили сервер, перезапустите его, затем запустите консоль администратора и откройте страницу SCA Modules, как описано выше. Выберите модуль PackageStatusModule и разверните узел Imports в Module components (см. рисунок 12).

    Рисунок 12. Module components
    Рисунок 12. Module components

    Нажатие ссылки Binding откроет страницу, позволяющую переопределить URL оконечной точки, использующийся для импорта. Измените его на URL оконечной точки резервного сервиса - http://localhost:9082/PackageStatusServiceBackup/services/PackageTrackingService. Как и прежде, мы предполагаем, что ваш тестовый сервер использует порт 9082. Если это не так, необходимо также обновить URL и использовать корректный порт.

    Наконец, нажмите кнопку OK и сохраните изменения. После этого выполните тест повторно; вы должны увидеть в консоли сервера выводимую информацию для резервного сервиса.


Заключение

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

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

Наконец, вы увидели, как можно использовать консоль администратора для изменения адреса оконечной точки, используемого элементом import со связываниями Web-сервисов, что позволяет перенаправлять запросы от одного провайдера сервиса к другому, опять же, без необходимости перезагрузки модуля в программу развертывания и развертывания его на сервере.


Другие статьи данной серии


Загрузка

ОписаниеИмяРазмер
Пример кодаpart3-downloads.zip52 KB

Ресурсы

Комментарии

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=228354
ArticleTitle=IBM WebSphere Developer Technical Journal: Создание Enterprise Service Bus с использованием WebSphere ESB - Часть 3
publish-date=06042007