Динамическая маршрутизация во время исполнения в WebSphere Enterprise Service Bus

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

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

Грэг Фларри, старший сотрудник технической службы, IBM India Software Lab Services and Solutions

19.04.2006

Узнайте, как реализовать динамическую маршрутизацию во время исполнения для Web-служб (SOAP/HTTP и SOAP/JMS) в IBM® WebSphere® Enterprise Service Bus Version 6.0.1.

Введение

Используя интеграцию IBM WebSphere Enterprise Service Bus (далее ESB), разработчики могут создавать посреднические программные компоненты для поддержки интеллектуального взаимодействия между инициаторами запросов служб и провайдерами служб. В Websphere ESB посреднические модули обеспечивают виртуализацию служб для изолирования инициаторов запросов от интерфейса, протокола и идентичности провайдеров.

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

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

В этой статье вы узнаете, как обойти текущие ограничения в ESB и реализовать динамическую маршрутизацию во время исполнения для Web-служб. Сначала мы опишем нормальную методику создания посреднического ESB-модуля, позволяющего только статическую маршрутизацию (называемую также маршрутизацией во время разработки), а затем покажем методику, используемую для реализации динамической маршрутизации во время исполнения. Этот подход использует пользовательский примитив посреднического модуля, который заменяет некоторые встроенные действия системы посредничества ESB. Обращаем ваше внимание на то, что вы должны использовать WebSphere ESB V6.0.1.1 (или WebSphere Process Server V6.0.1.1, который включает в себя ESB) для использования методики, показанной в этой статье.

Статическая маршрутизация для SOAP/HTTP

В этом разделе очень кратко показано, как создать посреднический ESB-модуль, поддерживающий только статическую маршрутизацию. Здесь предполагается, что вы имеете представление об общих принципах разработки посреднического ESB-модуля с использованием WebSphere Integration Developer. Обратитесь к статье "Начало работы с WebSphere Enterprise Service Bus и WebSphere Integration Developer", в которой представлено отличное введение в разработку посреднических модулей с использованием Integration Developer.

В листинге 1 показан WSDL для Web-службы (SOAP/HTTP), который выступает в роли реального провайдера; провайдер просто возвращает повторение (эхо) сложной структуры данных. Этот WSDL-файл размещается в проекте Business Integration Library, названном Resources, который облегчает обращение к WSDL-файлу в рабочей области Integration Developer.

                
     <?xml version="1.0" encoding="UTF-8"?>
 <wsdl:definitions targetNamespace="http://big.com" 
xmlns:impl="http://big.com"
xmlns:intf="http://big.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <wsdl:types>
  <schema targetNamespace="http://big.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:impl="http://big.com" xmlns:intf="http://big.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <complexType name="BEData">
    <sequence>
     <element name="one" nillable="true" type="xsd:string"/>
     <element name="two" nillable="true" type="xsd:string"/>
    </sequence>
   </complexType>
   <element name="echoResponse">
    <complexType>
     <sequence>
      <element name="echoReturn" nillable="true" type="impl:BEData"/>
     </sequence>
    </complexType>
   </element>
   <element name="echo">
    <complexType>
     <sequence>
      <element name="d" nillable="true" type="impl:BEData"/>
     </sequence>
    </complexType>
   </element>
  </schema>
 </wsdl:types>

 <wsdl:message name="echoRequest">
    <wsdl:part element="impl:echo" name="parameters"/>
 </wsdl:message>
 <wsdl:message name="echoResponse">
    <wsdl:part element="impl:echoResponse" name="parameters"/>
 </wsdl:message>

 <wsdl:portType name="BigEcho">
    <wsdl:operation name="echo">
       <wsdl:input message="impl:echoRequest" name="echoRequest"/>
       <wsdl:output message="impl:echoResponse" name="echoResponse"/>
    </wsdl:operation>
 </wsdl:portType>

 <wsdl:binding name="BigEchoSoapBinding" type="impl:BigEcho">
    <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="echo">
       <wsdlsoap:operation soapAction=""/>
       <wsdl:input name="echoRequest">
          <wsdlsoap:body use="literal"/>
       </wsdl:input>
       <wsdl:output name="echoResponse">
          <wsdlsoap:body use="literal"/>
       </wsdl:output>
    </wsdl:operation>
 </wsdl:binding>

 <wsdl:service name="BigEchoService">
    <wsdl:port binding="impl:BigEchoSoapBinding" name="BigEcho">
       <wsdlsoap:address location="http://localhost:9081/BigEcho/services/BigEcho"/>
    </wsdl:port>
 </wsdl:service>
</wsdl:definitions>
			

На рисунке 1 показан вид перспективы Business Integration после копирования WSDL-файла в проект Resources Library. Обратите внимание на присутствие порта (с названием BigEcho), интерфейса (тип WSDL-порта, также названный BigEcho) и типа данных (BEData), используемых в интерфейсе.

Создайте посреднический модуль с именем StaticRoute, который обращается к Resources Library в своих зависимостях, используя методику, рассмотренную в статье "Начало работы с WebSphere Enterprise Service Bus и WebSphere Integration Developer". StaticRoute имеет следующие компоненты: один import, один export и один mediation. На рисунке 2 показана диаграмма Integration Developer Assembly Diagram, которая является результатом:

• Создания посреднического модуля, содержащего посреднический компонент и автоматически названного Mediation1.
• Добавления посреднического модуля в компонент import, автоматически названного Import1, и в компонент export, автоматически названного Export1.
• Назначения интерфейса BigEcho компонентам Import1 и Export1.
• Генерирования информации о связывании Web-служб (HTTP) для Export1.
• Генерирования информации о связывании Web-служб (HTTP) для Import1.
• Выбора для Import1 файла BigEcho.wsdl для связывания.
• Подсоединения Export1 к Mediation1 и Mediation1 к Import1.

На рисунке 3 показана информация о связывании для Import1. Вы можете увидеть подтверждение информации из BigEcho WSDL в листинге 1.

На рисунке 4 показано отображение операций для посреднического модуля в редакторе Mediation Flow, которое в данном случае является очень простым: операция echo в export отображается в операцию echo в import.

На рисунке 5 показан простой маршрут запроса, где узел Input (представляющий запрос из Export1) подсоединен к узлу Callout (представляющему запрос к Import1). Такая схема передает входящий запрос непосредственно из export в import. Если необходима какая-нибудь дополнительная обработка, например, преобразование, посреднические примитивы для выполнения обработки будут подключаться между Input и Callout.

На рисунке 6 показан простой маршрут ответа, где узел CalloutResponse (представляющий ответ из Import1) подсоединен к узлу InputResponse (представляющему ответ для Import1). Такая схема передает входящий ответ непосредственно из import в export. Если необходима какая-нибудь дополнительная обработка, например, преобразование, посреднические примитивы для выполнения обработки будут подключаться между CalloutResponse и InputResponse.

После того, как посреднический модуль сохранен и развернут на тестовом сервере (либо ESB, либо WebSphere Process Server), вы можете протестировать этот посреднический модуль. Мы использовали простой Java™-клиент, который вызывает прокси, сгенерированный из созданного для Export1 WSDL-файла.

Для генерирования прокси из перспективы Business Integration выполните следующие действия:

1. Откройте вид Physical Resource и разверните проект StaticRoute, как показано на рисунке 7.
2. Нажмите правой кнопкой мыши на интерфейсе Export1_BigEchoHttp_Service.wsdl (который описывает посреднический модуль как Web-службу и автоматически генерируется при создании посреднического модуля) и выберите Web Services => Generate Client.
3. Поместите прокси-клиент в подходящий проект. Мы создали простой Java-клиент, который активизирует прокси, который, в свою очередь, активизирует посреднический модуль.
   
   Рисунок 7. Вид Physical resources StaticRoute
   
   
   

Используемая нами реализация службы BigEcho работает в той же тестовой среде, что и посреднический модуль, и отображает сообщение "+++ Got to BigEcho" в консоли тестовой среды, показывающее, что посреднический модуль активизировал службу BigEcho.

Динамическая маршрутизация для SOAP/HTTP

Подумайте, что должно произойти, если вы захотите изменить провайдера, используемого посредническим модулем StaticRoute. Самым очевидным решением является изменение адреса оконечной точки, используемой связыванием Import1 во время исполнения. К сожалению, текущая версия ESB не поддерживает такие действия. Вы могли бы изменить StaticRoute и добавить второй import, предоставляющий альтернативного провайдера; выбор используемого import мог бы быть сделан во время исполнения. Хотя добавление новых альтернатив во время разработки является нормальным для некоторых ситуаций, оно не будет работать во всех ситуациях, например, когда адрес оконечной точки реального провайдера берется из реестра служб, такого как UDDI.

Мы будем реализовывать форму динамической маршрутизации, используя посреднический модуль, содержащий пользовательские посреднические примитивы. В статье "Разработка пользовательских посреднических модулей для WebSphere Enterprise Service Bus" описаны основные технические приемы использования пользовательских посреднических примитивов. Мы создадим посреднический модуль DynamicRoute, который обращается к библиотеке Resources в своих зависимостях. DynamicRoute имеет один export, один import, и один mediation. После выполнения следующих действий:

• Создания посреднического модуля, содержащего посреднический компонент и автоматически названного Mediation1.
• Добавления в посреднический модуль компонента import, автоматически названного Import1, и компонента export, автоматически названного Export1.
• Назначение интерфейса BigEcho компонентам Import1 и Export1.
• Генерирования информации о связывании Web-служб (HTTP) для Export1.
• Генерирования информации о связывании Web-служб (HTTP) для Import1.
• Выбора для Import1 файла BigEcho.wsdl для связывания.
• Подсоединения Export1 к Mediation1 и Mediation1 к Import1.

Отображение операций для посреднического модуля DynamicRoute, опять же очень простое, является таким же, как и для StaticRoute (показано на рисунке 4). Простой маршрут ответа, где CalloutResponse подсоединен к InputResponse, тоже аналогичен маршруту для StaticRoute, показанному на рисунке 6. Значительные отличия имеются в маршруте запроса, где мы ввели пользовательский посреднический примитив (рисунок 8).

Мы вставили пользовательский посреднический примитив с названием Router и подсоединили узел Input к его входу, как и ожидалось. Однако обратите внимание на то, что выход Router подсоединен к узлу InputResponse, а не к Callout. Это означает, что запрос направляется в Router, но не проходит через него в Import1. Вместо этого Router должен активизировать Web-службу, представленную компонентом Import1. Более того, поскольку Import1 не используется, ответ не может пройти назад через Import1, то есть, маршрут ответов не используется. Вместо этого Router посылает принятый им ответ в Export1 через узел InputResponse.

1. Выберите посреднический примитив Router и отобразите его свойства.
2. Перейдите на закладку Details и нажмите кнопку Define.
3. В диалоговом окне Define Custom Mediation мастера Define Custom Mediation нажмите кнопку Next.
4. В диалоговом окне Specify Message Types убедитесь в том, что Message Root установлен в / и нажмите кнопку Next. Использование / в качестве корня сообщений позволяет посредническому примитиву видеть Service Message Object полностью, включая любой контекст и заголовки.
5. В диалоговом окне Create a new interface нажмите кнопку Next.
6. В диалоговом окне Generate Java Implementation нажмите кнопку Finish и сохраните маршрут посреднического модуля.
7. После сохранения маршрута посреднического модуля вернитесь к Assembly Diagram и сохраните ее.
8. Нажмите правой кнопкой мыши на Mediation1 и выберите Merge Implementation.
9. Нажмите кнопку OK в появившемся диалоговом окне для объединения реализации. Вы увидите мастер Merge Implementation, показанный на рисунке 9.
   
   Рисунок 9. Мастер Merge Implementation
   
   
   
10. Убедитесь в том, что флажок под Create Java Component отмечен, и нажмите кнопку OK.
11. Отображается редактор Mediation Flow. Вернитесь к Assembly Diagram и сохраните посреднический модуль.
12. В главном меню выберите Project => Clean.
13. Нажмите кнопку OK в появившемся диалоговом окне. Посреднический модуль в Assembly Diagram должен теперь выглядеть примерно так, как показано на рисунке 10.
    
    Рисунок 10. Посреднический модуль с пользовательским посредническим примитивом
    
    
    
14. CustomMediation1Partner представляет пользовательский посреднический примитив Router. Теперь вы должны подсоединить CustomMediation1Partner для Import. В первом диалоговом окне Add Wire нажмите кнопку Yes для создания подходящего интерфейса.
15. Во втором диалоговом окне Add Wire, показанном на рисунке 11, нажмите кнопку No. Это упрощает работу маршрутизатора путем исключения отображения между Java-объектами и Service Message Objects.
    
    Рисунок 11. Диалоговое окно Add Wire
    
    
    
16. Assembly Diagram должна выглядеть примерно так, как показано на рисунке 12. Сохраните посреднический модуль.

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

1. Вернитесь к редактору Mediation Flow.
2. Выберите примитив Router и отобразите его свойства.
3. Перейдите на закладку Implementation.
4. Нажмите Open Java Editor и кнопку OK в появившемся диалоговом окне.
5. Найдите метод execute().
6. Теперь вы можете ввести код, позволяющий посредническому примитиву Router активизировать Web-службу, представленную компонентом Import1. Он использует среду Service Component Architecture (SCA), на которой основана ESB. В листинге 2 показан необходимый исходный код. Вы должны понимать, что входной параметр DataObject (input1) является целым SMO, следовательно, посреднический примитив может видеть контекст и заголовки, также как и тело. Аналогично, возвращаемый DataObject тоже должен быть целым SMO. Естественно, входной параметр содержит входное сообщение (или полезную нагрузку) от оригинального инициатора запроса, тогда как возвращаемый параметр содержит ответ от провайдера.
   
   Листинг 2. Активизация службы в пользовательском посредническом примитиве со статическим адресом
   

   public DataObject execute(DataObject input1) { System.out.println("... In Router mediation primitive"); // (1) Создать ссылку на оконечную точку EndpointReference eRef = EndpointReferenceFactory.INSTANCE .createEndpointReference(); eRef.setAddress("http://localhost:9081/BigEcho/services/BigEcho"); // (2) ) активизировать службу и извлечь полезную нагрузку ответа Service echoService = (Service) ServiceManager.INSTANCE.getService("BigEchoPartner", eRef); DataObject request = input1.getDataObject("body/echo"); DataObject response = (DataObject) echoService.invoke("echo", request); DataObject responseBody = response.getDataObject("echoReturn"); // (3) создать ответное сообщение и ответ BOFactory boFactory = (BOFactory) ServiceManager.INSTANCE .locateService("com/ibm/websphere/bo/BOFactory"); DataObject message = boFactory.createByMessage("http://big.com", "echoResponse"); DataObject myRes = boFactory.createByElement("http://big.com", "echoResponse"); // (4) добавить ответ и выйти myRes.setDataObject("echoReturn", responseBody); message.setDataObject("parameters", myRes); input1.setDataObject("body", theMes); return input1; }

   
   
   Фрагмент кода (1) в листинге 2 создает ссылку на оконечную точку. Адрес в этой ссылке жестко закодирован в службу BigEcho, как показано в WSDL-файле в листинге 1.

   Фрагмент кода (2) получает прокси для службы BigEcho по адресу в ссылке оконечной службы. Обратите внимание на то, что на рисунке 4 компонент import представляется символом, помеченным BigEchoPartner. Символическое имя компонента import необходимо для выполнения операции поиска. Соединение между CustomMediation1Partner и Import1 позволяет компоненту Router успешно использовать символическое имя в операции поиска. Затем фрагмент извлекает полезную нагрузку сообщения запроса. Поскольку переданное сообщение является целым SMO, XPath-выражение body/echo используется для доступа к полезной нагрузке запроса. Затем фрагмент активизирует службу, используя полезную нагрузку. И, наконец, он извлекает полезную нагрузку.

   Фрагмент кода (3) создает ответное сообщение и ответ из соответствующих элементов, определенных WSDL-файлом в листинге 1.

   Наконец, фрагмент кода (4) вставляет полезную нагрузку из оригинального ответа в структуру ответного сообщения. Это позволяет передавать любые заголовки или контекст через посреднический примитив Router. Затем фрагмент возвращает ответ, который передается в узел InputResponse, как описано выше.

7. Сохраните код, приведенный в листинге 2.
8. Сохраните маршрут посреднического модуля и посреднический модуль и опять выберите Project => Clean.
9. Разверните посреднический модуль.
10. Для тестирования посреднического модуля DynamicRoute вы можете использовать тот же самый клиент, который вы создавали для тестирования StaticRoute, просто изменив адрес оконечной точки, используемый прокси в клиенте, так чтобы он указывал на DynamicRoute вместо StaticRoute. Например, если адресом оконечной точки для StaticRoute является http://localhost:9080/StaticRouteWeb/sca/Export1, то адрес оконечной точки для DynamicRoute равен http://localhost:9080/DynamicRouteWeb/sca/Export1. Запустите тестовый клиент. Если вы проверите консоль сервера, вы увидите, что были активизированы посреднический модуль и служба BigEcho, как показано в листинге 3.
    
    Листинг 3. Информация, отображаемая в консоли после активизации посреднического модуля и службы
    

    SystemOut O ... in Router mediation primitive SystemOut O +++ Got to BigEcho.

    
    
    

Усовершенствованная динамическая маршрутизация для SOAP/HTTP

Описанный выше подход предполагает, что реальный адрес оконечной точки извлекается каким-то образом в том же самом посредническом примитиве, который использует адрес оконечной точки. Однако это не есть настоящий повторно используемый подход. Давайте рассмотрим более пригодный для повторного использования подход к динамической маршрутизации. Подход использует транзитный контекст SMO, который является механизмом взаимодействия между посредническими примитивами. Более подробную информацию можно найти в WebSphere Enterprise Service Bus Information Center. Мы введем еще один посреднический примитив в маршрут запроса, который устанавливает желаемый адрес оконечной точки в транзитном контексте. Мы также изменим посреднический примитив Router для извлечения адреса из транзитного контекста и вызова провайдера службы по этому адресу.

1. Сначала создайте новый бизнес-объект с названием EPR в библиотеке Resources, как показано на рисунке 13. Этот бизнес-объект будет определять используемый транзитный контекст. Бизнес-объект EPR содержит адрес из одного именованного поля, и мы используем пространство имен по умолчанию. В практической реализации определение структуры может основываться, например, на спецификации WS-Addressing.
   
   Рисунок 13. Транзитный бизнес-объект
   
   
   
2. Разрешите транзитный контекст в маршруте запроса, открыв редактор Mediation Flow для посреднического модуля DynamicRoute.
3. Перейдите на закладку Request flow.
4. Выберите Input node и откройте его свойства.
5. Перейдите на закладку Details. Вы увидите что-то похожее на рисунок 14.
6. Нажмите кнопку Browse справа от поля Transient context.
7. В диалоговом окне Data Type Selection выберите EPR и нажмите кнопку OK. Закладка Details для узла Input теперь должна отображаться с установленным транзитным контекстом, как показано на рисунке 14.
   
   Figure 14. Установка транзитного контекста
   
   
   
8. Перезапустите проект DynamicRoute для того, чтобы механизм транзитного контекста заработал.
9. Затем добавьте еще один пользовательский посреднический примитив, который устанавливает контекст. В редакторе Mediation Flow для DynamicRoute удалите соединение между узлом Input и Router.
10. Добавьте новый пользовательский посреднический примитив и назовите его Setter.
11. Соедините узел Input с входом Setter и выход Setter - с входом Router.
12. Откройте свойства Setter, перейдите на закладку Detail и нажмите Define.
13. Так же как и при определении Router, убедитесь в том, что корень установлен в /, затем нажмите кнопку Finish. Маршрут запроса должен теперь выглядеть так, как показано на рисунке 15.
    
    Рисунок 15. Маршрут запросов в DynamicRoute с узлом Setter
    
    
    
14. Сохраните маршрут посреднического модуля, вернитесь к Assembly Diagram и объедините реализацию, как описано выше.
15. Очистите посреднический модуль. Вы должны увидеть что-то похожее на рисунок 16. CustomMediation2Partner представляет пользовательский посреднический примитив Setter.
    
    Рисунок 16. Dynamic Route с установщиком и маршрутизатором
    
    
    
16. Теперь вы должны создать реализацию для пользовательского посреднического примитива Setter, который помещает желаемый адрес оконечной точки в транзитный контекст, передаваемый в Setter. В листинге 4 приведен необходимый исходный код. Фрагмент кода (1) просто устанавливает адрес оконечной точки в желаемое значение. XPath-выражение context/transient/address отражает тот факт, что SMO имеет потомка с названием context, этот context имеет потомка с названием transient, а этот transient, поскольку мы объявили, что transient имеет определенную EPR структуру, имеет потомка с названием address, который содержит желаемый адрес оконечной точки. В практической ситуации адрес устанавливался бы, например, используя информацию, полученную из реестра служб.
    
    Листинг 4. Установка транзитного контекста для поддержки динамической маршрутизации
    

    public DataObject execute(DataObject input1) { System.out.println("... In Setter mediation primitive"); // (1) установить EPR-адрес input1.setString("context/transient/address", "http://localhost:9081/BigEcho/services/BigEcho"); return input1; }

    
    
    
17. Измените посреднический примитив Router для извлечения желаемого адреса оконечной точки из транзитного контекста и используйте его в качестве адреса оконечной точки для активизации службы. В листинге 5 приведены необходимые изменения в коде статической маршрутизации для пользовательского посреднического примитива Router:
    
    Листинг 5. Активизация службы в пользовательском посредническом примитиве с динамическим адресом
    

    public DataObject execute(DataObject input1) { System.out.println("... In Router mediation primitive"); // (0) извлечь адрес String address = input1.getString("context/transient/address"); // (1') Создать ссылку на оконечную точку EndpointReference eRef = EndpointReferenceFactory.INSTANCE .createEndpointReference(); eRef.setAddress(address); // (2) активизировать службу и извлечь тело ответа ... // (3) создать ответное сообщение и добавить ответ ... // (4) добавить ответ и выйти ... }

    
    
    

    Фрагмент кода (0), добавленный к статической форме, приведенной в листинге 2, извлекает желаемый адрес оконечной точки из транзитного контекста; XPath-выражение идентично используемому для вставки адреса оконечной точки в Setter. Фрагмент кода (1) создает ссылку на оконечную точку, используя адрес, извлеченный из транзитного контекста. Фрагменты кода с (2) до (4) идентичны фрагментам из листинга 2.

18. Если вы запустите тестовый клиент снова, то увидите примерно такую информацию, которая показана в листинге 6. Вы увидите, что посреднический примитив Setter устанавливает адрес желаемой оконечной точки, а посреднический примитив Router использует его для активизации службы BigEcho.
    
    Листинг 6. Выводимая в консоли информация после активизации службы с усовершенствованным посредническим модулем
    

    SystemOut O ... In Setter mediation primitive SystemOut O ... In Router mediation primitive SystemOut O +++ Got to BigEcho.

    
    
    

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

Дополнительное связывание

Вы узнали, как разрешить динамическую маршрутизацию для SOAP/HTTP связывания Web-служб. Вы можете также использовать эту же методику и для SOAP/JMS связывания Web-служб. Однако есть несколько предостережений. Во-первых, рассмотрим SCA-модуль для SOAP/JMS службы, состоящий из компонента export и бизнес-компонента. Мы определили, что имя очереди, используемой для экспорта, и имя WSDL-файла, сгенерированного системой Integration Developer, выводятся полностью из имени интерфейса и имени компонента export в модуле. Это означает, что когда вы хотите создать два модуля с одинаковым интерфейсом, необходимо дать компонентам export различные имена, иначе имена очередей и WSDL-файлов будут конфликтовать, что приведет к нежелательным последствиям.

Во-вторых, мы определили, что WSDL-файл (или Web Service Port), связанный с компонентом import в модуле, должен быть доступен этому модулю. Мы просто скопировали информацию в библиотеку Resources, на которую ссылается модуль.

Наконец, взгляните на листинг 7, который содержит элемент service из автоматически сгенерированного WSDL для модуля SOAP/JMS, содержащего компонент export с именем JS1Export1, который использует тип порта BigEcho из листинга 1. Обратите внимание на то, что атрибут location для элемента soap:address в элементе wsdl:port элемента wsdl:service содержит строку URI, перечисляющую значения для имени очереди (адресат), имени фабрики соединений и имени порта. Строка & используется в качестве разделителя между этими значениями. Строка URI, используемая в методе EndpointReference.setAddress() (см. листинги 2 и 5), должна использовать & в качестве разделителя.

                
<wsdl:service name="JS1Export1_BigEchoJmsService">
  <wsdl:port name="JS1Export1_BigEchoJmsPort"
	binding="this:JS1Export1_BigEchoJmsBinding">
    <soap:address 
	  location=
		"jms:/queue?destination=jms/JS1Export1
		&connectionFactory=jms/JS1Export1QCF
		&targetService=JS1Export1_BigEchoJmsPort"
    />
  </wsdl:port>
</wsdl:service>
			

Методика работает и для SCA-связываний. Для SCA-связываний не генерируются WSDL-файлы. Обратите внимание на то, что формат адреса, необходимого для создания ссылки на оконечную точку, имеет следующий вид: sca://<project name>/<export name>.

Заключение

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

Благодарности

Автор хотел бы поблагодарить Роба Фиппена (Rob Phippen) за долгие часы обсуждения динамической маршрутизации в WebSphere ESB, которые привели к появлению методики, описанной в данной статье.

Ресурсы

• Оригинал статьи "Dynamic routing at runtime in WebSphere Enterprise Service Bus".
  
  
• Страница продукта WebSphere Enterprise Service Bus: полная информация о продукте.
  
  
• "Начало работы с WebSphere Enterprise Service Bus и WebSphere Integration Developer": Узнайте больше о сервере WebSphere Enterprise Service Bus и сопутствующем ему инструментарии WebSphere Integration Developer. В данной статье описано, как разрабатывать маршрут в посреднике для элементарной Web-службы. Разработайте промежуточный маршрут для соединения с этой службой с более сложной логикой маршрутизации, обеспечиваемой несколькими предварительно скомпонованными посредническими функциями, предлагаемыми инструментарием; разверните и протестируйте эти маршруты, используя как тестовые возможности инструментария, так и автономное JSP-приложение.
  
  
• "Разработка пользовательских посреднических модулей для WebSphere Enterprise Service Bus": В данной статье представлено введение в использование пользовательских посреднических модулей, использующих среду WebSphere Integration Developer V6 для WebSphere Enterprise Service Bus V6. В данной статье приведены также алгоритмы разработки трех типов пользовательских посреднических модулей в простом сценарии.
  
  
• Спецификации: Service Component Architecture (SCA) и Service Data Objects (SDO).
  
  
• WebSphere Enterprise Service Bus Information Center: Документация по продукту.
  
  
• Зоны developerWorks SOA и Web-служб: Технические ресурсы и загружаемые файлы для IBM SOA и Web-служб.
  
  
• Зона developerWorks WebSphere Web Services: Технические ресурсы и загружаемые файлы для IBM WebSphere Web-служб.

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

• Подключайтесь к сообществу developerWorks, участвуя в блогах developerWorks.
  
  

Об авторе

		Грэг Фларри (Greg Flurry) является старшим сотрудником технической службы в группе IBM Enterprise Integration Solutions. В сферу его ответственности входит работа с пользователями по теме ориентированных на службы решений и продвижение соответствующих продуктов IBM.

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

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

В начало